This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

stack overflow on os_sys_init_user

Hello there,

I am having a stack overflow on a cortex-M3, using RL-ARM. I have my memory allocated as follows:

main stack size: 1042 bytes (0x0000 0412, configured in startup_stm32f10x_cl.s)

heap size: 1042 bytes (0x0000 0412, configured in startup_stm32f10x_cl.s)

individual task stacks:
init task: 160 bytes
task 1: 512 bytes
task 2: 348 bytes
task 3: 348 bytes
task 4: 210 bytes
task 5: 200 bytes
task 6: 200 bytes

I have a task called "init" that exists to start the other tasks. init is getting passed to os_sys_init_user. The problem is that program execution never gets into the body of init (if I put a breakpoint on the first line of init, it never gets there).

Some other features of how I have things set up:

I am using os_sys_init_user (rather than os_sys_init) to start *all* of my tasks, including init, to make it easy for me to fine-tune the size of each task's stack. In RTX_Config.c, I have the following settings:

Number of concurrent running tasks: 7
Number of tasks with user-provided stack: 7
Task stack size [bytes]: 20
Check for stack overflow: checked
Run in privileged mode: checked
Number of user timers: 5

I figure if I am using user-provided stack for every task, the task size value in RTX_Config.c shouldn't matter (20 seemed to be the min value it would let me use). Is that assumption correct? I've tried upping the size of the main stack size in startup_stm32f10x_cl.s, and I've tried upping the size of the user-defined stack allocated to init. In both cases I program execution ended up in os_stk_overflow.

What can I do to fix this overflow? Any thoughts would be greatly appreciated.

thanks,
David Merrill

Parents
  • Thanks Franc.

    Just so I understand completely, I want to clarify how the stack is organized:

    Is it true that regardless of how many concurrent tasks I account for in RTX_Config.c (i.e. 7, in my case), the system idle task adds one more? And if I am providing user-defined amount of stack to *all* of my 7 tasks, the "Task stack size [bytes]" value in RTX_Config.c will determine the size of the system idle task's stack? And if so, is there any reason to give more than 68 bytes, or will that definitely be enough?

    Another question is: Am I correct to think that the "main stack size" (as defined in startup_stm32f10x_cl.s) is separate from the 7+1 stacks that I have already mentioned? And if so, does this main stack handle variables and function calls from the main() function + interrupts?

    So really, if my assumptions are correct, the complete picture of RAM usage should be:

    main stack + 7 user-defined task stacks + 1 system idle task stack + heap.

    Is that correct?

    Finally, if I have "check for stack overflow" enabled, will this monitor overflow on all (9) stacks?

    thanks,
    -David

Reply
  • Thanks Franc.

    Just so I understand completely, I want to clarify how the stack is organized:

    Is it true that regardless of how many concurrent tasks I account for in RTX_Config.c (i.e. 7, in my case), the system idle task adds one more? And if I am providing user-defined amount of stack to *all* of my 7 tasks, the "Task stack size [bytes]" value in RTX_Config.c will determine the size of the system idle task's stack? And if so, is there any reason to give more than 68 bytes, or will that definitely be enough?

    Another question is: Am I correct to think that the "main stack size" (as defined in startup_stm32f10x_cl.s) is separate from the 7+1 stacks that I have already mentioned? And if so, does this main stack handle variables and function calls from the main() function + interrupts?

    So really, if my assumptions are correct, the complete picture of RAM usage should be:

    main stack + 7 user-defined task stacks + 1 system idle task stack + heap.

    Is that correct?

    Finally, if I have "check for stack overflow" enabled, will this monitor overflow on all (9) stacks?

    thanks,
    -David

Children