• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 54 subscribers
  • Views 2298 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SDK V1.2.1 hal_sleep.c halSleep() Bug?

Eng351
Genius 4125 points

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

  • 0
    Genius 4125 points

    Further to this, simply, max possible value of timeout = 0xFFFFFFFF, so max value after timeout >>= 16 is 0xFFFF i.e. 2s

  • 0 in reply to Eng351
    Genius 4125 points

    Any answers from TI on this? Is this a bug or a feature?

  • 0 in reply to Eng351
    TI__Guru 57865 points

    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

  • 0 in reply to J Lindh
    Genius 4125 points

    Thanks Nick, have added a work around.

  • 0 in reply to Eng351
    Prodigy 10 points

    For me

    timeout = HAL_SLEEP_MS_TO_32KHZ( osal_timeout );

    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

  • 0 in reply to J Lindh
    Prodigy 40 points

    Hi, 

    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

  • 0 in reply to Szer Ming Lee
    Prodigy 70 points

    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.