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]

Update: I did a fault isolation sequence of taking features out of the project until the 700uA behavior went away.  I found that setting CONFIG_FLASH in prj.conf causes the sawtooth current behavior.

I'm needing to use NVS to store control parameter values in flash.  In a previous set of DevZone questions, I learned how to set up another flash partition, in addition to the partition for Bluetooth settings, and use a pm_static.yml file to define the partition.  I understood from the samples that I needed CONFIG_FLASH to make this work.

I'll include the prj.conf for your review.  Have I got conflicting configurations that causes this current behavior (like the flash controller cycling)?

#CONFIG_BT=y
#CONFIG_BT_PERIPHERAL=y
# Need this to set the advertised name at run-time
#CONFIG_BT_DEVICE_NAME_DYNAMIC=y
# Per Bluetooth Assigned Numbers, this is "Sensor"
#CONFIG_BT_DEVICE_APPEARANCE=1344
# Don't pollute the console stream with junk
CONFIG_LOG=n
CONFIG_BOOT_BANNER=n
# For security (and persistent bonding)
# See v2.1.0/zephyr/samples/bluetooth/peripheral
#CONFIG_BT_SMP=y
# Make the Sensor NOT attempt to override the connection parameters
# commanded by the PDU
#CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n
# Sensor has to go low-power, so it has to be equipped with a 32.768KHz crystal
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y
# Uses ADC to read battery (Vdd)
CONFIG_ADC=y
# Temp/Humidity device uses I2C
CONFIG_I2C=y
# Beeper uses PWM
CONFIG_PWM=y
# Needed to get RSSI from Host Controller Interface (HCI)
#CONFIG_BT_CTLR_CONN_RSSI=y
# Partition Manager is required for accessing flash partitions at runtime
# Sensor does not (yet) use a bootloader, so specify this setting (for now):
CONFIG_PM_SINGLE_IMAGE=y
# Configs for using flash for bond keys and Control/Metadata
#CONFIG_FLASH=y    # THIS IS WHAT DOES IT!!!
#CONFIG_FLASH_MAP=y
#CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_NVS=y
#CONFIG_SETTINGS=y
#CONFIG_BT_SETTINGS=y
# Power Management stuff
CONFIG_PM_DEVICE=y
CONFIG_PM_DEVICE_RUNTIME=y
# Turn off the UART/Console for additional power savings
CONFIG_SERIAL=n
CONFIG_CONSOLE=n
CONFIG_UART_CONSOLE=n
# Enable simulated peripheral to run on DK board
CONFIG_SENSOR_SIMULATION=n
# Select configuration of LEDs for DK board when running on DK board
CONFIG_SENSOR_USE_DK=n