High current consumption in the Template Matter sample

I have followed the guide Adding clusters to Matter application to add two TemperatureMeasurement clusters to the Template sample. 

I have flashed this onto an nRF52840-DK and hooked up a PPKII to the External Supply. I have switched SW6 to nRF ONLY to take the peripherals out of the equation.

The power consumption is a whopping 500µA even with CONFIG_SERIAL=n

In this post, Power consumption of Matter template example - Nordic Q&A - Nordic DevZone - Nordic DevZone, the user converts to from a Minimal Thread Device to a Sleepy End Device and has a tiny power consumption.

I have tried everything I could find to make mine sleepy, but nothing has worked so far. 

The CHIP_ENABLE_ICD_SUPPORT is set to y, but that doesn't seem to have done anything.

Can you please provide me some guidance on making this work??

Parents
  • Hi, 

    What NCS version are you using? Please check out this guide Reducing power consumption in Matter.

    Regards,
    Amanda H.

  • I'm using NCS 3.0.2

    I have followed that guide and made significant reductions. I'm not quite sure which setting removed the 500µA, but a pristine build resulted in the reduction.

    That said, I still have two issues which I need help with.

    #1 I have set CONFIG_CHIP_ICD_SLOW_POLL_INTERVAL to 30000, but as you can see in the PPKII graph above, the radio seems to turn on every 15 seconds.

    #2 There is a 3mA spike every one second. I have a single timer, configured to run at 10 second intervals. I configure the timer in AppTask::Init() and start it in AppTask::StartApp()

    CHIP_ERROR AppTask::Init()
    {
    ...
    k_timer_init(&sSensorTimer, &SensorTimerHandler, nullptr);
    k_timer_user_data_set(&sSensorTimer, this);
    ...
    }
    
    CHIP_ERROR AppTask::StartApp()
    {
    	ReturnErrorOnFailure(Init());	
    
    	k_timer_start(&sSensorTimer, K_MSEC(10000), K_MSEC(10000));
    
    	while (true)
    	{
    		Nrf::DispatchNextTask();
    	}
    
    	return CHIP_NO_ERROR;
    }

    Could you help with these two questions?

  • Tom McGuinness said:
    #1 I have set CONFIG_CHIP_ICD_SLOW_POLL_INTERVAL to 30000, but as you can see in the PPKII graph above, the radio seems to turn on every 15 seconds.

     To ensure that the SED device wakes up exactly at every poll period, set the following Kconfig options to the value greater than the poll period value (for Matter ICD CONFIG_CHIP_ICD_SLOW_POLL_INTERVAL):

    See Child timeouts configuration

    Tom McGuinness said:
    #2 There is a 3mA spike every one second. I have a single timer, configured to run at 10 second intervals. I configure the timer in AppTask::Init() and start it in AppTask::StartApp()

    Are you using the internal RC oscillator (CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y)? If so, check out this post

  • Thanks Amanda,

    I have checked the OPENTHREAD settings using menuconfig.

    CONFIG_OPENTHREAD_MLE_CHILD_TIMEOUT=240

    CONFIG_OPENTHREAD_CHILD_SUPERVISION_CHECK_TIMEOUT=190

    CONFIG_OPENTHREAD_CHILD_SUPERVISION_INTERVAL=129

    I believe this are the default values.

    I had actually removed the CONFIG_OPENTHREAD_MTD setting, so I restored that! D'oh!

    That improved things. The one second spikes are gone now, but the radio is still turning on every 15 seconds, rather than 30.

    Unfortunately, setting CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION to n as per the post resulted in a compilation error. I have got CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC set to y.

    /home/tomasmcguinness/ncs/v3.0.2/zephyr/include/zephyr/toolchain/gcc.h:87:36: error: static assertion failed: "MPSL requires clock calibration to be enabled when RC is used as LFCLK"
       87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert((EXPR), "" MSG)
          |                                    ^~~~~~~~~~~~~~
    /home/tomasmcguinness/ncs/v3.0.2/nrf/subsys/mpsl/init/mpsl_init.c:382:9: note: in expansion of macro 'BUILD_ASSERT'
      382 |         BUILD_ASSERT(IS_ENABLED(CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION),
          |         ^~~~~~~~~~~~
    /home/tomasmcguinness/ncs/v3.0.2/nrf/subsys/mpsl/init/mpsl_init.c:388:30: error: 'CONFIG_MPSL_CALIBRATION_PERIOD' undeclared (first use in this function)
      388 |         clock_cfg.rc_ctiv = (CONFIG_MPSL_CALIBRATION_PERIOD * 4 / 1000);
          |                              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/tomasmcguinness/ncs/v3.0.2/nrf/subsys/mpsl/init/mpsl_init.c:388:30: note: each undeclared identifier is reported only once for each function it appears in
    /home/tomasmcguinness/ncs/v3.0.2/nrf/subsys/mpsl/init/mpsl_init.c:389:34: error: 'CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_MAX_SKIP' undeclared (first use in this function)
      389 |         clock_cfg.rc_temp_ctiv = CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_MAX_SKIP + 1;
          |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/tomasmcguinness/ncs/v3.0.2/nrf/subsys/mpsl/init/mpsl_init.c:390:22: error: 'CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_TEMP_DIFF' undeclared (first use in this function)
      390 |         BUILD_ASSERT(CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_TEMP_DIFF == 2,
          |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/tomasmcguinness/ncs/v3.0.2/zephyr/include/zephyr/toolchain/gcc.h:87:52: note: in definition of macro 'BUILD_ASSERT'
       87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert((EXPR), "" MSG)
          |                                                    ^~~~
    /home/tomasmcguinness/ncs/v3.0.2/zephyr/include/zephyr/toolchain/gcc.h:87:51: error: expression in static assertion is not an integer
       87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert((EXPR), "" MSG)
          |                                                   ^
    /home/tomasmcguinness/ncs/v3.0.2/nrf/subsys/mpsl/init/mpsl_init.c:390:9: note: in expansion of macro 'BUILD_ASSERT'
      390 |         BUILD_ASSERT(CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_TEMP_DIFF == 2,
          |         ^~~~~~~~~~~~

    We're making progress!

  • Tom McGuinness said:
    That improved things. The one second spikes are gone now, but the radio is still turning on every 15 seconds, rather than 30.

    Good to hear that. Sounds like the one-second spikes are unrelated to the internal RC oscillator. 

Reply Children
No Data
Related