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.

CC2560 ti-rtos clock and standby

Other Parts Discussed in Thread: SYSBIOS, CC2630, CC2560

IHi,

 

use TI RTOS module “ti.sysbios.knl.Clock” to generate a periodic 10ms clock to wake a process. If the power save mode “standby” is disallowed, the wakeup time is very accurate. However, if “standby” mode is allowed, I see variation at each wakeup time. Can you tell me what contributes the wakeup time variation and how to improve it?

  • I’ve taken some scope shots of the 24MHz XTAL when the MCU is coming out of reset (on rising edge of nRESET input to the CC2630). These scope shots with some curser measurements are attached in case they provide any clues. I took two samples and took many marker measurements at various zoom levels. The file-names are pretty descriptive, but please let me know if anything needs an explanation, or if there are any other measurements on our hardware that we can provide for a speedy resolution, please let me know.

    I have scope plots - please email me directly and I can send them to you.

    Cheers
    Calum
  • Hi Calum,

    I'd like to better understand your setup. Are you using the CC2630 (as in your message body) or the CC2560 (as in the title), and which board? Also, this 'power save mode' you are referring to, which device is it on? Could you describe what you have to do to turn the mode on? Which version of TI-RTOS are you using?

    Best regards,
    Vincent
  • It CC2630 on a custom board. The power save mode is "power standby". It is turned on in a TI-RTOS configuration file.

    /* Idle CPU when threads blocked waiting for an interrupt */
    Power.idle = true;
    Power.policyFunc = Power.standbyPolicy;

    The TI-RTOS is 2.11.0.09

    Thanks!

  • Hi Wai,

    The Power_standbyPolicy function is defined in <BIOS installation directory>/packages/ti/sysbios/family/arm/cc26xx/Power_standbyPolicy.c. If you inspect the code, you would see this logic:

    ticks = Power_getTicksUntilWakeup();

    /* check if can go to STANDBY */
    if (ticks > Power_getTransitionLatency(Power_STANDBY,
    Power_TOTAL)) {

    ...

    /* go to standby mode */
    Power_sleep(Power_STANDBY, NULL, NOTIFY_LATENCY);
    Clock_stop(Power_Module_State_clockObj());
    justIdle = FALSE;

    }

    /* idle if allowed */
    if (justIdle) {

    /*
    * power off the CPU domain; VIMS will power down if SYSBUS is
    * powered down, and SYSBUS will power down if there are no
    * dependencies
    * NOTE: if radio driver is active it must force SYSBUS enable to
    * allow access to the bus and SRAM
    */

    ...

    }

    The logic is such that depending on how soon the next Timer interrupt is supposed to happen and whether that is greater than the transition latency, the code would either go into full standby or it would just go into 'idle'. Consequently, I'd expect the wakeup latency to be somewhat different depending on which mode it ends up in, every time when this function is called in the idle loop.

    In addition, the code is implemented using calls to driverlib, such as SysCtrlAonUpdate(), PRCMDeepSleep(), SysCtrl_DCDC_VoltageConditionalControl(), etc. some of which are called when exiting the function upon wakeup from sleep. You may want to lean on the CC2630 forum for more details on the latency of these driverlib calls to get a better idea if any of these could further explain the variations you are seeing.

    Best regards,

    Vincent