The firmware execution falls into Idle Task

Kernel
21

It seems that you are trying to enter low power mode from the idle hook. Does it assume that all the application tasks run at a higher priority and therefore, when the idle task runs, there is no other application task ready to run?

Since vApplicationIdleHook is defined as weak, can you try to add an empty implementation of it in your application and see what happens:

void vApplicationIdleHook (void)
{
}
22

Could you please provide some details about how to do that?
Thanks.

23

If you are asking about how to pause the code in the debugger and how to examine memory, you should consult the manual of your IDE.

Once you are able to examine the memory in debugger, check the values of xStateListItem and xEventListItem for each TCB. You can get the state list and event list from xStateListItem and xEventListItem like this. Then you can find out the task state based on which list the task is on - FreeRTOS-Kernel/tasks.c at main · FreeRTOS/FreeRTOS-Kernel · GitHub.

Also, did you try the above suggestion of stubbing out vApplicationIdleHook?

24

Thank you so much for the info, aggarg! I appreciate it.
I’ll try the solution. For the vApplicationIdleHook, I add the empty implementation. I’ll test it.

25

From how can I get the TCB imformation from the task handle? - FreeRTOS, it seems we can’t get the TCB info directly. There is a function vTaskGetInfo() can give us some info.

26

@richard-damon’s suggestion was not to write code to get this information but examine the TCB memory in the debugger. In other words, you do not need to write code but examine the memory location of TCB in the debugger and check the values there.

27

So far, the system hang issue and the random hard fault issue seem to be resolved. There is another hard fault which is different from the previous random hard fault. I still need to work on it. But the firmware running on the board is a lot of better. It can keep running for more than 50 hours continuously compare to just 1 or 2 hours before the fixes. Our goal is to get the firmware running without issues for more than 30 days. Over the last few weeks, we’ve done the following:

  • Increased the size of the heap for FreeRTOS
  • Increased the size of the stack for the related tasks
  • Run the firmware in the Release mode. Meaning, there is almost no printf in the code.
  • Go through the code to ensure the functions are thread-safe. For the shared global data, we use the portENTER_CRITICAL()/portEXIT_CRITICAL() if necessary.
  • Reviewed the original design. There are a sending data task and a receiving task to communicate with the third party chip in the project. Previously, the sending data task also handles the data receiving in some special cases. We changed the design by asking the receiving task to handle the data receiving for the sending task. This seems help a lot.

Thanks!

28

Thank you for reporting back!