ATMEL-ICE & STARTING DEBUGWIRE - HOW ???

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

I'd love to know if I'm the useless one or Atmel cannot supply basic information with their products.

 

I managed to work out the orientation of the 6 pin SPI plug by following wires and looking at the wiring table in the Atmel-ICE user guide. It would have been simpler if Atmel could have actually shown the locating bit of the plug in the diagrams so you know which way round the plug is.

 

Anyway, that aside, I've managed to use the Atmel-ICE to program an ATMEGA328P, using Atmel Studio 6.2 last version. 

 

When I try to start debugging (Debugging / Start Debugging and Break) I get the following message:

 

ISP on Atmel-ICE does not support debugging. Device is only programmed.

Use Start Without Debugging to avoid this message.

 

That's a lot of use Atmel. Get around a problem by doing a different task. From Google/Youtube, etc I was expecting a different error message that gave me an option of AS setting the DWEN fuse for me, but maybe that was in an earlier release of 6.2.

 

There's an option to disable Debugwire in the debugging menu, but no option to enable it. The Atmel-ICE user guide doesn't actually tell you the steps to enable the DWEN fuse, and I don't want to brick the chip. The user guide does say:

 

It is highly advised to simply let Atmel Studio handle the setting and clearing of the DWEN fuse.

 

I'd love to if the manual told me how.

 

So to enable the DWEN fuse do I go back to programming and tick the DWEN fuse box, then program again. When I simply put a tick in the DWEN box there's an exclamation mark there and when I hover over it a message pops up saying:

 

Value has been modified but not programmed

 

That's why I'm guessing I have to press program again ????????????

It's all very confusing because I though you can't program in SPI while DWEN is set, so if I program DWEN can I not reprogram to unset it.

 

EDIT:

 

I was twiddling my thumbs and thought stuff it. Ticked the DWEN fuse box and pressed PROGRAM. Now the Atmel-ICE won't even connect to the chip anymore. Tried powering the AVR board on and off but same result. Looks like my first AVR bricked.

 

When I try to start debugging I got the same message as last time, the:

 

ISP on Atmel-ICE does not support debugging. Device is only programmed.

Use Start Without Debugging to avoid this message.

 

I click OK to shut that box down then another one pops up afterwards saying the following:

 

Failed to launch program.

 

Error: Failed to start programming session before chip erase with eeprom preserve: Failed to 

enter programming mode. ispEnterProgMode: Erro status received: Got 0xc0, expected 0x00

(Command has failed to execute on the tool)

 

Keith.

Last Edited: Wed. Aug 3, 2016 - 06:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I'll skip reading all of the above....

 

( If you cannot enter into program mode it is likely that the DW fuse is already set)

 

Once your code compiles correctly simply select "Start debug and break".  HOWEVER:

 

Make sure you don't have any capacitor on the reset line.

 

Make sure that the Atmel Ice is selected as the debugger in your project.

 

Let Studio handle the setting and resetting of DWEN and FOLLOW THE INSTRUCTION. You are likely to mess things up if you fiddle with the fuses.

 

DO NOT program the chip, let the debug session handle that.

 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Yes, I would be a lot happier with box headers rather than the bare 3x2 male ISP header. Then there is no problem with inserting round the wrong way.
Most pcbs will have a square pad for pin #1 on the bottom (copper) side. Or a printed dot or 1 on the component side.

If you are using debugWIRE on a UNO, remember to open the RESET-EN solder bridge. And close it when you want to return to regular Arduino operation.

David.

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

Aah I say.

 

Thanks guys, I now see 2 potential problems.

 

#1 is I programmed the device first then tried to start debugging. So that's wrong eh ? Just build the program, then go straight to "Start debug and break". I would never have guessed that. So that means the debug session must actually program the code into the AVR automatically. I'm sure I didn't see any such instructions in the Atmel-ICE user guide.

 

#2 is I am actually using an Uno board to do this. I'll look into that RESET-EN solder bridge and anything else in the circuit. Might be better off doing this on a breadboard for now just to be sure.

 

I'm trying to "unbrick" the AVR with HV programming on my STK500, then I find out it isn't being recognised in Atmel Studio 6.2 (it worked before). Later on I tried AVR Studio 4.19 and I can get my STK500 to show up so seems there's some problem with AS 6.2

 

Cheers,

 

Keith.

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

If you do not open the RESET-EN bridge,   debugWIRE cannot possibly work.    The open/close of a solder-bridge is very easy to do.

 

When you have obeyed the rules,   debugWIRE works amazingly well.    Think about it.    You have got debugging "for free".   All other debug interfaces use up GPIO pins.

 

Yes,  once enabled,   you simply  "Start debug and break" for each iteration of the edit-debug-test cycle.

 

David.

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

david.prentice wrote:

If you do not open the RESET-EN bridge,   debugWIRE cannot possibly work.    The open/close of a solder-bridge is very easy to do.

 

When you have obeyed the rules,   debugWIRE works amazingly well.    Think about it.    You have got debugging "for free".   All other debug interfaces use up GPIO pins.

 

Yes,  once enabled,   you simply  "Start debug and break" for each iteration of the edit-debug-test cycle.

 

David.

 

I seen the 10K pullup in the Uno schematic and thought the debugwire would simply pull that low, like what happens in many circuits. If that's not the case I didn't know.

 

I've got no problems with the opening/closing of a solder bridge. I design my own circuit boards, cnc drill them on my self built cnc plasma table, then solder all the components in. So I'm certainly not frightened of opening up a solder bridge. Especially easy with my Hakko 808

 

How can I obey rules if I don't know what they are in the first place. That's what I said in my first post, the lack of clear instructions on HOW. Instead I have to try and guess at what to do.

 

Your statement is also implying I'm complaining about the debugwire system when I'm complaining about Atmel not giving clear instructions on how to use it. I'm not the only one who goes through confusion with this one. I bought the Atmel-ICE mainly for the debugging and I'll be extremely happy and excited when I get it working. I don't need to think about it, already did that before I bought it, and ended up thinking that will be awesome.

 

Keith.

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

Just to clarify: DW uses the Reset pin for communications therefore a capacitor on the rest pin will kill the comms.

 

Opening up the solder bridge removes the rest cap from the circuit and DW can now be used.

 

REMEMBER!! Whenever you finish with debug, in 5 minutes, 5 days or 5 years EXIT DW from within a debug session to get normal programming functionality back.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I would agree that documentation is not always easy to find.   This should get you started: http://www.atmel.com/webdoc/atmelice/atmelice.special_considerations_debugwire.html

 

In practice,   open RESET-EN,   remove BOOTRST fuse,  Select debugWIRE in your AS7 project.

 

Then follow any prompts and obey the instructions.

 

Yes,   debugWIRE is slower and less powerful than JTAG.    But hey-ho,   it does not use any GPIO lines.

If you have experience with JTAG, PDI, SWD, ... you will find that debugWIRE gives the same environment.  

 

If you have a problem,   just ask.

 

It is difficult to judge people's technical knowledge.     If you give the information,   you will get the appropriate response.

There a lot of people that do not even know what a capacitor is.    And many M.Sc students that do not know Ohms Law.

 

David.

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

A big thank you to you all.

 

I'm confident I'll crack this when I get back to it with the new knowledge you guys have gave me and a video/tutorial or two I've come across. I wish I didn't have to go out to work today because I'm itching to test my code on chip.

 

I was angry and frustrated yesterday. I'd been at this little project 3 days sitting at the computer (headache + aching neck & arse) fixing coding issues then finally wanted to test my new Atmel-ICE toy and have my very first go at debugwire. It's for a project close to my heart and something I HOPE I can later make a buck on.

 

John, I went and looked at the Uno data sheet again and seen the capacitor. My board is a clone so I don't even know if it's a little different from the schematic I have, so I think I'll do things in the STK500 and hook the Atmel-ICE up to that (and disconnect the STK500 reset link).

 

Thanks for that link Dave, I've put that info in a Word file. 

 

And oh yes I got my STK500 working with AS 6.2 Had to go to "Available Tools" right click, "Add Tool" and there it was waiting for me to select it.

 

Getting there LOL.

 

Keith.

 

 

Last Edited: Wed. Dec 16, 2015 - 05:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Uno clones with the monster USB socket generally have a nice RESET-EN solder bridge.
The new clones with a micro USB socket do not seem to have the official pads.
OTOH, these clones have holes for extra male headers which makes them brilliant for prototyping.
You have to cut the DTR capacitor track manually.
David.

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

Everyone above talks about hardware stuff. The error message

Quote:
ISP on Atmel-ICE does not support debugging.

seems to suggest that while you have selected (in the project properties, Tool tab) the correct tool (Atmel-ICE) you have then selected the wrong interface, "ISP". What happens if you actually select debugWire in that combo?

 

(Sorry, my Atmel-ICE is buried deep inside some cupboard ATM or I would have supplied a few screen-shots.)

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]

Last Edited: Wed. Dec 16, 2015 - 09:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The clone I was using is a "DK" type from China, it doesn't seem to have any RESET-EN and not sure where that cap will be. The other one is a FREETRONICS brand and it has it clearly labelled. Might get a board to dedicate to this programming / debugging task.

 

Just managed to reset the DWEN fuse with high voltage programming on the oldie STK500. I now have a new love for that old board. I stuffed up my previous attempts to do that because I didn't have a single wire connector in place BSEL2 to PC2. One ATMEGA unbricked.

 

John you are dead right. Amongst the other things I was doing wrong that was one of them. 

 

Time to attempt debugwire again.

 

Keith.

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

I suggest that you just dedicate a cheap clone for debugWIRE. Do your development on this.
When fully debugged, run the code on a regular Arduino.
Regarding clone brands. Compare the pcb traces with the official Arduino schematics. Wield your knife or soldering iron as appropriate. Since the clones are so cheap, cutting a trace is no big deal. Solder bridges are easier.

David.

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

Cheers Dave,

 

I'll do that, plenty of them on Ebay.

 

John, any reason why you don't use the Atmel-ICE (buried deep inside some cupboard). Do you have some other preferred debugger ?

 

Well, success, got debugwire working (YIPPEE), AND..........

 

Failure.

The breakpoints which work perfect in the simulator don't work the same in debugwire.

 

I've got two Timer 2 interrups, one for compare and one for overflow. I have breakpoints at the first line of code in each ISR. The code stops at the compare ISR but not at the overflow ISR. I tried to find some info and am wondering if I need to do run to cursor instead of setting breakpoints the same as the simulator.

 

I'll continure debugging the debugger when I get in from work tonight. I see there's also a tickbox for halting the timer when code is stopped. I'll have to play with that one too.

 

Keith.

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

ICE-in-cupboard: No AVR activity for me this autumn (except here).

What?

Work.

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

Well well well, look what I found, exactly the same problem:

 

https://www.avrfreaks.net/forum/ice-mega328-breakpoint-isr-not-being-hit?skey=debugwire

 

Hopefully that's where my problem lies (bug in the debugger LOL ???).

 

Thanks again lads,

 

Keith.

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

As far as I know, there is no problem with the debugger.
Note that you must ensure that you write code where a breakpoint can be placed. i.e. the code has not been removed by the Optimiser.

If you have a problem, attach a ZIP of your AS7 project to your post.
Then someone might attempt to reproduce it on their own hardware.

David.

Last Edited: Fri. Dec 18, 2015 - 09:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks David,

 

good point about code being optimised out. I'm still trying to get that one concreted in my head.

 

This particular code could not have been optimised out:

ISR (TIMER2_OVF_vect)
  {
	T2_OVERFLOW = TRUE;
  }  

FALSE is 0 (zero) and TRUE is 1

 

T2_OVERFLOW is FALSE before this ISR so the compiler can't get rid of that instruction.

 

The code works perfectly in the simulator and I have a watch window for the T2_OVERFLOW variable, and see it change from 0 to 1 after the T2_OVERFLOW = TRUE instruction

 

In the other thread I think the guy had the very same debugwire problem (timer OF interrupt ISR) and he put the breakpoint at the "{" before, and everything worked.

 

I've just got out of bed and will try it after brekky.

 

Keith.

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

T2_OVERFLOW must be volatile for main() to see it.

I am not aware of any breakpoint problem in hardware or debugger software.

It sounds as if you have discovered an Internet myth.

David.

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

Hello All, 

 

I guess I am just going to add to the Chaotic discussion above. But I have an issue for which I request you help: 

 

1. I have a ICSP header on a generic Nano

2. I connected the ICE to this header and powered on and programmed and then went into debug mode 

3. The AS7 asked if I would like to enable DWEN etc to debug (Debug tool is set correctly). 

4. Apparently the DWEN got set and then the µController can not be spoken to any more. 

 

I have tried all, but there is no way to get back into the device. I dont have a high voltage programmer. What should I do ? 

I have already bricked 2 boards. 

 

Regards

 

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

@xxin

See post#2 above

 

David (aka frog_jr)

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

I have now scratched out the copper trace connecting pin 29 (reset) on the Nano Board and still nothing happened. 

 

I have already bricked 4 other boards trying all kinds of combinatios. 

 

I have another UNO board which has not capacitor on the reset pin, still no change ! 

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

 

And every time the DWEN has been enabled on the board, it shows this ? 

Very disappointing ATMEL ! 

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

Xxin wrote:
Very disappointing ATMEL !

NO!  debugWire works very reliably when you set your hardware up properly.  If you search the threads here on the subject you will find that the majority of the time the problem is in the hardware setup.  The other times the software is not configured by the user, or there is a driver conflict.

 

Since you have decided to open another thread I am going to lock this one.

 

Jim - Moderator

 

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

Topic locked