Posts by j_a_lockwood

This is not a problem anymore, I don't believe. I think the problem stemmed from borrowing an emulator which may not have had the latest firmware on it. Consider this resolved.

I have an issue when using SystemView and my J-Trace emulator.
I can run SystemView once after connecting and downloading my application, but after the first time, it cannot find the special SEGGER_RTT_CB structure when attempting to start a new (SystemView) trace.
Running the same application with my J-Link Ultra+ works fine with SystemView starting and stopping.
Any suggestions?

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.

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.

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!)

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.

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?

When I go to the entry for the Min Run Time (0.0032 ms) for my ECatSlaveStack task, and hover over the timeline graph, the dynamically displayed bar that starts at the beginning of the task running and the end shows 497.0 us. What is particuly noteworthy is that the SysTick interrupts it right near the end, returning to the task for just a small amount of time before returning back to the scheduler.

There seems to be two different methods that calculate the run time. One for the graph, and one for the stats.

I have attached a picture to show this.

Also note, I HAVE customized the SYSVIEW code to run a task (SeggerSysView) upon receiving a request to send the system descriptions, at which point the task sends each system description entry one at a time via a low-priority task, rather than in bulk. I found that sending it all at once via the callback takes too long for my time-sensitive application, and impacts the Max Run Time stats.

I have tried reverting back to the original code, and it seems to behave the same way, so it doesn't seem that I have introduced the problem.

I have noticed, even in the user's manual that all of those tasks also have very low Min Run Time values.

Can someone please look at the picture and see if I am possibly missing a log event of some sort which causes this behavior, or is this a bug?

The other thing that is a problem is that the frequency of the task running is incorrect. It really runs at 500 Hz, and this calculation problem is most likely related.

I am running the latest version 2.38.

Thanks in advance.