CC2650 How to wakeup module weekly

Rajneesh,

The argument for Task_sleep() is a number of system Clock ticks.  By default the Clock tick period for CC26xx and CC13xx devices is configured at 10 microseconds.  (This value was chosen based on many tradeoffs that I won’t go into details about here.)  So this means, with a 32-bit tick counter, the default maximum duration for Task_sleep() is 11.93 hours. 

If you want to be inactive for a week or a month, it is probably best to go into “Shutdown” mode.  This will give even better power savings, but will require the application to be structured to warm boot from reset.  While the Standby mode can be activated automatically by the Power Manager, the Shutdown mode requires an explicit call by the application to the Power_shutdown() API.

The Bluetooth Smart forum (e2e.ti.com/.../538) has several threads and advice regarding using Power_shutdown().  You might look there...

Regards,
Scott

Rajneesh,

Yes, you can use the RTC to wake the device from Standby.  That is the main reason the Clock module uses the RTC, so the device can wake ‘naturally’ from power saving states, when there is actual work to do.  

The Clock module is configured to run in a tick suppression mode (called TickMode_DYNAMIC), where the next interrupt is programmed for when there is scheduled work, rather than on every periodic interval.  (That is the only reason the Clock tick period can be set to 10 microseconds, because if the device had to indeed wake every 10 microseconds there’d be no time to do actual work or save any power.)  One of the consequences of the implementation is that the CPU must wakeup before the Clock tick counter wraps thru 32-bits, otherwise the tick counter loses sync to actual time.  (This is the 'maximum suppressible tick count', which ensures the Clock module wakes in time to keep sync.)  So with the current Clock configuration and power management implementation, the device will always wake from Standby at least once every 11.93 hours.  If there is nothing to do, the device will immediately transition back into Standby.  It was anticipated that Shutdown mode would be used for very long durations of inactivity.

An obvious thing to do would be to increase the Clock tick period to be greater than 10 microseconds.  The consequence here is that the tick resolution expected by the radio stacks is increased, affecting accuracy.  And also, the RCOSC calibration used on each wake from Standby uses the Clock module for delays, so extending the tick period will extend the calibration latency.

I don’t know about your particular use case and accuracy requirements, but it might be OK for you to increase the Clock tick period, so you can use Task_sleep() for longer durations.  In your application configuration file you probably have “Clock.tickPeriod = 10;”.  You can try increasing the value of ‘10’ microseconds, and then change the number of ticks passed to Task_sleep().

Another option might be to keep the current Clock configuration, and then on each wakeup check to see how close the RTC time is to the target wake time.  If you are not close to your target time, do nothing, and check again after the next 11.93 hour wakeup.  I'd guess this is probably not what you want to do, but it is an option, to use the existing implementation and stay in Standby as long as possible, without affecting Clock accuracy.

Yet another option could be to have an external trigger wake the device from shutdown at the appropriate time.  This obviously requires some external source for triggering the interrupt at a specific time.

I hope all the above makes sense.  There are a lot of details and tradeoffs involved here.  These are the best suggestions I have at this point.

Again, you might post a question to the Bluetooth Smart forum to see if there are any suggestions there…

Regards,
Scott

Hi Scott,

I have a question about "tick suppression". Why do we need to set clock tick when "tick suppression" is already used?

According to my understand of Cortex M, the CPU has a built-in SysTick timer which is used as kernel ticker. The implementation of tick suppression is to predicate/calculate the next expiration time of SysTick and configure the timer in advance. At least, I implement it in my own RTOS in this way. So, in my RTOS, there is no need to set clock tick since there is no more "tick period". A task can sleep at 1ms, 10ms or 100ms and kernel will wakeup after 1ms, 10ms or 100ms, respectively.

Unfortunately, the SysTick timer is only 24bits and driven by 48MHz. That means the maximum expiration time of SysTick is 349us. For every 349us, CPU will be activated to execute SysTick exception handler even there is nothing to do. This is not good. So, I am also very curious about how to change the clock source SysTick timer.