Bastian de Byl
4c1f2e1991
Build Firmware / Build stm32-teslacharger (pull_request) Successful in 58s
Fix B on the VCU side (b24864e) opens HV contactors when BMS reports cell voltage above the user's ChargeLimit_pct target. That isolates the pack but doesn't tell the OBC modules to stop drawing AC. Result: ~0.55 kW continuous EVSE draw dissipated as conversion loss in the OBC, water pumps stay engaged, app reports "Charging <1 kW" indefinitely. Root cause: ChargerStateMachine's EVSEACTIVATE state has only four exits (CheckVoltage udc>udclim, CheckTimeout, CheckUnplugged, CheckChargerFaults). With contactors open the VCU can't drive pack voltage above udclim, so none of the exits fire — state machine wedges. Fix: make udclim CAN-driven on 0x212 bytes 1-2 (uint16 LE, range 50-420V). The VCU normally sends 398 V (no change in behavior). When VCU is in CHARGE_COMPLETE state it drops to 200 V — well below any realistic pack voltage — which fires the existing CheckVoltage() path within 1 second (10 × 100 ms ticks) and transitions EVSEACTIVATE → STOP → OFF. OBC modules disable, AC draw drops to zero. Elegant because we reuse the existing CheckVoltage() logic instead of adding new state-machine code, new params, or new exit paths. Pre-S10 firmware silently ignored bytes 1-2; pre-S10 VCU with S10 teslacharger leaves udclim at its persistent flash default (398V). Safe upgrade in both directions. Pool: 42 → 43 / 50 slots used, still comfortable headroom. Pairs with stm32-hal-vcu PR #47's matching dynamic-udclim TX commit. CAUTION: udclim updates here are RAM-only; running `save` while VCU is forcing 200V would persist that value and require canclear-and- rebuild to recover. Documented in chargercan.cpp comment block. #patch Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>