Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




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 ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists