Skip to content

Stop first-boot bootloop on unconfigured HAN RX pin (#1184)#1223

Open
gskjold wants to merge 1 commit into
mainfrom
fix/issue-1184-unconfigured-han-pin-bootloop
Open

Stop first-boot bootloop on unconfigured HAN RX pin (#1184)#1223
gskjold wants to merge 1 commit into
mainfrom
fix/issue-1184-unconfigured-han-pin-bootloop

Conversation

@gskjold

@gskjold gskjold commented Jun 25, 2026

Copy link
Copy Markdown
Member

Problem

Fixes #1184 — WT32-ETH01 (and any WROOM-based ESP32) enters a permanent bootloop on first boot with no configuration.

The reported log:

(setupHanPort) Setting up HAN on pin -1/-1 with baud 2400 and parity 11
Guru Meditation Error: Core 1 panic'ed (IllegalInstruction).

Root cause

On a fresh device, hasConfig() can't validate the EEPROM and forces boardType = 0xFF + clear(), and clearMeter() leaves the meter as GPIO/passive with rxPin = 0xFF, txPin = 0xFF, baud = 0. (This matches the "board type 255 / zero voltage" in the report.)

Each loop, handleMeterConfig() builds a PassiveMeterCommunicator and calls setupHanPort(). The only invalid-pin guard there was if(rxpin == 0). With rxPin = 0xFF (-1 as the int8_t copy) that guard doesn't fire, so it prints pin -1/-1 and proceeds to:

hwSerial->begin(baud, serialConfig, -1, -1, invert);
uart_set_pin(uart_num, txpin, rxpin, -1, -1);   // tx=-1, rx=-1

With rx=-1 the Arduino-ESP32 core falls back to UART1's default pins, which on WROOM modules are the SPI-flash data lines. Rebinding them corrupts flash reads and the next instruction fetch faults → IllegalInstruction panic at a flash address → reset → bootloop. Because this happens before the web server starts, the user can never reach the wizard to select the correct board type.

Fix

Bail out of setupHanPort when rxPin is the unconfigured 0xFF sentinel, the same way pin 0 is already handled. The device then boots cleanly into the AP/config wizard where the board type (243 = WT32-ETH01) can be selected. Covers both callers (PassiveMeterCommunicator::configure and KmpCommunicator).

Verification

src/PassiveMeterCommunicator.cpp is Arduino-dependent firmware, so it isn't covered by the native pio test decoder harness. The change is a single guard matching the existing pin-0 idiom directly below it.

🤖 Generated with Claude Code

…op (#1184)

On a fresh device with no config, clearMeter() leaves rxPin = 0xFF and
defaults the meter to GPIO/passive. setupHanPort only rejected pin 0, so
with rxPin = 0xFF (-1 as int8_t) it proceeded to bind UART1 with rx/tx -1.
On WROOM-based ESP32 (e.g. WT32-ETH01) that falls back to the default UART1
pins on the SPI-flash lines, corrupting flash access and triggering an
IllegalInstruction panic before the config UI comes up -> permanent bootloop.

Bail out of setupHanPort when rxPin is the unconfigured 0xFF sentinel, the
same way pin 0 is already handled, so the device boots into the AP/config
wizard where the board type can be selected.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

🔧 PR Build Artifacts

Version: c89a41e

All environments built successfully. Download the zip files:

Artifacts expire after 7 days. View workflow run

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bootloop on WT32-ETH01

1 participant