Hi,

I am working on a custom hardware containing a nrf52840 and some peripherals.

I am now upgrading from zephyr 2.4 to zephyr 3.1 and experiencing a significant power consumption increase.

When using zephyr 2.4 I was able to reduce the overall idle power consumption to about 70 uA while still doing periodic Bluetooth-le broadcasting.

After upgrading to zephyr 3.1 the idle power consumption is now at about 550 uA.

To track down to the root-cause I removed all application code, now having a main loop which is doing only sleep calls.

When removing all configured components I was able to reduce to 130 uA. But as soon as I add the Uart to the config (CONFIG_SERIAL=y) the power consumption goes up to 550 uA. Even when actively trying to put it into suspended mode.

Can anybody give me some advice of how to investigate where the increased power consumption comes from?

Regards,

Volker

Hi Jeremy,

thank you for this suggestion.

A compiler warning showed me, that the old kind of pin-configuration is now deprecated and then I found out, that I have to use pin-control now. But unfortunately this did not help.

Volker

I am currently making some kind of strange observation:

When using a J-Link debugging probe (using Segger Ozone) and placing a breakpoint into the function nrf_uarte_disable(), located in the nrf_uarte.h file, then the power consumption goes down to the expected 130 uA after suspending the uart device with pm_device_action_run( uart0Device, PM_DEVICE_ACTION_SUSPEND );

When switching off the power supply and switching on again … doing a startup without breakpoint … the power consumption ends up at about 550 uA.

For me this seems to be some kind of race-condition, but I am using only the one main thread. Up to now I was not able to investigate if there are some other zephyr initialization/startup threads, which might get scheduled in a different order, when debugger is in play.

I would appreciate any suggestion or tip, of how I should/can proceed to investigate this further!?

Volker

Hi Jeremy,

thank you for this suggestion.

A compiler warning showed me, that the old kind of pin-configuration is now deprecated and then I found out, that I have to use pin-control now. But unfortunately this did not help.

Volker