Unexpected consumption using System OFF Sample & nRF52840DK

[clockis]

Greetings,

I have been measuring the current consumption of our custom FW in our custom board using PPK2 and found some unexpected spikes in the current consumption curve.

I decided to look deeper into this so programmed our custom FW to the nRF52840 DK and the behavior remained the same.

Finally I decide to test some samples with absolutely no changes on the nRF52840DK to confirm the normal behavior of the current curves I should see when the system is Active, in Sleep (system ON Idle) & finally System OFF(which is irrelevant for my application).

It seems that flashing the nRF System OFF sample (unchanged, as it was in the NCS) to the nRF52840 DK produces the same current curve. As mentioned in other tickets ( I have searched and read all of the relevant ones in existence) the current curve in System Sleep (with UART off) should be a few tens of microamps but I am consistently getting the current curve shown below.

Connection diagram (PPK2 in Ampere mode) 
I have also measured with the SW6 to the DEFAULT and nRF ONLY positions but the results were the same.

!!!Below you can see the current curve for the nRF52840DK flashed with the nRF System OFF sample and focus on the duration that corresponds to the System Sleep (System ON Idle) part of the duration ( the sample enters the SYstem Sleep state for two seconds, this what is shown below)

System Sleep (System ON Idle)

System Sleep (System ON Idle) the curve shown above ZOOMED IN ( to be able to distinguish the spikes)

The whole current curve for the System OFF sample

I have tried all different methods of measurement using the PPK2 (Ampere mode & Source mode by providing the external supply from the PPK2) but in all instances, I am getting the same current curve(shown above).

I have also tried the beacon sample (with no changes/modification, as is) and gotten the same curve in Idle mode (apart from when the device wakes up to advertise), between the advertising events I get the same spikes up to 3mA with the current never falling bellow 100's of microamps.

Beacon sample

Beacon sample ZOOMED IN

Even more ZOOMED IN

According to other tickets as well as this one that contains current curves for the Beacon sample this is not at all the Normal curve I should see for this sample

(this is what the people in the ticket mentioned report as the normal current curves for this sample)

which is completely different from my curves.

What could be the cause for the behavior and current curves I am observing when loading the nRF System OFF & Beacon samples to the nRF52840DK and measuring using the PPK2?

Please get back to me for any further information needed, I can also provide the data for the curves shown above.

I look forward to hearing from you.

Best regards,

Stavros

[clockis]

Hi Vidar,

I have run the System Off & Beacon samples without any changes as I did previously and also by disabling the UART during build (CONFIG_UART=n). It is clear that the issue is the UART not being suspended, as you can see the power consumption drops to the expected values when disabled.

System Off sample - unmodified

Zoomed in the System Sleep (System ON Idle) state

System Off sample - built with UART disabled (CONFIG_SERIAL=n)

immediately you can see the difference in the SYstem ON Idle portions of the execution.

Zoomed in the System Sleep (System ON Idle) state

As you can see the System ON Idle (system Sleep) portion o f the sample has the expected values (same current curve and values as the system_on_demo.hex you provided) and significantly less power consumption. This is also observed for the beacon sample shown below.

Beacon sample - unmodified

Zoomed in the System Sleep (System ON Idle) state between the advertising events

Beacon sample - built with UART disabled (CONFIG_SERIAL=n)

Zoomed in the System Sleep (System ON Idle) state between the advertising events

Again the power consumption is significantly less and aligns with the current values reported by the datasheet

Now I want to find the way to disable/suspend the UART module during runtime correctly as the 

pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND);

function does not seem to work properly.

I will need to be able to do this in the current SDK version (v2.1.0) because migrating to the v2.5.1 only because I want to suspend the UART during runtime will be very time-consuming.

So my question is how is it possible to suspend the UART correctly in the v2.1.0 version of the SDK?

I will try of course your suggestion but I should be able to properly suspend the UART in v2.1.0 as well unless that is a bug in the NCS which will require extensive modifications to patch. I would like to keep working with v2.1.0 unless it's absolutely necessary and no other way is possible but to migrate to a newer version. Also if there is a fix I can apply to my version of NCS that would be great or if you have any alternatives o suggest.

Thank you for your support and I look forward to hearing from you!

Best regards,

Stavros

[Vidar Berg]

Hi Stavros, 

The main goal of attempting to build the project with a newer SDK version was to help narrow down the issue. I've just done that, and it think I've found the culprit; until SDK v2.4.0, the nRF52840 DK board file had the UARTE1 instance enabled by default. The PM action only disables the UARTE0 instance, which is assigned to the Zephyr console.

Solution:

Create a DT overlay (nrf52840dk_nrf52840.overlay) that disabled the UARTE1 instance:

 

&uart1 {
    status = "disabled";
};

[clockis]

Hi Vidar,

I tested the System Off modified sample with an nrf52840dk_nrf52840.overlay file with the lines you suggested and it worked!

The consumption is now on the correct/expected levels! Thank you!

Unfortunately, I am still trying to fix this issue on my custom fw application, I have gone through all the steps of making sure to suspend the UART and disable uart1 but I am still getting this increased consumption (exactly the same current curve as when a UART peripheral is enabled) which is clearly a UART peripheral still enabled.

Is there a way to check (e.g. from the output files like .conf or the Compiled DeviceTree Output) if a UART module is still enabled?

Thank you and I look forward to hearing from you

Best regards,

Stavros

[Vidar Berg]

Hi Stavros,

Glad to hear that it worked now.

clockis said:

Is there a way to check (e.g. from the output files like .conf or the Compiled DeviceTree Output) if a UART module is still enabled?

Yes, you can check the generated zephyr.dts in build/zephyr to see whether the uart1 node is enabled or not.

To be sure the ~500 uA is from the UART, do you get the expected idle current if you build with CONFIG_SERIAL=n

Best regards,

Vidar

[clockis]

Vidar Berg said:

To be sure the ~500 uA is from the UART, do you get the expected idle current if you build with CONFIG_SERIAL=n

I do not. But it has exactly the same current curve and current levels that I see with the samples (UART enabled)

Beacon System Sleep between advertising events

My custom FW (essentially just initializes some sensors which are not present in the DK and at this point its just a connectable BLE device that just advertises every 100 msec, not much different in terms of execution than the beacon. There is no other execution that is performed at this point only BLE advertise)

These are identical, for me it is for sure the UART.

What else could cause this current curve/consumption between advertising events ( where the device does nothing else but BLE advertise)? Could it be some other peripheral that is enabled, like SPI or I2C? Any input or hint is very helpful on this, or how I could go about debugging this.

Thank you very much

BR

Stavros