FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [March 2008 Threads] Question about LPC21xx portSAVE_CONTEXT()Posted by JC on March 6, 2008 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
RE: Question about LPC21xx portSAVE_CONTEXT()Posted by Dave on March 6, 2008 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).
RE: Question about LPC21xx portSAVE_CONTEXT()Posted by JC on March 6, 2008 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
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|