Stack memory corruption when in Idle task

Hi all,
I’m chasing a weird issue and could need some help.
I’m using FreeRTOS 9.0.0 on a i.mx7ulp using IAR. I have two tasks and one sw-timer running. Task-Stack sizes are suffently big and also the debugger shows that there is enough stack-space left. Also I’m quite confident that I didn’t mess up the priorites (Idle: 0; Timer: 9; Task1: 6; Task2: 7).

But a part of my Application stack gets overwritten with a sequence of 'A5’s. I would normaly expect to only see this inside the heap, where the task-stacks are located.
According to the memory breakpoint this happens, when xTaskIncrementTick is called.

Does anybody has an idea whats happening here?

Which heap memory allocator are you using? Also, which stack is getting corrupted - the interrupt stack or one of the task stacks?

The task stacks get filled with 0xA5 when they are created, and the stack memory comes from the heap (assuming the tasks are allocated dynamically), so you would expect to see 0xA5 in the heap as you say. Any registers that are not filled with special values, such as a stack pointer value, are also likely to also get filled with 0xA5 when a task runs for the first time because the registers are popped from the task’s stack which has not been used yet (so still contains the initialilsation value of 0xA5). When an interrupt occurs a subset of those registers get pushed to the interrupt stack, and if the registers have still not been used and still contain 0xA5 you can then legitimately get those 0xA5 values in the interrupt stack.

Is your interrupt stack large enough - it’s size is likely set in the linker script or by constants in the C startup code.

Am I correctly reading the sequence:

  1. A memory location is not set to 0xA5 at some point.
  2. A memory breakpoint is set on that location to break whenever the content of the memory location is changed to 0xA5.
  3. When the memory breakpoint is hit, the call stack shows xTaskIncrementTick.

If the above is correct, probably interrupt stack is overflowing.

Another thing to watch out for is that main stack is reclaimed when the scheduler is started. Is the memory which is getting corrupted on the main stack (i.e. created in main before starting the scheduler)?


Thanks for your responses!

@rtel I’m using static memory allocation with heap_4.c. It’s the main application stack that is corrupted (see below).
@aggarg Yes this sequence is right.

I think I’m starting to see the issue but I don’t really know how to resolve it:
I’m not creating the tasks directly in the main but instead have them embedded into C++ objects. These objects also have some other member variables etc. After that I call a start-member function of these objects which will actually call xTaskCreate.
After that these objects of course still reside in the main application stack and are also still required. Now my new finding based on your responses is, that this stack is than reclaimed for the Interrupt stack.
Is there a proper way to locate the objects created in my main() before calling vTaskStartScheduler() somewhere else. Or can I manually set another location for the interrupt stack?


Make them global/static if possible and you should be fine. When using FreeRTOS heap you could placement new them, too. Or add the appropriate new ‘ delete operators.

Making them global resolved my issue!
Thanks to all for the help!