A binary dump is a sequence of bytes and nothing else. It carries no addresses, no record boundaries, no checksum, and no end marker. Everything that makes the file interpretable comes from outside it: an assumed start offset, an assumed length, and an assumption that no region in between was skipped.

Those assumptions are usually correct. When they are not, the file is not obviously wrong — it is wrong in a way that shifts everything after the error by a fixed amount, which is the failure mode that consumes the most time.

Three assumptions, three ways to be wrong

Start offset. The internal flash begins at address zero. A dump taken with the tool’s default offset usually starts there. A dump taken after a partial read may not, and a file that begins mid-page will disassemble into plausible nonsense that never quite makes sense.

Length. The file’s length should equal the die’s flash size. A shorter file means the read stopped early; a longer one means the tool padded to a configured size. Padding with FF and truncating a real read look identical in a hex viewer.

Continuity. A binary implies that byte n follows byte n-1 in the address space. If the tool skipped a page because it failed verification, the file contains no signal of that — the skipped page simply is not there, and every subsequent byte is at the wrong address.

The third is the one worth guarding against actively, and the guard is to build the dump page by page with an explicit address for each page, then assemble the binary from verified pages rather than from a single streaming read.

Why the vector table is the alignment check

Every AVR image begins with a vector table: a reset vector at address zero followed by interrupt vectors, usually a fixed number of bytes apart. On this family the reset vector is a jump instruction, and a jump instruction has a recognisable encoding in the first word and a target in the following word.

That structure is a powerful alignment test. If the file is correctly aligned, the first word decodes as a jump and the second word points somewhere inside the code region. If the file is off by one byte, the first word decodes as garbage that does not exist in the instruction set.

So the first four bytes of the file tell you whether the offset is right, before any interpretation of content. That check costs seconds and catches the most common offset error.

The P and V suffixes and the read itself

Neither suffix changes the file format. Both change the electrical envelope: P for the picoPower die with its revised oscillator and lower sleep current, V for the extended low-voltage range.

What they change for a binary dump is the probability of a silent page error. A dump assembled from a marginal read contains bytes that were sampled before the bus settled, and a binary gives you no checksum to notice with. A hex file at least fails its per-line checksum; a binary just looks like data.

The practical consequence: when the tool produces a binary, the verification has to be built in. Read each page twice, compare, and only append when they match. A page that never matches is a page to investigate, not to average.

What the file cannot tell you

Three things are structurally absent from any binary of the flash:

• The fuse byte. Clock source, start-up delay, boot section size, interface enables. Without it, the image may be applied to a blank part that then fails to start.
• The lock byte. Current protection state, which is not content.
• The EEPROM. A separate array, addressed separately, and not part of a flash dump even though it often holds the values that make the product work.

A binary that is passed on without those three is a partial recovery, regardless of how cleanly it disassembles.

Reconstructing confidence

The sequence that produces a binary worth trusting:

1. Read the signature. Confirms which member of the family and therefore how much of the map is real.
2. Read the fuse and lock bytes and record them alongside the file, not separately.
3. Read page by page, twice, with an explicit address for each page.
4. Assemble from verified pages only, and log any page that failed verification.
5. Disassemble the first word and confirm it is a jump into the code region.
6. Disassemble the last page and confirm it is not an artefact of padding.

Step 6 is the one people skip. A file padded to a round length ends in FF, which decodes as an invalid instruction. That is expected. A file that ends in valid-looking code is telling you the real length is shorter than the file.

Related notes

• ATmega640P and complete hex files — the same content in a container that carries addresses.
• ATmega640 and the external bus — the case where the internal image is not the whole program.
• ATmega324PA and marginal reads — why two passes are not optional.

FAQ

Is a binary smaller than a hex of the same data? Yes, roughly half, because it omits the address and checksum text. The size difference is not a sign of missing content.

Can a binary be converted to hex later? Yes, given a start offset. That conversion is the point at which the missing address information is restored — but the offset must be right, or every address in the resulting file is wrong.

Why does padding matter? Because padding and truncation are indistinguishable in a hex viewer. The only way to tell is the instruction encoding at the boundary.

Is the EEPROM in the binary if the tool was configured to include it? Possibly, at a separate offset, which the binary does not record. Never assume; read it explicitly.

Conclusion

A binary dump is a claim about ordering with no evidence attached. The address, the length, and the continuity are all supplied by the tool and none of them is checkable from the file. Building the dump page by page with explicit addresses, verifying twice, and testing the first instruction’s encoding turns the claim into something that can be relied on.

Comments are closed.