Possible Cortex-M tickless idle OBO's

tzc0der wrote on Friday, June 28, 2013:

Atmel SAM4S (CM4), FreeRTOS 7.4.2, Atmel Studio (GCC)

In port.c, the systick reload value is calculated thus:

 ulTimerReloadValueForOneTick = ( configSYSTICK_CLOCK_HZ / configTICK_RATE_HZ ) - 1UL; [\code]
... which makes sense according to the datasheet (SAM4S), but later, the code calculates how many 'normal' tick periods have passed in an extended sleep time:
[code]
/* Something other than the tick interrupt ended the sleep.
Work out how long the sleep lasted. */
ulCompletedSysTickIncrements = ( xExpectedIdleTime * ulTimerReloadValueForOneTick )  - portNVIC_SYSTICK_CURRENT_VALUE_REG;
/* How many complete tick periods passed while the processor
was waiting? */
ulCompleteTickPeriods = ulCompletedSysTickIncrements / ulTimerReloadValueForOneTick;
[\code]
In each of these calculations, shouldn't [b](ulTimerReloadValueForOneTick + 1)[/b] be used instead of  [b]ulTimerReloadValueForOneTick[/b] due to the fact that the period is actually one more than the reload value?
This hasn't caused any issues that I know of so far and the reload values are usually quite large so the error is small, but I thought I would ask/point this out. 
Thanks.

tzc0der wrote on Friday, June 28, 2013:

Atmel SAM4S (CM4), FreeRTOS 7.4.2, Atmel Studio (GCC)

In port.c, the systick reload value is calculated thus:

ulTimerReloadValueForOneTick = ( configSYSTICK_CLOCK_HZ / configTICK_RATE_HZ ) - 1UL; 

… which makes sense according to the datasheet (SAM4S), but later, the code calculates how many ‘normal’ tick periods have passed in an extended sleep time:

/* Something other than the tick interrupt ended the sleep.
Work out how long the sleep lasted. */
ulCompletedSysTickIncrements = ( xExpectedIdleTime * ulTimerReloadValueForOneTick )  - portNVIC_SYSTICK_CURRENT_VALUE_REG;
/* How many complete tick periods passed while the processor
was waiting? */
ulCompleteTickPeriods = ulCompletedSysTickIncrements / ulTimerReloadValueForOneTick;

In each of these calculations, shouldn’t (ulTimerReloadValueForOneTick + 1) be used instead of  ulTimerReloadValueForOneTick due to the fact that the period is actually one more than the reload value?

This hasn’t caused any issues that I know of so far and the reload values are usually quite large so the error is small, but I thought I would ask/point this out.

Thanks.
P.S Can someone delete the previous post with bad formatting?

rtel wrote on Friday, June 28, 2013:

Thanks for pointing this out - it is not the first time I have made similar errs, and probably won’t be the last.  There is also one other change that needs to be made to the tickless implementation in the circumstance that an interrupt other than the tick brings the MCU out of low power.  I will try and address these issues shortly.

Regards

tzc0der wrote on Friday, June 28, 2013:

Thank you. I look forward to seeing the changes and learning from your implementation.

rtel wrote on Sunday, June 30, 2013:

I have refined the implementation in all the ports:

http://freertos.svn.sourceforge.net/viewvc/freertos/trunk/FreeRTOS/Source/portable/GCC/ARM_CM3/port.c?revision=1957&view=markup

Regards.