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]

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