• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 1389 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Stack overrun with multiple tasks in system.

E. Boris
Prodigy 170 points

Other Parts Discussed in Thread: CC2640

OK - I am working with a CC2640 using an IAR IDE.

The system is configured with multiple tasks 5 total including IDLE and ICALL. Basically - when I have all 5 tasks in the system - the rtos crashes at BIOS_start() immediately due to a stack overflow.

If I remove one of the application tasks - everything seems to work fine. The RTOS is up and running and the application task is working fine.

If I re-insert this task and remove the other application task - everything seems to work fine. That application task seems to be working fine.

But when I put both tasks back in the system together I again receive a stack overflow and exit. 

So individually - both tasks seem to be ok running in the system by themselves. However - when both are in the system together an overflow error occurs. 

Is there some overarching parameter I am missing in the .cfg file that should be set larger?

  • 0
    TI__Mastermind 18260 points

    E. Boris said:
    So individually - both tasks seem to be ok running in the system by themselves. However - when both are in the system together an overflow error occurs.

    Can you try increasing each Task's stack size to an amount that is assuredly more than the Task needs?

    If this alleviates your system exit then you can use ROV to look at each Task's peak stack usage and adjust the sizes back down to something that is closer to what the Task is actually using.

    In most situations a Task's stack usage won't increase based on *other* Tasks being present in the system, but due to Task dynamics and interplay, an interrupt might be happening while a certain Task is running and that Task doesn't have enough stack space to field the interrupt, and when you take that Task out of the system then the interrupt happens while a different Task is running, and that different Task has enough space.

    I realize that last sentence is a mouthful, hopefully it makes some sense.

    Can you show your code that creates the Tasks? (either .cfg code for statically-created Tasks, or C code for dynamically-created Tasks or constructed Tasks)

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Prodigy 170 points
    I found the issue. In the pre-include project options there is a #define ICALL_MAX_NUM_TASKS. I'm guessing that this represents the number of possible tasks possible to run (minus 1 for the IDLE task). When we added that last task it pushed us over the limit. Modified the value from 3 to 6 and things seem much better now.
  • 0 in reply to E. Boris
    TI__Mastermind 18260 points

    That's great to hear that you found the issue.

    Perhaps these e2e threads from the Bluetooth Smart Forum will be informative for you:

    https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/p/452237/1634260

    https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/t/412719

    Regards,

    - Rob

  • 0 in reply to E. Boris
    TI__Mastermind 18260 points

    E. Boris said:
    I found the issue. In the pre-include project options there is a #define ICALL_MAX_NUM_TASKS. I'm guessing that this represents the number of possible tasks possible to run (minus 1 for the IDLE task). When we added that last task it pushed us over the limit. Modified the value from 3 to 6 and things seem much better now.

    Would you please mark either your post or my response to it as "Answered" for the system?

    Thanks & Regards,

    - Rob