Quality RTOS & Embedded Software

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




Loading

uxListRemove results in address exception

Posted by blatini on August 4, 2014

I'm using FreeRTOS 8.0.1 on PIC32MX.

I'm getting an address exception error which I've traced to the RTOS function uxListRemove(). The value of pxItemToRemove->pvContainer is initialized to NULL in vListInitialiseItem() and its value isn't checked in uxListRemove() before it is dereferenced in these statements:

List_t * const pxList = ( List_t * ) pxItemToRemove->pvContainer;

...

/* Make sure the index is left pointing to a valid item. */
if( pxList->pxIndex == pxItemToRemove )
{
	pxList->pxIndex = pxItemToRemove->pxPrevious;
}

The address exception occurs on the if statement -- because in this instance, element pvContainer is still NULL. I don't know why is hasn't been initialized to something other than NULL. I only know that it hasn't. 0x0000 is an invalid address in PIC32; RAM is referenced by virtual addresses beginning at 0xA0000000.

The value of ListItem_t pxItemToRemove immediately before the exception is:

xItemValue == 4 pxNext == 0xA0004BF8 (a valid RAM address) pxPrevious == 0xA0004BF8 pvOwner == 0xA0004BE0 pvContainer == 0

I haven't done anything that I would consider unusual. In fact, I have 2 nearly identical tasks executing in sequence. The first deletes itself before the second task is created. The first task executes fine. The second task will execute fine if I remove the first task (via commenting it out). But if it follows deletion of the first task, I get this address exception. I've checked that the idleTask is running to clean up deleted items. And I played with adjusting stack sizes, etc. before I traced this down to uxListRemove(). I appears to me that perhaps the value of this pointer "pvContainer" should be checked before it is dereferenced. I haven't explored the RTOS kernel to see what's actually being done here.


uxListRemove results in address exception

Posted by rtel on August 4, 2014

Are you using interrupts? If so, at which interrupt priority are they running at what is the value of configMAXSYSCALLINTERRUPT_PRIORITY in FreeRTOSConfig.h?

Regards.


uxListRemove results in address exception

Posted by blatini on August 4, 2014

configMAXSYSCALLINTERRUPT_PRIORITY is set to 3.

I'm using 1 peripheral interrupt, the priority of which I set to 3. I configured it with the assembly language wrapper, as described in the RTOS documentation. It is running properly.


uxListRemove results in address exception

Posted by rtel on August 4, 2014

It is running properly.

Well, maybe not, depending on what is causing the problem. The most common cause of the type of corruption you describe is an interrupt running at the wrong priority. The interrupt itself may appear to execute, but if it were at an incorrect priority it could corrupt data while it was running.

How are you setting the interrupts priority? Do you have stack overflow detection turned on? Stack overflow detection only checks the task stacks, so have you tried increasing the size of the stack used by interrupts? Do you have configASSERT() defined?

Let me know if you are not sure about any of the above questions and I can provide links to the relevant documentation.

Regards.


uxListRemove results in address exception

Posted by blatini on August 4, 2014

configCHECKFORSTACK_OVERFLOW is set to 3

I'm setting the IRQ priority by directly setting bits in the associated PIC32 IPC register. I've verified with the debugger that the priority is 3 in the correct register bits immediately before the address exception occurs.

My interrupt doesn't do anything but copy register contents to an RTOS queue via xQueueSendFromISR and clear the interrupt flag. So I can't imagine that it requires much stack space.

configISRSTACKSIZE is set to 300. I increased it to 512, and the problem still occurs.

configAssert is defined as in the PIC sample project:

/* Prevent C specific syntax being included in assembly files. */
void vAssertCalled( const char *pcFileName, unsigned long ulLine );
#define configASSERT( x ) if( ( x ) == 0 ) vAssertCalled( __FILE__, __LINE__ )


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" );
}

uxListRemove results in address exception

Posted by blatini on August 4, 2014

Thanks for your assistance! Your comments about interrupts got me to looking in a different place than I've been looking, and I located the problem in my code. I wasn't clearing the interrupt queue handle to NULL after calling vQueueDelete. And since I'm checking whether it is NULL before creating it again later, it wasn't created anew for the 2nd task, so the interrupt was using the old queue handle. If that makes sense ...

Anyway, thanks for your time. It is much appreciated!


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




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

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

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