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?

[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?

[jthmp]

Hi, I was pulled away to another issue. I still have this on my todo for today and will get back to you will results.

[jthmp]

So I tried applying  *(volatile uint32_t *)( NRF_QSPI_BASE+0xFFC) = 0; and *(volatile uint32_t *)( NRF_QSPI_BASE+0xFFC) = 1; as you suggested but I still get the current jump.

Or was there more to that fix?

[jthmp]

This is probably the results of some gpio issue. We can close the ticket for now since investigating will take more time for us.