After trying to trace this down with the debugger, I found out the following:
When I monitored the pxReadyTasksLists in tasks.c prior to the crash, I noticed that the pxIndex field of pxReadyTasksList[6] was no longer pointing to an item in the pxReadyTasksLists:
Figure 1
So when the taskSELECT_HIGHEST_PRIORITY_TASK macro is called, and it updates the pvCurrentTCB based on the pvOwner field of the list item assuming that it contains a pointer to a task’s TCB, the application will actually jump to an arbitrary address (0x17 in the above case) and crash to HardFault.
I’m assuming at this point that at any given time, the pvOwner of the next uxNumberOfItems in the pxReadyTasksLists[n] should point to the beginning of the TCB of a task with priority n. This didn’t seem to be the case prior to the error shown in Figure 1. I checked the other priority tasks that were supposed to be in READY state as well and the pvOwner values were off for many of those as well, as seen in Figure 2 and Figure 3:
Figure 2
Figure 3
It’s worthwhile to mention, that the task priorities in our system are as follows:
- prvRXHandlerTask - Priority 6 (highest)
- prvCheckLinkStatusTask - Priority 6 (highest)
- prvIPTask - Priority 5
- Rest of the tasks in the system have a priority 4 or lower