# xTimerReset generates hard fault

**URL:** <https://forums.freertos.org/t/xtimerreset-generates-hard-fault/8063>\
**Category:** Kernel\
**Created:** [September 18, 2019, 2:49pm UTC](https://forums.freertos.org/t/xtimerreset-generates-hard-fault/8063 "2019-09-18T14:49:27Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [September 18, 2019, 2:49pm UTC](https://forums.freertos.org/t/xtimerreset-generates-hard-fault/8063/1 "2019-09-18T14:49:27Z")

</div>

**[ffnyboe](https://sourceforge.net/u/ffnyboe/)** wrote on [Wednesday, September 18, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/9fddcf707a/#11c1):

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.

---

<div class="post-metadata">

**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\
**Post date:** [September 18, 2019, 3:06pm UTC](https://forums.freertos.org/t/xtimerreset-generates-hard-fault/8063/2 "2019-09-18T15:06:28Z")

</div>

**[richard\_damon](https://sourceforge.net/u/richard_damon/)** wrote on [Wednesday, September 18, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/9fddcf707a/#b0cf):

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.

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [September 18, 2019, 5:24pm UTC](https://forums.freertos.org/t/xtimerreset-generates-hard-fault/8063/3 "2019-09-18T17:24:59Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Wednesday, September 18, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/9fddcf707a/#11c1/4e90):

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:  
[https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html](https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html)