Question about LPC21xx portSAVE_CONTEXT()

I’ve got all my vectored IRQs using the new portSAVE_CONTEXT/handler/portRESTORE_CONTEXT schema.  It all works well. Now I’ve got an FIQ, and it needs to occasionally queue an item via xQueueSendFromISR.  This means the FIQ needs to use the same schema.  It’s like the Hindenburg II. I reduced the FIQ interrupt handling code to just toggling a pin at a 1ms rate, and writing the T1 interrupt register to clear the interrupt.  Still flames out.  Specified my handler as __attribute__ ((interrupt ("FIQ"))), works great.  Reverted to the save/restore context, changed the timer to a vectored interrupt, works great. As near as I can tell/guess, the portSAVE_CONTEXT and/or portRESTORE_CONTEXT functions do not like being interrupted and followed by another portSAVE_CONTEXT call.  Vectored interrupts don’t interrupt each other, so this issue would never arise.  When the abort occurs, it appears to usually be at the STMDB  LR,{R0-LR}^ instruction in portSAVE_CONTEXT. Have I just rediscovered what everyone else already knows?  And is there an elegant solution to this problem? Thanks, --jc

Question about LPC21xx portSAVE_CONTEXT()

Interrupts that use the api have to all run at the same priority as the default code has it. Supporting nesting in this manner is clumsy on an ARM7 but very easy on an M3 so you best bet is to change to an M3 ;-) This is a weakness of the ARM7 compared to true embedded processors. Can you write your FIQ code so as not to use the api? This is how most motor control aps use FreeRTOS. Did you see http://www.freertos.org/FAQISR.html#Nest (which I think is a bit out of date as the fujitsu port also has nesting by default).

Question about LPC21xx portSAVE_CONTEXT()

Sorry, no changing to the M3 at this point :) I’m sure I can manage something for the FIQ to communicate what it needs to.  Using the API is just more elegant.  The points at which it needs to notify are not critical, but getting into the FIQ and doing what it needs to do is. While the points in the FAQ you reference are valid, the stack depth and such are not an issue for this application.  Got room to spare, for a change. Thanks for info, --jc