Documentation lags silicon. A revision that left the fab last quarter may have no errata sheet worth reading, no change list, and a device signature byte that no tool recognises. The temptation is to treat such a part as “the same chip as last time” and proceed — and most of the time that works, which is exactly why the exceptions are expensive.

The alternative is to build a description of the part from measurements. Three of them are enough to catch the differences that matter.

Measurement one: the signature

Three bytes, read before anything else. Vendor and family are stable; the third byte is the model. When a revision changes nothing observable, the third byte is unchanged and the toolchain proceeds without complaint.

When it does change, the read still succeeds — the tool is what fails. Recording the three bytes is worth doing even when the part is recognised, because it is the one piece of evidence that identifies the die later in the process, and it takes a second.

Measurement two: the fuse and lock readback

The fuse map is stable across revisions, which makes it a calibration reference. Read it, record it, and compare it with what the image says should be there.

A discrepancy between the fuse byte you read and the assumptions in the firmware is informative. It can mean the device was reprogrammed in the field with different settings, that the part came from a different production run, or that the fuse byte is being read through a marginal interface. All three are worth knowing before an image is interpreted.

The lock byte readback is the same kind of evidence: it states the protection mode as the hardware sees it, which is the only authority on the question of whether a read is permitted.

Measurement three: erase behaviour

Erase the part and read it back. On a healthy part the array is uniformly FF and the lock bits are clear. Deviations from that, in order of frequency:

That table is the most useful diagnostic in the whole sequence, because it separates three things that otherwise look identical: a working part, a marginal setup, and a damaged die.

It also has a cost that must be stated plainly — the erase removes whatever was there. It belongs after the read has been attempted and after the decision that the contents are not recoverable by other means.

What the image says about the revision

Firmware written for a specific silicon revision often contains a workaround. Workarounds are recognisable: a redundant register write, a delay loop before a peripheral is enabled, a check of a status bit that the datasheet says is fixed.

Finding one in a recovered image is evidence about the die. A delay inserted before enabling a specific peripheral implies the revision needed it. That kind of code-level fingerprint is sometimes the only documentation a revision has.

It also matters for reproduction. An image restored onto a newer part carries workarounds that are unnecessary; an image restored onto an older part may be missing one that is essential. Neither failure mode is visible without knowing which revision the image was written for.

The practical stance

Treat an unidentified revision as a part whose electrical envelope is unknown rather than as a part identical to its predecessor. Concretely:

• Read at the design rail, never at the bottom of the range.
• Verify every page twice.
• Record signature, fuses, and lock byte with the image, not separately.
• Note the date code from the package, which is often the only revision evidence available.

The date code is underrated. It is printed on the part, it survives every toolchain’s indifference, and it distinguishes two otherwise identical units.

Related notes

• ATmega640 and the external bus — the shape question that precedes any revision question.
• ATmega640P and the three interfaces — which door the fuses left open.
• ATmega644A and revision footprints — the same problem on a smaller die.

FAQ

Does an unknown signature mean the part is counterfeit? No. It means the die is not in the tool’s table. Counterfeits usually reproduce a known signature rather than an unknown one.

Can I read a revision-specific fuse field safely? Reading is safe. Writing a fuse field whose meaning you are unsure of is not, because some settings remove the interface you would need to undo them.

Is the date code a reliable revision indicator? It is a production indicator. Two units with different date codes may still be the same revision, but two different revisions cannot share a date code.

Should workarounds be removed from a recovered image? Only with an understanding of what they compensate for. Removing one that was still necessary produces an intermittent fault that is hard to trace.

Conclusion

An undocumented revision is not a mystery, it is an unmeasured part. Signature, fuse readback, and erase behaviour describe it well enough to work with, and the workarounds inside its firmware often document it better than any published note. The mistake to avoid is assuming continuity — that is the assumption whose failures cost the most.

Comments are closed.