• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 416 subscribers
  • Views 511 views
  • Users 0 members are here
Options
Related

The firmware is hung after a few hours

pilot

I'm working on a project that uses RA6M5 MCU. The FreeRTOS version is 10.4.3. There are 20 tasks in the firmware.
The firmware is hung after a few hours. I ran the firmware from IAR. When the firmware is hung, I hit the Pause button in IAR. It falls into the Idle task. Here is the call stack:

rm_freertos_port_sleep_preserving_lpm
vApplicationIdleHook
prvIdleTask
prvTaskExitError

I tried to get Tracealyzer working with IAR. But it didn't work for me. I'm trying to figure out which tasks got stuck, and which part caused the stuck. Could you please provide some ideas about how to narrow down and find the problem?

Thanks!

  • 0

    Hello pilot,

    We have already provided some suggestions on how to debug your FREERTOS application.

    From your previous posts, I remember that you have created a big project with a lot of  tasks.

    So, can you please share your project with us, in order to try to test it?

    Regards,

    AL_Renesas

  • 0 in reply to AL_Renesas

    Thanks AL. I appreciate it.


    In fact, the project I worked on isn't a new project. Basically, what we do is to change the MCU from a FreeScale one to RA6M5 based on the existing project. We also changed a third party chip on the board. There are about 20+ tasks in our project. It's hard to share the code.


    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 60 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!