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.
Help please
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?
Hi,
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 );
Best Regards
Thanks Nick, have added a work around.
For me
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?
Best regards
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.
Thanks
Szer Ming
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.