Breaking Changes
Changes that require action when upgrading. Newest first.
The firmware and the CLI are upgraded together. Every wire-protocol change below breaks mixed versions — a new CLI cannot drive old firmware, and old firmware cannot be driven by a new CLI. A mismatched pair fails with a timeout or a decode error rather than misbehaving quietly.
pip install --pre firestarter && firestarter fw -i --preAll of these are beta-only. Nothing is promoted to stable without operator authorization.
vcc / vdd / vpp ("5V") and pulse_duration ("100 us") are replaced by
vcc_mv, vdd_mv, vpp_mv and pulse_duration_us, holding integers (5000,
100). There is no tolerant reader for the old schema — this is a clean
break by design.
If you have a ~/.firestarter/database.json override written against the old
schema, it will no longer load. The failure is loud — a missing key raises
rather than silently resolving to a valid-looking 0.
Upgrade: rewrite your override with the new key names and integer millivolt / microsecond values.
firestarter info on an AT28C-family part — and 55 other EEPROMs sharing the
same decode condition — previously reported VCC: 4.0v and now reports
VCC: 5.0v.
This is a data correction, not new decoding. Upstream's vcc field for
these chips was the programmer's low-margin verify rail, not the chip's
operating supply, and Firestarter was surfacing it as if it were VCC. The
corrected value is the chip's own already-decoded operating-supply field. The
decode table itself is unchanged.
This does not fix, and does not claim to fix, any write-path failure. vcc
never crosses the wire to the firmware — it is display-and-data only.
The database now delivers a per-chip page size for the 18 chips whose upstream
record is natively protocol 0x0D. 15 move from the firmware's 64-byte floor to
their datasheet 128-byte page; 3 are corroborated at 64 and unchanged. Firmware
receiving no page-size field keeps the conservative 64-byte floor, so an older
host still issues legal write cycles.
This does alter write behaviour for those 15 parts, and it is software-proven and unvalidated on silicon — no physical AT28C part was tested. Those parts issue half as many page-write cycles, so writes may complete faster; nothing else about the command surface changes.
AT28C256 is unaffected — its upstream record is not natively 0x0D and its
page size was already 64. Nothing here explains any failure reported against it.
Protocol 0x0D remains unverified and no chip's support status changed.
The host-to-firmware JSON command no longer carries a type field (the old
mem_type integer). algorithm is now the only value the firmware uses to
decide how to program a chip; the mem_type fallback dispatch chain is gone
from both sides.
Every chip database entry — built-in or override — must now carry a usable,
non-zero algorithm. A chip lacking one is refused by the CLI before any serial
byte is sent. There is no silent fallback.
A stale host is not harmful to new firmware. The firmware skips unknown JSON
fields, so a type field simply does nothing. The only loss is the fallback
path, which was already dead code for every real chip in the database.
The host-to-firmware JSON command channel uses COBS framing with a CRC8-CCITT
integrity byte. Every command — including the firmware version probe — is
wrapped as [COBS(JSON + CRC8)][0x00] and written in a single atomic call. The
firmware verifies CRC8 before the JSON parser sees any byte; the previous
channel had no checksum.
The legacy plaintext command path is removed from the firmware entirely. There is no plaintext fallback, and no mixed-version interop — a new host cannot drive unframed firmware, and an old host cannot drive new firmware.