The firmware has hard fault and hung some times


I'm working on a project that uses RA6M5 MCU. The FSP version is 3.5.0. The FreeRTOS version is 10.4.3.

I found there is a hard fault after the firmware running a few hours. From the memory dump, the R14(LR) shows a function address. I found the function from the generated map file by IAR. Other than this R14, is there any other info that I can use from the hard fault dump print-outs?

Hard Fault

   R0 : 00032595   R1 : fffffff1
   R2 : 00000000   R3 : 2003f804
   R4 : 00000000   R5 : 2003f274
   R6 : 00000000   R7 : 2003f804
   R8 : a5a5a5a5   R9 : a5a5a5a5
   R10: a5a5a5a5   R11: a5a5a5a5
   R12: 00000002   R13: 200003c8
   R14: 00032595   R15: a5a5a5a5

                  0002516a 6100001e 
2003f804 000253c3 00000000 20001878 
2003d804 a5a5a5a5 a5a5a5a5 000221cb

Another problem is, after running a few hours, the firmware can be hung. As the watch dog timer isn't kicked, after about 30 seconds, the firmware will be reset. I tried to run the firmware from IAR. When it is hung, I pause the exection. I found it falls to prvIdleTask in "\Renesas\aws\amazon-freertos\freertos_kernel\task.c". I'm wondering what's the reason that the firmware runs into the Idle task. Is there a way to avoid it?


Parents Reply Children
  • Hi pilot,

    Some extra comments from my side.

    Some of your  R registers have the value a5a5a5a5, which sometimes can be shown when you have an overflow on the stack on some of the FreeRTOS tasks. You may need to increase the size of your tasks.

    Also, during debugging process, you can watch the value of PC ( program counter) when the hard fault happens and add this address value on the disassembly window on IAR, in order to detect where exactly on your program this hardfault happens, take a look on the screenshot below that shows the PC address, when I set a breakpoint on my program:

    Also, please check the link below, it maybe help you to debug hard fault on FreeRTOS projects:



  • Good point! I added the size of the stack for some tasks. I'll run testing to see if it'll help.

    I'll also keep an eye on the PC.

    Thanks AL!

  • I increased the stack size for a few tasks. I didn't see the hard fault ever since. But I saw the system hung. I ran the firmware from IAR. When the firmware is stuck, I hit the Pause button in IAR. It falls into the Idle task. Here is the call stack:


    Here is a screen shot:

    I suspect there is a dead lock besides the stack size issue. I have a recursive mutex. Previously, I called "xSemaphoreTakeRecursive(myMutex, 0xFFFFFFFF)". Now I change it to something like: xSemaphoreTakeRecursive(myMutex, pdMS_TO_TICKS(20000))
    I'll try this to see if it'll help.
    Let me know if you have any suggestions.