FreeRTOS Max Used Priority is Unreasonably Big

dottavia wrote on Tuesday, January 16, 2018:

So I am trying to step debug on an CC3200 chip using Eclipse + GDB with a Segger J-Link debugger. I have installed the freeRTOS plugins for Eclipse as well as pulled in the freeRTOS dll provided by Segger.

After playing around with it for a while I was able to almost get it to work with Thread Aware Debugging. However no matter what I do I can’t seem to get past this error:
ERROR: FreeRTOS maximum used priority is unreasonably big, not proceeding: 00002B2D.

I have checked the threads and their priorities but nothing is set higher than the max setting in the RTOS config file.

Thank you for any guidance you can provide.

rtel wrote on Tuesday, January 16, 2018:

I have no idea how the plug-in is implemented I’m afraid, but I’m going
to guess it is because configUSE_PORT_OPTIMISED_TASK_SELECTION
is set to 1. When that is the case the priorities are stored as a bit
map so a single assembly instruction can be used to find the highest
priority. That can make the variable that holds the value have an
extremely large value if it is read as an integer rather than as a
bitmap. configUSE_PORT_OPTIMISED_TASK_SELECTION is set to 0?

dottavia wrote on Tuesday, January 16, 2018:

So I checked our RTOS config and yes it was actually set to 1. I set it to zero and it seems that the issue is still there. Although for a moment there was a weird event where after I changed it that error didn’t occur the first time debugging. Then next time it did and has reoccurred since.

dottavia wrote on Tuesday, January 16, 2018:

An update to my pervious post. I am no longer stuck on that error. After some playing around I was able to fix it. However now when step debugging through the code I hit a SIGBREAK at the line “pxCurrentTCB = pxNewTCB” which is line 609 in my file tasks.c

It seems like when that line runs in the debug window the values change from Thread #2 to Thread #3 Suspended Signal: SIGTRAP:/Trace/breakpoint trap and the code window just shows break at 0x0.

rtel wrote on Tuesday, January 16, 2018:

An update to my pervious post. I am no longer stuck on that error. After
some playing around I was able to fix it.

Please don’t start a support thread for an issue, then say you have
fixed it without without also saying what the fix was - others with the
same issue may be reading this in the future and to maximise the value
of the forum the threads should have a documented conclusion (plus it
will save our time from answering the same question multiple times).

However now when step
debugging through the code I hit a SIGBREAK at the line “pxCurrentTCB =
pxNewTCB” which is line 609 in my file tasks.c

It seems like when that line runs in the debug window the values change
from Thread #2 to Thread #3 Suspended Signal: SIGTRAP:/Trace/breakpoint
trap and the code window just shows break at 0x0.

Could it be a context switch is occurring between debug steps?

dottavia wrote on Tuesday, January 16, 2018:

I didn’t really fix it. I changed the port optimize value like recommended. I just have to reset the power each time I debug and it gets past that first error. It still pops up if I try to run debug sessions back to back without power cycling.

It could be. I have done everything possible to get Thread Aware Debugging working that I possibly could and in no case have I been able to follow thread switches. Is there anything specific I can do to see if a context switch is occuring?

rtel wrote on Tuesday, January 16, 2018:

Is there anything specific I can do to see if
a context switch is occuring?

You can have a break point in the PendSV handler.