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

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

jthmp — Wed, 01 Apr 2026 17:46:22 GMT

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

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

jthmp — Wed, 01 Apr 2026 17:30:44 GMT

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?

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

jthmp — Wed, 01 Apr 2026 16:52:45 GMT

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.

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

hmolesworth — Wed, 01 Apr 2026 00:31:47 GMT

How's it looking?

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

hmolesworth — Wed, 25 Mar 2026 15:52:31 GMT

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

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

jthmp — Tue, 24 Mar 2026 19:31:13 GMT

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

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

hmolesworth — Tue, 24 Mar 2026 17:27:32 GMT

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

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

jthmp — Tue, 24 Mar 2026 17:08:33 GMT

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

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

hmolesworth — Tue, 24 Mar 2026 16:51:16 GMT

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.

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

jthmp — Tue, 24 Mar 2026 15:49:34 GMT

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?

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

hmolesworth — Fri, 20 Mar 2026 22:16:07 GMT

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.

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

jthmp — Fri, 20 Mar 2026 17:11:35 GMT

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.

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

jthmp — Fri, 20 Mar 2026 17:09:40 GMT

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.

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

hmolesworth — Fri, 20 Mar 2026 16:23:47 GMT

Following on from Edvin's suggestion, which can take a lot of time to test when the fault is intermittent, you could instead simply power down any peripheral that you disable or are not using, provided you power the peripheral back up prior to initialising. I use this for reliability, and although not fully documented in the data sheets some of the information is published in Nordic Devzone responses.

Perhaps choose appropriate peripherals from this list, copied from one of my projects:

// Calculate index for Power Control field
#define POWER_INDEX (0xFFC/sizeof(uint32_t))
STATIC_ASSERT( (NRF_SPIM0_BASE+0xFFC) == 0x40003FFC, "POWER_INDEX calculation does not match compiler");

// Comment out peripherals actually in use by the application
void PowerOnPeripherals(uint32_t PowerBit)
{
   uint32_t Setting = 0;  // 0 is power off
   if (PowerBit > 0) Setting = 1;

   // Power Enables - Sorted by Peripheral address
// *(volatile uint32_t *)( NRF_CLOCK_BASE+0xFFC) = Setting; //  CLOCK Power off    shared address, no register
// *(volatile uint32_t *)( NRF_POWER_BASE+0xFFC) = Setting; //  POWER Power off    shared address, no register
   *(volatile uint32_t *)( NRF_RADIO_BASE+0xFFC) = Setting; //  RADIO Power Enable
   *(volatile uint32_t *)(NRF_UARTE0_BASE+0xFFC) = Setting; //  UARTE Power Enable
   *(volatile uint32_t *)( NRF_SPIM0_BASE+0xFFC) = Setting; //  SPIM0 Power Enable shared address
// *(volatile uint32_t *)( NRF_SPIS0_BASE+0xFFC) = Setting; //  SPIS0 Power Enable shared address
// *(volatile uint32_t *)( NRF_TWIM0_BASE+0xFFC) = Setting; //  TWIM0 Power Enable shared address
// *(volatile uint32_t *)( NRF_TWIS0_BASE+0xFFC) = Setting; //  TWIS0 Power Enable shared address
   *(volatile uint32_t *)( NRF_SPIM1_BASE+0xFFC) = Setting; //  SPIM1 Power Enable shared address
// *(volatile uint32_t *)( NRF_SPIS1_BASE+0xFFC) = Setting; //  SPIS1 Power Enable shared address
// *(volatile uint32_t *)( NRF_TWIM1_BASE+0xFFC) = Setting; //  TWIM1 Power Enable shared address
// *(volatile uint32_t *)( NRF_TWIS1_BASE+0xFFC) = Setting; //  TWIS1 Power Enable shared address
   *(volatile uint32_t *)(  NRF_NFCT_BASE+0xFFC) = Setting; //   NFCT Power Enable
   *(volatile uint32_t *)(NRF_GPIOTE_BASE+0xFFC) = Setting; // GPIOTE Power Enable
   *(volatile uint32_t *)( NRF_SAADC_BASE+0xFFC) = Setting; //  SAADC Power Enable
   *(volatile uint32_t *)(NRF_TIMER0_BASE+0xFFC) = Setting; // TIMER0 Power Enable
   *(volatile uint32_t *)(NRF_TIMER1_BASE+0xFFC) = Setting; // TIMER1 Power Enable
   *(volatile uint32_t *)(NRF_TIMER2_BASE+0xFFC) = Setting; // TIMER2 Power Enable
   *(volatile uint32_t *)(  NRF_RTC0_BASE+0xFFC) = Setting; //   RTC0 Power Enable
   *(volatile uint32_t *)(  NRF_TEMP_BASE+0xFFC) = Setting; //   TEMP Power Enable
   *(volatile uint32_t *)(   NRF_RNG_BASE+0xFFC) = Setting; //    RNG Power Enable
   *(volatile uint32_t *)(   NRF_ECB_BASE+0xFFC) = Setting; //    ECB Power Enable
   *(volatile uint32_t *)(   NRF_AAR_BASE+0xFFC) = Setting; //    AAR Power Enable
   *(volatile uint32_t *)(   NRF_CCM_BASE+0xFFC) = Setting; //    CCM Power Enable
   *(volatile uint32_t *)(   NRF_WDT_BASE+0xFFC) = Setting; //    WDT Power Enable
   *(volatile uint32_t *)(  NRF_RTC1_BASE+0xFFC) = Setting; //   RTC1 Power Enable
   *(volatile uint32_t *)(  NRF_QDEC_BASE+0xFFC) = Setting; //   QDEC Power Enable
   *(volatile uint32_t *)(  NRF_COMP_BASE+0xFFC) = Setting; //   COMP Power Enable
   *(volatile uint32_t *)(NRF_LPCOMP_BASE+0xFFC) = Setting; // LPCOMP Power Enable
   *(volatile uint32_t *)(  NRF_EGU0_BASE+0xFFC) = Setting; //   EGU0 Power Enable
   *(volatile uint32_t *)(  NRF_EGU1_BASE+0xFFC) = Setting; //   EGU1 Power Enable
   *(volatile uint32_t *)(  NRF_EGU2_BASE+0xFFC) = Setting; //   EGU2 Power Enable
   *(volatile uint32_t *)(  NRF_EGU3_BASE+0xFFC) = Setting; //   EGU3 Power Enable
   *(volatile uint32_t *)(  NRF_EGU4_BASE+0xFFC) = Setting; //   EGU4 Power Enable
   *(volatile uint32_t *)(  NRF_EGU5_BASE+0xFFC) = Setting; //   EGU5 Power Enable
   *(volatile uint32_t *)(NRF_TIMER3_BASE+0xFFC) = Setting; // TIMER3 Power Enable
   *(volatile uint32_t *)(NRF_TIMER4_BASE+0xFFC) = Setting; // TIMER4 Power Enable
   *(volatile uint32_t *)(  NRF_PWM0_BASE+0xFFC) = Setting; //   PWM0 Power Enable
   *(volatile uint32_t *)(   NRF_PDM_BASE+0xFFC) = Setting; //    PDM Power Enable
   *(volatile uint32_t *)(   NRF_MWU_BASE+0xFFC) = Setting; //    MWU Power Enable
   *(volatile uint32_t *)(  NRF_PWM1_BASE+0xFFC) = Setting; //   PWM1 Power Enable
   *(volatile uint32_t *)(  NRF_PWM2_BASE+0xFFC) = Setting; //   PWM2 Power Enable
   *(volatile uint32_t *)( NRF_SPIM2_BASE+0xFFC) = Setting; //  SPIM2 Power Enable shared address
// *(volatile uint32_t *)( NRF_SPIS2_BASE+0xFFC) = Setting; //  SPIS2 Power Enable shared address
   *(volatile uint32_t *)(  NRF_RTC2_BASE+0xFFC) = Setting; //   RTC2 Power Enable
   *(volatile uint32_t *)(   NRF_I2S_BASE+0xFFC) = Setting; //    I2S Power Enable
#if defined(NRF52833_XXAA) || defined(NRF52840_XXAA) //|| defined(TESTING_ON_nRF52833DK)
   *(volatile uint32_t *)(  NRF_USBD_BASE+0xFFC) = Setting; //   USBD Power Enable
   *(volatile uint32_t *)(NRF_UARTE1_BASE+0xFFC) = Setting; // UARTE1 Power Enable
   *(volatile uint32_t *)(  NRF_PWM3_BASE+0xFFC) = Setting; //   PWM3 Power Enable
   *(volatile uint32_t *)( NRF_SPIM3_BASE+0xFFC) = Setting; //  SPIM3 Power Enable
#endif
}

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

Edvin — Fri, 20 Mar 2026 08:01:17 GMT

Hello,

[quote user="jthmp"]

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

[/quote]

You shouldn't need this. By default, all pins are disconnected inputs, which is the state that draws the least amount of current.

I would try to remove one peripheral at the time (never enable it in the application) until the behavior goes away. That should help pinpointing where the issue is.

Could it be other devices on your PCB that is drawing the current?

Best regards,

Edvin

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

hmolesworth — Thu, 19 Mar 2026 20:16:34 GMT

Probing the io pins with a 'scope would be worth doing, though if there is no 'scope available simply touching each io pin connection with a sharp sewing needle held in a bare hand would indicate any pin voltage issues by a corresponding change in observed current. Your comment about unexpected pullup or pulldown or an input held in an unexpected state with pullup/down enabled would give somewhere close to the observed jump assuming 3V and 13k internal resistance.

If not already doing so, adding timer overflow interrupt processing might catch an unexpected timer issue. If not already doing so, add an io pin toggle on sleep/wake to verify the mark:space ratio remains exactly as expected. Any io pin can be hijacked for that purpose provide it doesn't have a load - pushbutton input is ideal if no external pullup/down.

What is the exact value VDD before and after the jump; is there a measurable difference? Are there any potential phantom power sources attached to io pins?

A schematic is needed to provide more thoughts, either post here or email direct if the circuit is connfidential.

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

jthmp — Wed, 18 Mar 2026 22:13:23 GMT

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?

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

jthmp — Wed, 18 Mar 2026 17:58:19 GMT

Thank you for your reply hmolesworth,

We will try out your suggestion and get back to you with a schematic snapshot if necessary.

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

hmolesworth — Wed, 18 Mar 2026 16:51:14 GMT

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