ESP32 node 35: brownout crash loop at phy_init (root cause of Wi-Fi drops / no auto-reconnect)

[AndrewDemsDS]

Symptom

The ESP32 node (esp-matter path) becomes unstable, drops its Wi-Fi association, and never rejoins on its own. It stays offline (Matter node unreachable, A/C uncontrollable) until the module is manually power-cycled.

Root cause: brownout crash loop at phy_init

Captured serial over a USB-TTL on UART0 (115200 8N1). The node is in a deterministic brownout crash loop: every boot resets ~33 ms after phy_init: phy_version ... prints, i.e. the instant the RF PHY powers on / calibrates, before Wi-Fi ever scans or associates:

I (1000) wifi_init: WiFi RX IRAM OP enabled
I (1033) phy_init: phy_version 4863,...
E BOD: Brownout detector was triggered
rst:0x3 (SW_RESET)
W hisense_ac: boot reason: BROWNOUT (supply sagged)

14 identical cycles in 15 s, ~1 s each. The brownout detector is already at the least-sensitive level (~2.43 V) and still trips, so the 3.3 V rail is collapsing below 2.43 V under the PHY turn-on peak (~400-500 mA) that the marginal 5 V supply plus dev-board decoupling cannot source. The stock Wi-Fi module ran on this same rail fine, so the weak link is the ESP32 board's power path, not the appliance supply.

This explains "never reconnects until power-cycle" precisely. The device does reset on its own, but on the marginal supply it cannot get past phy_init on the reboot, so it loops invisibly (offline) until a full power-cycle lets the rail recover. It is a supply/brownout problem, not primarily a missing esp_wifi_connect() re-arm.

Fixes

1. Shorten the power wires (done): reduced IR drop; the node is now stable on Wi-Fi at idle (6/6 live Matter reads, no resets). Margin is thin.
2. 470-1000 uF bulk cap at the module 3.3 V / GND + 0.1 uF ceramic: the real fix. Not yet fitted.
3. Firmware power-saving (investigated): the phy_init peak cannot be reduced by TX-power / Wi-Fi-PS / CPU-freq (all pre-association or average-current levers on a peak-current event). The only firmware lever in that window is confirming PARTIAL RF calibration is not silently falling back to the ~4x-current FULL calibration (a brownout-corrupted NVS cal blob can force FULL, a plausible self-sustaining loop). The matter-safe OTA-time win, extending the TX-power throttle to the Matter BDX OTA path, is DONE (shipped in 19077d9 as HisenseOTARequestorDriver, throttling to 10 dBm for the BDX transfer and restoring on idle; it ships in all flavours, no #ifdef gate). The earlier "(currently HTTP-only)" note is obsolete. See OTA, watchdog, bus-error & link-loss recovery #12.
4. Defense-in-depth (for genuine RF drops distinct from brownout): a robust WIFI_EVENT_STA_DISCONNECTED re-arm with backoff + a task watchdog so a hung connectivity task reboots into a recovery attempt.

Done when

The node survives both a Wi-Fi drop and a supply sag without going dark until power-cycle: cap fitted + reconnect handler + optionally the BDX-path OTA TX throttle.

_{Ported from the project's private tracker.}

[AndrewDemsDS]

Correction to the "Fixes" item 4 (the STA_DISCONNECTED re-arm / watchdog defense-in-depth), after reading the esp-matter/CHIP platform layer:

esp-matter already handles Wi-Fi reconnection — no app-level handler is needed (and adding one would fight CHIP's state machine, which deliberately sets the station to application-controlled to prevent double-driving). ConnectivityManagerImpl_WiFi.cpp handles WIFI_EVENT_STA_DISCONNECTED by driving DriveStationState(), which re-arms esp_wifi_connect() on the reconnect interval and loops until reconnected. The effective CONFIG_WIFI_STATION_RECONNECT_INTERVAL on this build is 100 ms (vs CHIP's 5000 ms default), so a genuine Wi-Fi drop (AP reboot / roam) auto-recovers within ~100 ms.

So the "never reconnects until power-cycle" symptom was entirely the brownout reset-loop (device resets at phy_init and can't re-associate on the marginal rail until a full power-cycle), not a missing/slow reconnect path. The connectivity watchdog angle is separately covered: v1.1.6 adds a task-WDT PANIC scoped to the RS-485 bus task (a hung bus task reboots into recovery). Net: item 4 needs no code; the open work here remains the bulk cap (the real supply fix).

[AndrewDemsDS]

Hardware fix belongs on the custom PCB (#11), not a bodge cap

Re-scoping the hardware half of this. The brownout is a dev-board power-path
limitation, not an appliance-supply one (the stock Wi-Fi module ran fine on the
same 5V rail). So instead of retrofitting a bulk cap onto the marginal dev-board,
fold the fix into the custom ESP32 carrier PCB tracked in #11 and design the
power path for the PHY peak from the start. That retires the "fit a cap" step
here and makes the brownout a non-issue by construction.

PCB power-path spec (derived from the brownout data)

• Bulk decoupling at the module 3.3V/GND: 470-1000uF low-ESR electrolytic (or
  polymer) plus a 0.1uF ceramic, placed right at the module pins, to source the
  ~400-500mA phy_init turn-on peak that currently drags the rail below the
  brownout floor (~2.43V, detector already at the least-sensitive level).
• 3.3V regulator sized for the transient: rated well above the peak with low
  dropout from the appliance 5V, feeding short/wide power traces over a solid
  ground pour. The IR drop we chased by shortening the flying leads disappears
  once it is a trace, not a wire.
• Power sourced through the PCB from the appliance 5V, not the dev-board
  USB/VIN path.

This electrical spec is the input to #11.

Firmware stays defense-in-depth (mostly already shipped)

The firmware levers cannot reduce the phy_init peak itself (TX-power, Wi-Fi-PS
and CPU-freq all act post-detection or post-association), so they never
substitute for the PCB power path. Current state:

• RS-485 bus task already subscribes to the task watchdog (panic-reboot on a
  hung task) -> firmware/src/rs485-driver/hisense_rs485.cpp.
• BDX-path OTA TX throttle (10 dBm during the transfer, restored on idle) already
  shipped in 19077d9 (app_main.cpp HisenseOTARequestorDriver), so the
  "currently HTTP-only" note in the description above is stale.

Landable firmware follow-ups, belt-and-suspenders only, not blockers:

• CONFIG_ESP_PHY_REDUCE_TX_POWER=y: post-brownout TX backoff on the retry boot.
• Observer-only Wi-Fi reconnect backoff via CHIP's
  SetWiFiStationReconnectInterval (no esp_wifi_connect() from app code, to
  avoid racing the ConnectivityManager state machine).

Done-when (updated)

Custom PCB powers the module through phy_init across 20+ cold power-cycles with
no brownout reset, and the node survives a Wi-Fi drop without going dark until a
power-cycle. The PARTIAL -> FULL calibration-fallback investigation (grep a
crash-loop UART log for falling back to full calibration) stays open but is
moot once the rail holds.

Cross-ref #11.

[AndrewDemsDS]

Closing: the remaining work is hardware, tracked in #11.

Firmware defense-in-depth landed (PR #94, v1.1.8):

• CONFIG_ESP_PHY_REDUCE_TX_POWER=y — lowest PHY TX power on the boot after ESP_RST_BROWNOUT (post-brownout backoff on the retry boot).
• Wi-Fi connectivity-transition logger — timestamps Lost/Established so a real Wi-Fi drop is distinguishable from a brownout reboot. (The runtime reconnect-backoff idea was dropped: esp-matter's ESP32 _SetWiFiStationReconnectInterval is declared-but-undefined, so it doesn't link; CHIP already auto-reconnects on a fixed 5s timer.)

Neither firmware lever reduces the initial phy_init calibration peak that trips the reset — that is purely a power-path problem.

The durable fix is hardware → #11, which now carries the power-path spec derived from this issue's brownout data (bulk decoupling at the module pins for the ~400-500mA PHY peak, a regulator sized for the transient, power sourced through the PCB). The PARTIAL→FULL calibration-loop hypothesis stays unconfirmed and is moot once the rail holds; it needs the same bench access as the hardware fix, so it rides along with #11 rather than blocking a separate issue.