nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Simonr — Mon, 14 Sep 2026 08:27:13 GMT

Hi Thiery

1. We refer to the Zephyr board file for the XIAO nRF54LM20A sense board here, where the default voltage is 1.8V. https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/seeed/xiao_nrf54lm20a/xiao_nrf54lm20a_nrf54lm20a-common.dtsi#L83-L86 But if you have set that manually to 3.3V and confirmed that's the case I assume it's overwritten in your project.

2. Understandable.

3. Thank you. This has been forwarded internally, and we'll review it on our end before getting back to you.

Best regards,

Simon

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Thiery — Mon, 14 Sep 2026 06:18:53 GMT

Hi Simon,

Thank you for the follow-up. Two things to address, plus new isolation data from today.

1. LDO1 / VOUT2 voltage. We re-verified LDO1's actual configured voltage by reading it back directly from the PMIC hardware register at runtime (not just re-reading our devicetree source): regulator_get_voltage() on the imu_vdd/LDO1 device returns 3,300,000 µV (3.3 V) with a success return code, matching our devicetree's regulator-min/max-microvolt = <3300000> exactly. So LDO1 is confirmed at 3.3 V on real hardware, not 1.8 V — we don't have an explanation for where the 1.8 V figure came from on your side; could you point us to the specific file/line you were looking at, in case it's an older revision we shared earlier in this thread?

For VOUT2: we don't have a devicetree consumer for the nPM1300's BUCK2 output anywhere in our firmware — it's not used by any driver in our design, so we don't have an equivalent runtime readback for it. If you have visibility into what R28/R29 physically connect to on the schematic (LDO1's output specifically, vs. VOUT2, vs. something else), that would help us target further testing without guessing.

2. Ferrite bead removal. We'd prefer not to do this at this stage — it means modifying the board in a way that isn't easily reversible, and we don't have a spare unit we're willing to risk for exploratory rework right now. If there's a non-destructive way to get equivalent information, we're glad to try that instead.

3. New isolation data since our last message. Two further single-variable tests, same PPK2 protocol as before:

LDO2 in isolation — no measurable increase over baseline (~5.9 vs ~6.0 µA), against LDO1's ~218 µA excess in the same session. Points at the anomaly being specific to LDO1's net, not the LOADSW/LDO block generically.
PDM microphone wake sequence, revisited — tried the datasheet's documented Sleep-Mode entry sequence (brief clock burst then static low, instead of static low from power-up). No change measured. Doesn't hold up as tested, though our clock generation wasn't scope-verified.

Best regards, Thiery

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Simonr — Tue, 08 Sep 2026 06:24:21 GMT

Hi Thiery

If all else fails, there are ferrite beads on the IMU and MIC supplies. Can you try to remove them to try to isolate where the current is going? The LDO quiescent current should be <1µA.

Can you also confirm which voltages you're using for the VOUT2 and LDO1 rails? In the schematic both are labelled as 3.3V, and the VSET2 resistor corresponds to 3.3V on VOUT2, but in your Zephyr board .dts file, the LDO1 is set to 1.8V. If VOUT2 and LDO1 has different voltages there are other chances for leaks. For example, if the nRF54LM20 has a bias-pull-up set on the I2C pins, ther will be a voltage difference over R28 and R29.

Best regards,

Simon

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Thiery — Mon, 07 Sep 2026 13:09:52 GMT

Hi Simon,

Tested exactly as you suggested — same isolated methodology (single continuous PPK2 capture, imu_vdd held on throughout, only the CTRL3_C value changed mid-capture), now with a third segment adding PP_OD=1 on top of H_LACTIVE=1:

Segment	CTRL3_C	Measured
H_LACTIVE=0, PP_OD=0 (original default)		272.078 µA
H_LACTIVE=1, PP_OD=0 (already shipped)		239.009 µA
H_LACTIVE=1, PP_OD=1 (your suggestion)		239.082 µA

H_LACTIVE alone accounts for the full 33.07 µA (matches the 3.3V/100kΩ calculation almost exactly). Adding PP_OD on top changes nothing — 239.082 vs 239.009 µA is within measurement noise. Makes sense in hindsight: once H_LACTIVE=1 makes the idle state HIGH, the push-pull driver is already sourcing close enough to VDDIO that there's no meaningful current left through R38 for open-drain to save.

So with that confirmed, and pin configuration/initial chip state already verified for all four pins (SDA, SCL, INT1, CS) — we're back to the same open question: ~239µA on LOADSW1/LDO1 alone, zero load, zero I2C traffic, still unaccounted for. Is there anything further on your side to check, or should we consider this an inherent characteristic of the block that isn't in the current datasheet?

Best, Thiery

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Simonr — Mon, 07 Sep 2026 09:06:03 GMT

Hi Thiery

Okay, so you measure INT1 (P0.06) to be low while the LDO is powered, correct? If that's the case, there would be 3.3V across R38, so could that be the culprit here?

The polarity here would need to be updated in a control register, as well as setting the PP_OD bit to 1. This changes the pin behavior from push-pull to open-drain.

Can you try that and see if it makes a difference?

Best regards,

Simon

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Thiery — Fri, 04 Sep 2026 09:57:38 GMT

Hi Simon,

To answer directly: yes, H_LACTIVE gives a real, measured improvement (265.33µA → 232.61µA, isolated, LDO1 held on continuously, zero I2C traffic — a 32.7µA delta matching the 3.3V/100kΩ calculation within 1%). All four relevant pins are now accounted for (SDA, SCL, INT1, and CS — the last one only found via your schematic). And yes, we still see ~232µA with LDO1/imu_vdd enabled alone, no load, no I2C traffic — that's the number left after the H_LACTIVE fix, and it only appears when the LDO is enabled (our disabled baseline is consistently ~3.3-3.9µA).

On backpowering — we tested this exact scenario already, for all four pins, and it doesn't match what we see. Method: each pin configured as a plain floating input (no SoC-side pull), imu_vdd held disabled, then enabled, then disabled again:

Pin	LDO1 never enabled since boot	LDO1 enabled	LDO1 disabled again
SDA	stable LOW	stable HIGH	HIGH ~100ms, then stable LOW
SCL	stable LOW	stable HIGH	HIGH ~100ms, then stable LOW
CS	stable LOW	stable HIGH	HIGH ~100ms, then stable LOW
INT1	stable LOW	stable LOW	stable LOW

If an external pull-up on a still-powered rail were backpowering the net, we'd expect these pins to read HIGH with the LDO off — none do, in either the "never touched since boot" case or after being on. SDA/SCL/CS only rise once imu_vdd is enabled and decay within ~100ms of it being disabled (consistent with the pull-up sitting on imu_vdd itself, not an external rail). INT1 stays low throughout, which is the H_LACTIVE mechanism we already described — not backpowering.

So with backpowering ruled out on all four pins, and pin configuration otherwise confirmed correct, the ~232µA on LOADSW1/LDO1 with zero load and zero I2C traffic still stands unexplained. Is there anything else on our side worth checking, or does this point back to something internal to the block?

Best regards, Thiery

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Simonr — Thu, 03 Sep 2026 08:43:26 GMT

Hi Thiery

I'm not sure I understand what you explain in point 4 here. Does setting one of the IMU pins to H_LACTIVE improve the current consumption somewhat. Are all pins accounted for and you now still see a ~230µA current consumption, and only when LDO1 is enabled?

Can you check the state of the GPIOs when the LDO is off? If they are high, there might be due to the LDO backpowering the net you see this issue. These should be high impedance or pulled low to make sure you avoid backpowering scenarios.

Best regards,

Simon

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Thiery — Tue, 01 Sep 2026 10:37:08 GMT

Thank you for the follow-up questions on pin configuration and IMU power state. We tested both directly on hardware rather than re-deriving them from the datasheet.

1) Microphone clock/data: already covered in our original report — tested twice, no change (253µA) either time.

2) IMU pins (SDA/SCL/INT1) high-Z with imu_vdd off: the one part we hadn't actually tested. All three float correctly — no external pull-up bias, rules out leakage into the unpowered IMU.

3) IMU initial low-power state: confirmed empirically — CTRL1_XL and CTRL2_G both read 0x00 (power-down) at every delay tested, 5/5 reads.

4) A fourth pin we'd missed: after your reply we obtained Seeed's official schematic, which revealed IMU_CS (P3.12, 100kΩ pull-up, never tested before). It behaves correctly — not the cause. But INT1 did not: it sat permanently low even with imu_vdd on, fighting its own 100kΩ pull-up. Root cause: H_LACTIVE defaults to 0 in CTRL3_C, and with no interrupt source routed, the pad's "inactive" state is actively driven low by the chip itself. Isolated measurement: 265.33µA → 232.61µA after setting H_LACTIVE=1, a 32.7µA improvement matching the 3.3V/100kΩ calculation within 1%. Now shipped in production, confirmed no regression (~22-23µA system-level).

With pin configuration and initial chip state fully verified, and this independent fix shipped, the dominant LOADSW1/LDO1 steady-state current (~250-275µA, zero load, zero I2C traffic) still accounts for the large majority of the figure and remains unexplained on our side. Any guidance on a known internal quiescent/ground current for this block in LDO mode would be very welcome — it's the last item between our ~20-22µA and the 5-6µA target. Thanks' Thiery

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Simonr — Tue, 01 Sep 2026 07:53:54 GMT

Hi Thiery

What pins are you using on the nRF54LM20A in your application? The LDO powers a few things that have initial states that is connected further in the system. For example, there are two 100k pull-up resistors connected to that rail for IMU signals. If the nRF54LM20A drives P3.12 or P0.06 low for example, you will get power from those right away. That would account for ~660µA.

Best regards,

Simon

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Thiery — Mon, 31 Aug 2026 16:39:23 GMT

Thank you for the follow-up questions on pin configuration and IMU power

state. We tested both directly on hardware rather than re-deriving them

from the datasheet, using a dedicated read-only diagnostic build on unit

#02 (SWD/memory-trace readback, no UART/console involved).

**1. Microphone clock/data (`PDM_CLK`/`PDM_DIN`).** Already covered in

our original report, §8, "Further checks performed": `imu_vdd` and the

on-board PDM microphone's `dmic_vdd` are the same physical LDO1 node

(`imu_vdd: dmic_vdd: LDO1` in our devicetree). Driving the otherwise-

floating `PDM_CLK`/`PDM_DIN` pins to a defined low level was tested twice

— once in isolation, once again in the diagnostic build behind our §8.1

trace — with **no change (253 µA) either time**. We have not re-tested a

third time; the result already stands and we don't believe it needs

revisiting.

**2. IMU pins (SDA/SCL/INT1) high-Z with `imu_vdd` off.** This was the

one part of your question we had not actually tested — every prior test

in our isolation matrix (§8) measured *current*, none had read the

*voltage/logic level* on these three pins with `imu_vdd` confirmed at

0 V. New test: `imu_vdd` held disabled from boot (confirmed via

`regulator_is_enabled()`), SDA (P0.08), SCL (P0.07), and INT1 (P0.06)

each configured as a plain floating input (no SoC-side pull), sampled

every 100 ms across three phases:

| Phase | `imu_vdd` state | INT1 | SCL | SDA |

|---|---|---|---|---|

SDA/SCL only rise once `imu_vdd` is enabled, and decay back to low within

~100 ms of it being disabled. Had an external pull-up on a rail other

than `imu_vdd` been biasing these pins, they would already have read high

in the first phase, before `imu_vdd` was ever touched — none did. This

rules out our working hypothesis (leakage into the unpowered IMU through

its own ESD/protection diodes from a pull-up on a still-powered rail):

the SDA/SCL pull-up is on `imu_vdd` itself, and INT1 shows no pull in any

phase. We're confident this is not a contributor to the §8 anomaly.

**3. IMU initial low-power state.** The LSM6DS3TR-C's `CTRL1_XL` and

`CTRL2_G` registers (accelerometer/gyroscope output-data-rate control)

have a documented reset value of `0x00` (power-down, ODR = 0000) for

both. We confirmed this empirically rather than by datasheet citation

alone: read via direct I2C immediately after a fresh

`regulator_enable()` on `imu_vdd` — at 5 ms (matching our production

soft-start wait) and again at 15/25/35/45 ms, before any configuration

write reaches the chip. Result: `CTRL1_XL = 0x00`, `CTRL2_G = 0x00` on

5/5 reads at every delay tested. The chip is already at its lowest-power

state the instant it receives power; there is no firmware action

available to improve on this.

**Where this leaves us.** With pin configuration and initial chip state

both verified correct — and the microphone-rail hypothesis independently

ruled out twice — the `LOADSW1`/`LDO1` steady-state current of

~250–275 µA with zero load and zero I2C traffic (§8) remains unexplained

on our side. We'd still welcome any guidance on a known internal

quiescent/ground current for this block in LDO mode that isn't captured

in the datasheet's electrical-specification tables — this is now the only

open item standing between our current ~20–22 µA and the 5–6 µA target.

Happy to share the diagnostic firmware, the raw memory-trace dumps, or a

fresh PPK2 capture if any of that would help narrow it down further.

## 9. Secondary observation (not yet confirmed as a recurring cost)

The build links in the full NCS security stack — `mbedtls`, PSA Crypto,

and the CRACEN hardware crypto accelerator/KMU (`CONFIG_NRF_SECURITY=y`,

`CONFIG_PSA_CRYPTO_DRIVER_CRACEN=y`, `CONFIG_CRACEN_IKG_SEED_LOAD=y`, etc.)

— for a BLE **broadcaster-only** application with no pairing, no

connections, and no application-level cryptography. This appears to be

pulled in transitively through the Bluetooth host/controller's own

randomness requirements on this SoC family, not something our application

code requests. Because `bt_enable()` is now called only once (at true cold

boot, not every cycle), any associated CRACEN/KMU provisioning cost would

be a one-time boot cost rather than a recurring one — it does not appear in

our 10 s steady-state measurements, and we have **not** identified evidence

of it holding any power domain active in the background afterward. Flagged

here for completeness in case Nordic support recognizes a known interaction

between this and the idle current figures above.

---

## 10. Key source files (current, significant configuration only)

### 10.1 `boards/xiao_nrf54lm20a_nrf54lm20a_cpuapp.overlay`

```dts

&power_en {

/delete-property/ regulator-boot-on;

};

#include <zephyr/dt-bindings/regulator/npm13xx.h>

&pmic {

regulators {

imu_vdd: LDO1 {

regulator-min-microvolt = <3300000>;

regulator-max-microvolt = <3300000>;

};

/* Deferred-init: SYS_INIT would otherwise run before main() powers imu_vdd. */

&lsm6ds3tr_c {

zephyr,deferred-init;

};

/* Deferred-init: charger init() writes ~12-15 I2C transactions at every

* boot even without a battery read; only needed when a reading is due. */

&pmic_charger {

zephyr,deferred-init;

};

/ {

cpuapp_sram@2007ec00 {

compatible = "zephyr,memory-region", "mmio-sram";

reg = <0x2007ec00 DT_SIZE_K(4)>;

zephyr,memory-region = "RetainedMem";

status = "okay";

retainedmem0: retainedmem {

compatible = "zephyr,retained-ram";

status = "okay";

};

aliases {

retainedmemdevice = &retainedmem0;

};

&cpuapp_sram {

reg = <0x20000000 DT_SIZE_K(507)>;

ranges = <0x0 0x20000000 0x7ec00>;

};

&pmic_leds {

status = "disabled";

};

&py25q64 {

status = "okay";

};

&usbhs {

status = "disabled";

};

&usbhs_wrapper {

status = "disabled";

};

```

### 10.2 `prj.conf`

```ini

CONFIG_SERIAL=n

CONFIG_CONSOLE=n

CONFIG_UART_CONSOLE=n

CONFIG_PRINTK=n

CONFIG_BOOT_BANNER=n

CONFIG_NCS_BOOT_BANNER=n

CONFIG_GPIO=y

CONFIG_SPI=y

CONFIG_FLASH=y

CONFIG_SPI_NOR=y

# Tickless idle -- required for k_sleep() to be a real WFI sleep between

# ~1 s poll cycles, not a busy/software wait.

CONFIG_PM=y

CONFIG_PM_DEVICE=y

CONFIG_PM_DEVICE_RUNTIME=y

CONFIG_HWINFO=y

# Official NCS library, explicitly supported for CONFIG_SOC_NRF54LM20A_CPUAPP

# (nrf/lib/ram_pwrdn) -- powers down RAM sections beyond the linked image

# end (~23.5 KB used out of 507 KB retained by the overlay).

CONFIG_RAM_POWER_DOWN_LIBRARY=y

CONFIG_BT=y

CONFIG_BT_BROADCASTER=y

CONFIG_BT_DEVICE_NAME="XIAO-DOOR"

CONFIG_RETAINED_MEM=y

CONFIG_CRC=y

CONFIG_SENSOR=y

CONFIG_NPM13XX_CHARGER=y

CONFIG_MFD=y

CONFIG_REGULATOR=y

CONFIG_MAIN_STACK_SIZE=4096

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

CONFIG_REBOOT=y

```

### 10.3 `src/main.c` — structure

- `sample_motion()` — enables `imu_vdd`, re-asserts `CTRL3_C`/`CTRL6_C` by

direct I2C write every cycle (see §4.3), sets ODR (208 Hz), reads

X/Y/Z in one burst I2C transaction, disables `imu_vdd`.

- `main()` — one-time init (LED GPIOs released, external-flash pins forced

to a defined low-leakage state, fixed BLE identity, `bt_enable()`,

`power_down_unused_ram()`), then an infinite loop:

`sample_motion()` → send BTHome health frame if due (15 min cadence) →

`k_sleep(K_MSEC(1000))`.

- No `sys_poweroff()` / `z_nrf_grtc_wakeup_prepare()` anywhere — the SoC is

never rebooted during normal operation.

Full source available on request; this report includes only the

sections materially relevant to the power-consumption question in §8.

---

## 11. Summary for Nordic

| | |

|---|---|

| Current measured (steady state, no motion) | ~20–22 µA |

| Target | 5–6 µA |

| Sibling reference (nRF52840, same function) | ~10 µA |

| Dominant remaining cost | `imu_vdd`/LDO1 rail: ~250–300 µA whenever enabled, cause not yet identified (§8) |

| Everything else checked against the datasheet | Already at documented/optimal defaults (§7.1) |

We would welcome any guidance on the `LOADSW1`/`LDO1` idle-current question

in §8 — it is, by a wide margin, the single highest-leverage item standing

between the current measured result and the project's target.

Thanks again for your help,

Best regards

Thiery

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Simonr — Mon, 31 Aug 2026 13:37:17 GMT

Hi Thiery

Thank you for the input Thiery. It's a bit hard to determine where the current is going without knowing exactly how the IMU and microphone is operating.

Can you confirm whether the nRF54LM20A pins that goes to the IMU or microphone are configured correctly? Are all IMU pins set to high-z (these have external pull resistors), and do you drive the microphone clock and data low?

Please also confirm that the IMU is in an initial low power state.

Best regards,

Simon

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Thiery — Fri, 28 Aug 2026 14:12:09 GMT

Hi,

Thank you for pointing us to the Rev2 errata index — we've reviewed [38], [40], and [41] in full there.

Workaround status:

[38] ("trigger any TWI command after enabling the LDO"): already applied on our side via the Zephyr NCS regulator driver (regulator_npm13xx_enable(), PR #83790) — it performs a 2 ms delay followed by an LDSWSTATUS read automatically after enable. We also tested extending this to 20 reads over 100 ms in case a single read wasn't enough: no change in the elevated current.
[40] and [41]: don't apply to our setup — we power LOADSW1/LDO1 directly from VSYS (no BUCK in forced PFM feeding it), only ever start one LDO at a time (never two within 200 µs of each other), and our battery has stayed at a healthy ~4.2 V throughout testing (well clear of any VSYSPOF margin issue) — we've never observed a reset.

Current trace, with and without LDO1 enabled: Single continuous PPK2 capture (60 s), unit under test powered from BAT+/BAT− only (USB disconnected), dedicated diagnostic firmware that calls regulator_enable() on LOADSW1/LDO1 once and leaves it on indefinitely — no I2C traffic to any device on the rail, no sensor reads, isolating the regulator itself.

Segment	Duration	Average current
Baseline, LDO1 disabled	0–13.86 s	3.90 µA
Enable transition	~0.4 s	brief burst up to ~32 mA
LDO1 enabled, steady state	remainder of capture	~254 µA (stable)

The steady-state figure reproduces an earlier isolation test on the same unit (different firmware build, same methodology): 253 µA — independent reproduction, same result. CSV export of the full capture and PPK2 screenshots attached.

Given this jump (3.9 µA → 254 µA) happens with zero load and zero I2C traffic on the rail, and the datasheet's LOADSW/LDO electrical specification tables (Table 23/24) don't list a quiescent current figure for either mode — is there a known ground/quiescent current for this block that simply isn't captured in those tables?

Best regards Thiery

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Simonr — Fri, 28 Aug 2026 13:15:05 GMT

There are a few errata around the LDO on the nPM1300 listed here: https://docs.nordicsemi.com/r/bundle/errata_npm1300_rev2/page/err/npm1300/rev2/latest/err_300_new.html

Please make sure the proper workarounds for those are in place on your end. I have not found any mention of an internal LDO leakage on our end. Do you have a trace of the current consumption on your end so we can take a look at how it looks like, both with and without LDO enabled on nPM1300 should be helpful.

Best regards,

Simon

RE: nPM1300 LOADSW1/LDO1 quiescent current issue — XIAO nRF54LM20A Sense

Thiery — Fri, 28 Aug 2026 11:56:55 GMT

Latest tests:

XIAO nRF54LM20A Ultra-Low-Power BLE/IMU Sensor — Current State Report

**Prepared for:** Nordic Semiconductor support / DevZone

**Project:** Battery-powered BLE door/motion sensor (BTHome v2 over Home Assistant)

**Date:** 2026-08-28

**Board:** Seeed Studio XIAO nRF54LM20A Sense (nRF54LM20A SoC + nPM1300 PMIC + LSM6DS3TR-C IMU)

**SDK:** nRF Connect SDK v3.4.0 (Zephyr base), GNU ARM toolchain (NCS toolchain manager, bundle `dcbdc366a1`)

**Reference design:** sibling project on nRF52840 (Seeed XIAO nRF52840 Sense) achieves ~10 µA with equivalent BLE + motion-detection functionality — used throughout as the practical target.

---

## 1. Executive summary

We are porting a battery-powered BLE motion/door sensor from an nRF52840-based

design to the XIAO nRF54LM20A Sense. The application: periodic accelerometer

polling (~1 s reactivity), BTHome v2 health telemetry over BLE advertising

every 15 minutes, all running from a single-cell LiPo through the on-board

nPM1300 PMIC.

An initial architecture (System OFF + full SoC reboot on every ~1 s poll

cycle) plateaued at **70–144 µA** average current — well above target and

found to be structurally limited by fixed re-initialization costs paid on

every reboot. Pivoting to a **System ON IDLE** architecture (no reboot; the

SoC sleeps via `CONFIG_PM` tickless idle and wakes on a GRTC-backed

`k_sleep()`) removed that structural floor. A sequence of single-variable

tests — architecture pivot, driver-delay tuning against documented specs,

Nordic's official RAM power-down library, and IMU output-data-rate tuning —

has brought measured current down to **~20–22 µA**, a 3.4–7× reduction from

the legacy architecture.

**One unresolved item is now the main blocker to reaching the 5–6 µA target**

and is the subject of the support request in §8: the nPM1300 `LOADSW1/LDO1`

rail (used to power the IMU) draws **~250–300 µA** whenever enabled, with **no

load and no I2C traffic**, independent of LDO vs. Load Switch mode and

independent of firmware — this figure represents ~70–80% of the current

per-cycle cost and has resisted 13+ independent isolation tests.

---

## 2. Hardware configuration

| Item | Detail |

|---|---|

| Board | Seeed Studio XIAO nRF54LM20A Sense |

| SoC | nRF54LM20A (Cortex-M33, nRF54L series peripheral set) |

| PMIC | nPM1300 (I2C-controlled, battery charger + 2× LDO/LOADSW + bucks) |

| IMU | ST LSM6DS3TR-C (accelerometer + gyroscope, I2C, on `imu_vdd`/LDO1 rail — shared with the on-board PDM microphone) |

| External flash | PY25Q64 (SPI NOR, kept in deep power-down / deterministic pin state) |

| Power source | Single-cell LiPo via nPM1300, no USB connected during measurement |

| Debug/flash interface | On-board SAMD11 USB↔SWD bridge (CMSIS-DAP), OpenOCD |

| Current measurement | Nordic PPK2, Ampere-meter mode, external supply on BAT+/BAT−, USB-C **always disconnected** during measurement (verified protocol, no simultaneous USB+PPK2 connection at any point) |

---

## 3. Software / toolchain

- **nRF Connect SDK:** v3.4.0, workspace at a local mirror (`C:\ncs\v3.4.0`)

- **Board target:** `xiao_nrf54lm20a/nrf54lm20a/cpuapp`

- **Board support package:** community Seeed Studio module (`platform-seeedboards`), used via `BOARD_ROOT`

- **Toolchain:** NCS toolchain manager bundle, GNU ARM Embedded compiler, `west` 1.5.0

- **Build command:**

```bash

west build -b xiao_nrf54lm20a/nrf54lm20a/cpuapp -d build --pristine \

-- -DBOARD_ROOT="<path>/platform-seeedboards/zephyr"

```

- **Flash/verify:** OpenOCD + CMSIS-DAP over the on-board SAMD11 bridge; every

flash is verified byte-for-byte with `verify_image` against the `.hex`

(never `dump_image`+`cmp`, which produces false positives on RRAM padding

that was written by a previous, different binary).

---

## 4. Firmware architecture

### 4.1 Legacy architecture (abandoned)

`System OFF` + full SoC reboot on every ~1 s poll cycle

(`z_nrf_grtc_wakeup_prepare()` + `sys_poweroff()`), matching the classic

nRF52-era ultra-low-power pattern. On this SoC this plateaued at

**70–144 µA**: every reboot re-initializes the MFD/regulator driver, the BLE

controller/host, and (until deferred-init was applied) the nPM1300 charger —

fixed per-boot costs that dominate at a 1 Hz duty cycle. Root-caused via the

Nordic datasheet's own power-consumption table (System ON IDLE + GRTC + full

RAM retained = 4.3 µA documented floor, vs. 0.7–1.0 µA for System OFF) — the

gap was never the power *mode* itself, but the fact that a reboot re-runs

driver `POST_KERNEL` init on every cycle, none of which is retained.

### 4.2 Current architecture (System ON IDLE)

- `main()` is a single infinite loop; the SoC is **never rebooted** during

normal operation. `CONFIG_PM=y` enables Zephyr's tickless idle so

`k_sleep()` between cycles is a genuine WFI-based CPU sleep, not a

busy/software wait.

- Bluetooth (`bt_enable()`) is initialized **once**, at true cold boot —

removing a per-cycle BLE-stack-init cost that had been the single largest

contributor under the reboot architecture.

- The accelerometer (`imu_vdd`/LDO1 + LSM6DS3TR-C) is still power-cycled

every ~1 s (regulator enable → sample → regulator disable) — this remains

necessary because the rail itself draws ~250–300 µA whenever active (see

§8); duty-cycling it is the only way found so far to keep the average

current down while still meeting the ~1 s motion-detection reactivity

requirement.

- BTHome "health" frames (battery %, voltage) are advertised only when due

(every 15 minutes), gated **before** any BLE call so the BLE stack is

touched only for the ~700 ms burst that's actually needed.

- RAM sections unused by the linked image (~94% of the SoC's 512 KB) are

powered down via Nordic's official `RAM_POWER_DOWN_LIBRARY`

(`nrf/lib/ram_pwrdn`), called once after boot.

### 4.3 Correctness detail specific to the pivot

Because the SoC no longer reboots, `device_init()` on the LSM6DSL driver

only runs its low-level chip-init routine (`lsm6dsl_init_chip()`) **once**

(Zephyr's `device_init()` returns `-EALREADY` without re-invoking the

driver's `init` callback once `dev->state->initialized` is set — see

`zephyr/kernel/device.c`). Since `imu_vdd` is still power-cycled every

sample, the physical IMU register state resets every cycle even though the

Zephyr-side "initialized" flag does not. `CTRL3_C` (BDU + address

auto-increment) and `CTRL6_C` (low-power mode) are therefore now

re-asserted explicitly by direct I2C write on every sample, independent of

the Zephyr sensor API's init state — without this, X/Y/Z readings would

silently become inconsistent from the second sample onward.

---

## 5. What currently works (functionally verified)

- BLE advertising: fixed static random identity (from `hwinfo` device ID),

non-connectable, BTHome v2 service-data payload.

- BTHome "health" frame (battery %, battery voltage, packet ID, low-battery

flag) sent on a 15-minute cadence, correct values confirmed via battery

reading (`"battery=100% (4228 mV)"` etc., verified with a temporary

console before switching to the silent measurement build).

- Accelerometer polling every ~1 s: plausible, stable X/Y/Z readings

verified via temporary UART console across many consecutive cycles after

every firmware change with functional risk (e.g. after enabling

`RAM_POWER_DOWN_LIBRARY`, after the ODR change) — no crash, no bus fault,

no reset loop observed in any test.

- Retained-RAM state (packet ID, next health-frame deadline) survives an

unexpected reset via a CRC-validated struct in a `zephyr,retained-ram`

region — no longer required for the normal operating cycle (the SoC does

not reboot), kept only as a safety net.

**Console/serial is hard-disabled (`CONFIG_SERIAL=n`) for every measurement

build.** A separate, temporary console-enabled build is used for functional

verification, then reverted before any PPK2 measurement.

---

## 6. Test & measurement methodology

1. State the objective, the exact parameter(s) changed and in which file,

and the expected result **before** building — single-variable changes

only, one at a time between two measurements.

2. Build, flash, and verify byte-for-byte (`verify_image`) — re-flash and

re-verify if it fails.

3. If the change carries any functional-correctness risk (e.g. touches

sensor register state or RAM layout), do a temporary console-enabled

functional check (several polling cycles observed over UART) **before**

switching to the silent measurement build.

4. Confirm `CONFIG_SERIAL=n` / `CONFIG_CONSOLE=n` / `CONFIG_UART_CONSOLE=n`

/ `CONFIG_PRINTK=n` are in effect for the measurement build (a UARTE

driver PM-runtime reference leak was found early on that silently keeps

the console active in System OFF once any other peripheral is also

active — console is now always hard-disabled, never runtime-suspended).

5. PPK2 measurement protocol (strict, never varied):

1. Disconnect the board from USB-C.

2. Wait 20 s.

3. Connect the board to the PPK2 (BAT+/BAT− only).

4. Power the board from the PPK2.

5. Wait 10 s.

6. Start the measurement, capture screenshots at multiple zoom levels

(whole-window average, single-cycle burst, idle-floor zoom).

7. Stop the PPK2 power output.

8. Disconnect the board from the PPK2.

9. Reconnect the board to USB-C.

PPK2 and USB-C are **never** connected to the board simultaneously at

any point in this protocol.

6. Record measured µA (whole-window average) and µC (charge — used to

compare cycles independent of small interval-count variance across

measurement windows).

---

## 7. Measured results

All measurements: unit "#01", board at rest, no motion, single-cell LiPo via

nPM1300, PPK2 Ampere-meter mode.

| Stage | Change | Avg. current (10 s window) |

|---|---|---|

| Legacy architecture | System OFF + full reboot every ~1 s cycle | 70–144 µA |

| Architecture pivot | System ON IDLE, no reboot, `CONFIG_PM=y` | 30.85 µA |

| Test #32 | `imu_vdd`/LDO1 stabilization delay 20→5 ms (nPM1300 datasheet soft-start spec: 1.8 ms typ.) | 27.07 µA |

| Test #33 | IMU ODR-settle delay 15→10 ms (104 Hz period ≈ 9.6 ms) | 25.21 µA |

| Test #35 | Nordic `RAM_POWER_DOWN_LIBRARY` — unused RAM sections powered off | 20.63 µA |

| Test #36 | IMU ODR 104→208 Hz, settle delay 10→6 ms | ~20–22 µA¹ |

¹ Raw 10 s window for test #36 read 21.54 µA, but that capture happened to

include one BLE health-frame burst (triggered once per boot by the retained

"next health deadline" resetting on a fresh flash) — not directly

comparable to the other rows, which did not contain that event. The

per-cycle burst charge (18.40 µC, down from 17.45–20.11 µC) and the

idle-floor reading (4.26 µA, essentially at the datasheet's documented

System ON IDLE floor of 4.3 µA) both confirm a real, if modest, further

improvement; a clean re-measurement is pending.

**Remaining gap to target:** 5–6 µA final objective, ~10 µA sibling

nRF52840 reference (with equivalent motion-detection functionality). The

per-cycle accelerometer sampling burst (currently ≈18 µC / ~15–19 ms) now

accounts for roughly 70–80% of total cycle cost and is dominated almost

entirely by the fixed ~250–300 µA `imu_vdd`/LDO1 rail current for as long as

it stays enabled — see §8.

### 7.1 Items checked against the datasheet and confirmed already optimal

No firmware change was needed for the following — each was verified in the

datasheet and/or the board's devicetree/Kconfig, not assumed:

- **System ON sub-power mode** defaults to `Low-power` (not `Constant

Latency`) on entry to System ON — the most power-efficient option,

requires no software action (§5.1.1 of the datasheet).

- **RRAM (program memory) low-power mode** (`RRAMC.POWER.LOWPOWERCONFIG`)

resets to `PowerOff` — RRAM is already fully powered off automatically

during System ON IDLE.

- **Main SoC regulator (VREGMAIN) DC/DC mode** is already enabled by the

board's devicetree (`regulator-initial-mode = <NRF5X_REG_MODE_DCDC>`),

not left in the less-efficient LDO fallback mode.

- **HFXO vs. HFINT for I2C (TWIM):** the Zephyr TWIM driver never requests

HFXO explicitly, and MPSL only requests HFXO on-demand around actual

radio events (`CONFIG_MPSL_HFCLK_LATENCY`), not continuously or per I2C

transaction — our I2C traffic to the IMU already runs on the always-on

HFINT source with no crystal-startup cost paid per sampling cycle.

Measured burst durations match our own explicit `k_msleep()` budget with

no unexplained residual latency, confirming this by measurement as well

as by code inspection.

---

## 8. Request for support: `imu_vdd`/`LOADSW1`/`LDO1` idle current

This is the primary open question and the main blocker to reaching the

final target.

**Observation:** enabling the nPM1300's `LOADSW1`/`LDO1` output alone — no

I2C traffic to any device on the rail, no sensor reads, nothing else

changed — increases current from a 3.3 µA baseline (SoC in System ON IDLE,

GRTC + BLE only, this rail disabled) to **~250–275 µA**, and this figure is

**stable over multi-minute windows** (not a decaying transient).

**Isolation performed (9 independent single-variable tests, all confirm the

same ~250–275 µA):**

| # | Variable tested | Result |

|---|---|---|

| 1 | Wait up to 5 s for INT1 to settle before power-down | No effect |

| 2 | `WAKE_UP_DUR` debounce register (separate from the 31 mg threshold, which is never modified) | No effect |

| 3 | 200 ms stabilization delay before arming any interrupt | No effect |

| 4 | UARTE console PM-runtime-suspend bug fixed (console hard-disabled) | No effect |

| 5 | I2C bus explicitly suspended (`PM_DEVICE_ACTION_SUSPEND`) | No effect |

| 6 | Accelerometer low-power mode (`XL_HM_MODE`) — verified set via direct register read-back | Confirmed correct, not the cause |

| 7 | **No wake source armed at all** — IMU powered/initialized only | Still ~260 µA — rules out any wake mechanism |

| 8 | `power_en` regulator disabled (only `imu_vdd`/LDO1 active) | Still ~260 µA |

| 9 | **`imu_vdd`/LDO1 alone** — a single `regulator_enable()` call, no I2C to the IMU at all, base = GRTC+RAM+BLE (3.3 µA) | **~253 µA — cause isolated to `regulator_enable()` on this rail itself, reproducible, fully reversible** |

| 10 | Load Switch mode forced instead of LDO (register-verified `LDSWSEL=0x00`) | **275.67 µA — worse than LDO, and outside the LDO's rated voltage safety margin for the IMU** |

**Further checks performed, all negative:**

- **nPM1300 errata [38]** (LOADSW/LDO startup-time-exceeds-spec, applicable

condition: BUCKs unloaded + no TWI traffic after enable) — the Zephyr

driver (`regulator_npm13xx_enable()`) already applies Nordic's documented

workaround (a 2 ms delay + one `LDSWSTATUS` read). We extended this to 20

reads over 100 ms: **no change (253 µA)** — errata [38] ruled out.

- **Shared microphone rail:** `imu_vdd` and the on-board PDM microphone's

`dmic_vdd` are the same physical LDO1 node (Seeed's own devicetree labels

it `imu_vdd: dmic_vdd: LDO1`). Driving the floating `PDM_CLK` pin to a

defined low level: **no change (253 µA)** — ruled out.

- **`LDSWCONFIG`** (soft-start / active-discharge register): read back at

its reset value (`0x00`) on the build where `regulator_enable()` is never

called — nothing in our code writes it.

- **nPM1300 Product Specification, Table 23/24 (LOADSW/LDO electrical

spec):** no quiescent/ground current figure is documented for this block

in either mode.

- **Reproduced against the vendor reference example** (Seeed's own

`imu_click` sample, run unmodified): **same order of magnitude

(320–350 µA)** — this is not specific to our firmware.

**Question for Nordic:** is there a known quiescent/ground current for the

`LOADSW1`/`LDO1` block on the nPM1300 that is not captured in the

datasheet's electrical-specification tables, or a configuration step

(beyond mode, voltage, soft-start, and active-discharge, all already

checked) required to reach a low idle current in LDO mode with no load?

Given this rail's current dominates ~70–80% of our per-cycle cost, resolving

it is the single highest-value remaining step toward the 5–6 µA target.