Identifying power draw during sleep period of Matter ICD device on nRF54L15-DK

[Tom McGuinness]

Hi,

I'm trying to reduce the power consumption of my Matter Temperature sensor code.

I'm averaging around 90µA of consumption, but I'm confident that can be reduced. 

I have a timer setup that, when it fires, every 5 seconds, it will take two ADC readings. This looks like:

When my code is idle (before and after these three spikes), it's still drawing an average of 28µA. Using the PPKII, I've zoomed in and you can see the saw tooth shape.

I have disabled the following peripherals on the board

&uart20 {
	status = "disabled";
};

&uart30 {
	status = "disabled";
};

&mx25r64 {
	status = "disabled";
};

&pwm20 {
	status = "disabled";
};

&wdt31 {
	status = "okay";
};

I have also setup a few power saving settings under the prj.conf file.

CONFIG_PM_DEVICE=y

CONFIG_OPENTHREAD_MTD=y
CONFIG_OPENTHREAD_NORDIC_LIBRARY_MTD=y

CONFIG_CHIP_ENABLE_ICD_SUPPORT=y
CONFIG_CHIP_ICD_LIT_SUPPORT=y

CONFIG_RAM_POWER_DOWN_LIBRARY=y

CONFIG_LOG=n
CONFIG_CONSOLE=n
CONFIG_SERIAL=n

This project is based on the nrf/samples/matter/template sample. It is compiled using the "internal" overlay (which disables the external flash)

Could you help me identify what is using that 28µA??

[Hung Bui]

Hi Tomas, 

There is an online power profiler that you can use as the reference regarding the power consumption : 
Online Power Profiler for Matter over Thread

28/90uA as idle current is quite high. Could you try to test with the window_covering sample ? Please compile for non _ns board. 
You should see a few ua in idle mode. 

In your test did you compile for _ns or non _ns board ? 

[Tom McGuinness]

Hi, 

That sample doesn't appear to work on my custom PCB.

I have tried the "system off" Zephyr sample and that shows around 5µA of current when it's in deep sleep. 

what does the "_ns" board designation mean?

[Hung Bui]

Hi Tomas, 
Could you check what doesn't work ? Do you have a nRF54L15 DK to test ? 
Have you tried to compile the sample for the DK and then flash on your board ? 
Regarding _ns and non _ns , when you build with _ns there will be a separation between secure and non_secure partition of the chip. The application will be located at non secure area and the security API such as TF-M and PSA is located in the secure partition. You can read more about that here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/security/tfm/processing_environments.html

I would suggest to start the test with non _ns so that we don't get TF-M and PSA involved to avoid unnecessary current (for example for TF-M logging). You can start to use _ns after you have optimized the current consumption on the non _ns version. 

[Tom McGuinness]

Hi Hung,

Thanks for that.

It turns out the issue was related to interrupts. By switching the edge detection, the consumption dropped to around 18µA.

There is probably room to shave more off, but this is sufficient for now.

I've written up a post - https://tomasmcguinness.com/2026/02/01/matter-dual-temperature-sensor-power-consumption-finally-at-20%c2%b5a/

This might be helpful to anyone else.

Thanks!

Tom

[Hung Bui]

Hi Tomas, 

I'm glad that you managed to drop the current. I agree that maybe there is something you can shave off from the 18uA idle current, but it might be that there is something else on the PCB that may draw current. And that's expected. 

Regarding the fix you implemented, I got a tip from Vidar that by using GPIO_INT_LEVEL_HIGH  you may get the event being triggered again if you keep the signal asserted. So if you press a button it may trigger the event several times. The solution is to use GPIO_INT_EDGE_TO_ACTIVE  and  use 'sense-edge-mask' property in device tree. You can take a look here: 
RE: Interrupt energy intensive

[Tom McGuinness]

Thanks for the tip!

My reset button doesn't work at present due to a PCB flaw. I'll be sure to check the EDGE_TO_ACTIVE behaviour.