Quality RTOS & Embedded Software

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




Loading

RL78 portYIELD_FROM_ISR bug in version 7.1.1

Posted by willeybear on August 10, 2012
I discovered a bug in the RL78 port of version 7.1.1 when using portYIELD_FROM_ISR(). The symptom was that when portYIELD_FROM_ISR() was called and a context switch occurred, the stack frame that was active when the interrupt occurred was corrupted.

It turns out that vTaskSwitchContext() will corrupt the stack if it is not surrounded by a SAVE_CONTEXT/RESTORE_CONTEXT pair. The fix is to change
#define portYIELD_FROM_ISR( xHigherPriorityTaskWoken ) if (xHigherPriorityTaskWoken)vTaskSwitchContext()

to
#define portYIELD_FROM_ISR( xHigherPriorityTaskWoken ) if (xHigherPriorityTaskWoken) vPortYield()

in the file portmacro.h
to

RE: RL78 portYIELD_FROM_ISR bug in version 7.1.1

Posted by Richard on August 10, 2012
Thanks for your feedback. I will have to try and replicate this to see why testing has not picked it up (and then add a new test). Any additional information would be appreciated - for example, which byte on the stack gets clobbered.

Regards.

RE: RL78 portYIELD_FROM_ISR bug in version 7.1.1

Posted by willeybear on August 10, 2012
I haven't spent enough time in the details of the OS to know what bytes specifically get clobbered. The way I detected the error is that vApplicationStackOverflowHook() gets called and all the stack pointers in one or more TCBs are hosed.

RE: RL78 portYIELD_FROM_ISR bug in version 7.1.1

Posted by Richard on August 10, 2012
Could it possibly be a genuine stack overflow? If the stack has overflowed then it is likely that the stack will look corrupt.

Regards.

RE: RL78 portYIELD_FROM_ISR bug in version 7.1.1

Posted by willeybear on August 10, 2012
No, the hosed stack pointers are pointing to a completely different chunk of memory than where they were pointing before the "overflow" is detected. When I look at the areas where the stacks actually reside all of them have plenty of untouched space.

RE: RL78 portYIELD_FROM_ISR bug in version 7.1.1

Posted by Richard on August 14, 2012
I'm just looking at this now:

“It turns out that vTaskSwitchContext() will corrupt the stack if it is not surrounded by a SAVE_CONTEXT/RESTORE_CONTEXT pair. ”


According to the documentation page for the port, if portYIELD_FROM_ISR() is to be used, then the ISR must have an assembly file wrapper that calls SAVE_CONTEXT/RESTORE_CONTEXT. So far, from looking at this, I agree that attempting to call portYIELD_FROM_ISR() without the wrapper will corrupt the stack which is why it is not valid to do that.

“#define portYIELD_FROM_ISR( xHigherPriorityTaskWoken ) if (xHigherPriorityTaskWoken) vPortYield()”


That will cause a BRK instruction to be executed inside your ISR. I'm not sure if that is dangerous, but I would definitely say it is undesirable for reasons of efficiency.

Please let me know if you are seeing an issue when portYIELD_FROM_ISR() is used as intended, and, if so, provide a test case to replicate the issue so I can investigate further.

Regards.


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




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

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

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