FreeRtos Trap

Partners & Sponsors Infineon
1

I am using aurix TC27XD controller with freertos as OS for development. It has Marvell 88Q6113 IC wich transfer all traffic from its port to aurix. We are using Node module 1.0.4 stack. I am getting trap after few minutes from freertos as portTIN_CM_FREE_CONTEXT_LIST_UNDERFLOW. Can anyone help me how to fix this problem.strong text

2

On a TriCore that is sort of equivalent to a stack underflow. Are you trying to exit a function that implements a task by any means other than deleting the task?

3

Thanks for replying. I checked on previous commits. I observed this issue is coming when we are connecting any external devices to port of marvell 88Q6113 . Aurix facing much traffic and hence ping also slowing down. Can we connect on call for discussing this issue more details?. I am having below questions:

  1. Does issue can be from PHY ?
    2.Why pings slowing down after few minutes?
  2. Do we need to check tcpip thread?
  3. Is there any issue with pbuf?
  4. Any idea how can we trace it If we are facing different traps which are time dependent?

Regards,
Ankita

4

The following is from the TriCore architecture doc -


FCU - Free Context List Underflow (TIN 4)

The FCU trap is taken when a context save operation is attempted but the free context list is found to be empty (i.e. the FCX register contents are null). The FCU trap is also taken if any error is encountered during a context save or restore operation. The context operation cannot be completed. Instead a forced jump is made to the FCU trap handler and D15 updated with the FCU TIN value.

In failing to complete the context save or restore, architectural state is lost, so the occurrence of an FCU trap is a non-recoverable system error. The FCU trap handler should ultimately initiate a system reset.

Are you dynamically creating and deleting tasks? If yes, a possibility is that the Idle task is not getting starved leading to free contexts getting exhausted - FreeRTOS-Kernel/port.c at main · FreeRTOS/FreeRTOS-Kernel · GitHub

All other questions that you asked are highly dependent on your application and therefore, are not possible to answer without looking at the code. As for the debugging, I’d suggest turning off the functionality of your application one by one to narrow down the problematic part.

5

Hi, I tried to do the same but couldn’t able to found the trap. I am using 7 auto negotiation task of marvell IC port 0-6 having same priority. As per call stack, It is coming from Auto negotiation task.Do you think there is issue with 7 Task created and having same priority?

6

Are you deleting tasks dynamically? Does reducing the number of tasks fixes your problem?