[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-chat] Debugging an xmega with the AVR Dragon

From: Graham Davies
Subject: [avr-chat] Debugging an xmega with the AVR Dragon
Date: Sat, 09 Apr 2011 10:15:29 -0400

As previously posted, I am bringing up my first xmega project using an ATxmega32A4. This is mainly an informative post, but I would welcome any discussion.

It took me quite a lot of poking around on the Internet to figure out how to connect the PDI interface of the xmega to the AVR Dragon. Atmel give a recommended pinout for the PDI connector, which is similar to the ISP connector, and tell you how to wire it to the JTAG connector of the JTAGICE Mk II, but although they say the Dragon can be used for PDI they don't tell you how to wire it up. It turns out that you don't connect to the Dragon's JTAG header, but you connect to the 6-pin ISP header, just as if you were using ISP, but not connecting pins 3 and 4. This is fairly convenient as you can use a ribbon cable and either cut the middle two wires or not connect the pins at the target.

However, the build-load-run cycle is quite slow as compared to using JTAG with the mega family. My program is presently a mere 2192 bytes, and:
- Starting debugging takes five seconds before the Run button appears.
- Breaking execution takes four seconds before the Run / Stop buttons appear.
- Stopping debugging takes four seconds before the Start button appears.
- Changing a register value takes four seconds.

This may not seem much, but I am used to faster cycles and I'm finding these pauses intrusive.

It is hard to figure out whether to connect a pullup resistor at the RESET input to the xmega. This is something I habitually do with the mega, using a value around 100 kohms. However, there is Atmel material advising against this, with no mention of what values might be permissible or advisable. There is other material recommending a pullup and giving a startlingly low minimum value of just a few kohms.

Does anyone have any experience in this area? Could the omission of the RESET pullup be having some bad effect, like causing communication errors that result in the long turnaround times?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]