Hi
I’m working on NXP2365, using freertos V5.3.0
The porting i have, doesn’t allow to use nesting ISRs.
But i need them. My problem is the following: i have 2 ISRs, and both call sendToQueueFromISR, so both have the ASM wrapper necessary for RTOS.
I need that one can be interrupted by the other (nesting), but i don’t know how. is there a solution already done for my porting? thank in advance
Piero

I found this item on forum
https://sourceforge.net/projects/freertos/forums/forum/382005/topic/4800305 but i didn’t understand how i can use these macros in my arm7 porting bye
Piero

When an ISR with RTOS wrapper is called for an IRQ, all registers are stored in current task stack.
Also, ARM7 switch to IRQ stack (ARM7 has its own stack  for IRQ). This is the standerad wrapper: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; wrapper isr functionfor FREERTOS macro definition
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; wrapISR MACRO function portSAVE_CONTEXT ; Save the context of the current task. bl function ; Call the ISR routine. portRESTORE_CONTEXT ; Restore the context of the current task –
; which may be different to the task that
; was interrupted.
                                                 
ENDM Follow Brent idea, to have ISR that can be nested, i should need only this special wrapper: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; wrapper isr functionfor FREERTOS macro definition
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; wrapISR MACRO function portSAVE_CONTEXT ; Save the context of the current task. ISR_ENABLE_NEST() ;enable other IRQ to nest bl function ; Call the ISR routine. ISR_DISABLE_NEST() ; disable nesting portRESTORE_CONTEXT ; Restore the context of the current task –
; which may be different to the task that
; was interrupted.
                                                 
ENDM Any comment about this solution? i wants to review it with people on forum before try it. thanks for feedbacks
Piero

Hi First, after some research, i think the solution proposed above from me is wrong.
Second, Richard Barry said that there is no ARM7 RTOS that use nested interrupt.
Instead i found that uCOS, has this feature: i have a document that explain this, and searching inside the uCOS code, i found comments in kernel functions that shows that nested interrupt are used. Richard, do you have never have a look to that code? Is it really far from FREERTOS kernel or o a similar idea can be included? I work with FREERTOS with 2 different ports, ARM7 and PIC32, and it is very strange that with one (PIC32) i can nest IRQ (and i did it, very useful for our very complex application) and with the other one (ARM7) i cannot: i’d like to to work in the same way for both ports. Richard, Can i aspect something in the near future about nested irq for ARM7? Thanks in advance
Piero

Richard Barry said that there is no ARM7 RTOS that use nested interrupt

If you are going to make statements like that, please provide a reference.  I do not recall ever having said such a thing, and, if I did somewhere, would not agree with it now.  I do recall saying that even ARM’s own RTOS does not support it, but then I am only going on what I have been told, and I have not used it myself.

Richard, Can i aspect something in the near future about nested irq for ARM7?

With my current massive work load, and the move to ARM Cortex-M devices, it is unlikely there would be any major developments on ARM7 devices.  There may however be a time when an ARM9 port is developed further, and the changes to that are easy to pass into the ARM7 world too.  If you have a port that supports interrupt nesting, then I would definitely be interested and encourage you to post it to the FreeRTOS Interactive site. Regards

For the record, I have just deleted your post that linked to a document that describes the internal workings of a competitive product.  For legal reasons, I cannot take responsibility for publishing my own kernel implementation while simultaneously hosting links to competitors implementations. If you wish to draw other peoples attention to the document, please host the link yourself, then here you can post a link to your own page. Thank you for your understanding.  I do not take deleting posts lightly. Regards.

I do recall saying that even ARM’s own RTOS does not support it, but then I am only going on what I have been told, and I have not used it myself.

CORRECT!  i found your post and i read it: MY MISTAKE, sorry!!

If you have a port that supports interrupt nesting, then I would definitely be interested and encourage you to post it to the FreeRTOS Interactive site

I tried something but i failed.
I have only a workaround, i modified a little the kernel to allow to my self to use SWI (reserved for RTSO tick) also for call functions inside SWI ISR, just using a macro that set a global variable (it is an index that allow to choose function) and call asm(SWI). With this workaround, i’m using FIQ (even managing multiple sources in ISR) to nest IRQs, and i use the help of my custom SWI to allow  that something in FIQ send a message to task (custom routine just use sendqueueInISR according with global variable) SWI has low priority than IRQ, so message will be sent AFTER the end of current IRQ, so FIQ ISR could be a very fast routine with a very low latency, will have the ability to send (even postponed) a message to tasks, and IRQ routines nested will not delayed for a long time (send message from ISR waste time that could be too big for some IRQ with strict time constrains ) Let me know if could be useful to post this idea (i’m very busy at work too, so it will not be sooner) Also, i have a contribution to implement above RTOS shared buffers, where many consumer tasks can use big data (buffers) from a producer task, forward pieces to other tasks, exchanging small info using queues, and without lock producer during buffer elaboration (i didn’t use semaphores)
Again, Let me know if could be useful to post this idea (i’m very busy at work too, so it will not be sooner: also i should document it very well) Bye
Piero

Thank you for your understanding.  I do not take deleting posts lightly.

I understood. Sorry Bye
Piero