nPM2100 VBAT reads NACK while nRF7002 WiFi is active

[kile.gc]

System Context

• Host MCU: nRF54H20 (Custom Board)

• PMIC: nPM2100 (Connected via TWI/I2C)

• RF Co-processor: nRF7002 Wi-Fi (Powered by nPM2100 VOUT)

• Software Environment: nRF Connect SDK (NCS) v3.3.0

• Power Source: Bench PSU on VBAT (Rules out cell-side brown-out)

The Problem: Wi-Fi Induced PMIC ADC NACKs

We are hitting an issue where sensor_sample_fetch(npm2100_vbat) returns -EIO the moment the nRF7002 Wi-Fi interface comes up. The sensor recovers immediately when Wi-Fi is powered down.

Crucial Detail: Other I2C devices on the same bus (humidity, pressure, IMU) continue to communicate flawlessly during Wi-Fi activity. Only the PMIC misbehaves, isolating the issue from a general TWI bus collapse.

Diagnostic Findings & Instrumentation

We instrumented npm2100_vbat_sample_fetch() to log exactly which I2C operations fail. The NACKs are localized specifically to the ADC register block:

• Failing Registers: Scattered across ADC.TASKS_ADC write (0x90), ADC.AVERAGE read (0x9B), and ADC.READTEMP (0x97).

• Passing Registers: We never see a NACK on any BOOST_* registers (0x20–0x33) during the same window. The issue is strictly scoped to the ADC subsystem.

Attempted Fixes:

1. Delayed Mode: Switched VBAT to Delayed mode (20 ms delay, 4× oversampling) $\rightarrow$ No change, same NACK pattern.

2. Driver Patch (Status Polling): The upstream driver uses an open-loop sleep (100 µs × oversampling + delay). We patched it to actively poll ADC.STATUS (0x9D) for a Ready state before triggering and reading, adhering to §7.1 of the datasheet ("new conversion can only be started once status indicates that ADC is ready").

   • Result: This significantly improved shell-triggered reads. However, periodic background reads still NACK intermittently during heavy RF activity (e.g., MQTT reconnect loops).

   • The Catch: When it fails now, the ADC.STATUS read itself NACKs. The chip is refusing to even report its readiness.

Questions for the Engineering Team

1. Is this a known erratum/behavior?

   Can the ADC-block registers (and ADC.STATUS) NACK if the boost regulator is supplying heavy transient currents to a load like the nRF7002? We found no mention of this in the v1.0 datasheet or official FAQ blogs.

2. What is the recommended software workaround under heavy load?

   Would leveraging the hardware interrupt via EVENTS_ADC_SET.VBATRDY be more robust than polling STATUS, considering the STATUS register itself gets NACK'd?

3. What hardware modifications do you recommend to stiffen VOUT?

   To mitigate nRF7002 TX bursts, should we look at increasing the VOUT capacitance, changing the boost operating mode, or other layout/decoupling adjustments?

4. Will Nordic upstream a STATUS-aware driver fix?

   The current open-loop sleep implementation appears to violate the datasheet contract in §7.1. Anyone pairing the nPM2100 with a Wi-Fi co-processor is highly likely to encounter this race condition or subsystem lockout.

Best regards,

Kittitouch Lelapiyamit