• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 51 subscribers
  • Views 436 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.

CC2652R7: How can I know which module is preventing low power mode?

Esteban Ortiz
Prodigy 10 points

Part Number: CC2652R7

I have a custom board with a custom application that is exhibiting higher than expected power consumption. I wrote a debug function using Power_registerNotify to figure out if we are going down to low power mode and added the callback in the main task, but the notification is never happening. From this, and the high consumption, I can only assume my application is never going down to standby or low power. I'm using the default policy (SB) that says is very agressive and will go to SB whenever possible. 

Is there a way for me to figure out which module is preventing the application from going into SB? I'm using IAR and SDK simplelink_cc13x2_26x2_sdk_5_10_00_48.

Thanks,

  • 0
    TI__Mastermind 35070 points

    Hi,

    Can you describe at a high level what your application is doing?

    Is your firmware based off of one of our SDK examples?
    https://dev.ti.com/tirex/explore/node?node=A__AJE5PlHxcCS3M1k4fd7DWw__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST

    Since you've posted in the Bluetooth forum, probably a BLE5-Stack example?

    To check if it is a HW module keeping the device in active, the registers here may be referenced: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_10_01_24/docs/driverlib_cc13xx_cc26xx/cc13x2x7_cc26x2x7/register_descriptions/CPU_MMAP/PRCM.html 

    I'd recommend checking the PRCM registers, such as:

    • PDCTL0
    • PDSTAT0
    • PDCTL1
    • PDSTAT1

    After that, you can check the different peripherals that may require active mode.
    For example, to check this for UART, these registers are relevant:

    • UART0.CTL.UARTEN

    Thanks,
    Toby

  • 0 in reply to Toby
    Prodigy 10 points

    Thanks Toby, 

    Yes, the application is based on the simple_peripheral SDK example. The application is an interface to an ASIC that generates analog signals and a lot of data that gets streamed back over BLE. We are trying to reduce power to a minimum while the system is idle, meaning the ASIC is gated and no BLE activity happens, apart from advertising at a low rate. 

    Looking at the registers was very useful as it allowed me to see that many of the modules have CLK EN during sleep or deep sleep, so, I have a follow up question:

    If I2CCLKGR = I2CCLKGS = I2CCLKGDS = CLK_EN = 1, does this mean that my I2C module will prevent deep sleep because they require the clock to be running, or does it mean that only that particular module will not go to deep sleep?

    I'm thinking on modifying my I2C code to close the handle as soon as the I2C transactions are done, so I2C hardware resources are unused most of the time during idle state.

    Thanks

  • 0 in reply to Esteban Ortiz
    TI__Mastermind 35070 points
    Esteban Ortiz said:
    If I2CCLKGR = I2CCLKGS = I2CCLKGDS = CLK_EN = 1, does this mean that my I2C module will prevent deep sleep because they require the clock to be running, or does it mean that only that particular module will not go to deep sleep?

    Yes, that would be my understanding.

    Typically, for lowest power operation, we recommend to call *_close for any modules that aren't being used.

    Can you try calling I2C_close when the application is ready to enter low power?
    Depending on the I2C ASIC, before I2C_close, you may also need to send some I2C command to put that ASIC in low power mode.

  • 0 in reply to Toby
    Prodigy 10 points

    Do you know if the same logic applies to the GPIO module? I see GPIOCLKGDS and GPIOCLKGS having 1's in the CLK_EN position, but those modules don't have the GPIO_open/close function. And I think it makes sense since you don't want the GPIO module to release the pin states during low power. How would I configure the GPIO module to go down to deep sleep? 

    Thanks 

  • 0 in reply to Esteban Ortiz
    TI__Mastermind 35070 points

    GPIO states are preserved in Standby.

    Excerpt from datasheet:

    In other words, GPIO would not prevent Standby.