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?