nRF54L15 System OFF: ~36 µA on Rev 1 BC15M-V3 modules vs 0.9 µA on a Rev 2 DK, same system_off sample and NCS

[cmintz]

Setup

• Fanstel BC15M-V3 module (nRF54L15, FICR 0x340 = 0x1C, 0x344 = 0x01, i.e. Revision 1) on a small custom board. The only other active part is a TDK ICM-45686 IMU, on the same 3.0 V rail, left in its power-on state for the sample runs; its lines go to nRF pins the sample leaves as unused (disconnected) inputs. Supply: 3.0 V from a PPK2 in source-meter mode, straight onto the board's supply rail (100 µF + 0.1 µF decoupling).
• NCS v3.4.0, samples/boards/nordic/system_off. We build with the DK board target nrf54l15dk/nrf54l15/cpuapp plus an overlay that sets the module's crystal load capacitance (HFXO 17 pF, LFXO 7 pF, internal caps per the BC15M datasheet) and disables the DK-only peripherals our board doesn't have (UART, the external SPI flash). Console and the sample's GPIO/GRTC/LPCOMP wake sources are all disabled, via these additions to the sample's config: CONFIG_UART_CONSOLE=n, CONFIG_SERIAL=n, CONFIG_CONSOLE=n, CONFIG_PRINTK=n, CONFIG_GPIO_WAKEUP_ENABLE=n, CONFIG_GRTC_WAKEUP_ENABLE=n. The overlay is attached (3583.pod_bc15m_soc.overlay). The sample's early return after a power-on reset was removed — stock, it returns from main() when print_reset_cause() gets a cause of 0, so it never enters System OFF after a POR (worth a note in the sample README).

Measurement conditions (verified)

• Genuine power-on: the rail is drained (device powered off while awake and left off for 20 s, or the supply rail shorted to 0 V) before each run. The firmware records RESETREAS at the very start of main(): 0x0.
• No debug power request at the time sys_poweroff() is called: TAD SYSPWRUPREQ = 0, DBGPWRUPREQ = 0 (read by the firmware itself, saved to RRAM, read back afterwards).
• Current is steady at the 1 ms scale (per-second minimum of 1 ms windows ≈ the average), so this is not a wake/reboot loop. A 10 s raw capture at 100 µs resolution (101k samples) reads mean 40.2 µA, max 44.3 µA, zero samples above 100 µA.

Results (steady current in System OFF, 3.0 V)

variant of the stock sample	current
VREGMAIN DC/DC (DK default)	35-36 µA
VREGMAIN LDO	145 µA
LFRC instead of LFXO	36 µA
DK crystal load caps instead of module values	36 µA

The sample was measured on two of our five boards (35-38 µA on both). Our own application sleeps at 40-44 µA (incl. ~8 µA IMU wake-on-motion) on all five — verified with no debug probe connected at all on one board; the other four were measured with a probe attached but idle. The DC/DC-vs-LDO ratio (~4×) points at a ~110-145 µA load on the regulated core domain that persists into System OFF. It is not board leakage or the IMU: the unpowered board measures open-circuit on an ohmmeter, and anything powered straight from the 3.0 V rail could not change with the nRF's regulator mode.

Control: the nRF54L15 DK, same sample, same NCS, same 3.0 V, DC/DC

chip	FICR 0x340 / 0x344	System OFF
BC15M-V3 (all five of ours)	0x1C / 0x01 (Rev 1)	36-40 µA
nRF54L15 DK (PCA10156 1.0.0)	0x1C / 0x02 (Rev 2)	0.92 µA mean (0.73 median, 10 s raw at 100 µs, max 6.7 µA)

The DK ran the stock sample for its own board (no overlay), powered through its nRF current-measurement header (P6) with nothing else attached. Its figure was taken with its on-board debugger still requesting debug power (emulated System OFF), so its true figure is at most that. The two differ in both the module and the silicon revision, so this does not by itself say which one is responsible.

(Attached image: 10 s of each at 100 µs resolution. The pod trace is our application, so it includes ~8 µA for the IMU's wake-on-motion; the stock sample on the same board sits at 35-36 µA.)

Other observations

• Attaching a debugger to a device in this state and halting shows the core in nrf_regulators_system_off() (the loop after the SYSTEMOFF write), with RESETREAS = 0x800 (GRTC).
• VREGMAIN.INDUCTORDET reads 0 while DCDCEN = 1 on the BC15M — but the Rev 2 DK (external inductor, 0.92 µA asleep) reads exactly the same, so this is not a clue.
• SystemInit applies the erratum 37 write and disables GLITCHDET (checked in the disassembly). The erratum 37 register (0x5005340C) reads back 0 even immediately after writing 1 with TAD enabled.
• A pin reset does not clear it: cold power-on → 40 µA asleep; nRESET shorted to GND by hand (no debugger connected at all) → woke, slept again at the same 40 µA. So this is not the erratum-37-style "high after POR, normal after pin reset" pattern.
• Explicit shutdown before sys_poweroff() changes nothing (our application, no debugger): sys_clock_disable(), GRTC TASKS_STOP, CLOCK TASKS_XOSTOP/PLLSTOP/ LFCLKSTOP, every MEMCONF.POWER[n].RET/RET2 = 0, RESETREAS cleared, then the erratum 37 write plus a >40-cycle delay → still 40 µA (37.6 µA min per 1 ms).
• Forcing the Rev 1-only erratum 32 regulator write from SystemInit (0x50120640 = 0x1EA9E040, which it applies only when FICR 0x334 <= 0x180A1D00) at EARLY init changes nothing: still 40 µA.
• The module vendor (Fanstel) confirms these modules are lot B0V3, i.e. B0 = Rev 1 silicon, and that the module contains no other active component: its current consumption is the nRF54L15's.
• Ruled out: erratum 31/37 workarounds, NFC pads (nfct-pins-as-gpios), LFXO vs LFRC, crystal load caps, glitch detectors, NCS v3.3.0 vs v3.4.0.

Questions

1. Is a System OFF current of ~36 µA (DC/DC) / ~145 µA (LDO) known for Rev 1 silicon (FICR 0x344 = 0x01)? Five Rev 1 (B0) BC15M-V3 modules all show it, the module vendor states the module has no other active component, and a Rev 2 DK reads 0.92 µA under the same conditions.
2. If it is not a known Rev 1 behaviour, what could keep a ~110-145 µA load on VREGMAIN in System OFF, given that it scales with the regulator mode?

[Håkon Alseth]

Hi,

 

Revision 1 shall be able to go into system off with the specified current consumption.

It sounds like you have floating signals on your custom board.

You mention:

The only other active part is a TDK ICM-45686 IMU, on the same 3.0 V rail, left in its power-on state for the sample runs; its lines go to nRF pins the sample leaves as unused (disconnected) inputs.

You should set the pins to a defined level, as floating signals may cause excessive current consumption from your external sensor. Use internal pull-resistors to ensure that this is done.

 

If it is not a known Rev 1 behaviour, what could keep a ~110-145 µA load on VREGMAIN in System OFF, given that it scales with the regulator mode?

DCDC is required for lowest current consumption. Using LDO only is not a supported option, as per the reference design: https://docs.nordicsemi.com/r/bundle/ps_nrf54l15/page/chapters/ref_circuitry.html-concept_refcircuit_config_1

 

Kind regards,

Håkon

[cmintz]

Thank you, Håkon, you were right: it was the sensor, not the nRF54L15. 

**Root cause:** the TDK ICM-45686 powers up with weak (~100 kΩ) internal pull-ups enabled on several pads. On our board two of them conduct continuously:

- **INT2** (our wake-on-motion line) has its pull-up enabled by default (`IPREG_BAR_REG_62` bit 1). We drive INT2 push-pull, active high, so it idles low and the pull-up fights the pin's own output for the whole time the device sleeps: about 30 µA at 3 V. TDK's datasheet says to disable it when the pin is used as an I/O; we hadn't.
- **Pin 7** is tied to GND on our board and also has a default pull-up. Nordic's stock `system_off` sample never configures the IMU, so in that test this pull-up was on, which is where its ~33–36 µA came from. The DK control had no IMU at all, so my Rev 1 vs Rev 2 comparison was really "board with the sensor vs board without it".

With both pulls cleared by our firmware, the board now sleeps at **11 µA**: about 8 µA for the IMU's wake-on-motion plus 1–2 µA for the nRF54L15, in line with the datasheet.

What found it was a supply sweep of the sleeping board. The current rose linearly with VDD (about 9.6 µA/V, i.e. a ~100 kΩ path), which points to a resistive leak, not a load behind the DC/DC. The DC/DC-vs-LDO argument in my first post was wrong: that ratio can't come from a single load, and the LDO figure was taken with a debugger attached. Please disregard it. Also, the DK figure was not in emulated System OFF as I wrote; reading the snapshot after the fact woke the chip.

Thanks again for pointing us at the sensor.