Bastian de Byl
23716a260b
Build Firmware / Build stm32-teslacharger (pull_request) Successful in 1m1s
PR #8 (-S6) caused chip boot fault: MapChargerMessages() uncommented canMap->Clear(). Clear() ends with canHardware->ClearUserMessages(), which fires the HandleClear callback (main.cpp:170-173) — and HandleClear calls MapChargerMessages(). Recursive chain: main() -> MapChargerMessages -> Clear() -> ClearUserMessages -> HandleClear -> MapChargerMessages (re-entry) -> Clear() (recurse...) -> ... stack overflow -> HardFault Bench symptom (Kyle): ESP8266 web UI stops responding after flashing -S6. Recovery required re-flashing an older firmware (3-5 attempts). This commit: 1. Re-commented canMap->Clear() inside MapChargerMessages — the safe path. The upgrade rebuild now requires a manual "canclear" via the openinverter terminal/web UI, which fires HandleClear once and triggers an additive MapMessages + Save. 2. Added a static `in_progress` reentrancy guard so any future accidental Clear() inside this function or its callees turns into a no-op re-entry instead of a chip-bricking fault. 3. Kept the canary as Param::tmpobcmax (from PR #8) — useful as a schema marker, just no longer auto-triggers a destructive rebuild. 4. Bumped VERSTR S5 -> S7 (skips S6 so any bench reporting "S6" in the openinverter UI is visibly the broken build and gets flashed). Note: this does NOT solve the underlying "73 entries trying to fit in 50-slot CANPOS pool" issue — chargercan.cpp still has more AddRecv + AddSend calls than MAX_ITEMS. Step 2 (reduce entries) is a separate follow-up PR. #patch Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>