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

CC2652RB: CC26X2 Power Policy Driver standby to sleep

POTNURU SAATHWIK
Prodigy 30 points
Part Number: CC2652RB

Hi,

We are Interfacing the Vibration sensor to CC2652RB through SPI communication protocol, The slave device(sensor) is operated at different output data rate's (100Hz, 1600Hz, 3200Hz,...)

we are reading 40 samples(240 bytes) of raw data from the sensor buffer FIFO using a watermark count in a single SPI Multi byte read transaction and transmitting the sensor data over BLE. SPI is configured in blocking mode.

A timer is used to call SPI Multibyte read transaction depending on the configured Sensor output data rate(i.e., at 1600Hz, SPI Multibyte read is called at every 25 milliseconds, at 3200Hz, SPI  Multibyte read is called at every 12.5 milliseconds).

We observed that, MCU is going to Standby state between SPI Multibyte read transactions at 1600Hz (25 milliseconds between two SPI read operation) and  MCU is NOT going to Standby state at 3200Hz(12 milliseconds between two SPI read operation) and higher ODR's.

To debug this we added TI power policy driver and observed that Power_sleep() function is not getting executed at higher data rate's(3200Hz and above). i.e., MCU is not going to standby state between SPI transactions.

We want to know more details about the conditions for power policy driver to invoke Power_sleep()  function.

Thanks in advance,

Regards,

Saathwik.

  • 0
    TI__Mastermind 34940 points

    Hi,

    Which SDK are you using?

    The device will go into the lowest power state it can go, given the current state of the MCU, such as which peripherals are active.

    Another determining factor is if the device is able to go into sleep for > 2 ms. This is to account for overhead of entering/leaving standby.

    How long does the device spend processing the sensor data? If it is a lot of data, perhaps there is not that 2 ms margin for the the device to go to standby.
    Could you perhaps add in a GPIO toggle before/after the sensor read to see how much time the device is able to enter sleep?

    In addition to the Power_sleep() function, you may also want to check out PowerCC26XX_standbyPolicy (defined in C:\ti\simplelink_cc13x2_26x2_sdk_5_10_00_48_s\kernel\tirtos\packages\ti\dpl\PowerCC26X2_tirtos.c).

    Thanks,
    Toby

  • 0 in reply to Toby
    Prodigy 30 points

    Thank you Toby Pan for your reply,

    We are currently using SDK version simplelink_cc13x2_26x2_sdk_4_10_00_78.

    As mentioned, we are collecting 240 bytes of sensor data in a single SPI Multi byte read transaction, To process the Sensor data and transmit the data over BLE, the time consumed is approximately 1.6 ms (0.5 ms for processing + 1.1ms for transmitting).

    As per calculations, at 3200Hz sensor output data rate, SPI read is called for every 12 ms. After SPI read, as part of debug added SPI_close() after multi byte read, to make sure that there are no SPI transactions after a single Multi byte read. with this we are ensuring that there is no activity on MCU till the next SPI read. The MCU is idle for approximately10 milliseconds between SPI transactions and expected to go to standby. Still we observe Power_sleep() is NOT getting invoked and MCU is not going to standby.

    According to timing analysis, as MCU has enough time to go to standby, what are the other constraints we can look into to debug this further?

    Regards,

    Saathwik

     

     

     

  • 0 in reply to POTNURU SAATHWIK
    TI__Mastermind 34940 points

    To narrow down what could be holding off the standby mode, try checking the PRCM registers.
    Specifically, PDSTAT0 and PDSTAT1 that show which power domain is enabled.

    This can then be mapped to the power modes table in the TRM section 7.6.

  • 0 in reply to Toby
    Prodigy 30 points

    As Advised observed the PRCM registers,PDSTAT0 and PDSTAT1. we noted that, when sensor ODR is 1600Hz, PERIPH_ON, SERIAL_ON, RFC_ON bits of PDSTAT0 are toggling 0 and 1. and when Sensor ODR is 3200Hz,PERIPH_ON, SERIAL_ON bits of PDSTAT0 are always 1(Domain powered up) , RFC_ON is toggling?

    is this the reason MCU not going to standby? can we get more details on the conditions of the above registers operation?

    How can we debug this further? 

    NOTE: We also debugged by adding the power policy driver to the project and observed the behavior of "PowerCC26X2_ModuleState. constraintMask". It is observed that  constraintMask value is going to zero, but we observed that MCU is not going to standby. 

    Regards,

    Saathwik