stack overflow when first thread is started

Hi

I have just ported my code that was working without a RTOS to CMSIS RTOS and its loaded onto my cortex m3 arm and my code gets through by board initialization but as I get a stack overflow when the RTOS tries to start the first task.

I have configured 0x8200 bytes for my stack, 7 tasks, 2000 bytes for the default thread and 800 bytes for the other 6 threads. The thread viewer shows two additional threads, timer and idle.
My stack is located in the esram and is using all available bytes there.

I really do not have any idea what I have done wrong in allocating memory for the stack or in configuring the RTOS. I feel I missed something in the setup.

I was thinking about backing off the 7 threads and just try to start 1 and see if that overflows.

Is it possible to relocate my stack to my DDR memory space at 0xA0000000 so I can make the available stack size bigger? I don't know if throwing more memory at it will really solve this problem.

Does anyone have any ideas about what might be wrong or how I might go about debugging this overflow issue?

Parents
  • Well the trick would be to actually know, or figure out, what your code is actually using, and why. If you have excessively large auto/local variable allocations in a function called by all threads, then that's going to blow out all the stacks.

    Understand your code, your call trees. Review the static analysis generated by Keil (Project.htm)

    External memory can hold the stacks, it will be SLOW, but you could use a massive allocation for each, paint it with a clear fill character, and then periodically figure out what the high/low water marks are for each of the stacks.

    If the stacks are still excessively large for the tightly coupled SRAM you need to review the coding style and the interplay of the routines causing the problem, and where appropriate change the memory uses, or refactor.

Reply
  • Well the trick would be to actually know, or figure out, what your code is actually using, and why. If you have excessively large auto/local variable allocations in a function called by all threads, then that's going to blow out all the stacks.

    Understand your code, your call trees. Review the static analysis generated by Keil (Project.htm)

    External memory can hold the stacks, it will be SLOW, but you could use a massive allocation for each, paint it with a clear fill character, and then periodically figure out what the high/low water marks are for each of the stacks.

    If the stacks are still excessively large for the tightly coupled SRAM you need to review the coding style and the interplay of the routines causing the problem, and where appropriate change the memory uses, or refactor.

Children
More questions in this forum