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] [July 2016 Threads]
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;
}
~~~
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
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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.