Current draw jumps ~187 uA after 10 min for no apparent reason.

[jthmp]

We are using the legacy 17.1 nrf sdk with the nrf52840 MCU in tickless idle mode and notice that after about 10.5 minutes the current draw jumps from ~90uA to ~277 uA.

There is no obvious change in our firmware behavior and no unusual activity when the jump happens (that we can see so far, but still looking).

The system is just in idle mode the whole time.

In other versions of our firmware the time can be anywhere from 25.5 minutes to 35 minutes depending on the firmware version. But it's always a consistent time (ex: always 35 min).

We suspect it's a gpio being turned on (like a gpio input with a pullup) but so far we haven't found the culprit. 

We are going to apply errata 246 fix:
https://docs.nordicsemi.com/bundle/errata_nRF52840_Rev3/page/ERR/nRF52840/Rev3/latest/anomaly_840_246.html

but this should only save 40 uA.

What would cause a jump like this?

[hmolesworth]

One possibility is one or more slow or floating inputs start to cause feedthrough leakage which can be of the order of the current observed. To avoid this often the best course is to drive all unused io pins as output low (this has no significant effect on power consumption). Worth checking other pins (such as analogue inputs) for levels which may lie on the threshold around VDD/2 when the SAADC is disabled. I have seen this effect hold for periods of time when the pin voltage rises slowly to the tiny window which causes feedthrough from internal VDD to internal GND which loads slightly the battery voltage and the pin voltage then stops rising and stays in the problem window.

Description of feedthrough mechanism scba004e.pdf

Maybe post a pdf of the schematic for review

[jthmp]

So, it looks like there are no unused gpio. 

Here are things we have tried:

- reset all gpio to input / no pull on startup before configuring for actual use (didn't fix)

- printed out any gpio config / states changes in a thread to see if the current draw corresponds to a gpio change (no changed detected)

Do you have any suggestions for detecting what peripheral states might have changed that might be effecting this current draw jump?

[jthmp]

Hi Edvin, 
Yes, that's a good idea. We will try that.

It's possible that it's some other IC but so far we haven't been able to find any indication that it is. The whole system is just in idle mode and periodically wakes up to service a task (like logging).

One note, the extra current is the same amount of extra current that we see when enabling a gpio input with a pullup and then applying 0V to the input. About 180uA. 
So it definitely seems like it could be a gpio. But like a said, we added code to periodically check if any of the 47 gpio on the board had a state change when the issue occurs and we don't see any.

[jthmp]

Hi hmoleworth,

Those are suggestions we will try out, thanks!
Our mcu runs on 1.8V VDD. We'll test out the VDD jump.

As a note: we are using an Otti 3 Power profiler, (DC energy analyzer and power supply) to measure the current. 

[hmolesworth]

1.8V VDD and internal pullup of typically 14k is about 128uA when driving input to 0v with pullup enabled; do you really see an extra 180uA? As an aside, I would recommend a secondary measurement - with the Otii 3 disconnected, ie not used - using a battery and (say) a PPK-II just to confirm findings.

Perhaps also review Errata 78, 87, 122, 194, 195, 210, 241 in addition to 246. A better way to handle 246 is to place peripheral buffers in a separate RAM AHB bus area away from stack and other CPU variables.

One other thought; if using (say) SPIM with the pullup enabled on MOSI the last bit transmitted may be usually '1' but maybe every 10 minutes that last bit is a '0' and if the SPIM is not disabled that leaves current flowing through the pullup (if there is a pullup set). The same type of issue applies with MISO; if using a pullup - usually the case for MISO - and the attached device happens to leave MISO at '0' on the last byte transmitted the same applies. Some designs power down the external device, though it would seem odd to do that after 10 minutes; however if the external device were powered down the MISO pullup would have to be disabled as simply disabling SPIM does not change the pullup setting on the MISO io pin and the MISO pullup would be phantom-powering the external device via that device's internal schottky protection diode.

[jthmp]

Hi hmolesworth,
Thank you for those suggestions. When we enter idle mode we disable our peripherals (like i2c, spi...etc) before hand. For spi we wait till spi is not busy and then call 

- nrfx_qspi_uninit before going to idle

and then right after wakeup we call 

- nrfx_qspi_init

we do not manually configure any gpio. So, you are saying we should configure the gpio before and after idle in the way you describe? 

[hmolesworth]

No, configuring GPIO before and after sleep is not usually required, but there is insufficient information posted to decide: if the external devices are powered off in sleep by (say) an io pin then the SPIM port io must be manually changed when (say) the spim is uninit and the external SPI device is powered down. This is not required if the external SPI (or other) device remains powered up.

I would suggest trying a power-off of every SPIM. TWI, etc  used by the design while the nRF52840 peripheral is disabled in sleep. Here's an example for QSPI:

  nrfx_qspi_uninit
  *(volatile uint32_t *)( NRF_QSPI_BASE+0xFFC) = 0; //  QSPI Power Enable - turn off
  
  .. sleeping
  
  *(volatile uint32_t *)( NRF_QSPI_BASE+0xFFC) = 1; //  QSPI Power Enable - turn on
  nrfx_qspi_init

Better to try each in turn to isolate the culprit (if any); takes a while though and the power off/on is benign. Usual suspects are I2C and SPI, though UART and Timers and PWM can all be a nuisance.

Beyond this without a schematic I doubt I can help further.

[jthmp]

Hi hmoleworth.

We don't power down the flash IC when going into tickless idle mode.

Here is a snippet of the schematic showing the IC. All gpio lines go straight to the nrf52840 MCU soc (we are using the Laird BL654 Series module).

[hmolesworth]

The /CS pull-up recommended value is 10k I see, probably not an issue but worth noting.

SPI_IO2 and SPI_IO3 on the flash IC have internal pull-ups quoted at 40uA each; worth probing to see if those pins are held low on fault condition.

Edit: you mean nRF52840, not nRF54L15 I take it ..

[jthmp]

Hi, yes just fixed the MCU part, thanks!
Ok, I'll check those pins out as well.

[hmolesworth]

In passing since QSPI is being used the likelihood is that a high SCK speed is being used. Bus contention between CPU or other peripheral DMA and QSPI buffer DMA read/write can cause unexpected conditions. The solution is to ensure no CPU or other enabled peripheral DMA access can occur over the SRAM AHB slave bus used by the QSPI DMA buffers by allocating an entire RAM block; the nRF52840 has 8 such AHB slave RAM blocks.

Have a look at my post here which provides some guidance; worth reading all as practical details towards the end of the post:

nrf52840-display-glitch-using-spim

Edit: Changed SPIM3 in code earlier in this thread to QSPI:

  nrfx_qspi_uninit
  *(volatile uint32_t *)( NRF_QSPI_BASE+0xFFC) = 0; //  QSPI Power Enable - turn off
  
  .. sleeping
  
  *(volatile uint32_t *)( NRF_QSPI_BASE+0xFFC) = 1; //  QSPI Power Enable - turn on
  nrfx_qspi_init

[hmolesworth]

How's it looking?