Issues with configASSERT

Kernel
1

Hi Experts,
Recently I started the migration of my CC3200 to CC3220SF. But I’m getting configASSERT after calling a simplelink API for wlan profile add. Can anyone suggest how to debug that issue?

2

The assert itself should indicate what the issue is. Which assert re you hitting?

3

Hi Richard
Assert is this
configASSERT( ( portNVIC_INT_CTRL_REG & portVECTACTIVE_MASK ) == 0 );
But I’m unable to identify from where it is coming?
And main point is I’m a noob or rookie for using FreeRTOS so can you explain what can be cause causing assert to my application please tell me why it is coming by seeing the above bold statement.

4

Better add FreeRTOS version, source file and line number. Otherwise it‘s hard to help.

5

Oops, I’m really sorry about that mistake FreeRTOS version is 10.0 file port.c
line number 313.
Function is
void vPortEnterCritical( void )
{
portDISABLE_INTERRUPTS();
//__disable_irq();
uxCriticalNesting++;

/* This is not the interrupt safe version of the enter critical function so
functions that end in "FromISR" can be used in an interrupt.  Only assert if
assert() if it is being called from an interrupt context.  Only API
the critical nesting count is 1 to protect against recursive calls if the
assert function also uses a critical section. */
if( uxCriticalNesting == 1 )
{
	configASSERT( ( portNVIC_INT_CTRL_REG & portVECTACTIVE_MASK ) == 0 );
}

}

6

The comment of the assert already tells some details…
Question is what‘s the call stack down to entering vPortEnterCritical. Is it called from ISR or by which higher level function ?
BTW FreeRTOS versioning is 10.0.X and also the last number is needed.

7

FreeRTOS Version is 10.0.0. How do we know from which ISR event or by which higher level function we are getting that interrupt? Can you please elaborate a bit?
I have debugged step wise and got to know it is coming from a Simplelink event Handler (from Ti API’s)

8

Usually a debugger has a feature to show the so called call stack starting from a breakpoint or halt. It displays upwards each calling function.
You seem to use a SDK from TI and their provided device driver. I wonder if their driver is broken/buggy …
Well, we know more when we know from which (FreeRTOS) function vPortEnterCritical was called.

9

Just to be clear - that assert is telling you a function that should not be called from an interrupt was called from an interrupt. Looking at the call stack should tell you the path to the inappropriate function being called - specifically vPortEnterCrtitical() should not be called form an interrupt, looking at the call stack will tell you which function called vPortEnterCritical(), and then which function called that function, until you can see the route cause.

10

Hi, Richard and Hartmut
as you have said to check the call stack. I’ll follow your’s instruction.