DG Matrix — firmware for a 200kW Level 3 DC fast EV charger
Constraint
The box they were trapped in
DG Matrix needed safety-critical embedded firmware for a 200kW Level 3 DC fast charger — managing live charging sessions, real-time analog sensor readings, persistent configuration, and field firmware updates without on-site access. Everything had to run on a Xilinx Zynq-7000 SoC and pass hardware validation against real chargers, not bench setups.
Approach
How we attacked it
Bare-metal and RTOS C/C++ on the Zynq-7000's ARM Cortex-A9 cores. We wrote ADC drivers from scratch for the voltage, current, and temperature paths feeding the safety interlocks, SPI Flash routines for non-volatile configuration and event logs, and an environment-sensor stack for thermal management. A secure OTA pipeline lets the operator field-update firmware without dispatching a technician. Web dashboard and desktop diagnostic integrations sit on top so support staff can pull logs and push commands remotely.
Decisions
What we picked, and what we rejected
Hand-rolled ADC and SPI Flash drivers over the Xilinx BSP
The voltage, current, and temperature reads feed the safety interlocks on a 200kW charger — every line in that path needs to be code we can stand behind in a hazard analysis. The Xilinx BSP would have got us moving faster but left us defending vendor code we couldn't fully inspect.
A/B partition OTA with cryptographic signing over delta updates
A delta-update scheme is faster and uses less flash, but a corrupted patch on a 200kW charger isn't a software inconvenience. A/B partitions guarantee that if the new image fails to boot or self-validate, the charger rolls back to the last good firmware on the next power cycle.
Bare-metal for the safety loop, RTOS for the orchestration
The high-frequency ADC sampling and the safety interlock decisions sit in a deterministic bare-metal path with no scheduler in the way. The lower-rate work — config persistence, OTA orchestration, web/desktop comms — lives on top of an RTOS where preemption and tasks make the code easier to reason about.
Owned the firmware integration layer, not the cloud dashboard
DG Matrix already had operations and dashboard infrastructure. Re-building a UI we didn't own would have eaten the budget. We shipped the protocol contracts and the integration shims so their existing web and desktop tools talk to the new charger firmware unchanged.
Trade-off
What we didn't build
We owned the firmware down to the ADC and SPI Flash drivers rather than buying a Xilinx BSP wrapper, which meant longer bring-up but every analog read in the safety chain is code we can defend in a hazard analysis. Charger UI and the cloud backend stayed on the client's side — we shipped the integration layer, not the dashboards. OTA was built around an A/B partition with cryptographic signing, not a faster delta-update scheme, so a corrupted update can never brick a charger in the field.
Outcome
What changed after we shipped
Firmware passed the client's hardware validation programme and supports stable 200kW charging sessions in the field. Field updates ship without truck rolls; the integration layer feeds the operator's existing fleet dashboard and desktop diagnostics with no protocol surprises.
Talk to us
Have a similar project in mind?
Tell us what you're working on. We'll let you know whether it's a fit.