The ATXMEGA256A3-AU is the top of the 64-pin XMEGA A3 line: 256 KB of self-programmable flash with an 8 KB boot section, 16 KB of SRAM, 4 KB of EEPROM, two eight-channel 12-bit ADCs, and an AES and DES crypto engine, all in a 64-lead TQFP. Copying the flash program out of a locked one, a copy locked ATXMEGA256A3-AU microcontroller flash program engagement, starts at the boot loader section, because that 8 KB region is where the lock system and the self-programming capability meet.
Atmel reserved the top of the flash for a boot loader and gave it the BLBB lock pair, separate from the application section’s BLBA pair. Code running in the boot section holds the right to program the flash through SPM, the self-programming instruction, which is how field firmware updates work. The same privilege explains the standard lock configuration on production devices: the boot loader is left readable while the application section is placed under the strictest external lock, because the update mechanism needs a live bootloader even when the application code is sealed. The consequence for recovery is structural. A locked 256 KB part usually still executes its bootloader, and any flaw in that bootloader’s update logic, its record format or its timeout behaviour becomes a candidate channel for reading the application, which is why the identification session always ends by asking whether the customer’s boards were field-updated in service. Tracing that logic after extraction is routine work; finding the flaw without extraction is where the value lies, and the megaAVR clone notes record several bootloader-era patterns that carried over into XMEGA designs.
Above the section pairs sits the LB pair, writable only from outside. In its strict mode the programming interface may neither program nor verify the flash or EEPROM, and the fuse bytes are closed to it as well, so a locked part answers identification but refuses everything else. Chip erase is the only documented reset, and it consumes the image unless the EESAVE fuse was programmed to spare the EEPROM. The 4 KB EEPROM on this part typically holds calibration and identity data that a clone must carry, which makes the fuse state worth reading before anything destructive happens. The flagship megaAVR protection notes describe the same asymmetry on the previous generation, and the extraction-resistant design review explains how vendors accidentally leave one section readable.
After the image is secured, copying is disciplined rather than dramatic. The application, application table and boot sections go onto the blank device with their original boundaries, the EEPROM image follows, and the fuse bytes are set deliberately: preserving the lock state keeps the clone as tamper-resistant as the original, while relaxing it keeps the new fleet serviceable, and the customer should choose knowingly. Functional verification on the target board closes the work, and on this family we watch the event system and the twin ADCs particularly, because 64-pin industrial designs lean on them hard. The family service overview and the restoration workflow describe how multi-unit projects are staged and reported.
Self-programming mechanics deserve a word for teams who will maintain the clone in the field. SPM on this family erases and writes one page at a time, and the application table exists precisely so an update can stage new code or parameters without touching the running application. A bootloader that respects those boundaries survives our clone intact; a bootloader that erases generously across section boundaries gets its behaviour documented in the report, because the same generosity that eases updates also erases evidence during a future recovery. Knowing which personality your flash update logic has is worth one extra page of analysis, and it costs nothing once the image is already in hand.
One working device is enough to start; two are better, because a second sample confirms whether a reading anomaly belongs to the silicon or to the technique. The QFN version of this order code documents the identity-first route we take on that package. Tell us what the bootloader on your boards is known to do, if anything, and we will tell you whether that history changes the price.