uxListRemove gives a hardfault: IMPRECISERR


I have a problem using the task notification, and I would like some help.
I have an interrupt that receive data from the uart, and when it receive and “end char” it notify my task to process the data.

First round, so to speak, goes fine. The system wait for the notification and process the data when notified. On the way back though, when the task is setting up to wait for the next set of data, I get a hardfault:


My backtrack before the fault is this:

#0 uxListRemove (pxItemToRemove=0xb8824) at …\Components\FreeRTOS\Sources\list.c:177
#1 0x000136d8 in prvAddCurrentTaskToDelayedList (xTicksToWait=4294967295, xCanBlockIndefinitely=1) at …\Components\FreeRTOS\Sources\tasks.c:5196
#2 0x00013516 in ulTaskNotifyTake (xClearCountOnExit=1, xTicksToWait=4294967295) at …\Components\FreeRTOS\Sources\tasks.c:4652
#3 0x00010c8a in TaskProcess_Mactalk (pvParameter=0x0 <__Vectors>) at …\Components\Mactalk\Mactalk\Sources\Mactalk_Process.c:72
#4 0x00000000 in ?? ()

I have been stepping though the code in uxListRemove, and the fault occurs here at the following:

pxItemToRemove->pxPrevious->pxNext = pxItemToRemove->pxNext;

where pxItemToRemove->pxNext are:

pxNext = 0xFB1 <Reset_Handler>
pxPrevious = 0x4CD <NMI_Handler>
pxOwner = 0x4D5 <Hardfault_Handler>
pxContainer = 0x545 <MemManage_Handler>

I have verified that I am not getting an interrupt from the uart while the task is setting it self up again.
ConfigASSERT are defined as:

if( ( x ) == pdFALSE ) { taskDISABLE_INTERRUPTS(); for( ;; ); }

and configCHECK_FOR_STACK_OVERFLOW is sat to 2.
I am working on a NetX90(Arm cortex-m4f)

hope that someone can help :slight_smile:

Can you please show the code that is receiving the notification and the code that is sending the notification.

In my interrupt sending the notification I have:

static void RxCallback(DRV_UART_HANDLE_T* pvDriver, void* pvUser)
    uint32_t RxCnt = DRV_UART_GetRxCounter(pvDriver);
    DRV_UART_GetState(pvDriver, &eUartState);

    if(aRxBuffer[uiRxIndex] == END_CHAR)
     uiRxIndex = 0;
     BaseType_t xHigherPriorityTaskWoken = pdFALSE;
     vTaskNotifyGiveFromISR(Task_Mactalk, &xHigherPriorityTaskWoken);
     portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
    uiRxIndex += RxCnt;

pcDriver are the pointer to the uart driver.

The task receiving the notification

void TaskProcess_Mactalk(void* pvParameters)
    /** initialize some stuff **/
        if( ulTaskNotifyTake(pdTRUE, portMAX_DELAY) != 0)
            /** Process Data **/

The delay is sat to max since the uart is not at use at all time and I might get a timeout error if set otherwise.

I’m having issues viewing the posts in the forum at the moment - so have read the code on my phone which is not ideal - but it doesn’t show anything obviously wrong. I would recommend trying to determine the source of the fault - you can use the code here to locate the program counter value when the fault occurred: https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

Ah - I can view the text after posting. Looking at your original post again I see the values in the structure members are corrupt, which then no doubt causes the fault, so my previous suggestion of finding the program counter value when the fault occurs is not going to help - instead it is necessary to find the corruption that causes the pointer to be invalid.

Seems like a case of memory corruption. Some things to check:

  • Where is aRxBuffer defined? Is it possible that the code is writing out of bounds?
  • The task TaskProcess_Mactalk receives data in PACKET_T DATA which is created on the stack. Could this be overflowing?


Problem solved.

just quick:

Where is aRxBuffer defined? Is it possible that the code is writing out of bounds?

it does not goes out of bound, have a check that produce an error if that where to happen, and it have not done that so far.

The task `TaskProcess_Mactalk` receives data in `PACKET_T DATA` which is created on the stack. Could this be overflowing?

It overflew, every time I was copying the data from the buffer into the PACLET_T Data, where it corrupted other memory areas, which in turn produced the IMPRECISERR error.
I found the error while I was monitoring the memory arear where Data is located.

Thank you for taking time to report your solution back.