nRF52840 high sleep current with sawtooth waveform

[David Ormand]

I've got a project based on NCS v2.6.0 using a nRF52840 as contained in a Fanstel BT840F module.

With help from you all (thank you!), the software works. Bluetooth and PWM and NVS are all working fine.

I'm trying to wrap this up at the power estimating phase, and I'm seeing something I need more help with.

In the previous version of this project, as we were delivering prototypes, 22 out of the 25 initial units exhibited the expected low 8uA average current, but some exhibited on the order of 700uA.  Since we had our required yield in hand, we did not pursue it.

In the current version, which differs only slightly from the previous (LEDs driven through MOSFETs instead of directly from the GPIO, a beeper driven via PWM through a MOSFET), almost all of them show 700-ish microamps.  I've got one that starts off working right (8uA), but if I cycle power with less than a few seconds of off-time, probably not enough for the capacitors to discharge, it comes back up in the 700-ish mode.  I've got another that starts off working right, but if I turn it off for less than _minutes_ and turn it back on, it comes up in the 700-ish mode.

Since we can't make our yield, I'm investigating.  What I see is that when it is working right, I get a nice supply current waveform with small spikies (this is zoomed into the quiescent region between radio bursts, when the chip should be asleep except for OS-driven timekeeping):

When it is working wrong, I get a supply current waveform with a sawtooth pattern, around 150uA peak-to-peak and average 700-ish uA.  The frequency varies somewhat from unit to unit, but its around 20KHz.

The BT840 module is strapped for Normal Voltage (VDD connected to VDDH), and there's 21.1uF bulk capacitance on the external supply line.  I don't know what's inside the module (other than the datasheet says the DC/DC is ready for service with an internal inductor) and I can't probe on anything useful.

It's not at all clear that my software or configuration settings could be responsible for a phenomenon that happens on some units and not others, and will show up on even "good" units.  Plus, I don't see this if I load the software on a nRF52840DK hacked for current measurement through P22.

Probably not related, but I observe something else:  When running the SW on the DK, the current spikes that indicate processor activity occur at 1 millisecond intervals.  Sure looks like a "tick" to me.  Same software running on our target hardware (the occasionally good ones) has an interval around 15ms that varies from unit to unit.  And yet they communicate just fine and the LED blinks at the expected interval.

Note that on "bad" units that always exhibit the 700-ish uA current draw, the software works fine.  The LED blinks at the expected interval.  BLE connects and stays connected with the Central.

[David Ormand]

Yet another update.  We took the lid off the BT840 module and found a big inductor near pin 1 of the nRF52840 chip.  With an LCR meter, it reads around 5uH in-circuit.  Not sure how much to believe it, since measuring L2 on a DK board ranges from 6 to 12uH and the schemo says 10uH.

Test software build has all the Bluetooth stuff and Flash (NVS filesystem and Settings) taken out.  Per preceding updates, CONFIG_BT and CONFIG_FLASH are enabled or commented-out.  Apparently, when enabled, setup code is pulled out of the SDK, built, and executed, without anything in the application demanding it, since the current-draw behavior is different with and without them.  Test SW blinks the LED and beeps the beeper with PWM for 150ms at 3-second intervals.

With the DK board running the SW with CONFIG_BT and CONFIG_FLASH turned off (and with the LEDs configured for the DK), I can observe the "normal" low-current profile at P22,  When I probe the side of L2 that is probably connected to DCC (the side away from L3), I see low-level voltage punctuated by the 150ms bursts of activity at 3-second intervals.  The background is a sawtooth running at around 70Hz.  The bursts are actually a series of pulses at around 7KHz.  Each pulse is a train of square cycles at around 8MHz.

The DK build of SW was then modified to turn CONFIG_BT and CONFIG_FLASH back on.  No difference in the current profile or the waveform at the DCC inductor was observed.

The target board with the beeper and the I2C sensor removed (the LED was put back on for visual feedback) and the BT840 with the EMI shield removed was loaded with the SW with CONFIG_BT and CONFIG_FLASH commented-out.  The current profile was verified to be the "normal" low ~4uA mode.  The side of the big inductor closest to the nRF52840 was probed.  Turns out the waveform is very similar to that observed previously on the DK.  Only the frequency of the pulses (third picture down) is significantly different; 11KHz versus 7KHz.

Then the target board was loaded with software with CONFIG_BT and CONFIG_FLASH turned on.  The current profile was verified to be the naughty 700uA sawtooth.  NOW, the waveform observed at the same point is significantly different.  There is no burst at 3-second intervals (even though the LED is still blinking).  Instead, the waveform is a uniform train of pulses at 20KHz.  Each pulse is a 8MHz square wave, as before.  I note the 20kHz rate of pulses on the DC/DC is similar/same as the 20KHz of the 700uA current profile.

I don't know how the DC/DC converter on the nRF52 works, and there doesn't seem to be much SW control (DC/DC converters can be enabled by registers but there's nothing I see in the PS about modifying their operation), so I will be interested in comments for why there is an apparent difference in function.