xTimerReset generates hard fault

ffnyboe wrote on Wednesday, September 18, 2019:

Calling xTimerReset on a specific timer generates a hard fault. The timer is in dormant state before the call. I use the method another place in my program on another timer without problems.
I have tried checking if the timer object is NULL, which it isn’t (I know that using API methods on kernel objects that have not been created generates hard faults, but the object is created properly).
If the priority of the calling task is higher than the one of the daemon task, control returns from xTimerReset and continues further in the task code and the hard fault happens at a later time when the calling task blocks, however if the priority of the daemon task is higher - meaning that control passes to the daemon task before returning from the xTimerReset call - the hard fault happens right away. This indicates that the hard fault happens somewhere within the daemon task, to my best knowledge.

I hope that somebody has suggestions on what to do.

I use FreeRTOS v.10 on a ARM Cortex M4 processor.

richard_damon wrote on Wednesday, September 18, 2019:

One possible cause is memory corruption has overwritten some of the data in the timer structure, or the handle you are using to access the timer.

rtel wrote on Wednesday, September 18, 2019:

Let’s start by validating that the hard fault occurs in the timer task -
wait until the hard fault occurs then inspect the xCurrentTCB variable
in the debugger. You will probably have to cast the variable as “(
tskTCB* ) pxCurrentTCB” to see its internals. One of the structure
members is the task’s name. Is it the timer task? If so we can try
putting a break point in that task where it resets the offending timer.

If you want to go further and potentially find the source of the hard
fault you can follow the instructions here: