Thanks aggarg!
Once I captured the call stack when the firmware got stuck. It’s something like this:
StopDebugger
TaskExecution
TimerProcessInterrupt
r_gpt_call_callback
< Exception frame >
rm_freertos_port_sleep_preserving_lpm
vApplicationIdleHook
[Region$$Table$$Base + 0xe]
In the code:
“Renesas\aws\amazon-freertos\freertos_kernel\tasks.c”, the function “static portTASK_FUNCTION( prvIdleTask, pvParameters )” calls the function “vApplicationIdleHook();” which is in “Renesas\fsp_3.5.0\ra\fsp\src\rm_freertos_port\port.c”.
In the “vApplicationIdleHook()” function, it calls “rm_freertos_port_sleep_preserving_lpm(1);”
I’m not sure how the firmware runs into this function. I increased the stack size for a few tasks. So far, I haven’t seen any hard fault. Can we firmly say that the hard fault issue is fixed by increasing the stack size for those tasks?
Meanwhile, I’m not sure if the firmware stuck issue is a kind of hard fault. This is the issue I’m trying to figure out. The problem is, I don’t know what happened when the firmware got stuck. The behaviour is, the firmware got stuck for about 30 to 40 seconds. Then the firmware restarts itself. I’m trying to see if it’s related to the semaphore or mutex I used. Other than the semaphore/mutext, is there other possible cause of the stucking issue?
I also look for some way to find out what exactly happened when the firmware got stuck. I haven’t get Tracealyzer working with IAR yet. Please let me know if you have some other ways to help me find out the cause of the issue.
Thanks!