Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


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?


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,

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

Version 10.1.0 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner