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

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