XMega32A4 and AVR Dragon

Log in or register to post comments
Go To Last Post
15 posts / 0 new
Author
Message
Eliteguard89
Eliteguard89's picture
Level: New Member
Joined: Thu. Aug 4, 2011
Posts: 14 View posts
#1
Posted by Eliteguard89: Sun. Mar 4, 2012 - 05:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I already know the answer, but I want to check.

For the ISP header on the AVR dragon I have pin 1 connected to PDI_DATA, Pin 2 connected to my target voltage which is 3.3V, Pin 5 connected PDI_CLK, and Pin 6 connected to the target ground.

The Dragon reads that the target is 3.3V, but is unable to read the Device ID. I noticed by accidentthat I had the CLK and the DATA lines backwards before. Are the PDI lines sensitive enough to cause damage if they are wired backwards or do I have some other problem?

Tags:

AVR Microcontrollers, AVR XMEGA
Top
hzrnbgy
hzrnbgy's picture
Level: Hangaround
Joined: Sat. Mar 26, 2011
Posts: 216 View posts
Location: Aloha state
Posted by hzrnbgy: Sun. Mar 4, 2012 - 04:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its the same issue I was having before, dragon PDI unable to talk to xmegaXX series properly

I read somewhere in the forum to add a series resistor to the CLK and DATA line, I don't remember exactly the values though but works like a charm for me

Top
hzrnbgy
hzrnbgy's picture
Level: Hangaround
Joined: Sat. Mar 26, 2011
Posts: 216 View posts
Location: Aloha state
Posted by hzrnbgy: Sun. Mar 4, 2012 - 04:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

unfortunately, I covered my PDI programming wires with heatshrink so I cannot look into it

Top
Eliteguard89
Eliteguard89's picture
Level: New Member
Joined: Thu. Aug 4, 2011
Posts: 14 View posts
Posted by Eliteguard89: Sun. Mar 4, 2012 - 10:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have the AVR Dragon with the mounting holes, which from I understand is the newest version. I'm surprised you need to add external components to program a chip it supports.

So I looked at some PDI documentation from Atmel and it said add a 10k pullup resistor on the clock line which I did. I updated to AVR Studio 5.1, which had an upgrade for the AVR dragon and I get this error upon reading the Device ID:

14:39:32: [ERROR] Got error setting up PDI mode: Device is not supported in this emulator mode. Debugger command setParameter failed., ModuleName: TCF (TCF command: Device:startSession failed.)
14:39:32: [ERROR] Got error setting up PDI mode: Device is not supported in this emulator mode. Debugger command setParameter failed., ModuleName: TCF (TCF command: Device:startSession failed.)
# JtagIceMkiiProtocol::assertResponse(): Device is not supported in this emulator mode. Debugger command setParameter failed.
# Got error setting up PDI mode: Device is not supported in this emulator mode. Debugger command setParameter failed.
# Got error setting up PDI mode: Device is not supported in this emulator mode. Debugger command setParameter failed.

Top
Eliteguard89
Eliteguard89's picture
Level: New Member
Joined: Thu. Aug 4, 2011
Posts: 14 View posts
Posted by Eliteguard89: Mon. Mar 5, 2012 - 01:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tried 1k Ohm in series in the CLK line and 100 Ohm, 200 Ohm, and 1k Ohm in series on the DATA line but nothing.

Starting to think I damaged the chip as it was working fine earlier.

Top
hardmanko
hardmanko's picture
Level: Rookie
Joined: Thu. Mar 8, 2012
Posts: 35 View posts
Posted by hardmanko: Thu. Mar 8, 2012 - 05:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was having essentially the same problem tonight with a 32A4U over PDI with a Dragon. I'm not sure if the reason is the same, but the symptoms were.

What worked was to buffer the clock line with a transistor. I was using an NPN (a standard 2N3904). Pull the collector to Vcc with a 10k and connect clock of the Xmega to the collector as well. Connect clock from the Dragon to the base of the transistor. Connect the emitter to ground.

Although this inverts the logic level of the clock, it worked for me, very consistently. You could also try a configuration with two transistors that doesn't invert the logic level. Data did not need to be buffered, even up to fairly long cable lengths (about 2 feet).

When I switch the data and clock wires to be intentionally wrong, once I switch back, the chip still works.

Top
ChasW
ChasW's picture
Level: Rookie
Joined: Mon. Oct 20, 2014
Posts: 23 View posts
Posted by ChasW: Fri. Sep 2, 2016 - 03:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hardmanko wrote:
I was having essentially the same problem tonight with a 32A4U over PDI with a Dragon. I'm not sure if the reason is the same, but the symptoms were. What worked was to buffer the clock line with a transistor. I was using an NPN (a standard 2N3904). Pull the collector to Vcc with a 10k and connect clock of the Xmega to the collector as well. Connect clock from the Dragon to the base of the transistor. Connect the emitter to ground. Although this inverts the logic level of the clock, it worked for me, very consistently. You could also try a configuration with two transistors that doesn't invert the logic level. Data did not need to be buffered, even up to fairly long cable lengths (about 2 feet). When I switch the data and clock wires to be intentionally wrong, once I switch back, the chip still works.
I was also getting these errors with the avr dragon connected in pdi mode to the xmega 128a4u:

 

error setting up PDI mode: Device is not supported in this emulator mode. Debugger command setParameter failed.
error setting up PDI mode: Device is not supported in this emulator mode. Debugger command setParameter failed.

 

I am running AVR Studio 6.2 SP2 and dragon firmware 7.26 for master, 7.26 for slave, and hardware version 17.

 

To just be able to get pdi working, I did the 2n3904 inverting buffer as described by hardmanko on the pdi clk line.  This seems to have consistently corrected the pdi connectivity, but with the xmega clk line connected to the collector this way, I am experiencing issues with sensitivity on the board that the transistor resides. If I put my hand anywhere near that transistor, the xmega randomly reboots- something i have to do to press buttons on the development board. If I touch that transistor, the xmega consistently reboots, so clearly this issue is with this buffer circuit. If I disconnect the clk line from the collector, stability to the system returns, but obviously pdi is disconnected and the programming and debugging interface connection is lost. Oh and I do have the supply to the 10k pull-up to the collector properly decoupled.

 

So before I dive in with a scope and time expense, I am open to any and all suggestions.

 

Does this pdi fix described in this thread work because it is buffering or because it is inverting the signal?

 

Has experienced this issue with the dragon in pdi mode and has a similar working fix?

 

Thanks in advance and sorry for reviving an old thread.

 

Last Edited: Fri. Sep 2, 2016 - 03:35 PM
Top
gchapman
gchapman's picture
Level: Raving Lunatic
Joined: Tue. Jan 9, 2007
Posts: 7946 View posts
Location: Arlington, Texas, u.S.A.
Posted by gchapman: Fri. Sep 2, 2016 - 08:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ChasW wrote:
Does this pdi fix described in this thread work because it is buffering or because it is inverting the signal?
Buffering though the 3904 might be over-driven (therefore add some resistance to its base).

PDI on Dragon has several threads here.

PDI is sensitive to skew and overshoot/undershoot/ground bounce (compare rise and fall times, keep the target cable short and likely add some resistance to the 2 PDI signals)

Dragon's logic level translator appears to be not as effective as the one in an AVRISP2.

One LUFA-based AVRISP2 has a USB megaAVR driving the PDI through some resistors (IIRC that method is described in the LUFA AVRISP2 documentation)

IIRC the Atmel AVRISP2's level translator is similar to

http://www.onsemi.com/PowerSolutions/product.do?id=NLSX4373 (NLSX4373: Level Translator, 2-Bit, 20 Mbps, Dual-Supply)

Pass NFET, 10K passive pull-up for bus hold, active pull-up for speed, fixed FET well, FET gate bias, SOIC for easy prototyping

Might try one of those for PDI.

For a given size, an NFET has better drive than a PFET.

Dragon's AVR have more than enough pull-down current; both pull currents need to be reasonably balanced (problem is it's possibly not).

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Sep 2, 2016 - 08:09 PM
Top
ChasW
ChasW's picture
Level: Rookie
Joined: Mon. Oct 20, 2014
Posts: 23 View posts
Posted by ChasW: Fri. Sep 2, 2016 - 09:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

ChasW wrote:
Does this pdi fix described in this thread work because it is buffering or because it is inverting the signal?
Buffering though the 3904 might be over-driven (therefore add some resistance to its base).

PDI on Dragon has several threads here.

PDI is sensitive to skew and overshoot/undershoot/ground bounce (compare rise and fall times, keep the target cable short and likely add some resistance to the 2 PDI signals)

Dragon's logic level translator appears to be not as effective as the one in an AVRISP2.

One LUFA-based AVRISP2 has a USB megaAVR driving the PDI through some resistors (IIRC that method is described in the LUFA AVRISP2 documentation)

IIRC the Atmel AVRISP2's level translator is similar to

http://www.onsemi.com/PowerSolutions/product.do?id=NLSX4373 (NLSX4373: Level Translator, 2-Bit, 20 Mbps, Dual-Supply)

Pass NFET, 10K passive pull-up for bus hold, active pull-up for speed, fixed FET well, FET gate bias, SOIC for easy prototyping

Might try one of those for PDI.

For a given size, an NFET has better drive than a PFET.

Dragon's AVR have more than enough pull-down current; both pull currents need to be reasonably balanced (problem is it's possibly not).

 

I put a 180 ohm resistor on the base and there is noticeable improvement. With AVR Studio loaded and the dragon connected, the MCU is stable- even with physical contact to the MCU board. With the dragon USB cable disconnected, but the PDI cable still connected is where there is minor issue remaining. With the base resistor, circuit sensitivity is reduced so I can operate switches on the MCU board now without trouble, but if I so much as touch that CLK line or so much as breath on that base resistor, the MCU reboots, again this is with the dragon unpowered, and perhaps this is normal. I am new to using PDI. Up until now it has all been ISP and JTAG, so perhaps the PDI sensitiviy is inherent and I just need to provide proper external level translation and use a scope to make sure the skew, undershoot, overshoot, and ground bounce are minimized.

 

Thank you.

Top
gchapman
gchapman's picture
Level: Raving Lunatic
Joined: Tue. Jan 9, 2007
Posts: 7946 View posts
Location: Arlington, Texas, u.S.A.
Posted by gchapman: Fri. Sep 2, 2016 - 09:22 PM (Reply to #8)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
One LUFA-based AVRISP2 has a USB megaAVR driving the PDI through some resistors ...
Though not LUFA :

Schematic

http://3.bp.blogspot.com/-Z29VWzYD6mw/UCwO6_1XhKI/AAAAAAAAAgw/nUlaM8B9FWQ/s320/usbasp_pdi_schem_33.png

From

https://ketturi.kapsi.fi/2013/05/programming-xmega-with-usbasp-avrdude/

From

Jim's Projects

Cheap USBASP knockoff programmer

http://jimlaurwilliams.org/wordpress/?p=4803

...

Update: PDI programmer and more cable stuff

...

... – the hacked avrdude/USBASP could see the XMega32A4U on the Xprotolab scope via PDI! 

...

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Sep 2, 2016 - 09:51 PM
Top
gchapman
gchapman's picture
Level: Raving Lunatic
Joined: Tue. Jan 9, 2007
Posts: 7946 View posts
Location: Arlington, Texas, u.S.A.
Posted by gchapman: Fri. Sep 2, 2016 - 09:48 PM (Reply to #9)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ChasW wrote:
I put a 180 ohm resistor on the base and there is noticeable improvement.
Way too low because there's a 10K ohm pull-up on its collector and the transistor will have current gain.

Digital (pre-biased) transistors have about 10K to 20K on the base (one R, or, Rin then Rdown).

ChasW wrote:
... but if I so much as touch that CLK line or so much as breath on that base resistor, the MCU reboots, again this is with the dragon unpowered, and perhaps this is normal.
Not normal; try adding a pull-down on the transistor's base (R in, R down, base) to keep the transistor off.

When any circuit loop impedance approaches or exceeds audio impedance (600 ohms, 1K ohms) then capacitive coupling is possible.

Try the circuit on a protoboard with a ground plane, or, a protoboard with no ground plane into a shielded case grounded to the XMEGA.

ChasW wrote:
... and I just need to provide proper external level translation ...
Likely not so proper as a megaAVR can do PDI with reasonable resistor values.

Some LUFA AVRISP2 do have a proper level translator.

If need the Dragon for a debugger then "adjust" it; else, try a third party AVRISP2.

 

"Dare to be naïve." - Buckminster Fuller

Top
ChasW
ChasW's picture
Level: Rookie
Joined: Mon. Oct 20, 2014
Posts: 23 View posts
Posted by ChasW: Sat. Sep 3, 2016 - 01:41 AM (Reply to #11)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pull-down on the transistor's base did the trick.

Thank you again!

Top
gchapman
gchapman's picture
Level: Raving Lunatic
Joined: Tue. Jan 9, 2007
Posts: 7946 View posts
Location: Arlington, Texas, u.S.A.
Posted by gchapman: Sat. Sep 3, 2016 - 05:02 AM (Reply to #12)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're welcome.

 

A subset of a Plons DragonLair might have better fit, form, and function.

A DragonLair has an octal buffer and line driver with resistors for an approximate impedance match (series termination).

Some buffer and line drivers come in 1G or 2G forms so could try one of those for the PDI clock signal (Dragon to XMEGA).

http://aplomb.nl/TechStuff/Dragon/Dragon.html (search for Lair)

via

https://community.atmel.com/users/plons-0 (a signature line in one of his posts)

http://www.onsemi.com/PowerSolutions/product.do?id=MC74VHC1G125 (MC74VHC1G125: Single Non-Inverting Buffer, 3-State)

 

"Dare to be naïve." - Buckminster Fuller

Top
Appleski
Appleski's picture
Level: New Member
Joined: Fri. Dec 10, 2010
Posts: 3 View posts
Posted by Appleski: Mon. May 1, 2017 - 01:45 PM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Same thing here, I have a Dragon and a custom XMEGA 32E5 board. I used short wires to connect both boards, but I was getting:
"Got error setting up PDI mode: Device is not supported in this emulator mode. Debugger command setParameter failed"

Adding 220ohm series resistor to CLK line fixed my problem.

Top
Caleb13
Caleb13's picture
Level: New Member
Joined: Mon. Sep 9, 2013
Posts: 6 View posts
Posted by Caleb13: Fri. Nov 3, 2017 - 02:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I run into this problem when I tried to program XMEGA-C3 kit (ATxmega384C3) with AVR Dragon over PDI interface. As Appleski suggested, connecting a 220 ohm resistor in series to CLK line resolved it. In my case, i soldered it directly to the XMEGA-C3 kit - the CLK line is nicely accessible on the bottom side of the board. I cleaned and cut the line with a scalpel and then soldered resistor in 0402 package across the cut.

 

BTW, the XMEGA-C3/Dragon combination worked fine with Dragons manufactured in 2015 and earlier. It seems Atmel/Michrochip finally succumbed to the lure of "global quality", which is really an euphemism for "letting the Chinese producer cut the costs so much it fucks up the product." Oh well, time to embrace the new normal, I guess.

Last Edited: Fri. Nov 3, 2017 - 02:07 PM
Top