• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 54 subscribers
  • Views 1750 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.

CC2541 Network Processor Power Savings Initialization

Nathan Conrad
Prodigy 240 points
Other Parts Discussed in Thread: CC2541

Hello,

I'm using a CC2541 as SPI Network Processor (HostTestApp) in connectable peripheral mode with Power Savings and the GATT DB off chip.  I notice that when ever I send the GAP Make Discoverable command that the CC appears to stay in active mode for 400ms even if I send the End Discoverable and get the responses before that time expired.  Advertising, however seems to stop immediately with the End Discoverable.

I assume this is just a delay to prevent running off the sleep timer until the 32Khz crystal is started.  I am assuming this as I noticed there is an extension command to tweak this time.

  1. Is this assumption correct?
  2. Why isn't the crystal shut down and delay canceled immediately after the End Discoverable?

In the scope trace below, violet is low at the initiation of the Make Discoverable and high at the End Discoverable.  Red is a 3X current probe.

I am asking these questions because our device has modes where we have very limited power available and need to ensure the CC is in deep sleep before entering these modes.  We had previously thought that ending discovery or terminating links and waiting a few tens of milliseconds would do the trick, but it seems we have encountered some cases like this where additional waiting is necessary.

  1. Are there any other cases where terminating discovery or the connection does not put the CC back in deep sleep (immediately)? 
  2. Are there any other cases where the CC isn't in deep sleep between advertising/connection events?
  3. If so, can they be identified so we can anticipate and handle them properly? 

Thanks in advance,

Nathan

  • 0
    TI__Guru** 105180 points
    Hi Nathan,

    Can you confirm which BLE Stack version you are using?

    Best wishes
  • 0 in reply to Nathan Conrad
    Genius 3320 points

    Hello, any update on this question?

  • 0
    TI__Mastermind 29650 points
    Hi Nathan,

    As you have noticed there is a 400ms timer being set at initial boot to prevent powering down to LPM2 before the LF XTAl has started. This is done to ensure proper operation of sleep modes. If you lose/cut power to the device and restart again from scratch you will see the same over again.

    Except for this the stack will not power down the device if it does not have time until the next timed event (connection or next advertisment) or while it is processing whatever happened in a connection or handling scan responses. In your case it seems like it takes 100s of ms before you see the device powering down again which I cannot really explain based on the above power plot.

    Are you using a out-of-the-box HostTest project or have you done any modifications to it?

    Regards,
    Svend
  • 0 in reply to svendbt
    Prodigy 240 points

    Svend,

    HostTest project CC2541SPI build of the 1.4 stack with the POWER_SAVING and GATT_DB_OFF_CHIP preprocessor configurations.  No modifications were made to the code besides these configurations.

    Thanks,
    Nathan

  • 0
    Prodigy 240 points

    It gets worse.  I added a work around to delay for the cases of 400ms of excess current after the start and end discoverable but am still having issues with the CC2541 consuming current where it probably shouldn't need to.  I isolated the CC2541 traces on my board and added a high resolution current probe between the supply and the CC2541.  When I zoom in on the current axis at the start and end discoverable events, I also see a weird ramp for almost 5 seconds that eventually hits more than 0.2mA peak before returning to normal.  Can this be explained?  I can work around a 400ms delay, but a 5 second delay would kill the user experience of our application.

    Thanks,

    Nathan

  • 0 in reply to Nathan Conrad
    TI__Mastermind 29650 points
    Nathan,

    The current ramp looks to me like something that can happen due to a floating input pin without pull enabled.

    .:Svend
  • 0 in reply to svendbt
    Prodigy 240 points
    Makes sense. I set the GPIO without pull as outputs, the SPI inputs should be held by the other micro, and I leave the others as is (which looks like it turns the pull on). Is the SPI output MISO taken out of output/peripheral mode with power savings or something? I will try pulling it.
  • 0 in reply to Nathan Conrad
    TI__Mastermind 29650 points
    The IO's should all retain their mode and/or output value in all power modes.
  • 0 in reply to svendbt
    Prodigy 240 points
    If that is the case, aren't all of the GPIO but the SPI left to the default (input w/ pull-up) with the HostRelease? As I mentioned I took care of the 20mA pins which don't have pullups by initializing them as outputs. We aren't using any other GPIO pins besides the SPI, SRDY (SPI interrupt), and the other obvious ones (crystals, power, bias, antenna).
  • 0 in reply to Nathan Conrad
    Prodigy 240 points
    OK. The weird current ramp problem is solved. It was indeed the MISO pin floating. This is most likely coming from the multiple-slave capability of the SPI peripheral is unrelated to the power mode. I was incorrectly assuming it would remain an output. This obviously would break the capability of having multiple slaves. I will assume this is my own problem. Thanks for pointing to the IO pin and the solution.