TI E2E Community
Low Power RF & Wireless Connectivity
Low Power RF Bluetooth® Low Energy & ANT Forum
SDK V1.2.1 hal_sleep.c halSleep() Bug?
I am having some issues with the latest SDK hal_sleep.c halSleep( uint32 osal_timeout ) function:
With the RF disabled, theOSAL is passing in a wakeup time of 30,000 (30s), but it is waking up every 2.00s (verified by scope).
I debugged halSleep() and found that the code which calculates the number of 32.768kHz cycles to sleep for is returning the wrong number - 0x0000FFFF which is causing the exact 2s wakeup.
The following code is where the problem happens (In the previous step osal_timeout is 30,000 as expected):
// get next OSAL timer expiration and convert to 32kHz units // Note: Could be early by one 32kHz timer tick due to rounding. timeout = llDivide31By16To16( (uint32)osal_timeout*4096, 125 );
After this line, timeout = 4294901885 (0xFFFF007D). Then:
// only need the quotient timeout >>= 16;
After this line, timeout = 65535 (0x0000FFFF) (as expected from above), but the result should be 983040 (0x000F0000).
Has anyone seen this before? I have tried with compiler optimization on and off but this makes no difference.
Further to this, simply, max possible value of timeout = 0xFFFFFFFF, so max value after timeout >>= 16 is 0xFFFF i.e. 2s
Any answers from TI on this? Is this a bug or a feature?
Good catch, it is a bug which will we fixed in the next stack release. In the meantime you can change the timeout value as follows:
timeout = HAL_SLEEP_MS_TO_32KHZ( osal_timeout );
Thanks Nick, have added a work around.
solves only the issue for periodic events.
Setup: Advertisment every 5 seconds
The function: LL_TimeToNextRfEvent( &sleepTimer, &llTimeout ); returns: first call: 65535, second call: 65535, third call: 32972
The result should be the sum of those three. So what happens is, it will wake up after 2 seconds with the wakeForRF flag set to TRUE and won't enter sleep mode until the RF event 3 seconds later.
Has anyone seen this before? Is there a workaround to calculate the real time for the next RF Event?
We are seeing exactly the behaviour described even after fixing the timeout calculation as recommended. We have out advertisement set at 10s, we see the device wake up after 2 seconds and then will not return back to sleep until the next advertisement.
Further to Szer Ming's comment: after fixing the timeout calculation, if we turn off advertising activity (no radio events scheduled), and set an application timer to fire after some long interval (for example 100 seconds) the CPU still wakes every 2 seconds. The application event fires correctly after 100 seconds but all those extra unnecessary wake ups (they require >~1ms each) eat into the DC power budget.
What does the function LL_TimeToNextRfEvent return when there is no radio event scheduled? I'm not able to find any documentation that tells me how the 2 return parameters behave.
Is this behaviour fixed in v1.3? Or is there a way to get this working correctly in v1.21. We would rather get a workaround for v1.2.1 if that's possible.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.