Ask five labs what a firmware copy contains and you will get five answers, most of them a single hex file. On an XMEGA A3 that answer is incomplete in ways that only become visible months later, when the recovered code runs on a replacement part and behaves like a different product.
Five Things, Not One
The 256A3 holds 256 KB of application flash, an 8 KB boot loader, 4 KB of data EEPROM, 16 KB of SRAM, and a small set of configuration items that are not memory in the usual sense. A delivery that carries only the first of those is a partial recovery.
The application array is 512 pages of 512 bytes, and it is the part everyone thinks of. The boot loader is 16 pages at 0x40000 through 0x41FFF, and it is the part that most often goes missing. On this device the boot loader can carry a field update routine, a communication protocol and its own set of constants, and a product rebuilt without it will not accept firmware updates even though the application runs.
The 4 KB of EEPROM, 128 pages of 32 bytes, holds whatever the designer decided was worth keeping across power cycles: calibration, totals, serial numbers, thresholds. Losing it turns a repaired board into one that needs a full recalibration procedure that may no longer exist.
The SRAM is not preservable and should not be promised. Contents are gone on power loss, and anything that mattered was copied to EEPROM by design.
The configuration items are the fifth piece, and they are the ones nobody asks about until a part will not start. They include the fuse state and the lock state, and on this family they are read from the fuse area at offset +0x07 and its neighbours.
What Survives a Chip Erase
Two things on this device have unusual erase behaviour, and both of them matter to anyone who experiments on a board before sending it out.
The user signature row is a single page of flash, deliberately excluded from a chip erase, and it needs a dedicated command to clear. It is meant for static parameters such as a serial number, a calibration set or a random seed. On a part that has been through a refurbishing line, it may still hold data written by the previous owner.
The production signature row cannot be written or erased at all. It carries the factory calibration for the internal oscillators and analog modules, the device identification and a serial number built from lot, wafer and wafer coordinates. It is readable from software and from an external programmer, and it is the item that makes a replacement part behave like the original rather than merely similar.
Then there is the EESAVE fuse, which decides whether EEPROM survives a chip erase. One setting preserves it, the other does not. A technician who erases a donor board to test a theory has, depending on that setting, either kept the retained parameters or destroyed them permanently. It is worth reading the fuse state before touching a working sample, not after.
The Order of Operations Problem
The lock fields on this family can only be tightened, never relaxed, and the only way to reset them is a chip erase that also clears the array. The locks are cleared after the rest of the flash, which is a sensible design decision and a trap for the unwary: by the time the device is unlocked, there is nothing left in it.
That single fact rules out an entire class of experiment. You cannot unlock a part to see whether it was locked, and you cannot verify a read of a protected device by erasing and retrying. The state has to be established from behaviour before any destructive action, and if the array is closed, the plan has to change rather than the device.
Where Each Route Leads
If the programming interface still answers and the global lock field is at the write-only state, the array is readable and this is a bench job with a short schedule. If the field is at the read and write state, the interface returns nothing and the work moves to opening the package. The firmware extraction overview describes both paths, and the decapsulation primer explains what opening a 64-lead part involves in practice.
For a part that is already damaged, prepare for a different conversation. A device that has lost its supply pins, been overheated or spent a decade under conformal coating is not a routine read, and the reading service is the place to check what the capture stage can still do.
What the Delivery Looks Like
Five items, each with a checksum: application array, boot loader, EEPROM, user signature row, and a text record of the fuse and lock state. Two independent reads compared byte for byte before release, and a note stating which of the five came from a direct read and which were reconstructed.
That last note matters for anyone who later has to defend the result internally, and it costs nothing to write at the time. Standard terms are on the non-disclosure agreement page, and the services overview lists what each option includes.