nRF Connect SDK PWM on nRF52811 produces high power consumption with huge spikes not seen on nRF5 SDK PWM on the same MCU

RE: nRF Connect SDK PWM on nRF52811 produces high power consumption with huge spikes not seen on nRF5 SDK PWM on the same MCU

ntennies — Thu, 11 Dec 2025 16:40:23 GMT

Håkon,

Thank you again for your help on this. I wanted to close the loop on it.

We did a comparison of nRF5211 registers settings between the nRF5 SDK and the Zephyr version and were able to source of the difference in behavior, which was due to a few things:

First, the difference in behavior was caused by a code error on the nRF5 SDK version of the code, which was that although we were enabling the DCDC regulator, we were doing so incorrectly (that call was accidentally getting made _before_ the SoftDevice had been inited). With the DCDC regulator enabled, we were seeing the same high, spikey power consumption on nRF5 SDK that we were seieng on Zephyr.
Of course, power consumption with DCDC enabled will be more spikey, but should be lower. We think the magnitude of the spikes and therefore the higher power consumption were due entirely auto-ranging artifacts on the nRF5 SDK. When we applied caps to the board, obviously the power spikes went away but also the power consumption ended up being lower than we DCDC disabled, as expected.

So we're all good here.

RE: nRF Connect SDK PWM on nRF52811 produces high power consumption with huge spikes not seen on nRF5 SDK PWM on the same MCU

Håkon Alseth — Mon, 24 Nov 2025 12:59:49 GMT

Hi,

I just want to re-iterate:

[quote user="mojosam"]You can instantly see a dramatic difference between this and the capture you made on the nRF52DK. In your capture, you never see current spikes above maybe 1.3 mA once PWM was enabled, but here we're getting current spikes over 10 mA. In addition, the noise in your capture was evenly centered the 952 uA average, but in this capture from an actual nRF52810, we see spikes going down close to zero uA.[/quote]

All my posted measurements are performed on actual nRF52810 and nRF52811 silicon, mounted on a nRF52-DK.

And please note that spikes are in-nature, expected, from any nRF5x device, due to the regulator refresh mode.

This is entered in various states of sleep, automatically by the hardware, in which "regulator refresh mode" will monitor the voltage output over a external capacitor.

When the voltage level goes to whatever "minimum value" is required for the sleep mode, the hardware will automatically re-charge the capacitor. This will then emit itself as a current spike in the mA area.

PPK2 will have a hard time to accurately show the exact spike (average current will be fine), as you are then switching between two (or even more) accuracy modes within the PPK2, which are listed here:

https://docs.nordicsemi.com/bundle/ug_ppk2/page/UG/ppk/ppk_measure_accuracy.html

PPK2 source meter is usually more accurate.

Q1: Could you verify your findings with another multimeter source?

This is to ensure this is not artefacts of the PPK2 switching levels or something similar.

Please, with a multimeter or something like that, measure the avg. current (or dynamic current drawn), and compare the exact same test case against ppk2.

PPK2 can, in some scenarios, have issues with certain chipsets/PCs, like the AM4/AM5 platform:

https://github.com/NordicSemiconductor/pc-nrfconnect-ppk/issues/318

Such a data loss is less noticeable if the current draw is constant (+/ small variations)

In your setup, that you explicitly state is equal in terms of nRF setup, however; there is a difference in avg measured current.

It is important to establish what the expected current is for both your scenarios.

Q2: Did you run the firmware that I shared with you?

Please share plots and also; please share any changes that you performed on the firmware to replicate any unwanted behavior (as a .diff or .zip).

Q3: Can you please address the former questions, related to your test setup?

[quote user="hkn"]

The issue is not the average, but the dynamic form of the current profile?

It does sound like there's less capacitance in your custom board, as compared to a DK. If you add a capacitor, lets say a 100 uF, does this improve the peaks?

[/quote][quote user="hkn"]

Can you please share your exact changes if this issue is related to firmware behavior?

[/quote]

Q4: Do you use PPK2 in source meter mode, or in ampere meter mode?

To address your comments:

[quote user="mojosam"]There is a difference in PWM peripheral controller configuration between nRF Connect SDK and nRF5 SDK, even when we use the nrfx_pwm module directly in both cases with identical configuration (as we have tried). As I mentioned, we attempted to address this possibility by porting the version of nrfx_pwm from nRF5 SDK -> nRF Connect SDK, and we still the same difference in behavior on nRF Connect SDK. So we don't believe this is due to a difference in PWM peripheral controller configuration.[/quote]

PWM hardware module does not draw additional current if the hardware is setup equal in both projects.

Please see my other comments, such as the above comments about the ppk2 in general, as well as which mode you placed the PPK2 into, and please answer questions that are asked.

[quote user="mojosam"]We don't believe there is a difference in DCDC regulator configuration. We are calling sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE) on the nRF5 SDK version of the app, and all of these builds have regulator-initial-mode = < 0x1 > set in the zephyr.dts, which means DCDC is enabled (correct?)[/quote]

Correct: https://github.com/nrfconnect/sdk-zephyr/blob/ncs-v3.1.0/include/zephyr/dt-bindings/regulator/nrf5x.h#L22

And as per my former measurements (and above explanation on how nRF regulators work); you shall see spikes in sleep modes.

[quote user="mojosam"]We have a call to sd_power_mode_set(NRF_POWER_MODE_LOWPWR) in our nRF5 SDK code, so I added nrf_power_task_trigger(NRF_POWER, NRF_POWER_TASK_LOWPWR) to our nRF Connect SDK test, but I we still have the high, spikey power consumption.[/quote]

This is the default mode of the nRF52 device, so unless it was explicitly overridden, this shall not need to be set.

[quote user="mojosam"]We have a call to SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;in our nRF5 SDK code, so I added it to our nRF Connect SDK test, but I we still have the high, spikey power consumption.[/quote]

This is not required in our devices, as per this thread:

RE: nrf_pwr_mgmt_run impact of SCB_SCR_SLEEPDEEP_Msk

[quote user="mojosam"]Are there other MCU settings that could be affecting system power behavior when PWM is enabled? For instance, other power regulator settings?[/quote]

Short answer is "not directly" - long answer is that some modules will place the SoC in a different internal power mode, but again; this highly depend on what other feature(s) are currently active in your test setup.

HFXO running? Radio running? SAADC running?

[quote user="mojosam"]And this isn't simply academic. We are seeing a significant increase in power consumption on average on the version of our app built on nRF Connect SDK than we are on the version built with nRF5 SDK + embOS, even though we see lower power consumption in the nRF Connect SDK version in some phases of our code. The only place we are seeing increased power consumption is when PWM is running, which led us to focus on this difference in behavior between the two software platforms.[/quote]

I believe we need to take a step back, and evaluate external factors to the measurements, to rule out other potential error sources, as per the above questions.

All tests that I have performed, on target silicon nRF52810/811, are unable to reproduce the scenario, which indicate that this is either an artifact of the measurement itself, or some other issue related to setup difference.

As previously pointed out, the way you measure is relevant, and especially when testing on custom board(s), as there will be differences in external decoupling and overall power draw as compared to a DK from us.

Kind regards,

Håkon

RE: nRF Connect SDK PWM on nRF52811 produces high power consumption with huge spikes not seen on nRF5 SDK PWM on the same MCU

ntennies — Fri, 21 Nov 2025 16:02:36 GMT

Håkon, thank you for your response.

While the things you've highlighted might explain why you are not seeing the problem we are seeing when you test this on the nRF52810, that doesn't address our core question: why are we seeing this dramatic difference in behavior between nRF Connect SDK and nRF5 SDK + embOS, running on the same hardware, and being tested in exactly the same way?

The difference in behavior here has to be caused by a difference in what software is doing. That's the only explanation.

But the problem here is that PWM used for clock generation does not require software to do anything once the PWM is configured and started. PWM clock generation happens entirely in hardware on the nRF52 MCU. It doesn't require interrupts to service anything (correct?).

So this means that if the PWM peripheral controller is configured and started in exactly the same way on nRF Connect SDK as on nRF5 SDK, we should see the hardware produce exactly the same power consumption profile on the same hardware tested in the same way. Correct?

But we're not, so I think there are only three general possibilities here:

There is a difference in PWM peripheral controller configuration between nRF Connect SDK and nRF5 SDK, even when we use the nrfx_pwm module directly in both cases with identical configuration (as we have tried). As I mentioned, we attempted to address this possibility by porting the version of nrfx_pwm from nRF5 SDK -> nRF Connect SDK, and we still the same difference in behavior on nRF Connect SDK. So we don't believe this is due to a difference in PWM peripheral controller configuration.
There is a difference in the configuration of some other part of the MCU:
1. We don't believe there is a difference in DCDC regulator configuration. We are calling sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE) on the nRF5 SDK version of the app, and all of these builds have regulator-initial-mode = < 0x1 > set in the zephyr.dts, which means DCDC is enabled (correct?)
2. We have a call to sd_power_mode_set(NRF_POWER_MODE_LOWPWR) in our nRF5 SDK code, so I added nrf_power_task_trigger(NRF_POWER, NRF_POWER_TASK_LOWPWR) to our nRF Connect SDK test, but I we still have the high, spikey power consumption.
3. We have a call to SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;in our nRF5 SDK code, so I added it to our nRF Connect SDK test, but I we still have the high, spikey power consumption.
4. Are there other MCU settings that could be affecting system power behavior when PWM is enabled? For instance, other power regulator settings?
There is a difference in the behavior of non-PWM interrupts or tasks other than main while PWM is running. In other words, enabling PWM is causing some non-PWM interrupts to fire periodically or a system thread is running periodically. Does VSCode / Zephyr provide a way to monitor which interrupts and threads are running so we can rule out this option?

Our goal here is to understand why we're seeing this fundamental difference in power consumption behavior while PWM is enabled between nRF Connect SDK and nRF5 SDK + embOS, while running on the same hardware, and while being tested in an identical way.

And this isn't simply academic. We are seeing a significant increase in power consumption on average on the version of our app built on nRF Connect SDK than we are on the version built with nRF5 SDK + embOS, even though we see lower power consumption in the nRF Connect SDK version in some phases of our code. The only place we are seeing increased power consumption is when PWM is running, which led us to focus on this difference in behavior between the two software platforms.

RE: nRF Connect SDK PWM on nRF52811 produces high power consumption with huge spikes not seen on nRF5 SDK PWM on the same MCU

Håkon Alseth — Fri, 21 Nov 2025 11:19:47 GMT

Hi Nathan,

[quote user="mojosam"]something that I think Nordic may be missing because you are using the nRF52832DK and nRF52840DK to emulate the nRF52810 and nRF52811.[/quote]

Sorry for not being explicit. Even when the board variant is the nRF52-DK; I did run tests on a nRF52810 target.

And the below screenshots are from running the same fw as previously shared, on a nRF52811 target.

[quote user="mojosam"]As we indicated, when we built our test using the nrf52840dk_nrf52811 board, and we ran this code on our nRF52811-based custom board, we see the problem. Without making any modifications, if we run this on our nRF52840 board, we do not see the problem, even though the nRF52840 can be used to emulate the nRF52811. I believe there is something about how Zephyr is treating the actual nRF52811 -- even if the nrf52840dk_nrf52811 board definition is used -- that is different than how this works with the actual nRF52840.[/quote]

If I understand you correctly, you are pointing towards this define in nrf52840dk board definition:

https://github.com/nrfconnect/sdk-zephyr/blob/ncs-v3.1.0/boards/nordic/nrf52840dk/CMakeLists.txt#L9

or the equivalent for nrf52dk/nrf52810:

https://github.com/nrfconnect/sdk-zephyr/blob/ncs-v3.1.0/boards/nordic/nrf52dk/CMakeLists.txt#L7

Can you please share your exact changes if this issue is related to firmware behavior?

[quote user="mojosam"]

As an example of this, it just so happens we have an older version of the nRF52811 board we're using that is based on the nRF52810. Again, this board is essentially just an nRF52810 with power circuitry (it's a devkit we created with a daughterboard connector, so if we don't have the daughterboard connected, it's just the nRF52810 with no peripherals attached).

We took the code you provided and made a single modification to it, changing which pad was used for PWM output (to 0,14). We then created a build config for the nRF52dk_nrf52810, just as I assume you did (BTW, we always select "Optimize for Debugging" in the build config to prevent optimization). PWM output works as expected, but here's what the PPK2 output looks like:

[/quote]

Are you testing with the PPK2 in ampere meter mode, or in source mode?

The issue is not the average, but the dynamic form of the current profile?

It does sound like there's less capacitance in your custom board, as compared to a DK. If you add a capacitor, lets say a 100 uF, does this improve the peaks?

I also see smaller differences when using ampere mode:

As compared to source meter:

I believe the direct reason why you are seeing a difference in the dynamic measurement is due to LDO vs. DCDC. Try disabling the DCDC:

&reg {
	regulator-initial-mode = <NRF5X_REG_MODE_LDO>;
};

Then the ampere mode will look like this due to less dynamic current consumption (but higher overall current consumption..) draw from the chip:

Kind regards,

Håkon

RE: nRF Connect SDK PWM on nRF52811 produces high power consumption with huge spikes not seen on nRF5 SDK PWM on the same MCU

ntennies — Fri, 21 Nov 2025 07:32:09 GMT

Thank you for your response.

> It almost looks like there is something asserting or reseting on your end?

We don't believe this is the case. Maybe I didn't make this clear, but when we see this high power consumption with huge current spikes after turning on PWM on the nRF52811 using nRF Connect SDK, we can see that the PWM output is working correctly on our digital logic analyzer, producing the required 3.2 MHz clock. So the MCU is definitely not resetting.

We don't have support for printk logging via serial set up -- we've been using a custom logging mechanism based on Segger RTT -- and we don't have assertions enabled, so we don't think an assertion is causing this issue. But the point is, nothing is affecting the correct output of the PWM signal, despite the high power consumption and current spikes.

Furthermore, in our actual application firmware, we turn on PWM for about 100ms toward the beginning our app -- and we see the same high power consumption and current spikes -- but our application continues to run correctly. So if there is a problem with a thread, it's definitely not the main thread.

>I used nrf52dk/nrf52810 as the board for testing.

As we indicated, when we built our test using the nrf52840dk_nrf52811 board, and we ran this code on our nRF52811-based custom board, we see the problem. Without making any modifications, if we run this on our nRF52840 board, we do not see the problem, even though the nRF52840 can be used to emulate the nRF52811. I believe there is something about how Zephyr is treating the actual nRF52811 -- even if the nrf52840dk_nrf52811 board definition is used -- that is different than how this works with the actual nRF52840.

You can instantly see a dramatic difference between this and the capture you made on the nRF52DK. In your capture, you never see current spikes above maybe 1.3 mA once PWM was enabled, but here we're getting current spikes over 10 mA. In addition, the noise in your capture was evenly centered the 952 uA average, but in this capture from an actual nRF52810, we see spikes going down close to zero uA.

Furthermore, I demonstrated that our code is continuing to run correctly even while this high power consumption and current spikes are occurring: I did this by modding your test code to turn PWM on for 500ms and then off for 500ms, looping forever. I see the expected output on the logic analyzer, and here's what I see in PPK2:

Furthermore, you can see exactly how strange the behavior of the power consumption is if we zoom on the end of the 100ms delay and the start of PWM:

I have spent a lot of time looking at PPK2 output from the nRF52840, nRF52810, and nRF52811 over the last several years using the nRF5 SDK, and I have never seen anything that looks like that when the MCU is in Sleep mode (as it should be in this case, after PWM is started). Furthermore, when I run the same code based on nRF5 SDK + embOS on this nRF52810 board, we again do not see this high power consumption or huge current spikes:

It seems to me that there is something about the nRF Connect SDK implementation for the nRF52810 and nRF52811 that is not working properly, something that I think Nordic may be missing because you are using the nRF52832DK and nRF52840DK to emulate the nRF52810 and nRF52811.

Please let me know what you think is happening. Thank you!

Nathan Tennies

RE: nRF Connect SDK PWM on nRF52811 produces high power consumption with huge spikes not seen on nRF5 SDK PWM on the same MCU

Håkon Alseth — Thu, 20 Nov 2025 14:51:44 GMT

Hi,

It almost looks like there is something asserting or reseting on your end? What does the log output look like?

Here is the sample that I used for testing, which yielded this result in ppk2:

And 3.2 MHz (HFINT sourced, which is why its a bit off on my end) output:

Here's the sample as a .zip for your convenience:

devzone.nordicsemi.com/.../0488.blinky_5F00_pwm.zip

I used nrf52dk/nrf52810 as the board for testing.

Kind regards,

Håkon