nRF7002 (NCS v3.0.2, legacy PS): periodic ~66 Hz internal pad activity during RPU sleep costs ~300 µA on host/IOVDD rail — mechanism and host-side control?

[Sherwood]

  Environment

  - Module: Minew MS12SF1 (nRF5340 + nRF7002, QSPI host interface: IO0-3 = P0.13-16, SCK = P0.17, CSN = P0.18, HOST_IRQ = P1.05)

  - Rails: VDD(nRF5340) = VDDH = VBAT70 = 3.3 V; IOVDD(nRF7002) = 3.3 V via a load switch fed from the same 3.3 V net

  - NCS v3.0.2 (sdk-zephyr f791c49f492), sysbuild, board nrf7002dk/nrf5340/cpuapp, nRF70 firmware patches as shipped with NCS v3.0.2

  - STA mode, WPA2-PSK, 802.11ax AP; legacy power save with WIFI_PS_WAKEUP_MODE_LISTEN_INTERVAL, listen interval 20 (2.048 s wakes), WIFI_PS_PARAM_TIMEOUT = 20 ms, CONFIG_NRF_WIFI_LOW_POWER=y, CONFIG_NRF70_QSPI_LOW_POWER=y, sleep type HW_SLEEP_ENABLE (driver default), CONFIG_NRF_WIFI_FEAT_KEEPALIVE=y (60 s)

  - Measurement: Nordic PPK2, 100 kSa/s. The module is powered directly by the PPK2 in source-meter mode at 3.30 V (no other supply in the loop), so the measurement covers nRF5340 VDD + nRF7002 IOVDD + VBAT70.

  Observation

  While the RPU is asleep between listen-interval wakes, we observe a strictly periodic ~65.9 Hz (≈32.768 kHz / 497) mechanism on the QSPI pads, visible in the supply current:

  - With host-side pulls (~13 kΩ) applied to the QSPI lines between transactions (pinctrl sleep state; NRF70_QSPI_LOW_POWER=y, so nrfx QSPI is uninitialized between transactions): quiet-state module current is 405 µA. Every 15.17 ms there is a brief (~3.6 mA, tens of µs) event followed by a 0.54 ms window in which the current drops to a stable ~103 µA floor,

  then returns to ~405 µA. Interpretation: an internal pad circuit periodically refreshes; between refreshes it continuously sources/sinks ~300 µA against the host pulls.

  - With the host pins floating and their input buffers disconnected: quiet current rises to ~695 µA (we believe the nRF7002-side input buffers burn as the pads drift to mid-level between refreshes).

  - With the host actively driving the lines at their observed idle levels (IO0-3 high, SCK low, CSN high): quiet current 440 µA, and the 65.9 Hz refresh events become substantially larger (mA-scale, ~ms), i.e. the internal mechanism actively exercises/drives the lines at each refresh rather than passively holding them.

  - The isolated VBAT70 branch alone measures 11–15 µA in the same sleep state — consistent with the 15 µA I_SLEEP figure in the nRF7002 PS v1.2, so the excess is on the IOVDD/host-interface side, not VBAT.

  - Supporting data point: on an nRF7002-DK (IOVDD = 1.8 V) we previously observed an analogous periodic notch mechanism at ~190 Hz, suggesting the refresh rate is internal and supply/temperature dependent.

  - Functionality is unaffected in all configurations (association, li=20 PS, RX delivery via HOST_IRQ, MQTT traffic all normal). This is purely a sleep-current issue: ~300 µA ≈ 20× the documented nRF7002 sleep current, and it dominates our battery budget.

  What we have checked in the NCS v3.0.2 host stack

  - Host sleep control is the binary WAKEUP_NOW bit (QSPI opcode 0x3F / WRSR2), with re-sleep on NRF70_RPU_PS_IDLE_TIMEOUT_MS; no runtime sleep-depth control.

  - Sleep parameters are fixed at UMAC CMD_INIT: sys_params.sleep_enable = HW_SLEEP_ENABLE, calib_sleep_clk = CALIB_SLEEP_CLOCK_ENABLE (1) (lmac_if_common.h), hw_bringup_time/sw_bringup_time defaults.

  - The only sleep-controller register the driver ever writes is SYS_SLEEP_CTRL_GPIO_CTRL (0xA4002DC8), and only the SR-coex bits 6/9 (NRF70_SR_COEX_SLEEP_CTRL_GPIO_CTRL, which is default y even without coex hardware).

  - No register definition for pad keeper/retention/IO-state-in-sleep exists in the shipped headers (the driver comments reference uccp530_77_registers.h, which is not shipped).

  Questions

  1. What is this ~66 Hz sleep-state pad mechanism (sleep-clock calibration? pad keeper refresh? something else in the LMAC ROM)?

  2. Is there a supported way — CMD_INIT parameter, register write (e.g. in the UCC sleep-controller block 0xA4002C00–0xA4002DFF, or the PMB region ~0xA5009xxx), or firmware-patch option — to disable, slow down, or otherwise cheapen it?

  3. What is Nordic's recommended host-side pad configuration (pull / float+disconnect / drive, per line) for the QSPI interface while the nRF7002 sleeps in legacy PS, to meet the datasheet sleep current at IOVDD?

  4. What are the semantics and supported values of sys_params.calib_sleep_clk, and is disabling it safe in HW_SLEEP_ENABLE mode with listen-interval power save (impact on beacon-wake timing accuracy)?

  5. If the mechanism is ROM-resident: can it be addressed via the downloadable nRF70 firmware patch, and is there a bit map available for SYS_SLEEP_CTRL_GPIO_CTRL and its neighboring registers?

[Simonr]

Hi

1. Do you have a current consumption plot so we can see how this looks exactly. Nothing at ~66Hz comes to mind initially.

I think the first step here would be to find out what is causing the excess current consumption before diving into possible mitigations. It should definitely be possible to lower the current consumption lower than 400µA in a sleep mode.

Best regards,

Simon

[Sherwood]

Thank you for looking at this. Plots attached, plus a register dump of the sleep-controller block.

  What the plots show (fig 1): with the RPU in legacy power-save sleep between li=20 listen-interval wakes, the module's 3.3 V rail (PPK2 source-meter, 100 kSa/s) sits at a held level of ~405 µA. Every 15.17 ms (65.9 Hz ≈ 32.768 kHz ÷ 497) there is a ~3.6 mA spike of tens of µs, immediately followed by a 0.53 ms release down to a stable ~103 µA floor, after

  which the current re-engages at ~405 µA. So ~300 µA of continuous sleep-state current is held by whatever this periodic mechanism maintains, and the chip demonstrates its own ~103 µA capability 66 times per second. The exact interval and amplitude are stable over hours.

  Why we believe it is internal to the nRF7002 (fig 2): the mechanism is unchanged under three mutually exclusive host-side QSPI pad configurations — (a) host pulls per the erratum-9 workaround (405 µA), (b) host actively driving the pins at their idle levels through ~50 Ω outputs (440 µA, and the refresh events become larger, i.e. something inside the chip

  drives the lines against our rails at each refresh), (c) pins floating with host input buffers disconnected (695 µA). A voltage-independent internal load re-engaged at ~66 Hz is the only model consistent with all three.

  Also eliminated by experiment: sys_params.calib_sleep_clk = 0 at CMD_INIT — no change whatsoever; sleep_type = SW_SLEEP_ENABLE — mechanism identical, plus additional periodic mA-scale events; erratum-9 pin terminations — applied throughout. Environment: NCS v3.0.2, FW patch 1.2.14.1 (we checked changelogs through 1.2.14.9 — no sleep-current-related entries),

  MS12SF1 module (nRF5340 host, QSPI, IOVDD = 3.3 V). A related observation: on an nRF7002-DK at IOVDD = 1.8 V we saw an analogous periodic release signature at ~190 Hz, so the rate appears supply/temperature-dependent.

  On "below 400 µA": to be precise about the budget — the total sleep-state current is 405 µA, of which ~300 µA is this mechanism (the ~103 µA floor during its own release windows is the level we are trying to make permanent; the datasheet I_SLEEP is 15 µA, and our isolated VBAT measurement does meet that — the excess is on the IOVDD/host-interface side).

  Attached register dump: the SYSBUS block 0xA4002C00–0xA4002DFF taken during sleep via the nrf70 debug shell (two passes; live counters marked). We note 0xA4002DC8 (the register the driver writes as the sleep-control GPIO register) reads exactly the driver's own value, and the block contains stable constants (0x387, 0x79, 0x2000) and repeated small-value tables

  (0x73–0x76) that look calibration-related. The driver sources reference uccp530_77_registers.h, which is not shipped, so we cannot decode further.

  Our specific questions:

  1. What is this ~66 Hz sleep-state mechanism — sleep-clock calibration, pad-keeper/retention refresh, or something else?

  2. Is there a host-writable register (in the 0xA4002C00–0x2DFF sleep-controller block or elsewhere) or CMD_INIT parameter to disable, slow, or reduce the current it holds between refreshes?

  3. Is nRF7002 retention refresh-based (which would make the periodic activity fundamental), and if the mechanism is ROM-resident, can it be addressed via the downloadable firmware patch?

  4. What is the recommended host-side QSPI pad handling during RPU sleep to reach the datasheet sleep budget at IOVDD = 3.3 V — and is the sleep current specified at all for IOVDD ≥ 3 V?

  We can supply raw PPK2 exports of any of these captures on request.

Fullscreen sleep_ctrl_register_dump.txt Download

nRF7002 sleep-controller block dump (SYSBUS 0xA4002C00-0xA4002DFF)
Taken via the nrf70 debug shell (read_reg) on NCS v3.0.2, FW 1.2.14.1,
MS12SF1 module, STA associated, legacy PS li=20, between listen-interval
wakes. Two passes ~1 min apart where noted (values that change marked *).

0xA4002C00: 0x00000000
0xA4002C04: 0x0000000A
0xA4002C08: 0x00000007
0xA4002C0C: 0x00000000
0xA4002C10: 0x00000000
0xA4002C14: 0x0000EE58 -> 0x0000EADE   *counter
0xA4002C18: 0x00000000
0xA4002C1C: 0x000036D7 -> 0x0000D312   *counter
0xA4002C20: 0x00000001
0xA4002C24: 0x000FCB24 -> 0x00083241   *counter
0xA4002C28: 0x00000000 -> 0x00000002   *
0xA4002C2C: 0x0000BC00   (RPU_REG_UCC_SLEEP_CTRL_DATA_0 - LMAC patch offset)
0xA4002C30: 0x00019680   (RPU_REG_UCC_SLEEP_CTRL_DATA_1 - UMAC patch offset)
0xA4002C34: 0x00000000
0xA4002C38: 0x00000001
0xA4002C3C: 0x00000000
0xA4002C40: 0x00000387
0xA4002C44: 0x00000000
0xA4002C48: 0x00000001
0xA4002C4C: 0x00000000
0xA4002C50: 0x00000387
0xA4002C54: 0x00000000
0xA4002C58: 0x00000079
0xA4002C5C-0xA4002C6C: 0x00000000
0xA4002C70: 0x000FD5FD
0xA4002C74: 0x0000000F
0xA4002C78-0xA4002C7C: 0x00000000
0xA4002C80: 0x00000073
0xA4002C84: 0x00000073
0xA4002C88: 0x00000073
0xA4002C8C: 0x00000074
0xA4002C90: 0x00000074
0xA4002C94: 0x00000076
0xA4002C98: 0x00000076
0xA4002C9C-0xA4002CFC: 0x00000000
0xA4002D00: 0x00000003
0xA4002D04: 0x00000003
0xA4002D08: 0x00000003
0xA4002D0C: 0x00000002
0xA4002D10: 0x00000002
0xA4002D14-0xA4002D7C: 0x00000000
0xA4002D80: 0x00000075
0xA4002D84: 0x00000075
0xA4002D88-0xA4002D9C: 0x00000000
0xA4002DA0: 0x00000001
0xA4002DA4: 0x00000001
0xA4002DA8-0xA4002DBC: 0x00000000
0xA4002DC0: 0x00000001
0xA4002DC4: 0x00000000
0xA4002DC8: 0x00000240   (driver-written coex bits 6+9; persists across sleep)
0xA4002DCC: 0x00000000
0xA4002DD0: 0x00000000
0xA4002DD4: 0x00002000
0xA4002DD8: 0x00000000
0xA4002DDC: 0x00002000
0xA4002DE0-0xA4002DFC: 0x00000000

[Elfving]

Hi, and sorry about the wait. I'll be taking over this case for a bit.

Odd current consumptions, as well as it bieng temprature dependant, immediately makes me think some pins are floating. But did you say that you've seen this on the DK as well? Or is this mainly on a custom board using the minew module? If you haven't been able to reproduce it on a DK, could you give that a go?

Have you had a HW review by us on this custom board before?

This is the fw you're trying, correct? If you are seeing it on a DK as well, I might be able to recreate what you are seeing here.

I am currently a bit confused as to what the core of the issue is, but what is for sure is that the default configuration from the SDK in combination with the DK should provide all the right configurations you are looking for. So making sure that the issue is not seen there is a good starting point.

Regards,

Elfving

[Sherwood]

Hi Elfving, thanks for picking this up.

  Q: DK or custom board? Both. The measurements in the attached plots are from the Minew MS12SF1 module (IOVDD = 3.3 V), where the periodic mechanism runs at ~65.9 Hz. But we first observed the analogous signature on a stock nRF7002-DK (IOVDD = 1.8 V): a periodic release/refresh pattern at ~190 Hz

  (~280 µs releases every ~5.25 ms), with the sleep-state host-rail current sitting at ~550–570 µA between releases instead of the datasheet's sleep budget. Same phenomenon, different rate — consistent with your temperature/voltage intuition, since the rate appears to scale with IOVDD and conditions.

  Q: floating pins? Ruled out experimentally, not just by inspection. Anomaly 9's terminations are applied, and we A/B'd three mutually exclusive host-side QSPI pad configurations on the same board, same firmware, same sleep state: (a) pulls per anomaly 9 → 405 µA sleep base, (b) host actively driving

  every pin to its idle level through ~50 Ω → 440 µA, (c) pins floating with host input buffers disconnected → 695 µA. The ~66 Hz mechanism is present and unchanged in all three (see fig 2, attached earlier). A floating-pin leak cannot survive configuration (b).

  Q: HW review? No Nordic review of the carrier — but the DK reproduction above removes the custom-hardware variable for triage purposes.

  Q: firmware? A custom application derived from the same stack as the sta sample, on NCS v3.0.2 (nRF70 FW patch 1.2.14.1). The mechanism is invariant across everything host-configurable we could find: sleep_type HW vs SW, calib_sleep_clk 0 vs 1, the SR-coex sleep-GPIO write present vs absent, and all

  pad configs above.

  Repro recipe for your bench (should work with the stock sta sample on a DK): STA associated to any AP, legacy power save (we use listen interval 20, but DTIM PS should show it too), no traffic; measure the nRF5340/host rail (the P22 path — note it includes the 7002's IOVDD branch on the DK) with a

  PPK2 at 100 kSa/s. In the quiet windows between listen-interval wakes, look for the periodic pattern: a brief internal event, then a ~0.3–0.5 ms drop to a much lower floor (~30–100 µA depending on board), then re-engagement at the several-hundred-µA held level. The chip demonstrates its own low

  floor at every release — the question is what holds the extra several hundred µA between them.

  The core issue in one sentence: during RPU sleep in power save, an internal ~66–190 Hz (board-dependent) periodic mechanism holds ~300–400 µA on the host/IOVDD side between its own release windows, ~20× the expected sleep budget, and no documented host configuration affects it — we'd like to know

  what it is (pad keeper refresh? retention? sleep-clock machinery?) and whether it can be disabled, slowed, or cheapened.

  We're happy to run the stock sta sample on our DK and share that exact capture if it helps line up with what you see on yours.