A task calls several nested functions, which have inside some arrays defined. That doesn’t exceed stack size, don’t even come close, however the task crashes with some memory corruption. When looking at the crash data, the variables show in a different memory segment than they should be. Task stack starts placing nested variables and then as if it hits some threshold inside FreeRTOS. So, question is, what can there be inside defined besides stack size of a task? Last offset from the end address of the stack that I could see was around 84B. Code example attached.
For the sake of completeness which memory manager do you use ?
Better check the return status when creating FreeRTOS resources like tasks.
Could you also try using static task memory (to exclude heap issues) ?
Are there any other tasks running ?
1 Like
What platform/target/compiler are you using?
Your functions may likely be inlined, resulting in a single function body. Some compilers don’t handle shadowed variable declarations correctly. What happens if you rename your variables such that no shadowed declarations occur? Note that since there is not a single write to your locals in your function call chain, a memory corruption can not be initiated by anything your functions do!
1 Like
- Memory manager is heap_4.
- Task creation returns pdPASS, so all’s good.
- Static task memory doesn’t help(that was the initial implementation, and this is another try).
- No other processes are running.
- Platform is some TI chip armv7 based, sorry can’t go into more details.
- Renaming variables doesn’t help (there was no shadowing, I verified in asm file, but I tested renaming to be sure).
Hey @erabotnikov
I noticed you said you’re using a TI ARMv7 Based chip. Are you using the onboard MPU? Asking since your task creation is using the portPRIVILEGE_BIT definition, but isn’t allocating any other MPU Regions as part of its creation. Just wondering since it’s potentially possible that if you’re using the MPU without correctly setting regions these values may be getting cache’d out in-between context switches.
I’d also recommend making these arrays volatile for now, just to try and minimize the chance the compiler optimizes out their usage.
Lastly, since you’re using multiplication and an ARM CPU I’d make sure your config for configENABLE_FPU is correct, and that you are calling whatever port-specific function, such as vPortTaskUsesFPU() on the ARM_CRx_No_GIC Port, that marks that the task is using the FPU, to ensure these registers are not clobbered when context swaps occur.
1 Like
Hi @skptak , thank you for the answer. The MPU is initialized… I think if MPU was causing a trouble then it would be seen in some other logic as well as the app is pretty complicated, but of course there could be a chance that this usage triggers smth with MPU, will check it, thanks.
Volatile arrays didn’t help.
Multiplication is only for the sake of compiler not making optimizations. Now I removed it and put volatile for all arrays - still crashes. Well will need to dig through stack management apparently. Thank you!
Could it be an alignment problem? One of your arrays is oddly aligned, so when the compiler tries to convert a character to an int for the multiplication, it may hit an alignment fault on yome mcus.
2 Likes
Also double check the linker script is correct for your memory layout.
2 Likes
Just for testing, can you try increasing the size of task stack - just multiply it by 4 and see if you still get the fault.
Can you share this crash data? Which fault are you hitting?
1 Like
@aggarg Stack increase doesn’t help ( tried *2)
The error is the regular data access fail just as some unalowed access is made. The debugger shows the arrays are not in the range of the stack… And even not in this memory anymore. Now I think maybe it can also be a compiler issue, beyond freertos.
have you excluded the alignment theory?
1 Like
@RAc I started from it, but seemed like it shouldn’t be an issue and now I’m back to it. It’s some combination of alignment with putting it on stack of the task.
My personal thoughts is to look at the assembly code generated for the functions, and spot if/where the compiler has made an error.
I can’t see how FreeRTOS could be doing anything here to cause the problem.
1 Like
I tried this code on a Cortex-M7 and it works correctly - so the problem is not likely with the code. Look at the generated assembly as suggested by @richard-damon. Also try to step through the assembly and try to find the faulting instruction as it may provide some hint.
1 Like
@erabotnikov I’m assuming that you’re using either the CM3 MPU Port or the CM4 MPU Port if you’re using an MPU port with FreeRTOS. Could you try creating the task using the xTaskCreateRestrictedStatic() API?
Your issue sounds kind of like an MPU related issue I had seen once when using an MPU region that was incorrectly aligned? Where I’m just wondering if by using a statically declared task stack that is correctly MPU aligned if you still see this fault. Lastly, have you ensured that you’re able to step into these functions? It’s possible that you’re actually hitting an MPU fault when trying to execute the code, not necessarily when you’re pushing something to your stack
1 Like
Thank you all, the issue has been found and it was NOT in FreeRTOS code, but in additional proprietary alignment handling. Thank you for the contribution!
Thank you for reporting back!
1 Like