• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 81 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.

AM6422: freertos vApplicationStackOverflowHook

wanglili 王
Intellectual 720 points
Part Number: AM6422


Tool/software:

Hello，

   We are using SDK 8.6, with the R5F core running the FreeRTOS operating system. When creating tasks, the system enters the vApplicationStackOverflowHook function.

    Let me describe the entire creation process. In the main function, the xTaskCreateStatic function is used to create a freertos_main task with a priority of 6 and a stack size of 327680. After executing the vTaskStartScheduler function, the freertos_main task runs and initially creates a new task A using the TaskP_construct function. Task A has a priority of 22 and a stack size of 8192 * 100. Within task A, another task B is created, also using the TaskP_construct function, with a priority of 13 and a stack size of 327680. Following this process, after task B is created, the system enters the vApplicationStackOverflowHook function, indicating a stack overflow in task A. However, by modifying the priority of the freertos_main task to 31 and deleting the task itself after execution, the system no longer enters the vApplicationStackOverflowHook function. I would appreciate your assistance in analyzing this situation.

  • 0
    TI__Mastermind 47856 points

    Hello wanglili,

    FreeRTOS Stack Behavior Observation :
    • When freertos_main runs and deletes itself:
    • Task A and Task B continue running without stack overflow.
    • The system works as expected; the freed stack from freertos_main is now available for other tasks.
    • When freertos_main runs and does not delete itself:
    • Task B executes, but vApplicationStackOverflowHook is triggered.
    • The overflow is reported for Task A, indicating Task A’s stack was exceeded during Task B execution.

    Next Steps / Recommendations :
    1. Review task stack allocations
    • Check whether Task A and Task B really need the currently allocated stack sizes.
    • Use uxTaskGetStackHighWaterMark() to measure actual stack usage at runtime.

    2. Keep freertos_main running for now
    • Do not increase its priority yet; keep it at 6.
    • Monitor system behavior after stack adjustments.


    3. Collect watermark statistics
    • Call uxTaskGetStackHighWaterMark() for each task at runtime:
    • Provides minimum free stack remaining.
    • Helps determine safe and optimal stack sizes for each task.


    4. Iterate
    • Increase stack sizes step by step.
    • Validate with high-water mark data.
    • Avoid over-allocation, but ensure no overflows occur.

    Regards,

    Anil.