• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 51 subscribers
  • Views 1086 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.

CC2640R2F: “standby mode entering” procedure - timing optimization

Guillaume Henri
Expert 4376 points

Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2640

Hi champs,

The CC2640R2F in this application is supplied by a supercap when the main power is turned off. This supercap is dimensioned to supply the CC2640R2F in Standby mode when the main power is off.

The overall problem here is that the timing which is taken by the CC2640 SW to go into standby mode is not deterministic and sometimes takes too long - this implies an energy overconsumption which leads to the fact that the supercap is not able to provide enough energy when the main power is turned off.

The request here is to get a solution to make the “standby mode entering” process timing deterministic and minimal

PHENOMENA OBERVATION

The PG signal (Power Good – in yellow in the oscilloscope snapshot) is connected to a CC2640R2F GPIO interrupt

The CC2640R2F standby mode entering process is the following :

Step1/ The PG signal falling edge triggers a CC2640 interrupt which calls “standby mode entering” procedure within TI RTOS CC2640 environment

Step 2/ The TI RTOS schedules “standby mode entering” using message queuing priorities

Step 3/ GPIO settings are modified before standby mode in CC2640 and particularly the GPIO connected to a LED driving PT25 (in Purple in the oscilloscope snapshot) is set to low

Conclusion : On pic1 we can see that the timing between PG falling edge and PT25 falling edge is 170us. On pic2 we can see that the timing between PG falling edge and PT25 falling edge is 5ms. This means that the “standby mode entering” process timing is not deterministic.

Looking at the BLE/TI RTOS firmware process, it sounds like the “standby mode entering” timing depends on TI RTOS scheduling and messages queuing

QUESTIONS

Q1 : How could the “standby mode entering” be made deterministic ?

We are thinking about 2 options :

Option 1 : Bypass OS scheduling to enter into “standby mode” by calling standby mode OS agnostic functions directly from the ISR triggered by the PT25 falling edge

Option 2 : Change “standby mode entering” message priority within TI RTOS environment to accelerate standby procedure execution

Q2 : Could you provide the OS agnostic functions to be called in order to implement option 1

Q3 : How could we change in the BLE code the “standby mode entering” message priority?

Thank you!

Best regards,

Guillaume

  • 0
    TI__Guru 58425 points
    Hi,

    I'm not sure I really understand the software implementation here, maybe you could elaborate a bit on it?
    For example I'm not sure I understand what you mean with "“standby mode entering” procedure within TI RTOS CC2640 environment" and "The TI RTOS schedules “standby mode entering” using message queuing priorities".

    How standby is typically handled in TI-RTOS is that if the device is idle and standby is allowed, it will always transition into standby as soon as possible. I have no notice about a "standby mode entering" message, is this a custom SW design?

    Typically I would expect the device to go into standby when ever possible with or without mains power unless the system put up any constraints. It would do this as soon as possible, meaning when any other task that might be running has completed/yielded to the Idle task. The time from interrupt to standby does depends on what else is going on in the system which in case of the BLE stack could be a lot.

    You could possible go ahead an just call Power_standbyPolicy() right away but this must be done from a task context (don't do this from inside the callback). However, I'm not sure how this would affect the BLE stack so I don't really recommend it unless you are certain it works.

    As for OS agnostic function goes, Power_standbyPolicy() is as close as it gets.