# Cortex M3 Tickless Idle  

**URL:** <https://forums.freertos.org/t/cortex-m3-tickless-idle/2850>\
**Category:** Kernel\
**Created:** [August 14, 2013, 8:30pm UTC](https://forums.freertos.org/t/cortex-m3-tickless-idle/2850 "2013-08-14T20:30:14Z")\
**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:** [August 14, 2013, 8:30pm UTC](https://forums.freertos.org/t/cortex-m3-tickless-idle/2850/1 "2013-08-14T20:30:14Z")

</div>

**[philbeeson](https://sourceforge.net/u/philbeeson/)** wrote on [Wednesday, August 14, 2013](https://sourceforge.net/p/freertos/discussion/382005/thread/7de6b780/#bfd2):

I’m trying to understand the CM3 /&nbsp; GCC port implementation of vPortSuppressTicksAndSleep.&nbsp; I think I understand everything except for the behaviour when entry to low power mode is aborted due to eTaskConfirmSleepModeStatus() returning eAbortSleep.

```
		/* If a context switch is pending or a task is waiting for the scheduler
		to be unsuspended then abandon the low power entry. */
		if( eTaskConfirmSleepModeStatus() == eAbortSleep )
		{
			/* Restart SysTick. */
			portNVIC_SYSTICK_CTRL_REG = portNVIC_SYSTICK_CLK_BIT | portNVIC_SYSTICK_INT_BIT | portNVIC_SYSTICK_ENABLE_BIT;
			/* Re-enable interrupts - see comments above the cpsid instruction()
			above. */
			__asm volatile( "cpsie i" );
		}

```

My understanding from the CM3 core documentation is that writing NVIC\_SYSTICK\_ENABLE\_BIT will reload the value from the SYSTICK\_LOAD\_REG and start counting down.&nbsp; Thus if the entry into sleep mode is aborted, the SYS\_TICK interval is restarted, loosing any of the tick period that has elapsed so far.

Given the amount of effort expended in trying to correct for lost clocks to the SYS\_TICK timer when it is disabled and then re-enabled when the tick-less period is generated by extending the SYS\_TICK period, this seems like a bit of an oversight.&nbsp; I therefore expect I’ve missed a subtlety in the implementation.

Can someone (Richard?) explain what I’ve missed and why restarting the SYS\_TICK timer without making a prior adjustment to the reload register is OK?

Thanks,  
Phil.

---

<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:** [August 15, 2013, 8:45am UTC](https://forums.freertos.org/t/cortex-m3-tickless-idle/2850/2 "2013-08-15T08:45:24Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Thursday, August 15, 2013](https://sourceforge.net/p/freertos/discussion/382005/thread/7de6b780/#fd61):

You are correct, this is an anomaly.&nbsp; It is very hard to get the code to go through that path, but for completeness it should be fixed.

I think copying the current count value into the reload register, starting the timer, then resetting the reload register back to its “normal” value for a tick period should be ok.

Do you agree?

Regards.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [August 15, 2013, 10:47am UTC](https://forums.freertos.org/t/cortex-m3-tickless-idle/2850/3 "2013-08-15T10:47:22Z")

</div>

**[philbeeson](https://sourceforge.net/u/philbeeson/)** wrote on [Thursday, August 15, 2013](https://sourceforge.net/p/freertos/discussion/382005/thread/7de6b780/#cede):

Thanks Richard,&nbsp;&nbsp; that’s exactly how I would resolve the issue.  
&nbsp;  
There’s obviously going to be a small drift due to the time taken to execute eTaskConfirmSleepModeStatus which I guess could be estimated in the same way you’ve already done for the other path, but given the likely infrequent execution of this path compared with the normal path, it’s probably not that important.&nbsp; I think it’s reasonable to expect some drift when using tick-less idle.

Regards,

Phil.