• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 50 subscribers
  • Views 1411 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.

400ms delay before entering PM2

Marty Holmquist
Prodigy 240 points
Other Parts Discussed in Thread: CC2541

Hello,

I'm seeing 400ms before PM2 is entered. No matter what event/methods are called the CC2541 stays in a 8mA draw for the 400ms after BLE and other higher current events finish. POWER_SAVING mode is enabled and I've seen other folks state simular issues, but have not heard a common fix. 

My code was built off the SensorTag source code.

Let me know what further information you may need to help suggest a place to look. I've tracked the tasks and events and found that following are repeating when I call my period event.

LL_ProcessEvent (Task 0 )  Event codes 128 and 256(??? Don't know what events these are)

GAPRole_ProcessEvent(Task 8) Event code 32768/GAP_ADV_DATA_UPDATE_DONE_EVENT

GAP_ProcessEvent(Task 5) Event code 32768/GAP_ADV_DATA_UPDATE_DONE_EVENT

SensorTag_ProcessEvent(Task 11) Event code 4 (My periodic event)

The event codes 32768 are likely the same event and being passed off between tasks.

 

Any ideas on where to look would be highly appreciated!

Marty

  • 0
    TI__Genius 17975 points

    You can call the function HCI_EXT_DelaySleepCmd (prototype and description in the file hci.h) to change this delay time from the default value of 400. Note that 400 is a safe value in that it allows for enough time for the crystals to stabilize. Reducing this value could potentially cause undesirable behavior.

  • 0 in reply to Willis1
    Prodigy 240 points

    Thanks Willis.  In reading about that function it states that this is for waking from PM3. This makes sense for the stability on delay since the crystal is off in PM3. BUT, I'm using PM2 which leaves the crystal running. Additionally my issue is not with a startup delay, but with entry into power saving mode.  

    I will try adjusting this value and see if it impacts the timing, but if it does that would seem to be a bug to me. Unless I made a modification that causes the OSAL to think it's turning on from PM3 versus entering PM2.  If that is even possible??? But I'll look for all options at this point!

  • 0 in reply to Marty Holmquist
    Prodigy 240 points

    Changing the value on HCI_EXT_DelaySleepCmd to 20ms did work!  But the question still stands on why this delay is there for entry into PM2 mode from normal operation.  I will check if I'm inadvertently going into PM3 mode, but not sure my code would ever wake up if it was doing so. My tests are not using an external IRQ that would wake the device.  

    So, should I be setting the delay to 0 for my scenario?  (Only using PM2)

    Thanks!!!

  • 0 in reply to Marty Holmquist
    Prodigy 240 points

    I changed the setting to 0 and confirmed that my BLE still worked.  So I would say this is the answer to my problem. I would request that TI update their documentation on this function and parameter to reflect it's behavior in PM2. Even better, ignore this delay unless starting up from PM3 as it's presently documented. 

    Hopefully this helps someone else that has been dealing with the problem!

    Marty