2019-11-03 11:30 PM
Hi,
I'm using STM32F412 module with freeRTOS (CMSIS_V2) middleware in STCube IDE.
Can I achieve below functionality as a stack overflow feature using STM32 MPU (Memory Protection Unit)?
1. Detect corruption of a function return address before the function returns to that address. I.e., the corrupted return address will not be used and appropriate remediation action will be performed instead, such as rebooting the product into a good known state.
2. Detect corruption of other variables in the stack frame, again before the function completes.
3. Be present in functions that have one or more arrays declared in the functions stack frame (this includes third party library code within the same run-time environment as the application code).
2019-11-04 12:25 AM
AFAIK, FreeRTOS has a stack-check feature you can use/configure.
But on a MCU without a MMU (and separate address spaces for tasks), there is no bulletproof protection against stack overflow.
With a downstream check, you can detect possible overwrite issues, but destroyed return addresses will most probably land you in the hardfault handler.
> Can I achieve below functionality as a stack overflow feature using STM32 MPU (Memory Protection Unit)?
I think not.
I believe you think about one MPU region per task/stack. With the requirement of a 2^n region size and an identical region alignment, it will be difficult to make ends meet with the quite limited RAM resources.
> 2. Detect corruption of other variables in the stack frame, again before the function completes.
The stack check of RTOSs use to do only "after the fact" detection.
They fill the task stacks with a specific pattern, and check the last word after the task has finished.
BTW, you can still produce other stack-related bugs. Like using a stack-based buffer in one task, and referring to this buffer in another, long after it has expired ...
2019-11-05 08:54 PM
Hi Ozone,
Thanks for your quick response.
I have few queries,
2019-11-05 11:17 PM
I did not work much with FreeRTOS, but have some experience with OSEK/VDX.
The stack check is done after a task has finished - you know something happened, but not what happened, and where. The default reaction is to stop the device, this is an error not supposed to occur. The RTOS kernel assumes you (statically) assigned stacks of proper size.
Only if the stack overflow affects a return address you will end up in a fault handler immediately. But stack overflows tend to produce varying error pattern.
I don't know if FreeRTOS supports any stack check involving an MPU, and I never tried those.
Our applications use the the MPU for safety-related features (preventing non-safe code from accessing safe data).
Perhaps put your question on the FreeRTOS forum, those are the experts.
BTW, we had a tricky stack-related bug with this OSEK application recently.
One task passed a stack buffer pointer to a function, which got used (written to) in the context of another task. While still a valid stack address, it randomly killed (overwrote) values on the stack of the caller task, causing a variety of symptoms on crashes. No MPU would have helped in this case.
2019-11-06 01:10 AM
Thanks for reply.