Hello,
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?
Thanks.
I have found that when the debugger is connected (or even SeggerRTT) to my RA6M5 the watchdog reset is disabled. I believe this is intentional so that break points won't cause watchdog resets.
Thanks for your info, David.
I suppose one or some of my tasks are getting stuck after running a few hours. I'm wondering if you know a way to detect which task(s) getting stuck.
I appreciate it. Thanks!
Hello pilot,
There is a way for runtime- debug using Tracealyzer 4 provided from percepio. Please check the app note that describes the whole process using e2studiο ( it includes all the necessary FSP FreeRTOS configuration settings) with Tracealyzer:
https://www.renesas.com/us/en/document/apn/renesas-ra-family-tracealyzer-freertos-debugging-application-note
You mentioned that you use IAR, it seems that Tracealyzer is supported with IAR tool, check the link below:
https://percepio.com/tracealyzer/gettingstarted/iar/
Υοu can understand that there isn't an obvious answer for your request, especially when the firmware hungs after hours.
About watchdog behavior when debugger is connected as mentioned from David, please check the comment below:
ΡRegards,
AAL_Renesas
Thanks AAL.
I'll try Tracealyzer.
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:
https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html?_ga=2.90016091.1748994012.1720603956-2039124593.1688650110
Regards,
AL_Renesas
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:
rm_freertos_port_sleep_preserving_lpm vApplicationIdleHook prvIdleTask prvTaskExitError
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.Thanks!