Stop first-boot bootloop on unconfigured HAN RX pin (#1184)#1223
Open
gskjold wants to merge 1 commit into
Open
Stop first-boot bootloop on unconfigured HAN RX pin (#1184)#1223gskjold wants to merge 1 commit into
gskjold wants to merge 1 commit into
Conversation
…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>
🔧 PR Build ArtifactsVersion: All environments built successfully. Download the zip files:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Fixes #1184 — WT32-ETH01 (and any WROOM-based ESP32) enters a permanent bootloop on first boot with no configuration.
The reported log:
Root cause
On a fresh device,
hasConfig()can't validate the EEPROM and forcesboardType = 0xFF+clear(), andclearMeter()leaves the meter as GPIO/passive withrxPin = 0xFF,txPin = 0xFF,baud = 0. (This matches the "board type 255 / zero voltage" in the report.)Each loop,
handleMeterConfig()builds aPassiveMeterCommunicatorand callssetupHanPort(). The only invalid-pin guard there wasif(rxpin == 0). WithrxPin = 0xFF(-1as theint8_tcopy) that guard doesn't fire, so it printspin -1/-1and proceeds to:With
rx=-1the 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 →IllegalInstructionpanic 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
setupHanPortwhenrxPinis the unconfigured0xFFsentinel, the same way pin0is 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::configureandKmpCommunicator).Verification
src/PassiveMeterCommunicator.cppis Arduino-dependent firmware, so it isn't covered by the nativepio testdecoder harness. The change is a single guard matching the existing pin-0 idiom directly below it.🤖 Generated with Claude Code