[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?

Loading RTOS plugin: GDBServer/RTOSPlugin_FreeRTOS...
RTOS plugin (v1.0) loaded successfully
RTOS plugin initialized successfully.
Received symbol: pxCurrentTCB (2000548C)
Received symbol: pxReadyTasksLists (20005490)
Received symbol: xDelayedTaskList1 (200054F4)
Received symbol: xDelayedTaskList2 (20005508)
Received symbol: pxDelayedTaskList (2000551C)
Received symbol: pxOverflowDelayedTaskList (20005520)
Received symbol: xPendingReadyList (20005524)
Received symbol: xTasksWaitingTermination (20005538)
Received symbol: xSuspendedTaskList (20005550)
Received symbol: uxCurrentNumberOfTasks (20005568)
Received symbol: uxTopUsedPriority (2000559C)
Received symbol: vPortEnableVFP (00023650)
All mandatory symbols successfully loaded.
All mandatory symbols successfully loaded.

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.

Ok. I found MY problem.

I set uxTopUsedPriority to a value +1 of what it should have been, and it caused this side effect.

It is all working now (and totally awesome!)

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.

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.

example: configMAX_PRIORITIES = 5,


you end up with:


pxReadyTasksLists[0],  - Priority 0   (1st Priority)
pxReadyTasksLists[1],  - Priority 1   (2nd Priority)
pxReadyTasksLists[2],  - Priority 2   (3rd Priority)
pxReadyTasksLists[3],  - Priority 3   (4th Priority)
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.