ATxmega128A1U PDI read protection — has anyone characterized it with ChipWhisperer Husky Plus?
Hi NewAE community,
I’m working on an ATxmega128A1U as part of an electronics repair. My goal is to recover the existing Flash contents while preserving the firmware on the original chip. I also have a second ATxmega128A1U that I can program and lock for controlled experiments.
My setup includes a ChipWhisperer Husky Plus, the NewAE probe kit, and a Rigol MHO954. I power the target from an external 3.3 V supply with a common ground. I’ve connected PDI_CLK and PDI_DATA, successfully read the device signature over PDI, and can monitor VCC and both PDI lines on the Rigol.
I’ve reviewed the NewAE password-bypass lab. I understand that its success condition is a response from the training firmware. What I’m trying to investigate is the hardware-enforced Flash read protection on the XMEGA AU programming interface. I haven’t found a published experiment for this exact device. NewAE Fault 2.2 notebook
-
Has anyone demonstrated or documented a non-destructive readout of an ATxmega128A1U with
LB[1:0] = 00? Reports of unsuccessful attempts on this exact part would also help. -
Is anything known about when the XMEGA AU evaluates the external read permission? For an initial side-channel comparison on my spare chip, would you align captures to reset release, entry into PDI programming mode, or a specific NVM read transaction? What observation would help distinguish those possibilities?
-
My proposed control is to program a known Flash image on the spare, verify it while unlocked, enable read protection, and record the response to the same read request. If I later observe an unusual response during fault injection, I would compare the returned bytes against that known image. What additional controls would you use to distinguish a real readout from a reset, stale data, or a PDI communication error?
I’d appreciate a pointer to a relevant notebook, paper, silicon erratum, or scope capture. I can share my wiring and a synchronized capture of VCC, PDI_CLK, and PDI_DATA if that would help.
Thanks,
Samet