Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

vAssertCalled question -- how to find the culprit?

Posted by roujesky1 on January 28, 2015

I know this question has been asked before, but I don't see it when I search. Heck, I may have asked the question, but I am old and forgetful... :( I am seeing that the code is entering vAssertCalled. How do I find how it got there? It is VERY intermittent, so it is hard to recreate. I look at pcFile and see '.'. uLine is 0x000498.
I am using a PIC32, with MPLAB X IDE v2.15, FreeRTOS V8.0.1.

there has to be a trick that i dont know....

thanks!!!


vAssertCalled question -- how to find the culprit?

Posted by rtel on January 28, 2015

If you don't have much flash space available you can define configASSERT() very simply:


#define configASSERT( x ) if( ( x ) == pdFALSE ) { taskDISABLE_INTERRUPTS(); for( ;; ); }

That will stop everything and make you processor sit in an infinite loop. configASSERT() is a macro, so if you break on the debugger to see which line is executing you will see exactly which assert you are in - and in the debugger will also be able to inspect the parameters to see how you got there.

If you have more memory available you can have a more traditional assert() definition:


#define configASSERT( x ) if( ( x ) == 0 ) vAssertCalled( __LINE__, __FILE__ )

which passes the line number and file name of the offending assert into a function. You have to provide the function yourself, something like this:


void vAssertCalled( unsigned long ulLine, const char * const pcFileName )
{
static portBASE_TYPE xPrinted = pdFALSE;
volatile uint32_t ulSetToNonZeroInDebuggerToContinue = 0;

    /* Parameters are not used. */
    ( void ) ulLine;
    ( void ) pcFileName;

    taskENTER_CRITICAL();
    {
        /* You can step out of this function to debug the assertion by using
        the debugger to set ulSetToNonZeroInDebuggerToContinue to a non-zero
        value. */
        while( ulSetToNonZeroInDebuggerToContinue == 0 )
        {
        }
    }
    taskEXIT_CRITICAL();
}

You may also want to update to a later version of FreeRTOS - I think there were some changes made to the asserts for the PIC32 (?). It should just be a drop in replacement, so just copy the newer files over the older files (take a backup of the older ones first, naturally).

Regards.


vAssertCalled question -- how to find the culprit?

Posted by roujesky1 on January 28, 2015

thanks for the quick reply. I have the following in FreeRTOSConfig.h

/* Prevent C specific syntax being included in assembly files. */

ifndef _LANGUAGEASSEMBLY
void vAssertCalled( const char *pcFileName, unsigned long ulLine );
#define configASSERT( x ) if( ( x ) == 0 ) vAssertCalled( __FILE__, __LINE__ )
endif

then, in my main.c i have

void vAssertCalled( const char * pcFile, unsigned long ulLine ) { volatile unsigned long ul = 0;

( void ) pcFile;
( void ) ulLine;

__asm volatile( "di" );
{
	/* Set ul to a non-zero value using the debugger to step out of this
	function. */
	while( ul == 0 )
	{
		portNOP();
	}
}
__asm volatile( "ei" );

}

so, my debugger is stopped at

volatile unsigned long ul = 0;

attached is a screenshot that shows the call stack. Basically, there is no stack for me to unwind... If I had something to unwind, I could find the culprit....

thanks!!!

Attachments

FreeRTOS.png (755635 bytes)

vAssertCalled question -- how to find the culprit?

Posted by rtel on January 28, 2015

Inside the function you have the file name and the line number in the file so that is telling you which assert was the culprit. If the parameters are optimised away then declare some global volatile variables and assign the parameters to them.

Alternatively use the debugger to manually set ul to a value other than zero to break out of the loop - then step out of the function to see where you are.


vAssertCalled question -- how to find the culprit?

Posted by roujesky1 on January 28, 2015

thanks! that did it. should have thought of that before!!! I stepped out and found my culprit. :)


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner