esp32: M5Stack ATOM Matrix + timer-poll sleep + Chassis-CAN diagnostics

[maslyankov]

Tested on a 2022 EU Model 3 HW3 running firmware 2026.8.3 with the
enhauto cable tapping Chassis CAN at the passenger footwell, plus
bench-tested for boot, WiFi AP, LED matrix, sleep cycle, and button
wake. This is the first practical real-vehicle test of the ESP32 port
on a non-OBD-II install, which surfaced two firmware-version-specific
issues that needed runtime overrides plus a substantial gap in the
upstream BMS parser coverage (closed via reverse-engineering against
ground-truth values from the enhauto Commander on the same harness).

Hardware: M5Stack ATOM Matrix + ATOMIC CAN Base + enhauto harness, ~$30.
Same wiring approach as the existing ATOM Lite, just with the front face
button wired correctly (see below) and the matrix LED driven properly.
HARDWARE.md updated with both the new ATOM Matrix row and the enhauto
Chassis-CAN install path with its known limitations.

Matrix LED

5x5 SK6812 grid is on the same GPIO 27 as the Lite's single LED, so
led.cpp now takes a LED_COUNT macro (default 1, 25 in the matrix env)
and a fill() helper drives all pixels. Brightness scaled down so 25
LEDs at full white don't pull more through the M5Stack USB regulator
than it can handle.

Front button on GPIO 39

The M5Stack ATOM (Lite and Matrix both) has the user-facing front button
wired to GPIO 39. The current firmware polls GPIO 0, which is the small
side BOOT button. Anyone pressing the obvious front button sees nothing
happen because the firmware never reads that pin.

The matrix env now overrides PIN_BUTTON=39 via build flag. GPIO 39 is
input-only (M5Stack PCB has external pull-up) and is RTC-capable, and
isn't a strapping pin so wake-by-press is reliable. ATOM Lite stays on
GPIO 0 for backward compat with anyone using the side button.

Deep sleep for M5Stack envs

LilyGO's EXT0-on-CAN_RX strategy doesn't work on the M5Stack — the
ATOMIC CAN Base routes RX to GPIO 19, which isn't RTC-capable. So both
m5stack-atom and m5stack-atom-matrix envs use a timer-poll wake:
60s deep sleep, 5s post-wake CAN probe, sleep again on miss.

WiFi+dashboard are deferred during the probe — saves ~50 mA × 5s on
every miss while parked. Probe window shows as dim white on the matrix.
Wiring warning is suppressed during probe (silence is expected then).

The button is wired as an EXT0 wake source alongside the timer.
Button-wake skips probe mode and goes straight to normal operation.
Button press during a probe also extends the wake. Existing
g_btn_ignore_boot already prevents the wake-press from being read as
a phantom click.

User knob is the existing sleep_idle_ms slider — default lowered from
120s to 60s for an in-car experience. Desk-setup users can raise it to
3600s and effectively disable.

Firmware-version workarounds (the on-car part)

These are what got added once I plugged into a real Tesla and started
discovering that the upstream assumptions don't always hold on
2026.8.3 EU HW3.

HW override. 0x398 GTW_carConfig isn't on every tap — Party CAN
doesn't have it on EU HW3 with ISA active, and Chassis CAN doesn't have
it at all on the enhauto tap. The 0x399 fallback in main.cpp then
misclassifies the car as HW4 (because ISA is HW4-only on the older
firmware the upstream code was tested against, but newer EU HW3
broadcasts 0x399 too for regulatory compliance). Added an hw_override
field — Auto / Legacy / HW3 / HW4 from a dashboard dropdown — that pins
hw_version and short-circuits apply_detected_hw(). Pinned override
is applied at boot before the dispatcher runs.

OTA-detect bypass. The upstream OTA detection at 0x318 byte 6
bits [1:0] treats raw value 1 as "in progress." On 2026.8.3, raw 1
is the steady-state idle value (or "background download in progress,
safe to drive"); the install-imminent code is something else. With the
upstream check, TX stays suspended indefinitely. Added ota_ignore
toggle (NVS-persisted) so consumers (TX gate, LED, dashboard banner)
bypass the detection. The raw value is exposed on the dashboard so the
user can see what their car actually broadcasts and report back if
anyone wants to refine the detection later.

Reboot button. Useful when an NVS setting needs a clean boot to
apply. ESP.restart() with a 200ms delay so the WebSocket ack lands in
the browser before the chip resets.

Read-only diagnostics

Ports the Flipper-side parsers for vehicle speed (0x257), steering
angle (0x129), motor torque (0x108 — using DI_torqueMotor at bit 21
with the 0.222656 scale, not DI_torqueDriver at bit 0 with 0.25 scale
which the original Flipper port had), DAS_status (0x39B: hands-on,
lane change, side collision, FCW, vision speed limit), and
DAS_autopilot tier readback (0x331 byte[0]).

Stalk position (0x3F8 → speed_profile) is also exposed because pushing
the follow-distance stalk in park is the most reliable in-park test
that the whole CAN pipeline (wiring → driver → parser → state →
dashboard) works end-to-end.

Fields use *_seen flags so the dashboard renders -- rather than
stale zeros when an ID isn't on the user's bus.

CAN serial trace mode

A per-ID change-detected printer that emits one [TRACE] line per ID
when its bytes change vs the previous capture. Toggle from the
dashboard. RAM-only (not NVS-persisted) because leaving it on can
starve the loop. Backpressure-guarded via Serial.availableForWrite
so it never blocks when USB is disconnected. Used this myself to find
the BMS substitute IDs (below) and to disprove a brake-bit candidate
(0x102 byte 4 bit 1) that looked promising in a single capture but
flickered independently on broader testing.

Chassis-CAN BMS fallback

The standard BMS frames (0x132/0x292/0x312) aren't broadcast on Chassis
CAN on this firmware. Reverse-engineered three substitute message IDs
by capturing trace and grepping for ground-truth values from the
enhauto Commander running on the same harness:

• 0x420 byte 2 = SoC % (verified at 64% / 0x40)
• 0x239 byte 5 × 0.5 − 40 = battery temp °C (verified ~22°C against
  cluster)
• 0x2B5 bytes 0-1 LE × 0.01 = LV (12V) bus voltage (15.85 V)
• 0x2B5 bytes 2-3 LE × 0.1 = HV pack voltage (378.5 V)
• 0x2B5 byte 4 × 0.1 = LV bus current (~20 A)

HV pack current still unavailable on this bus — the message that
carries it isn't broadcast here either. Added lv_bus_* state fields
to expose the 12V bus on the dashboard (low LV bus is a common Tesla
failure mode). The existing pack_voltage_v / soc_percent /
batt_temp_* fields populate from the new parsers, so the existing
BMS card works without any new UI plumbing.

Limitations on Chassis CAN (documented as N/A, not as bugs)

Things visible on the dashboard as -- because they're genuinely not
on this bus tap on 2026.8.3:

• Brake state: 0x145 ESP_status byte 2 bit 3 doesn't toggle on
  this bus. Tested 0x102 byte 4 bit 1 from a 3-tap capture but it
  false-correlates (it's likely a temperature sensor with the same
  ×0.5−40 encoding). Brake on Chassis CAN remains unidentified. Not
  blocking: driver_brake_applied isn't read by any TX path in either
  ESP32 or Flipper code, only displayed.
• HV pack current: not in the messages we've identified.
• DAS_status (0x39B): not on Chassis CAN here. 0x39D is on this
  bus but carries different fields.
• GTW autopilot tier (0x7FF): mixed/Ethernet bus only.
• 0x398 HW config: not on this tap (hence the HW override above).

What was actually verified on the car

• HW3 path (with override) — confirmed via DAS_autopilot tier readback
  (ENHANCED (2) correctly displayed)
• TX is reaching the car: enabling TLSSC Restore triggered the
  documented MCU reboot (read-modify-retransmit on 0x331 worked end-
  to-end)
• Front button works for clicks + wake from deep sleep
• Sleep cycle observed on serial (timer wake, probe, sleep again)
• Chassis-CAN BMS values (SoC, HV pack V, 12V bus V/A, battery temp)
  match enhauto Commander readouts within sensor accuracy

Did NOT test in motion. FSD activation bit 46 path wasn't engaged
because the test car has EAP entitlement, not FSD, and Tesla's server-
side entitlement check overrides the bit-level signal anyway.

Build matrix

All six existing PlatformIO envs build clean: m5stack-atom,
m5stack-atom-swap-pins, m5stack-atom-matrix, esp32-mcp2515,
esp32-lilygo, waveshare-s3-can.

Tagging needs-on-car-test for: ATOM Matrix on Party CAN (OBD-II) — I
only tested it on Chassis CAN — and FSD activation on a car with FSD
entitlement, which I don't have. (Label not actually applied because
it doesn't exist on the repo and I lack write access; flagging in
text.)

[maslyankov]

Battery SoC does not seem accurate so I will work on that next.

[hypery11]

High-quality first contribution with real-car testing. Approve with one minor fix.

Fix before merge: Remove the prefs_save(g_state) call from the can_trace WebSocket handler — the comment says "can_trace deliberately not persisted" but the save call writes all NVS keys anyway (unnecessary flash wear). Either remove the save call or add can_trace to prefs_load for consistency.

Everything else is production-ready:

• ATOM Matrix LED: clean addition, LED_COUNT=1 default preserves all existing boards
• Chassis-CAN: all read-only parsers, no new TX paths, correct ID range
• BMS parser: additive fallback for 0x420/0x239/0x2B5, doesn't break standard 0x132/0x292/0x312
• Sleep strategy refactor: generalizes BOARD_LILYGO guards cleanly
• NVS: hw_override and ota_ignore keys follow existing pattern, no conflicts with PR #40
• Security: no issues

Your reverse-engineering documentation is more thorough than most DBC contributions. Welcome to the project.