# Which is the right way to start a one-shot timer?

**URL:** <https://forums.freertos.org/t/which-is-the-right-way-to-start-a-one-shot-timer/17303>\
**Category:** Kernel\
**Created:** [April 27, 2023, 8:39am UTC](https://forums.freertos.org/t/which-is-the-right-way-to-start-a-one-shot-timer/17303 "2023-04-27T08:39:59Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mr\_M\_from\_K](https://avatars.discourse-cdn.com/v4/letter/m/ea5d25/32.png) [@Mr\_M\_from\_K](https://forums.freertos.org/u/Mr_M_from_K)\
**Post date:** [April 27, 2023, 8:39am UTC](https://forums.freertos.org/t/which-is-the-right-way-to-start-a-one-shot-timer/17303/1 "2023-04-27T08:39:59Z")

</div>

I created a timer using xTimerCreateStatic(), setting period to pd\_MS\_TO\_TICKS(500). Then later I started the timer with xTimerStartFromISR and found that the timer callback function was immediatelly executed. I changed to using xTimerChangePeriodFromISR, setting period (again) to pd\_MS\_TO\_TICKS(500).  
Is that intended behaviour? I would have expected xTimerStartFromISR to also start a 500 msec interval.  
Thanks for any help  
Martin

---

<div class="post-metadata">

**Author:** ![tony-josi-aws](https://avatars.discourse-cdn.com/v4/letter/t/a6a055/32.png) [@tony-josi-aws](https://forums.freertos.org/u/tony-josi-aws)\
**Post date:** [April 27, 2023, 11:56am UTC](https://forums.freertos.org/t/which-is-the-right-way-to-start-a-one-shot-timer/17303/2 "2023-04-27T11:56:31Z")

</div>

> Is that intended behavior?

No  
[[refer](https://www.freertos.org/FreeRTOS-timers-xTimerStart.html)]:  
… if the timer is not stopped, deleted, or reset in the mean time, the callback function associated with the timer will get called 'n 'ticks after xTimerStart() was called, where ‘n’ is the timers defined period. …

What FreeRTOS port/ HW arch are you using? Does the ISR that calls `xTimerStartFromISR()` has the logical priority less than or equal to [`configMAX_SYSCALL_INTERRUPT_PRIORITY`](https://www.freertos.org/a00110.html#kernel_priority) ?

Also, how did you verify that the callback is called immediately called after `xTimerStartFromISR()`?

---

<div class="post-metadata">

**Author:** ![Mr\_M\_from\_K](https://avatars.discourse-cdn.com/v4/letter/m/ea5d25/32.png) [@Mr\_M\_from\_K](https://forums.freertos.org/u/Mr_M_from_K)\
**Post date:** [April 27, 2023, 1:03pm UTC](https://forums.freertos.org/t/which-is-the-right-way-to-start-a-one-shot-timer/17303/3 "2023-04-27T13:03:06Z")

</div>

Hello tony josi,  
I read these lines too, but found something else, thats why I ask.  
I am working with STM32G0B0 = ARM Cortex M0+ and FreeRTOS 10.5.1. I think interrupt priorities don’t play a role here (??). I don’t have configMAX\_SYSCALL\_INTERRUPT\_PRIORITY defined.  
I found out by sending a message via UART. I made sure in the isr that all bytes are out before leaving the isr. Also I send a message from the timer callback, also making sure that all bytes are out before leaving the callback function. I use a terminal program (YAT) that displays the time for each line. The difference is quite clear to see, just checked it again.  
Any help is welcome (while currently I am happy with xTimerChangePeriodFromISR)  
Martin

---

<div class="post-metadata">

**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\
**Post date:** [April 27, 2023, 2:12pm UTC](https://forums.freertos.org/t/which-is-the-right-way-to-start-a-one-shot-timer/17303/4 "2023-04-27T14:12:33Z")

</div>

I don’t know about intended behavior, but it is explainable behavior that xTimerStartFromIsr() and xTimerResetFromIsr() behave as you observed in tickless idle.

The forum has a couple of different threads that explain. Here is a good one where I managed to save all of humanity:

> [@Timer callback executes immediately after start/reset of timer](https://forums.freertos.org/t/timer-callback-executes-immediately-after-start-reset-of-timer/16167):
>
> I’m using SiliconLabs Gecko SDK v4.1.2 which comes with FreeRTOS Kernel V10.4.3. I’m using FreeRTOS timer to trigger messages to another task after 5 seconds. My code starts/resets the timer when the button is pressed, and stops the timer when released. If I hold the button for 5 seconds, the callback function is called as expected. The problem i’m having is if I press the button (start/reset timer) and release the button (stop timer), then wait 5 seconds, and press the button again (start/…

---

<div class="post-metadata">

**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\
**Post date:** [April 27, 2023, 2:14pm UTC](https://forums.freertos.org/t/which-is-the-right-way-to-start-a-one-shot-timer/17303/5 "2023-04-27T14:14:31Z")

</div>

Another one. Although the diagram no longer looks right (in my browser at least).

> [@xTimerStartFromISR() and xTimerResetFromISR() with tickless idle](https://forums.freertos.org/t/xtimerstartfromisr-and-xtimerresetfromisr-with-tickless-idle/11560):
>
> When used with tickless idle, xTimerStartFromISR() and xTimerResetFromISR() might not behave as expected. For reference, these functions capture the current tick count (in the ISR) for use as the start time of the timer. If the ISR happens to interrupt a tickless idle period, the captured tick count isn’t current. It hasn’t yet been corrected by the tickless logic. The correction occurs immediately after the ISR. As a result, the timer is unexpectedly started from a time in the past, possib…

---

<div class="post-metadata">

**Author:** ![Mr\_M\_from\_K](https://avatars.discourse-cdn.com/v4/letter/m/ea5d25/32.png) [@Mr\_M\_from\_K](https://forums.freertos.org/u/Mr_M_from_K)\
**Post date:** [April 27, 2023, 3:03pm UTC](https://forums.freertos.org/t/which-is-the-right-way-to-start-a-one-shot-timer/17303/6 "2023-04-27T15:03:35Z")

</div>

Hi Jeff,  
thanks for your answer and the info, I hope to keep it in mind.  
Yes, I’m fine with xTimerChangePeriodFromISR.

Martin

---

<div class="post-metadata">

**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\
**Post date:** [April 28, 2023, 12:50am UTC](https://forums.freertos.org/t/which-is-the-right-way-to-start-a-one-shot-timer/17303/7 "2023-04-28T00:50:52Z")

</div>

It does seem a little odd to have to call xTimerChangePeriodFromISR(). Since this issue has come up a couple of times, here’s a possible fix for combining tickless idle and xTimerStartFromISR().

> <https://github.com/jefftenney/FreeRTOS-Kernel/commit/110f6044>
>
> Prior to this commit, functions xTimerStartFromISR() and
> xTimerResetFromISR() ma…y not behave as expected when called from an ISR
> that interrupts a tickless idle period. The expected start time (or
> reset time) of the timer is the time at which the ISR calls the timer
> function, but prior to this commit the actual start time (or reset time)
> was the time at the beginning of the tickless idle period.
> 
> The root cause is a stale value being returned by
> xTaskGetTickCountFromISR(). The value is stale because the ISR executed
> before the tickless logic corrected the system tick count. This commit
> adds a configuration option allowing the timer task to replace the stale
> tick count with the current tick count.
> 
> In configurations with tickless idle disabled, the new option defaults
> to disabled, for backward compatibility. With tickless idle enabled,
> the new option defaults to enabled, which represents a change in
> behavior from before this commit. The changed behavior is closer to
> expected behavior for tickless implementations that allow the ISR to
> execute prior to correcting the system tick count.
> 
> Tickless-idle implementations that correct the system tick count prior
> to allowing the ISR to execute may explicitly disable the new option
> as those systems have no need for this option.

If there is interest I am happy to open a PR.
