How a Spark charger talks to the car, the phone, and the cloud.

Everything starts on the STM32/AVR "power board." It is the only part that touches mains and the vehicle: it drives the Control Pilot (CP) signal on the J1772 connector, closes the contactor/relay, and continuously senses current, voltage and faults. The ESP32 never switches power directly — it asks the AVR to, over serial.

Fault & state codes reported by the AVR

connector_grizzle.cc · state parsing ~3811–3930 · command 4 = STATE

On power-up app_main() brings the system up in a fixed order, then hands control to a 10 ms OCPP super-loop that runs forever. Two things worth noting: the STM version check happens before networking (so the AVR can be re-flashed at boot), and the gateway/tester UART task is spawned early so a factory line can talk to the unit even before Wi-Fi exists.

The two MCUs speak a tiny ASCII line protocol over UART0 @ 115200 8N1 (default pins GPIO1 TX / GPIO3 RX). Every line is L:<CMD>:<VALUE>\r\n. The ESP reads a byte at a time with a 25 ms idle timeout to frame each line. This is the cyan lane in the map above.

# decoded SerialMessage struct (connector_grizzle.cc ~271)
stm32_state            2      // CHARGING
set_current            1600   // 16.00 A commanded
actual_current         2522   // 25.22 A measured
max_current            3200   // 32.00 A ceiling
voltage                23050  // 230.50 V
chrgr_en_and_pilot_level 0x0F // charging enabled + CP level

connector_grizzle.cc parse 3701–4125 · send sendMessage() 3674–3699 · enums in stm_messages_grizzle.h

The ESP carries the AVR's firmware embedded in its own binary (grizzle.bin, grizzle2.bin, grizzle3.bin) plus version stamps. At boot it interrogates the running AVR; on a version/checksum mismatch it walks the STM32 into its ROM bootloader and re-flashes it over the same wires — a different UART profile for each phase.

• Interrogate — open UART_NUM_2 @ 38400, read version1+version2; a .3 suffix means STM v2 → use grizzle2.bin, else v1 → grizzle.bin.
• Enter bootloader — send JUMP_TO_BOOT (8) or JUMP_TO_BOOT2 (20), wait 2 s, drain serial.
• Re-open @ 19200, EVEN parity, 8N1 — the STM32 system bootloader profile; handshake with init byte 0x7F.
• Erase (0x43/0x44) → write (0x31) in ~256-byte chunks from 0x08000000 → GO (0x21).
• On success, store the new version + checksum in NVS so the next boot is a no-op.

stm_firmware_updater_grizzle.h 69–223 · trigger stm_firmware_grizzle.h 127 · embedded bins via CMake

The ESP runs Wi-Fi in APSTA mode: it is simultaneously a SoftAP (its own hotspot) and a station on your router. The SoftAP is Spark_<last-4-of-serial>, password SparkPower123, WPA2, channel 1, up to 4 clients, gateway 192.168.4.1 with its own DHCP. A libwebsockets HTTP server on :80 binds all interfaces, so the same 50+ endpoints answer on both the hotspot and the router-side IP.

HTTP portal API — by function

Gateway / tester box — UART1 text commands

portal_grizzle.cc endpoints · main.cc uart_command_task 207–455 · AP config platform_esp.cc 779–786

Once provisioned, the charger's station interface joins the site network by DHCP. In a typical Soneil deployment that network is an InHand industrial/cellular router, often paired with a TP-Link Wi-Fi extender so the charger has solid signal in a parking structure. From the firmware's view it is just "a router with DHCP" — there is no InHand- or TP-Link-specific code; it is standard, vendor-agnostic Wi-Fi.

platform_esp.cc APSTA 568, AP 779–786, IP 459 · Ethernet build/config/sdkconfig.h 89–97

With an IP in hand, the ESP opens a secure WebSocket (wss) to the Charging-Station-Management-System using the ocpp1.6 subprotocol. The URL comes from one of four sources (priority NONE → UART → PORTAL → OCPP); Soneil's defaults are wss://api.soneilspark.io:8887 and wss://ocpp.io. The link self-heals with a back-off ladder and a 15 s ping / 60 s heartbeat.

transport websocket_lws.cc 175 · charging_station.h 66–135 · transaction_module.h 300–668 · configuration_module.h 141–146

Firmware arrives two ways. Locally, the app POSTs a .bin to /esp_OTA. Remotely, the CSMS sends an OCPP UpdateFirmware carrying a location URL — typically ftp:// — and the charger pulls the image itself. Either way it writes to the inactive OTA partition, validates, flips the boot pointer, and reboots; on the next boot the AVR is re-flashed if its stamp changed (Stage 4).

portal_grizzle.cc /esp_OTA 977 · firmware_grizzle.cc esp_ota_* · fetch_ftplibpp.cc 26–119 · firmware_update_module.h 108–249

The Spark app wears two hats: on the hotspot it drives the local HTTP API (pairing, calibration, manual start/stop); once the charger is on a CSMS it monitors and controls through the cloud. In parallel, a Home Assistant path publishes the charger over MQTT — which is what brings Google, Alexa, Siri and SmartThings into the picture. HA-MQTT and OCPP-telemetry are mutually managed so they don't both stream at once.

connector_grizzle.cc MQTT init 599–629, discovery 498–580, telemetry 642–680 · toggle portal_grizzle.cc 1446/1491

The local surface is built for easy servicing, which is also its risk. Worth stating plainly so it's a deliberate choice, not a surprise:

Mitigations to consider: gate the hotspot behind an on-demand enable, add a token to control endpoints, and rotate the admin path — see the earlier discussion on an /ap_timeout-style state read for the app.

The two MCUs are programmed by different tools. The STM32/AVR bottom board is flashed first on a bench programmer (Microchip/Atmel-style, SWD/ISP) with the compiled ELF — that image lives with the manufacturer, not in this repo. The ESP32 is then flashed over USB-UART with esptool.py and four binaries at fixed offsets. From then on the ESP carries the AVR image embedded (Part I · stage 4), so it can re-flash the bottom board itself.

# chip esp32 · DIO · 80 MHz · 4 MB
esptool.py --chip esp32 --before default_reset \
  --after hard_reset write_flash \
  --flash_mode dio --flash_freq 80m \
  0x1000    bootloader.bin \
  0x8000    partition-table.bin \
  0xe000    ota_data_initial.bin \
  0x1f0000  SparkChargerEsp.bin

artifacts charger/build/flasher_args.json · charger/partitions.csv · sdkconfig 4MB/DIO/80m · AVR ELF = manufacturer bench step

On the floor this is an automated test fixture built by MicroArts. A motorized actuator lowers a bed of pogo pins onto both boards clamped in a jig — the top (ESP) board and bottom (AVR) board — and a Raspberry Pi 4 runs the whole sequence off a touchscreen. It first does bare PCB checks (resistance, rail voltages, connectivity), then configures the unit through two channels at once: an Arduino Mega for serial commands and an ESP32-WROOM bridged onto the charger's Wi-Fi for the local API. A scanned barcode prefix picks the variant app, and the log uploads to GitHub.

The MicroArts test fixture — data flow

Fixture test sequence

Variant matrix — driven by the serial prefix

Configuration operations applied

Timestamp · Hostname · Serial · Max Current · Backend URL · Board Version
AVR Flash · Offline Dumb · Voltage Cal · Wifi SSID · Verdict · Details
# e.g. 2026-02-27 15:27:21 ; Santhosh ; 40252203539011 ; 48 ; wss://ocpp.io ; 12 ; 48 ; Enabled ; Yes ; Soneil ; PASS ; "…12 line-item checks…"

spark_charger_AP_app/spark_charger_tester_03-03-2026.py · AutomationWorker 810–1454 · variants 5034–5045 · webhook 630–645

Now assembled, the charger meets a real load. A Raspberry-Pi Python orchestrator conducts the test but touches no mains itself: it commands an ESP32 tester board (Arduino, serial @ 921600). Real power comes from a transformer whose 204 / 240 / 264 V taps are switched by the relay bank, which routes AC into the charger and emulates the car's connector states. The charger's EVSE output then feeds a real electronic load driven over MODBUS-RTU, while the RPi captures the charger's waveform on an oscilloscope.

ESP32_relay_board_updated_resistor_bank_12-02-2026.ino · MODBUS 171/221–401 · relays 213–732 · serial 921600 (855) · MODBUS 38400 (874)

The last gate is human + paperwork. A unit only advances if every station's verdict is PASS and its unique serial resolves cleanly in the sheet. Then it's sealed, ETL-listed for safety, boxed, and moved to the warehouse — ready for a customer whose very first act (Part I · stage 5) is to pair it with the Spark app.