Atmel-ICE Failed to Enable DW

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I am not sure if this should be in the AS forum or Tools. I am trying to do some debugging with my Atmel ICE with my Arduino UNO, but having little success. I get this error after I toggle the target power. Since its an UNO, by toggle I disconnect the USB and reconnect.

 

Failed to enable DW : Failed to enter programming mode, ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool)

 

Steps to recreate

  1. Click Debug>Start debugging and break
  2. I get this message
  3. Click Yes. This will set the dwen fuse on the UNO
  4. I get a message to toggle the power on the target... I do and click OK
  5. I get this error:

So, I know from experience that dwen is set. So I need to reenter debug mode to disable, but it won't let me (I get the error). So I connect the chip to my Dragon and can enter debug and disable. So what am I doing wrong where I cant debug on the Atmel ICE?

 

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you opened the RESET-EN solder-bridge ?

 

debugWIRE should work fairly painlessly.

When it asks to cycle power,   this means unplugging the UNO and the ATMEL-ICE.

 

When you cycle power after enabling with SPI,  it re-starts in debugWIRE.

When you "disable debugWIRE",    you do not cycle power.

 

Even if you get a bad message,   just cycle power and try Debug session again.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Have you opened the RESET-EN solder-bridge ?

I think my issue is the RESET-EN. I saw your answer here.  When I set up my UNO on a bread board, it works. So to opened the RESET-EN solder-bridge, I need to remove the solder connection. Would have been nice to have a jumper :). Nevertheless, David, I owe you a pint some day. Thank you.

I might put up a YouTube video. The debug process is not very intuitive and many hobbyist jumping from Arduino IDE to Atmel ICE, may benefit from it.

 

<<RANT AHEAD>>

So I own an STK500, AVR Dragon and now a Atmel ICE. I spend my spare time fiddling and reading AVR (and now the SAMD21). Each one of these programmers and/or debuggers has something the other one doesn't. For example the STK500 has the DIPS and prototyping area, but doesn't debug. The AVR dragon has a single prototyping area, nice but a pain when working on multiple projects.  The Dragon can do HVPP, where neither the STK500 and Atmel ICE can not. **Sigh**

<<END RANT>>

 

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Dragon can do HVPP, where neither the STK500 and Atmel ICE can not. **Sigh**

INCORRECT!!!!

The STK500 certainly CAN do HVPP.  I used to use that feature all the time.

 

Saved my pants every time.

 

Understand each device was built for different reasons.  The STK500 is very old in the development world, and the letters STK stand for STARTER KIT.  The newer STK600 is far more versatile as far as devices supported, yet also does not offer debugging per se.

 

The Dragon was somewhat of an in-between of an STK(the HVPP capability) and debugging, but is rather fragile.

 

The Atmel ICE is designed to be compact, and able to service a wide range of devices.

 

JIm

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Sun. Jan 3, 2016 - 02:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go on.   The ATMEL-ICE is excellent.    My only criticism is the tiny 5x2 headers and delicate ribbon.

 

The solder-bridge is not difficult to use.

Just think of the grief that the Arduino designers would have got from punters that "lost" their jumper.

 

From memory,   you remove some solder and cut the bridge first time.   Subsequent open and close is done with the soldering iron.

I suppose that a 2-pin header could have a copper trace to cut.

 

I note that the Chinese "Yellow" clones omit the RESET-EN pads.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PhillyNJ wrote:
Each one of these programmers and/or debuggers has something the other one doesn't.

Yes. If they all where identical it would be strange, wouldn't it...?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
INCORRECT!!!! The STK500 certainly CAN do HVPP. I used to use that feature all the time.

My my, I never knew. surprise- Thanks. Now I need to try it :).

 

david.prentice wrote:
From memory, you remove some solder and cut the bridge first time. Subsequent open and close is done with the soldering iron.

 

I might opt for throwing the chip on a bread broad and having a "slave UNO" ready to debug always. I am not a fan of modding the board. Even though its a $6 USD clone, I can't bring my self to doing it. For some dumb reason, I am afraid of damaging the board. The irony is that's its only $6 USD!. I can easily buy more at my local Micro Center. I digress... This will work for my UNO's but my Mega (as you know) is SMD. I picked up a nice Inland Clone for $9.99 USD a while back. Might be my "slave mega" sacrificial lamb... only used for debugging.

 

 

"When all else fails, read the directions"

Last Edited: Sun. Jan 3, 2016 - 02:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can enable JTAG on a MEGA2560.    No soldering iron required.    However,  the Arduino does not expect to lose the A4-A7 pins.

 

Unfortunately,   most of my shields use the A4 pin.   So this rules out JTAG.

 

Seriously,   you can use debugWIRE on the UNO even with Shields in place.

Either leave a clone in permanent debugWIRE or buy a XMINI-mega328P and solder the Arduino headers.

In practice,   I just bootload and seldom use the hardware debug.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the thread and the replies, I had the same issue and was in hair pulling mode for quite a bit!

 

I am programming a cheap Uno R3 clone and had the same problem and my board doesn't the reset solder bridge. I figured I'd bricked the microcontroller but continued to pursue the problem.  After reading this Atmel article http://www.atmel.com/webdoc/atmelice/atmelice.special_considerations_debugwire.html and checking the Uno schematic I found that my board's C5 capacitor is not linked to the reset line but one labeled C8 was....

 

I removed it and hey presto, it worked! I can now not only use it again but I can debug it too.

 

I'm sure this reply isn't of any use to the contributors of this thread but to others that fall foul to this I hope it is.

 

So if you encounter this problem I would suggest you:

  • Follow the trace from pin 13 (PD7) of the secondary microcontroller (ATMEGA32U2) to an SMD capacitor
  • Remove this capacitor (mine was labelled C8)
  • Bear in mind that when debugging code that has been optimized by the compiler you will get some apparently strange behaviour and often breakpoints will not work

 

This is my first serious bit of debugging using debugWIRE so I don't know how big of an issue that last point is but I'm sure it causes people plenty of confusion.

 

Thanks guys.

 

 

Avrisp mk ii
Xplained Atxmega128A1
ATTiny13, Mega328, Mega8 etc.
Pololu USB AVR Programmer
Open Workbench Logic Sniffer
AVR Studio 4 & 5

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had the same problem with a custom board with a ATMega168 and ATMEL-ICE. Just a 39K pullup on the reset no cap. And, by the way, this board had worked previously. This is how I fixed it.

In AtmelStudio(6.2) go to device programing, connect with ISP and erase the chip. After this debug was able to set the DWEN fuse. My guess is that my program, that was running on the chip, uses the SPI interface and that was preventing debug from setting the fuse.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In order for the ICE to set the debugwire interface it asserts RESET to program the fuse which stops the application as far as I know, so I do not see how erasing the AVR fixes this.  But HEY, if it worked it worked

 

Jim

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, I read all you posted and still after doing what you said it didn't work for me... this is my case:

 

I programmed the arduino uno a few times via SPI (already cut the reset-en pad), then did some debugging with the debug wire mode enabled, after that I don't know what happened that I couldn't check the "disableDebugWire and close". So now I am with my microcontroler completly unusable... Is there any way this could be fixed without buying a HVP?, I cannot enter neither debuggind or spi... thanks.

Victor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well it kind of has to be in one mode or the other. If it won't respond to ISP it must be in DWEN mode. Or id it won't respond to debug (and close) then it must already be in ISP mode.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Well it kind of has to be in one mode or the other.

True, but other causes for not responding are also possible, no target power, no clock signal due to fuse mangling, etc....

 

IIRC, getting into/out of DW mode requires power cycling of the target AVR.....

 

OP, try cycling power and then attempt ISP code loading and/or entering debug mode then disableDW and close one more time.

 

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
True, but other causes for not responding are also possible, no target power, no clock signal due to fuse mangling, etc....
Except he said that it was happily switching back and forth previously which presumably suggests all those things are OK? I suppose if he's been off on a fuse setting adventure he might have damaged something - like RSTDISBL?

 

Of course it might just be a wire that's come loose or a dry joint that broke or a break in a PCB track or something I guess?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Of course it might just be a wire that's come loose

Another likely cause, the burden is on the OP at this point, to solve or post a picture of his setup for us to help further! 

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I Solved it, this is what happened and what I did:

 

I builded up a circuit for HVP based on the datasheet of the ATMEGA 328P and made a programm for excecuting on a working microcontroler to re-programm the "bad" one fuses. It worked, I read the high byte fuses settings and both the DWIEN and SPI where enabled, and I know it shouldn't be like that, as you said it could be either in one mode (spi) or the other (dw), so instead of trying to find why it happened I simply burned the fuses as default and it ended up solving it, didn't take me so much, strange, but I learned that it can happen. So the only solution for this "extreme" case was to use the HVP, I could solve this problem many times before by just starting a debug session and then disabling it, but well stuff happens. Thanks for your support.

Victor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No.   When you are in debugWIRE mode,   the SPIEN fuse is not disabled.     Just read the fuses from a program running in debugWIRE mode.

 

You just have to follow the documented sequence for entering debugWIRE mode,  leaving debugWIRE mode.

 

There is no need to build any HVPP programmer.     Just follow the correct sequences.

 

Anyway,   I am pleased that you have got everything working for you.    Study the docs.    You will understand how it changes mode and why you need the correct sequence.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I followed the correct sequences many other times for solving this problem before and always worked, I followed the same steps showed by an Atmel Engineer I followed before and didn't work as it use to,  that's why I posted again... this time was different I swear!

Thanks again.

Victor

Last Edited: Fri. Aug 10, 2018 - 04:54 PM