Every other device in the XMEGA A1 line answers with three identification fields that are printed in the datasheet. The 384 KB member does not, and that single gap changes how a copy job on this part has to be scoped.
The Empty Row
Open the identification listing in the A1 datasheet and the first four entries are filled in: the 64A1 reads 1E 96 4E, the 128A1 reads 1E 97 4C, the 192A1 reads 1E 97 4E, the 256A1 reads 1E 98 46. The fifth row, for the 384A1, was left as TBD in the revisions that cover this density and stayed that way through several document updates.
This is not a secret. It is what happens when a density is added to an existing document late in its life and the identification table is not revisited. The part exists, it is orderable, and it is in production. What is missing is a published value that a reader could compare against.
For anyone verifying a recovered image, that matters. The usual confirmation step, read the identification and check it against the datasheet, is unavailable here.
Confirm It From the Address Map Instead
The device can still be identified with certainty, because its geometry is unique in the family. Three measurements settle it.
| Measurement | ATxmega384A1 | Nearest confusion |
|---|---|---|
| Last readable application address | 0x5FFFF | 256A1 stops at 0x3FFFF |
| Boot loader entry point | 0x60000 to 0x61FFF | 8 KB at 0x40000 on the 256A1 |
| Application page count | 768 of 512 bytes | 512 pages on the 256A1 |
| Data EEPROM | 4 KB, 128 pages | 4 KB on the 256A1 as well |
The same arithmetic settles the 256A1 in the other direction. Read upward past 0x3FFFF. On a 256A1 the array ends there and the boot loader begins at 0x40000. On a 384A1 the application area keeps going for another 128 KB, and the boot loader sits at 0x60000. That single observation, where the boot loader starts, separates the two densities without any identification value at all.
The page count corroborates it: 768 pages of 512 bytes is 384 KB, and no other A1 part reaches that number. The EEPROM is 4 KB in 128 pages of 32 bytes, which matches the 256A1, so it is not a discriminator on its own.
The One Thing That Is Different About This Part
SRAM. The 384A1 carries 32 KB, double the 256A1 and four times the 192A1. In a family where the middle densities plateau at 16 KB, that jump is the clearest sign that this is not a scaled 256. It also explains why the part turns up in products with large buffers: graphic panels, data logging instruments and anything that holds a frame in memory before pushing it out.
For a copy job, the SRAM size is a sanity check rather than a discriminator, since it cannot be read out of a locked device. But it matters when the customer intends to run the recovered code on a substitute part, because a 256A1 will not hold a 32 KB working set.
What a Copy of This Device Should Contain
The application array as one image, the 8 KB boot loader as a second, the 4 KB of EEPROM as a third, and a written record of the fuse and lock state. Each image carries its own checksum, and two independent reads are compared byte for byte before anything is released.
Two items are easy to leave out and hard to recover afterwards. The user signature row is one page of flash that is deliberately excluded from a chip erase, so on a salvaged part it may still hold a serial number or calibration constants from the previous owner. The fuse state records whether EEPROM survives an erase and whether the reset pin still functions as a reset, and a replacement built without that record will not behave like the original.
When the Array Is Locked
If the lock fields are programmed, none of the address-map work above is available, because the programming interface will not return the array at all. The job shifts to opening the package and reading the array optically, which is a laboratory schedule rather than a bench one. The invasive route describes what that involves, and the analysis report that accompanies it documents the die, the array boundaries and the state of the metal layers.
A 100-lead thin quad flat package is a reasonable target for that work, though the thin mould compound leaves little tolerance during preparation. Boards that have been potted or coated add a preparation step, and the schedule should assume it.
Scoping the Job
Send the top marking, the package, the board function and the unit count. Because the identification value cannot be used for confirmation on this density, state what the firmware is expected to be able to do, for example how large an image the application area holds or whether a boot loader is in use. That description lets the lab confirm the density from behaviour before any file is delivered.
An NDA is signed before files are exchanged, with the standard terms on the non-disclosure agreement page, and the services overview lists what each delivery includes so the scope can be agreed in one pass.