• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 55 subscribers
  • Views 490 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2340R5: The end-device does not enter the low-power mode

senjin
Intellectual 260 points
Part Number: CC2340R5
Other Parts Discussed in Thread: , SYSCONFIG

Tool/software:

I found in the latest SDK, there is a problem that the device cannot go into low power mode, Please help to confirm this.

SDK: simplelink_lowpower_f3_sdk_8_40_02_01

PROJECT: onoff_switch_LP_EM_CC2340R5_freertos_ticlang

procedure:

1, change Low Frequency Clock Source from LF XOSC to LF RCOSC.

2, burning the firmware to CC2340R52 chip, make it join to network.

3, test power consumption.

 by the way, In the simplelink_lowpower_f3_sdk_8_20_00_119 SDK, the device can enters the low-power mode.

  • 0
    TI__Guru**** 214197 points

    Hi Senjin,

    Thank you for reporting with clear instructions and details.  The SDK Test team does run power consumption measurements for each default example before release, so your findings are unexpected since changing XOSC to RCOSC should not affect the device's ability to enter standby low-power mode.  Can you please answer the following before I perform my own test?

    • No changes have been applied to the default on_off_switch.syscfg file with the exception of Device Configuration -> Low Frequency Clock Source changing to RCOSC.
    • The on_off_switch.c file, alongside any other project files, have not been altered in any way.
    • This test can be performed on a LP-EM-CC2340R5 and does not require custom hardware.
    • You are erasing all chip memory on the device, reprogramming, and resetting or power cycling the device in order for it to join the network.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 260 points

    1，Yes, no other changes to syscfg

    2. Yes，no changes to c files.

    3，not require custom hardware，In my hardware, none of the IO is connected to any peripherals.

    4，I tried power cycling the device. I downloaded the program through online debugging, and I'm not sure if flash was erased. 

  • 0 in reply to senjin
    TI__Guru**** 214197 points

    Understood.  Please confirm device erasure and power cycling before running the test.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 260 points

    Hi Ryan,

    I tried today to erase all the chip memory on the device, reprogram it, and reset the device, the device is still not enter low-power mode, please confirm.

  • +1 in reply to senjin
    TI__Guru**** 214197 points

    I am using SimpleLink SDK v8.40.02.01, SysConfig v1.22, TI Clang v4.4.0.1.LTS, and CCS v20.0.  When evaluating the out-of-box onoff_switch_LP_EM_CC2340R5_freertos_ticlang example on a default LP-EM-CC2340R5 with my freshly installed SDK, for which the channel has been changed to 17 for my personal preference and the Low Frequency Clock Source is selected as LF RCOSC by SysConfig, I can join the Zigbee network and observe similar power consumption as with the LF XOSC.  It is on the scale of tens of uA (including transmissions) and certainly less than the 6.3 mA shown on your screenshot.  Please let me know if any changes to my setup are required.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 260 points

    Hi Ryan,

    I have found the cause of the problem, high power consumption is due to the loss of connection to the parent. My child device is about 10 meters away from the parent device. I believe that the transmission power of the project, which is based on v8.40.02.01 SDK , is lower than the one based on v8.20.00.119 SDK, considering that the latest version of the SDK has fixed the setting power problem.

    I think even in this state, the device needs to enter the low power mode.

  • 0 in reply to senjin
    TI__Guru**** 214197 points

    Okay so the concern is not actually about the RCOSC vs XOSC?  The actual problem is that the sleepy ZED will not enter standby low-power mode when orphaned by its ZC/ZR parent?

    senjin said:
    I believe that the transmission power of the project, which is based on v8.40.02.01 SDK , is lower than the one based on v8.20.00.119 SDK, considering that the latest version of the SDK has fixed the setting power problem.

    Have you confirmed this with a spectrum analyzer or RSSI observations from a sniffer device?

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 260 points

    1, Yes, it's not really related to RCOSC and XOSC, but related to the orphan role

    2, I have confirmed that it has nothing to do with transmitting power. For the v8.20.00.119  SDK, there is no problem that orphan roles cannot enter low power, but the v8.40.02.01  SDK exists.

  • 0 in reply to senjin
    TI__Guru**** 214197 points

    I have replicated these results and supplied all information to the Zigbee R&D Team for further guidance.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Intellectual 260 points

    Hi Ryan,

    I want to add that if a new ZED tries to join the network and fails, it will not enter low power mode in this case.  I hope TI team can solve this problem together. By the way, how long will it take to solve this problem?

    Regards, 

    Senjin

  • 0 in reply to senjin
    TI__Guru**** 214197 points

    Hi senjin,

    Thank you for adding this condition.  I believe the higher power consumption in these two different ZED states originate from the same issue, given they occur after the ZED expects to communicate with a ZC but fails to do so. 

    Bug tickets such as this one are on temporary hold while resolving the F2 Z-Stack temperature change issue which was impacting some key accounts.  As this other investigation is nearing completion, please let me know the priority of your remaining Zigbee stack issues and I will encourage the Zigbee R&D Team to address them by order of importance.

    Regards,
    Ryan

  • +1 in reply to senjin
    TI__Guru**** 214197 points

    Hello senjin,

    A ticket has been filed to resolve the root issue, however the R&D Team has proposed the following workaround implemented in ti_f3_main.c:

    // Required for sleepy zed check in zb_osif_sleep()
#include "zb_mac_globals.h" // ADD THIS LINE

// ...

zb_uint32_t zb_osif_sleep(zb_uint32_t sleep_tmo)
{
//...

  // Get starting time
  t1 = ClockP_getSystemTicks();
  
  // ADD CODE BELOW
  // When device is a sleepy ZED, ensure that RX is off when going to sleep.
  if (MAC_PIB().mac_rx_on_when_idle == 0U)
  {
    ZB_TRANSCEIVER_SET_RX_ON_OFF(ZB_FALSE);
  }
  // END OF ADDITION
  
//...
}

    Please try this out and let us know if you find the behavior improves.

    Regards,
    Ryan