Exception abort on network stress conditions

Partners & Sponsors ST
1

Hello Support Team

using freeRTOS + TCP stack, we are able to test a network but stressing with a flood ping, after a while, the system goes in exception abort on Cortex R52. This looks to be related on context switch, pxTCB is NULL and it occurs in different parts of the system and happens randomically (after 5 minutes as well as 1 h). Adding extra checks like below, the SW is a bit more stable but the issue occurs soon or later.

BaseType_t xTaskIncrementTick( void )
{
…
pxTCB = listGET_OWNER_OF_HEAD_ENTRY( pxDelayedTaskList ); /*lint !e9079 void *
…
if(!pxTCB)
{
xNextTaskUnblockTime = portMAX_DELAY;
break;
}

Here some kernel configurations:

configMAX_API_CALL_INTERRUPT_PRIORITY 18UL
configMAX_PRIORITIES ( 30 )
configUNIQUE_INTERRUPT_PRIORITIES 32
ipconfigIP_TASK_PRIORITY 4

while the Ethernet uses a task to manage TX and RX process with a priority:

  • ipconfigIP_TASK_PRIORITY + 1
    and Interrupt priority is:
    configMAX_API_CALL_INTERRUPT_PRIORITY + 1

Do you have any advice?

Regards
Peppe

2

Seems like a memory corruption. Which FreeRTOS port are you using? Can you share your FreeRTOSConfig.h?

3

The recommended priority levels of the tasks when using FreeRTOS+TCP are:

  • Highest : the Network Interface driver (niEMAC_HANDLER_TASK_PRIORITY)
  • Medium : the IP-task (ipconfigIP_TASK_PRIORITY)
  • Lower : the tasks that make use of FreeRTOS+TCP

Is that the case?

Also, please make sure that there aren’t any ISRs that are run with logical priority above configMAX_SYSCALL_INTERRUPT_PRIORITY if they are using any FreeRTOS APIs.

4

Beside checking the task priorities, I would also look at the logging from the function vPrintResourceStats(). It will be difficult to catch the last logging lines if the CPU is about to get an exception.
vPrintResourceStats() should be called from the network interface, normally from the network interface in a function like prvEMACHandlerTask().