While no job is running, HydraFlasher reads the JEDEC ID of every socket once a second, plus the 64-bit unique ID on Winbond chips. That's how cards update the moment you insert or remove a chip, and how the flash log knows exactly which chip was flashed.

How often it reads, and at which SPI clock, is set on the settings page, where the scan can also be turned off. With the scan off:

• cards only change after jobs and probes, and the socket header reads scan off instead of live;
• new chips aren't identified automatically: probe them;
• the queue still checks the sockets between jobs, so a queued job never works with a chip that was swapped meanwhile.

The scan needs direct access to the serial port. Under sudo (see Installation) it's off, and chips only show up after a probe.

The JEDEC ID alone doesn't say which flashprog chip definition to use. HydraFlasher learns the name the first time flashprog probes a chip type, and remembers it in its config file. From then on, inserting that chip type shows its name right away.

It only learns from probes without a chip override. With an override, flashprog reports just the forced name, which would hide that other definitions also fit.

A chip whose type HydraFlasher hasn't learned yet shows as unknown <JEDEC ID> with "probe to identify". You don't need to do anything:

1. If a chip override is set, it's reset to Auto-detect, since an override would stop flashprog from recognising the new chip.
2. An identify probe runs automatically on that socket. If jobs are queued, it runs first, in the next pause between jobs.
3. The card then shows the real chip name, and the name is remembered.

If flashprog only matches one of its catch-all definitions (unknown SPI chip (RDID) and similar), it has no real definition for the chip. The card then shows unsupported chip in red. Read, erase and write are refused with an explanation, and the chip is never added to the remembered names.

What to do: check that the chip is seated correctly (a badly seated chip can return a garbled ID), then check whether a newer flashprog supports it.

Some chips match several flashprog definitions, for example a Winbond W25Q256 matches both W25Q256FV and W25Q256JV_Q. The card then shows 2 defs match.

When you start a job on such a chip, HydraFlasher asks which definition to use. Pick the one printed on the chip. The choice becomes the chip override, and HydraFlasher also remembers it for that chip type for the rest of the session, so later jobs don't ask again.

Each job gets the definition that fits its own chip, decided when you start or queue it:

1. the chip override, if it's one of this chip's definitions;
2. otherwise the definition you picked for this chip type earlier;
3. otherwise auto-detect, if only one definition matches;
4. otherwise you're asked.

Jobs that go through several sockets (probe, read and verify with ALL selected, and one-by-one production batches) pick the definition per socket the same way. With flashprog, a definition that doesn't fit a chip means "no chip found", so one wrong -c would make a socket look empty. A probe of a chip whose type isn't known yet always uses auto-detect.

So a one-by-one write or a queue over different chip types never sends one chip's definition to another. If a chip's definitions weren't known yet when you queued its job, the job uses your choice if it fits.

The chip box in the settings forces one definition (flashprog's -c). It's set automatically when you pick a definition; × resets it to Auto-detect.

An override only fits one chip type. Whenever a chip is inserted that the override doesn't fit, HydraFlasher resets it to Auto-detect and says so in the log, for example:

→ Chip override W25Q256JV_Q doesn't fit (CS1 holds W25Q128.V) – reset to Auto-detect

Jobs that are already queued keep the definition they were started with.