Nordic support,
We are experiencing unexpectedly high and noisy power consumption when using PWM with nRF Connect SDK v2.9.2 on a nRF52811-based custom board, which is problematic because our use case for the nRF52811 is a board that is both ultra-low power and requires low noise on power rails while PWM is enabled. We'd like your help understanding what is causing this issue.
What is strange is that we do not see this same behavior when implementing identical code for this nRF52811-based board using the nRF5 SDK. We also do not see this behavior when using PWM with nRF Connect SDK on a nRF52840-based custom board. In other words, the problem seems to be specific to nRF5 Connect SDK running on the nRF52811.
Our use case for PWM on this board is generating a 3.2 MHz clock to an external component. However, for the purposes of this testing, we are outputting PWM to a pad that is not connected to anything, to highlight the power consumption due to PWM vs whatever it is connected to.
Also, to simplify reproduction, all of our testing is performed using a modified version of zephyr/samples/basic/blinky, with main changed as follows:
int main(void){ static const struct device *clk_dev = DEVICE_DT_GET(DT_NODELABEL(pwm_clock_gen));
if (device_is_ready(clk_dev)) { k_sleep(K_MSEC(100));
clock_control_on(clk_dev, 0); }
k_sleep(K_MSEC(1000));}
So in our test, we sleep for 100ms, turn on the 3.2 MHz PWM output, and then sleep for 1000 seconds to contrast power consumption while our main thread is sleeping before and after PWM is enabled. Also, our nRF Connect SDK implementation relies on a custom, board-specific DTS file based on the nordic/nrf52811_qfaa.dtsi file (attached, named RC63_B25_V2_DEVKIT.dts.
Figure 1 shows what we are consistently seeing on the nRF52811-based custom board using nRF Connect SDK and the code above. This figure shows a detail of power consumption at the end of the 100ms sleep and then after PWM is enabled. As you can see, power consumption is around 1.4 mA @ 3V, but even more strange are the huge, frequent, but irregular spikes up to 10 mA while PWM is running.
We see identical behavior if we continue to use nRF Connect SDK but eliminate PWM from the DTS and simply rework the test application to use the lower-level nrfx_pwm modules intead of the Zephyr clock_control driver.
Figure 2, in contrast, shows what we are consistently seeing on teh nRF52811-based on custom board using nRF5 SDK and embOS RTOS and equivalent code based on the the nrfx_pwm driver. Power consumption is only 1.1 mA @ 3V and is very consistent once PWM is turned on, with no huge spikes up to 10 mA. This suggests a difference either in how nRF Connect SDK is configuring the PWM peripheral controller or a difference in how it is servicing PWM from interrupts or threads.
To rule out a possible problem with our board-specific DTS file, we then created a Zephyr build configuration that used the nRF52840dk_nRF52811 board configuration, but we still see the same problem: high PWM power consumptin and huge spikes in current draw.
When we ran that exact same build on a custom nRF52840-based board, however, we do not see the high PWM power consumption and huge spikes in current draw; the power consumption graph looks like Figure 2.
We also built the same DTS-based test code using v3.1.1 of the nRF Connect SDK and toolchain, but it exhibits identical high-power consumption and huge spikes on the nRF52811, so the problem doesn't appear to be limited to a specific version of the nRF Connect DK.
I should also mention that none of these builds enables USE_DMA_ISSUE_WORKAROUND or NRFX_PWM_NRF52_ANOMALY_109_WORKAROUND_ENABLED, in either nRF Connect SDK or nRF5 SDK.
Finally, we made an attempt to resolve this after we noticed that nrfx_pwm.c on the nRF Connect SDK differs in an important way from the nRF5 SDK version: if you pass NULL for the handler to nrfx_pwm_init() on nRF5 SDK, the PWM interrupt is not enabled, but it is always enabled on nrfx_pwm for nRF5 Connect SDK. Thinking this interrupt might be playing a role, we ported the nRF5 SDK version of nrfx_pwm to nRF Connect SDK to eliminate any differences in driver implementation, but we still experienced the high power consumption and huge spikes.
Based on sll of this, we're at a loss to explain what is causing the problem: the same hardware using the same driver code with the same configuration behaves very differently on nrF5 SDK with embOS than on nRF Connect SDK. It seems like it has to have something to do with some system-wide behavior or configuration for Zephyr, but then why don't we see it on the nRF52840?
I should mention that our nRF52811-based custom board is extremely simple, pretty much just an nRF52811 connected to power circuitry. In all tests above, we're using the DCDC regulator. The only unusual thing about this board is that it lacks an external LFCLK, and so our prj.conf for this test looks like this (our actual prj.conf is significantly larger):
CONFIG_SERIAL=n
CONFIG_NRFX_PWM0=y
CONFIG_CLOCK_CONTROL_NRF=yCONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=yCONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=yCONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=nCONFIG_CLOCK_CONTROL_NRF_K32SRC_50PPM=nCONFIG_CLOCK_CONTROL_NPCX_SUPP_APB4=n
Any guidance you can provide would be appreciated. Thank you!
Nathan Tennies
