Help with configASSERT in vPortExitCritical

Kernel
1

booherbg wrote on Thursday, April 13, 2017:

Hi all. I have an intermittant bug that I’m trying to track down. Essentially an assertion failure in line 413 of port.c – basically the first line of vPortExitCritical():

void vPortExitCritical( void )
{
	configASSERT( uxCriticalNesting );
	uxCriticalNesting--;
	if( uxCriticalNesting == 0 )
	{
		portENABLE_INTERRUPTS();
	}
}

I am trying to get my debugger to get trapped here so I can see a call trace. Even with a trace I fear that the actual reason for the error would be a previous call to vPortExitCritical(), as the assertion is simply that uxCriticalNesting is actually 0.

I would love any tips on where to look for how to track this down. I suspect there may be an issue with priorities, or some rogue conditional branch that may be causing this. It feels like someone is calling vPortExitCritical() from outside a critical region (thus reducing uxCriticalNesting to 0 prematurely). Does that sound like a correct guess?

I’m running FreeRTOS 8.2.3 on an Arm Cortex M7, and a Segger J-LINK debugger.

Blaine

2

rtel wrote on Thursday, April 13, 2017:

You can add some code to give yourself a place to place a break point,
as follows:

void vPortExitCritical( void )
{
     if( uxCriticalNesting == 0 )
     {
         __asm volatile ( "NOP" );
     }

     // Rest of vPortExitCritical() code goes here.

This uses GCC syntax. You can then place your breakpoint on the NOP
instruction.

3

booherbg wrote on Thursday, April 13, 2017:

Thank you. I’m giving this a try to see what my call trace looks like.