• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 50 subscribers
  • Views 1265 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BLE stack disabling low power mode

Peter Borenstein
Mastermind 8695 points
Other Parts Discussed in Thread: CC2541, CC2540

Hi all,

A hidden component of the stack has been turning off low power mode.  osal_pwrmgr_device(PWRMGR_ALWAYS_ON) is being called from some hidden part of the code. 

I saw the same thing on cc2541 and cc2540. 

The problem magically went away. I still see osal_pwrmgr_device(PWRMGR_ALWAYS_ON) called, but now it is quickly followed up by osal_pwrmgr_device(PWRMGR_BATTERY). I assume that the function is being called by the Link Layer based on the program counter.

I fear this may happen again.

Additional background:

The core pulls around 6 to 7mA when active. This power rate destroys coin cell batteries. The stack will put the device in power mode 2 if all layers of the stack are in agreement. A layer can request not to go into power mode by calling osal_pwrmgr_device(PWRMGR_ALWAYS_ON) 

  • 0
    TI__Expert 6840 points

    Hello,

    This is part of PM3 wake up sequence. You can change this value if you want,but risk PM2 not operating correctly is you shorten, reduce it, and enter PM2 too quickly.

    1.4 release notes

    - Added an HCI Extension command HCI_EXT_DelaySleepCmd which provides the user 
    control of the system initialization sleep delay (wake time from PM3/boot 
    before going back to sleep). The default sleep delay is based on the 
    reference design 32 kHz XOSC stabilization time.

    /*
    ** Ensure the 32kHz crystal is stable after POR/External Reset/PM3
    ** before allowing sleep.
    ** Note: There is nothing in hardware to indicate this to software.
    */
    if ( events & LL_EVT_START_32KHZ_XOSC_DELAY )
    {
    // check if the delay hasn't been disabled
    if ( sleepDelay )
    {
    osal_pwrmgr_device( PWRMGR_ALWAYS_ON );

    osal_start_timerEx( LL_TaskID, LL_EVT_32KHZ_XOSC_DELAY, sleepDelay );
    }

    BR,

    -Greg

  • 0 in reply to GregS
    Mastermind 8695 points

    Hi Greg,

    Thank you for the reply. Unfortunately, I don't think your solution applies to me as HCI_EXT_DelaySleepCmd is not called anywhere in my code.  In the sample code provided by TI, PWRMGR_ALWAYS_ON is set, and normally it is quickly followed by PWRMGR_BATTERY. 

    I see in the disassembly window that the LL_ProcessEvent() function calls osal_pwrmgr_device() at two separate points in the code. What is the other LL event that sets PWRMGR_ALWAYS_ON, and what could be stopping that event from not setting PWRMGR_BETTERY?

    I am seeing all of this using the TI Sensor Tag and I'm running an unmodified version of the SimpleBLE Peripheral written by TI. The issue disappeared before, and now it has returned

  • 0 in reply to Peter Borenstein
    Mastermind 8695 points

    Hi Greg,

    My placement of breakpoints may have been upsetting the system.  I see the TI devices and my devices got into PM2 depending on where I place breakpoints in IAR.