Unable to program after failed to debug with Dragon

I use the ATMEL Dragon to program the 3pi over ISP. That work(ed) great.

I tried to debug my program on the target (never done that before).
When I tried to connect, It gave some message about changing some settings about DebugWire
(unfortunately I forgot the exact message).
It then failed to detect the device (device ID 0xffff).

Now I am unable to program it anymore.
It fails to read the signature.

Did I just lobotomize the robot?
Can it be restored ?

is it possible to debug programs on the target with the Pololu USB AVR programmer ?

Could this happen with the Pololu USB AVR programmer ?

Can this problem be fixed with a Pololu USB AVR programmer ?

Ben’s post here might be helpful to you. He says:


Do I understand it correctly that when I remove the capacitor that connects pin29 (PC6) to ground,
I can access the 3pi via debugWire ?

According to the schematic, this capacitor is C26. Is this correct ?
Where is this capacitor on the board ?

Can I program the 3pi via debugWire, or do I need to switch back to ISP for this ?
if so, which fuse bit does this ?

Will I ever need to put this capacitor back in or can it stay removed ?


Hello Jef.

debugWire requires that there be no capacitance on the reset line, so you will need to remove capacitor C26:

This capacitor is not necessary for operation of the board and does not need to be replaced.

You can program your 3pi and configure its fuses via the debugWire interface if you have a programmer that supports debugWire. Your AVR Dragon is such a programmer; our Orangutan USB programmer and Pololu AVR programmers do not support debugWire.

The fuse that determines whether debugWire is enabled is the DWEN fuse. Once debugWire is enabled, the the reset line no longer functions as a reset line, which means that standard ISP programming will no longer work, and the only way to restore ISP programmability is via the debugWire interface.

- Ben

I removed the capacitor as described.

After some troubled attempts, I was able to start a debugging session.
that allowed me to activate the AVR Dragon dialog through menu Debug | AVR Dragon options.

On the “connection” tab, I clicked button “Disable debugWire”.

This caused the 3pi to shut down (lights out, left wheel stop spinning).
I then get a message: “Failed to enter SPI mode.debugWire fuse was not disabled.”

After that I am unable to start debugging anymore. Each time I try, the 3pi shuts down and I get the message: “Failed to enter stop mode. Unable to continue debugging.”

SPI still doesn’t work.

Is this because the 3pi always shuts down during changing the fuse bits ?
I did put new batteries in.

That doesn’t sound good. The 3pi shouldn’t shut down when you change the fuse bits. Are you using alkaline batteries or rechargeable ones? If the latter, are they freshly charged? Can you describe all of the connections you have to your 3pi while you’re doing this?

- Ben

I am using regular fresh alkaline batteries.
It has always shut down after anything changed.
It was not a problem when I programmed the 3pi, but everything went bad after I tried to debug it (i.e. the Dragon changed the fuse bits).
The Dragon probably isn’t the best to use on the 3pi (the wheels keep spinning when connected).
If I get this fixed, I am planning to buy the Pololu USB programmer.

Is it possible that I sent the robot in so that you can have a look at it ?
If you want, I can include the Dragon with it so that you can witness it yourself (please return it together with 3pi).

What would the charge be for this ?
Is it possible I can pay for the S&H and purchase of Pololu USB programmer in a single credit card transaction over the phone ?

about the connections, the only thing connected to it is the 6-wire ISP connector from the ATMEL Dragon. The 3pi runs on its own batteries. No other mod or peripheral.


You can send the 3pi back to us to take a look at (please don’t include your AVR Dragon); the 3pi shouldn’t shut down after programming. I’m not sure what would cause this, although I know that the AVR Dragon uses the poor practice of always driving its ISP outputs (this is why the 3pi’s left wheel spins while the dragon is plugged into the ISP header), which could cause unintended shorts if the AVR it’s connected to is also driving those pins. In general, an AVR programmer should only drive the pins after it has asserted the AVR’s reset so that it can be sure that the AVR isn’t trying to use those pins in a conflicting way. If you want to use debugWire in the future, I suggest you only connect the reset pin from your dragon to the 3pi, not the entire ISP header.

Please contact me directly at ben at pololu dot com to obtain an RMA number. There isn’t any charge for us to take a look at your 3pi (and repair it if possible).

- Ben

another question:
would AVR JTAGICE mkII, be a better programmer/debugger than the AVR Dragon ?

Probably, if only because I don’t think it drives the programming lines while not asserting the AVR’s reset. I haven’t really used either extensively, and I don’t have any experience debugging with the JTAGICE mkII, so I can’t give you much of a recommendation.

- Ben

I responded to your email for an RMA number.