[SOLVED] Thread Aware FreeRTOS debugging seems to ignore pxOverflowDelayedTaskList

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Thread Aware FreeRTOS debugging seems to ignore pxOverflowDelayedTaskList

    I am using FreeRTOS v.8.2.3 and debugging in standard Eclipse with GNU ARM Eclipse plugins.

    Whenever I use the max delay to pend on a semaphore, unless the tick count is 0, the task will be placed on pxOverflowDelayedTaskList. When this happens and I pause the debugger, any threads that are on this list is missing from the list of threads displayed in the debugger.

    The symbol is defined and shown as loading correctly in the JLinkGDBServerCL console output and it is the correct value.


    Has anyone else noticed this?
  • Hi,

    pxOverflowDelayedTaskList is just a pointer to the task list holding overflowed tasks. It either points to xDelayedTaskList1 or xDelayedTaskList2, which both are being searched.

    Could you please check if the symbols xDelayedTaskList1 and xDelayedTaskList2 have the correct values?

    Best regards,
    Arne
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Source Code

    1. Loading RTOS plugin: GDBServer/RTOSPlugin_FreeRTOS...
    2. RTOS plugin (v1.0) loaded successfully
    3. RTOS plugin initialized successfully.
    4. Received symbol: pxCurrentTCB (2000548C)
    5. Received symbol: pxReadyTasksLists (20005490)
    6. Received symbol: xDelayedTaskList1 (200054F4)
    7. Received symbol: xDelayedTaskList2 (20005508)
    8. Received symbol: pxDelayedTaskList (2000551C)
    9. Received symbol: pxOverflowDelayedTaskList (20005520)
    10. Received symbol: xPendingReadyList (20005524)
    11. Received symbol: xTasksWaitingTermination (20005538)
    12. Received symbol: xSuspendedTaskList (20005550)
    13. Received symbol: uxCurrentNumberOfTasks (20005568)
    14. Received symbol: uxTopUsedPriority (2000559C)
    15. Received symbol: vPortEnableVFP (00023650)
    16. All mandatory symbols successfully loaded.
    17. All mandatory symbols successfully loaded.
    Display All


    The value of pxDelayedTaskList is 0x200054f4 (&xDelayedTaskList1).
    The value of pxOverflowDelayedTaskList is 0x0x20005508 (&xDelayedTaskList2).

    Everything looks defined and correct to me.

    I have 5 tasks. IDLE, two of which call vTaskDelay to sleep a few ticks, and two of which call xQueueReceive with the maximum delay (which puts them onto xDelayedTaskList2).

    As a test, I changed the initialization code of FreeRTOS to set pxDelayedTaskList = &xDelayedTaskList2, and pxOverflowDelayedTaskList = &xDelayedTaskList1.

    After making this change, now the tasks which are visible are the two that were originally hiding, and the two that were originally visible are hidden (and IDLE is always visible, as it is always where the code happens stop when paused). This leads me to believe that xDelayedTaskList2 is not being searched.

    The post was edited 1 time, last by j_a_lockwood ().

  • Hi,

    what value did you set uxTopUsedPriority to? configMAX_PRIORITIES?

    Best regards,
    Arne
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • The short answer - Essentially, yes.

    The long answer - I do things a little differently than most. For a variety of reasons (that is too long to explain and irrelevant), I have a bunch of scripts run during the build process, in order to have all TCBs initialized and FreeRTOS structures statically initialized prior to getting to main(). I adjusted my script to compute uxTopUsedPriority = (configMAX_PRIORITIES -1).

    I actually figured this out by using IDA to attach to the code of RTOSPlugin_FreeRTOS.dll, and put breakpoints in to examine the loop that processes the various Thread lists. I saw that 0x200054f4 (xDelayedTaskList1) was processed twice which clued me in to my problem.
  • Hi,

    I consider this as a bug in the plugin. It will be changed in the next release, uxTopUsedPriority should be set to configMAX_PRIORITIES for the plugin.
    Additionally I have added support for using uxTopReadyPriority instead of uxTopUsedPriority, so you no longer need to set uxTopUsedPriority any more.

    Feel free to give feedback.

    Best regards,
    Arne
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • I disagree that it is a bug.

    I have read (at least for openOCD) that this value should be set to configMAX_PRIORITIES, but since priorities start at 0, it makes more sense to me to configure uxTopUsedPriority to configMAX_PRIORITIES - 1.

    Source Code

    1. example: configMAX_PRIORITIES = 5,
    2. you end up with:
    3. pxReadyTasksLists[0], - Priority 0 (1st Priority)
    4. pxReadyTasksLists[1], - Priority 1 (2nd Priority)
    5. pxReadyTasksLists[2], - Priority 2 (3rd Priority)
    6. pxReadyTasksLists[3], - Priority 3 (4th Priority)
    7. pxReadyTasksLists[4], - Priority 4 (5th Priority) (configMAX_PRIORITIES)

    thus, the top used priority is 4.

    I think it is just a matter of documenting what the value really should be. The top used priority IS configMAX_PRIORITIES-1.
  • Hi,

    we will change it back to configMAX_PRIORITIES-1, as this makes more sense and to be compatible with other solutions.

    Best regards,
    Arne
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.