There are about a zillion posts on this forum on the problems using the Xmega PDI interface when programming with the Dragon. Indeed, Atmel tells us:
"XMEGA PDI issues: XMEGA PDI mode on AVR Dragon does NOT work for the following XMEGA devices: A3/D3 - revisions B, C and E or A1 (up to revision K)"
Before I knew this neat little fact, I designed the first version of a new product based on the ATxmega256A3U to include both JTAG and PDI programming interfaces. In fact, both interfaces worked fine on that board; I didn't know there was an issue. :-)
Note: the PCLK line has the requisite 10K pullup in both revs.
I then rev'd the board for some additional functionality and improvements. The JTAG I/F worked great for programming with the Dragon while the PDI did not. I received the dreaded
"Got error setting up PDI mode: Device is not supported in this emulator mode. Debugger command setParameter failed." error.
The design of these programming ports is identical from the original to the revised. And, this is why and when I searched this forum and found that lots of users have experienced this issue.
So, to debug this I thought I'd probe the PDI interface, first with the digital scope, then the logic analyzer to "see what I could see". What I found was that if either instrument was attached to the PCLK line, the PDI I/F magically worked with the Dragon. Both of these instruments will have very high impedance, and a small capacitance. So, just to be crazy about it, I tried adding an 82 pF cap from the PCLK line to GND.
PDI programming through the Dragon now works perfectly (at least so far...).
So, it would appear that there is some timing issue in the the Dragon that is "right on the edge" when used with the silicon revs mentioned above. Obviously, adding the small cap to GND on the PCLK line will slow the edge a bit - apparently just enough to make it work. Other values of capacitance might work. However, I'm not really interested in pursuing this because I like the JTAG I/F; I've had essentially no issues with it. But, it's nice to know that both programming ports work.
I'm not suggesting this as a fix; Atmel told us only that there was an issue, not what that issue was with suggested solutions. But, maybe this workaround will allow someone to get by in a pinch if the PDI is the only programming I/F available and he/she only has the Dragon.