nRF52832 high current consumption after reset

[KimWurtz]

Hi folks

We are facing an issue with occasionally ~240 uA added current consumption on our nRF52832 based custom board when it comes out of reset. We only see the problem on maybe 1-2% of the devices and even devices having this erratic behavior does not aways exhibit this issue. To narrow down the root cause of the problem we have tried various things, but so far only below "solutions" seems to solve the problem:

1. Replace the softreset with a watchdog reset seems to solve the problem.
2. Removing the secure bootloader from the solution and just let the device startup in our application from reset seems to solve the problem. We can softreset the device without having the extra current consumption after reset.

We have verified that just before softresetting the device the current consumption is normal (not the added ~230 uA), but just after reset the current is added an so far only if the secure bootloader is part of the solution.

Judging from the amount of added current consumption, I suspect it is a resource in the chip that has requested for the HF oscillator and forget to turn it off again. Is there any known issues regarding this with the secure bootloader? Any other clue that could cause this issue? 

We are using Softdevice S132 v5.0.0 / SDK 14.0.0 and its accompanying secure_bootloader_ble

[Einar Thorsrud]

Hi,

Is the device using the LFXO or LFRC as low frequency clock soruce? The reason I ask is that there is a known issue in S132 version 5 where the HFXO may be left running after LFRC calibration. Thisis fixed in version 6.0.0.

[KimWurtz]

Both the bootloader and the application are configured with "CLOCK_CONFIG_LF_SRC 1" in the sdk_config.h file, which means 32 kHz XTAL, we are not using the LFRC oscillator.

[Einar Thorsrud]

I see. That ruels out the issue I mentionned.

Have you verified that either performing a watchdog reset or removing the bootloader fix the issue by"enough" testing? Have you done any changes in the bootloader? The main differences between a watchdog reset and a soft reset are described in the reset behavior table. But it is difficult to say what could also requier the bootloader to be presnt, and manifest itself on ony a smal portion of the devices.

Do you have other findings or other information you can share that may tell us more about this issue?

[hmolesworth]

"A retained register is a register that will retain its value in System OFF mode and through a reset, depending on reset source" (quote from the link Einar provided). Now softreset retains registers including the port pins CNF register, which may have a pull-up or pull-down enabled. Watchdog reset clears the port CNF register, probably clearing any pull-up or pull-down settings. "The PIN_CNF registers are retained registers".

Pull-up or pull-down resistance value is about 13k0 and 3.3V @ 13k = 250uA, merely a coincidence?

If not a coincidence - and simple to test - clear all port CNF registers immediately before a softreset.

[KimWurtz]

Sorry for not getting back on this topic, but had been away for a while. However I have now had the time to investigate this a bit further.

My first assumptions around the HFXO not being turned off was wrong. The HFXO is indeed turned off. Further investigations however reveals that the problem is related to the Watchdog. We use the Watchdog in our application with a timeout of 120 sec and feeds the watchdog every 10 sec. We have it configured this way:

void watchdog_init(uint32_t seconds)
{
if (NRF_WDT->RUNSTATUS & (WDT_RUNSTATUS_RUNSTATUS_Running << WDT_RUNSTATUS_RUNSTATUS_Pos)) {
// Watchdog is already running which means that this was a soft reset and the watchdog
// is already configured

// Feed dog
watchdog_feed();
} else {
// Not running, need to configure

// Run watchdog in sleep mode, pause watchdog in debug halt mode
NRF_WDT->CONFIG = (WDT_CONFIG_SLEEP_Run << WDT_CONFIG_SLEEP_Pos) | (WDT_CONFIG_HALT_Pause << WDT_CONFIG_HALT_Pos);

// 120 second timeout
NRF_WDT->CRV = seconds * 32768 - 1;

// Require RR0 to feed watchdog
NRF_WDT->RREN = (WDT_RREN_RR0_Enabled << WDT_RREN_RR0_Pos);

// Go!
NRF_WDT->TASKS_START = 1;
}
}

So the Watchdog keeps running when the system is idling.

What is seen to be consistent behavior is the following:

1) Power On Reset -> Bootloader passes execution to application -> application configures the WDOG for the first and only time -> application feeds WDOG every 10 sec. (Power consumption is a couple of uA's OKAY).

2) Next at some point in time, the application soft reset the device -> Bootloader passes execution to application -> application feeds watchdog every 10 sec. (Power consumption is now ~ 250 uA BAD).

3) Application again soft reset device at some point in time -> Bootloader passes execution to application -> application feeds WDOG every 10 sec. (Power consumption is a couple of uA's OKAY).

 

4) Application once again soft reset device at some point in time -> Bootloader passes execution to application -> application feeds WDOG every 10 sec. (Power consumption is a couple of uA's OKAY).

5) Application once again soft reset device at some point in time and the device now behave as in 2) 

This pattern repeats itself infinitely that is every third soft reset provokes the high current usage.

I have then tried to reconfigure the watchdog so the watchdog is also stopped when CPU is idling like this:

NRF_WDT->CONFIG = (WDT_CONFIG_HALT_Pause << WDT_CONFIG_HALT_Pos);

Now the behavior changes a bit regarding the current consumption:

1) Power On Reset -> Bootloader passes execution to application -> application configures the WDOG for the first and only time -> application feeds WDOG every 10 sec. (Power consumption is a couple of uA's OKAY).

2) Next at some point in time, the application soft reset the device -> Bootloader passes execution to application -> application feeds watchdog every 10 sec. Power consumption is now ~ 2 uA for the first 30 sec (equal to 3 retriggering of the watchdog) and at the 3rd retriggering, the current jumps to ~250 uA and stays there until the next retriggering 10 sec. later where current falls back to ~2 uA. This pattern then repeats itself for every retriggering of the watchdog.

Now at this point Power-On reset doesn't remove this problem.

Apparently an issues with the Watchdog system (there are also a couple errata around the watchdog and I also see other users have reported similar issues). However could it also be an issues with the bootloader and application compatibility? I see that the bootloader de-initialize the clock system before passing execution to the application and for that to work with the an already enabled watchdog (after a soft reset) I had let the bootloader NOT stop the LFCLK which it normally does.

Br Kim

[KimWurtz]

I should add that completely stop using the watchdog in the application also solves the problem.

[hmolesworth]

How is sleep related to the watchdog trigger, is it asynchronous? ok-ok-ok-high-ok-ok-ok-high-... looks suspicious if that is always the sequence. Any DMA transfers taking place, and if so and especially with multiple DMAs are the DMA buffers enforced to lie within different RAM blocks? That includes a single SPI with Rx and Tx buffers lying in separate RAM blocks. If common RAM, then worth enforcing separation just in case.