Testing Chips
The project supports a lot of chips, but only a fraction of them have ever been
tried on real hardware. dev test is how you check one and tell us what
happened.
You need the beta — see Install Beta.
firestarter dev test <chip>dev test writes to the chip. There is no prompt, no confirmation, and no
read-only mode. Use a blank chip, or one holding data you are willing to lose.
The one exception is a UV-erasable EPROM. Those cannot be erased without a UV lamp, so the test only ever writes a small 256-byte slot near the top of the chip, and each run moves down to the next unused slot. A 64 KiB part is good for roughly 250 runs, and the test tells you how many slots are left. A UV chip that has already been used is still fine to test with.
Every other kind of chip is written in full, so anything on it is gone.
The test runs a chip through the operations it claims to support — writing, reading back, erasing, blank-checking — and reports what each one did.
It runs the write-and-verify part twice. This is not extra coverage of the firmware, which is deterministic and cannot disagree with itself. It is there to catch something physical changing between the two runs: a sagging supply rail, marginal timing, a poor contact in the socket. A flaky setup invents failures that look like chip failures, and running it twice is what separates the two.
How the chip gets written depends on what kind it is:
- UV-erasable EPROMs — one small slot per run, as described above. The bits each run would have used are simply split between the two passes, so the chip ends up in the same state and lasts just as long.
- EEPROMs and page-write chips — written in full, twice. These erase themselves as part of writing, so the second pass has real work to do.
- SRAM and FRAM — written with a pattern, then its exact opposite. These rewrite freely, so it costs nothing and it exercises every data line both ways.
- Larger flash chips — written in full, except for boot blocks that are permanently locked in hardware. Those are named in the report so you can see they were skipped rather than silently missed.
dev test --fast runs the write-and-verify once instead of twice. It is a
deliberately weaker check — with only one pass there is nothing to compare, so
an intermittent fault cannot show up at all. Fast runs are also left out of
the two-report agreement described below, so two fast runs can never get a
chip promoted on their own. Use it while experimenting; use the normal command
when the result is meant to stand as evidence.
A chip being listed does not mean anyone has run it. Most entries were derived from chip data, not from a bench. Your report is the only way the project finds out whether a listed chip actually works — and a failure is just as useful as a success, because it stops the next person trusting an entry that does not work.
Reports do not change what the project claims to support. Nothing you submit automatically marks a chip as supported; that stays a deliberate decision a maintainer makes after seeing at least two independent reports that agree. One report is a data point, not a verdict — including your own.
When the test finishes it offers to file the result as a GitHub issue for you. Say yes and it fills in everything needed:
firestarter dev test <chip> --submitIf you would rather do it by hand, or the submit step fails, open an issue at https://github.com/henols/firestarter_prom/issues and include:
- the chip's exact part number, and the manufacturer marking on the package
- everything the test printed, from the command down
- which board you used, and your shield revision from
firestarter hw - the output of
firestarter --version - anything unusual about the chip — pulled from a scrapped board, unknown history, bent pins, a socket adapter
If a chip fails, say so plainly and include the full output. A failing report that gets a chip corrected is worth more to the project than a passing one.
Relocated from firestarter_app/doc/community-validation.md in firestarter_app at d56424e1979edf7245cffb9ec3111c0469f5b23f, then rewritten 2026-08-31 on the wiki; not re-verified against the code.