Quality RTOS & Embedded Software

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


Tasks list corruption / HardFault in xPortPendSVHandler()

Posted by dhemaius on July 6, 2016

FreeRTOS v8.2.3

System has been running for a while, then after a vTaskSwitchContext() call inside xPortPendSVHandler(), a hard fault occured when it tried to pop the core registers. Here is the list of values that did not make sense at that point :

pxCurrentTCB = 0x00000005 ( found out it came from corrupt pxReadyTasksLists[6] )

pxReadyTasksLists[6].uxNumberOfItems = 0xFFFFFFFF pxReadyTasksLists[6].pxIndex = 0x2001ADA8 pxReadyTasksLists[6].pxIndex->pxNext = 0x2001ADA8 pxReadyTasksLists[6].pxIndex->pxPrevious = 0x2001ADA8 pxReadyTasksLists[6].pxIndex->pvOwner = 0x00000005 ( @ xDelayedTaskList1.uxNumberOfItems) pxReadyTasksLists[6].pxIndex->pvContainer = 0x2001ADBC ( points on xDelayedTaskList1.xListEnd ) pxReadyTasksLists[6].xListEnd @ 0x2001ADA8

xDelayedTaskList1.uxNumberOfItems = 0x00000005 xDelayedTaskList1.pxIndex = 0x2001ADBC xDelayedTaskList1.xListEnd @ 0x2001ADBC

uxTopReadyPriority = 81 ( configMAX_PRIORITIES = 7 !!! )

Any idea how such a corruption can happen?

Futhermore, sneeking around trying to find out how an empty list is still being used, I found something peculiar inside listGETOWNEROFNEXTENTRY macro... Why reaffecting ( pxConstList )->pxIndex->pxNext to ( pxConstList )->pxIndex when it just found out that ( pxConstList )->pxIndex->pxNext is the end of the list marker, causing ( pxConstList )->pxIndex->pvOwner to be invalid?


define listGETOWNEROFNEXTENTRY( pxTCB, pxList )

{ List_t * const pxConstList = ( pxList ); /* Increment the index to the next item and return the item, ensuring / / we don't return the marker used at the end of the list. */ ( pxConstList )->pxIndex = ( pxConstList )->pxIndex->pxNext; if( ( void * ) ( pxConstList )->pxIndex == ( void * ) &( ( pxConstList )->xListEnd ) ) { ( pxConstList )->pxIndex = ( pxConstList )->pxIndex->pxNext; } ( pxTCB ) = ( pxConstList )->pxIndex->pvOwner; } ~~~

Tasks list corruption / HardFault in xPortPendSVHandler()

Posted by edwards3 on July 6, 2016

These things are nearly always because of interrupt priority problems. Are your interrupt priorities set below configMAXSYSCALLINTERRUPT_PRIORITY? Do you have configASSERT() defined? Do you have stack overflow checking defined to 2? For links to the info http://www.freertos.org/FAQHelp.html


HF_PSV.png (39617 bytes)

Tasks list corruption / HardFault in xPortPendSVHandler()

Posted by dhemaius on July 6, 2016

A colleague just revised that on my request before I saw your post and the answer is yes, some ISR using the API were above (meaning number < ) the configMAXSYSCALLINTERRUPT_PRIORITY. I should have thought about it earlier, because I have been down that road.

I had added a configASSERT verification inside uxListRemove() in the past to trap an underroll of pxList->uxNumberOfItems and I still get that error.

Call Stack is always as follow :

prvIdleTask SysTickHandler xTaskIncrementTick uxListRemove assertfailed (aka configASSERT )

I will personnally check again for a wrong priority I guess.


HF_PSV.png (39617 bytes)

[ 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