• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1395 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.

RTOS/CC2650: [CC2650 BLE] best power mode for my application, please advise.

Hae Ryong Jung
Expert 2150 points

Part Number: CC2650
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hi All, 

Please advise me about best power mode of my application with following 2 conditions.

1. My device will wake up periodically by timer interrupt, gathering data(sensor controller is not available). then goes to sleep. Period will be quite long, such as over a couple of hours.

2. During sleep mode, device waits two events. serial communication and BLE connection. if no event, then stay in sleep mode.

As I have checked, RF and UART seems not to be available at standby mode, then idle mode is the only option for my power down mode ?

I hope to stay in standby mode and wake up to active mode if possible.

Would you please give me some advice ?

Best Regards,

Hae Ryong

  • 0
    TI__Mastermind 26780 points

    Hi Hae,

    Going into Standby will result in a power gating of both the RF core and peripheral power domains.  But for a typical BLE application this is not a problem, because the corresponding peripheral drivers will restore state as the device is awoken from Standby, via notifications sent to these drivers by the Power driver.  There are a lot of details involved that I won’t go into here, but my main point is that you can usually use the RF core in your application, and many peripherals, and still let the device go in/out of Standby.

    If you haven’t seen it, the Power Management User’s Guide (in your TI-RTOS installation, for example: C:\ti\tirtos_cc13xx_cc26xx_2_21_00_06\docs\Power_Management.pdf) provides a description of the power management concepts.

    From your description there are two things that might be an issue for your app:

    1)  You indicate “device waits two events. serial communication”.  If a UART must remain powered and able to wake the device from sleep, then Standby can’t be used.

    2) And “wake up periodically by timer interrupt”.  The general purpose timer peripherals are also power gated during Standby, so if you’re using one of those, then Standby can’t be used.  But if you use the kernel’s Clock module for periodic wakeups (either by creating a Clock object, or using a kernel API timeout, for example with Semaphore_pend()), then you can still use Standby, because the Clock module uses the RTC underneath, which continues to run during Standby.  Any timeouts from the Clock module (and RTC) will automatically wake the device from Standby.

    If Standby can’t be used in your application, then the next best option is the IDLE_PD state.  This allows gating of the CPU power domain (but with retention of critical state), for additional savings over simple wait for interrupt (WFI).

    Hope this helps…

    Regards,
    Scott

  • 0 in reply to ScottG
    Expert 2150 points
    Hi Scott

    Thanks for your detail descriptions.
    It is quite helpful.
    I think IDLE seems to be the possible option for this.

    Best Regards,
    Hae Ryong
  • 0 in reply to Hae Ryong Jung
    Expert 2150 points
    Hi Scott,

    Would you please let me know how to wake up with RTC in standby mode ? (any reference code or else..)
    I think I have to use standby mode and resolve the issue about BLE and periodic wakeup. (except serial connection)

    Best Regards,
    Hae Ryong
  • 0 in reply to Hae Ryong Jung
    TI__Mastermind 26780 points

    Hi Hae,

    The simplest thing to do is to use one of the kernel APIs with a timeout.  All these timeouts use the Clock module, and the Clock module uses the RTC, which will wake the device from Standby.

    For example, in a task thread, call:

        Task_sleep(delay_in_microseconds/Clock_tickPeriod);

    The parameter to Task_sleep() is the delay in units of Clock tick periods, and “Clock_tickPeriod” is the configured tick period for Clock, in units of microseconds.  To reference “Clock_tickPeriod” your file will need:

        #include <ti/sysbios/knl/Clock.h>

    The call to Task_sleep() will block the execution of the current task, with the timeout being registered with the Clock module.  When all tasks are blocked the Idle loop will run, and there the Power driver’s policy will check constraints and the time until the next tick, and automatically transition the device to Standby.  When the RTC interrupt occurs at the timeout the device will be awoken from Standby, and then your task will resume, returning from the Task_sleep() call.

    You can also explicitly create a Clock object to register a timeout with Clock for when you want to wake from Standby.  There is a “Clock” example that comes with TI-RTOS that shows usage of some of the Clock APIs.

    Hope this helps.

    Best regards,
    Scott

  • 0 in reply to ScottG
    Expert 2150 points
    Hi Scott,

    Thank you very much.
    I will look into it.

    Best Regards,
    Hae Ryong