FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [January 2015 Threads] 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!!!
AttachmentsFreeRTOS.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. :)
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|