Hello everybody, after a lot of reading and researching the net, I went ahead and ordered an Atmel Ice Basic for $90 thinking it would allow me to have real debugging, single stepping, variable watch, etc. on Atmel 8-bit parts. I've used JTAG ICE in past projects on Mega1284 parts and it was pretty decent, so I was hoping for similar capability, but I'm finding the Atmel ICE with debugWire is not so great.
I spent the last 4 days trying to get somewhere with this device and it's been nothing but frustration. If there are any satisfied users out there I apologize in advance, as my post is not intended to incite. I just need to vent a little after all the time I spent to learn that the Atmel ICE is no better than a $10 Atmega Xplained Mini board in terms of debug capability. If I'm off base on any of what I'm about to say please let me know what I'm doing wrong, I'm willing to be be shown the way.
First off, Atmel's literature portrays the Atmel ICE as a fantastic device capable of all sorts of debugging and programming tasks. JTAG, PDI, aWire, UPDI, SWD, TPI, hardware breakpoints, software breakpoints,......whew! looks good huh? Except the debugWire system (used on the mega328P arduino) is not that great. If you're debugging a simple Blink LED program it works fine, but anything beyond that is an exercise in futility. I'll give my example to illustrate.
I have an Atmega328P on an Arduino Nano board connected to a nRF24L01 wireless transceiver, a temperature/humidity sensor, some switches, LED's, and analog inputs. So I grab my new ICE and connect it to the 6-pin ISP header on the Nano and get ready to really get into the code.
Problem #1 : The Atmega328P uses debugWire to do debugging (Reset line) and the rest of the ISP pins for ICE programming. But the Reset line cannot have any capacitors hanging on it and any pullup resistors have to be greater than 10K ohm. So, cut traces on the Nano board to release the DTR capacitor (used for auto-programming via Arduino bootloader), and remove the 1K ohm pullup and replace with 10K ohm. Problem solved. Great, you can now use the ICE to upload code and get the chip into debugWire mode. BUT, to get into debug mode, Atmel Studio first uploads your code and then has to prompt you to enable debugWire. You have to answer OK, and then you're told you have to remove/replace power to the target, at which point debugging can begin. Note, if you want to go back to bootloader programming as in the Aruino IDE, you have to reconnect the DTR capacitor. You can get used to this cycle as a small price to pay to get real debugging right?
Problem #2 : Wrong! Of course, once you've entered debug mode you can't just place breakpoints anywhere you wish. Some lines just won't allow a breakpoint to be set (even with compiler Optimization turned completely off). It's rather annoying not knowing where you can place a breakpoint and where you can't. So set one or two where you can. Now try to single step through the code. Nope, can't always do it! Sometimes you can, and sometimes it jumps into assembly code (even though you pressed Step-Over, not Step-Into). Try to press Step-Out, which should take you back to where it called from, but nope, this doesn't always work either. Sometimes you try to Step-Out and the code just keeps running as if you pressed Run. The setting, single-stepping, and stepping out of code is very unpredictable at best. A lot of the time, I would set a breakpoint on some function and press Debug-Run, but the breakpoint never gets reached, or never stops there for some unknown reason. Worse yet, if you press the Stop button and try to resume debugging again, Atmel Studio will recompile and you get debugWire failure messages. This happens because you're in debugWire mode, but stopping or making a change requires a re-compile. Atmel Studio dutifully tries to upload your modified code BUT you're in debugWire enabled mode remember?, meaning SPI won't work, so can't upload and you get a different fail message. Nice, huh? Even worse than that, you now try to Exit debugWire and Close (which is the recommended method when you're done debugging so you don't brick the chip) and find a new message telling you it couldn't exit debugWire mode. And you can't program the chip through the SPI pins either until debugWire is closed. The only way out of this is to try to use the Attach to Target button. If you're lucky it will reconnect through debugWire to the target, and then you can try again to Exit debugWire the proper way. This cycle of writing code, set breakpoints, start debug, enable debugWire mode, do your limited debugging, exit debugWire mode, make changes, re-compile, and start over again is a big PITA, and takes a couple of minutes each time.
Problem #3 : Okay, so maybe a lot of my complaints stem from the fact that it's an Arduino Nano, and the 328P chip only offers debugWire debug mode. But there are still a few things attributable to the Atmel ICE. Want to examine variables when the program breaks? Well, that depends on the variables. Some simple types do seem to be available to view and even modify. But I also found quite a few that said "unsupported" or "unknown identifier" and these could not be seen or added to the watch window. Most C pointers were visible though. Then there's the fact that the ICE itself could get into some infinite loop once in a while, with it's orange LED flickering away and no breakpoints hitting. The only cure was to unplug the USB cable to the ICE and try to Attach to Target again. A different issue that took me a while to catch (dumb me) was that the nRF24L01 module used the same SPI interface pins as the ICE, which led to strange crashes. I changed the nRF24L01 connections to a software SPI on different pins and the crashes went away. One other issue, in my code, I ask the user to press a reset button at a certain point when initializing the program. That's a big no-no, the debugWire interface is the Reset line, so you can't ground it through a switch to reset the chip!
After dealing with these quirks for a couple of days, I could almost get to the point of doing some productive debugging. However, it was now NO better than what can be done with a $10 Atmega328P Xplained Mini board. And the Xplained Mini board somehow magically handles the switching between debugWire and SPI programming seamlessly (or maybe it use the debugWire interface to upload the code?), but at any rate it dispenses with all the enable/disable pop-up windows found when using the ICE. For this chip(Atmega328P) and the debugWire method of debugging, the $90 Atmel ICE has no advantage over the $10 board. Maybe the ICE is more powerful and stable with JTAG debugging. I don't have any parts to test that out.
One last thing, when uploading the code to the chip after pressing Debug-Run, the Atmel ICE is very slow when flashing the chip. My program compiled to around 22 Kbytes, and it took about 50 seconds to upload. Add in the time for answering the debugWire enable prompts, and for disconnecting/reconnected power to the target, then exiting debugWire, etc. and your debug-modify cycle time is closing in on two minutes whenever you change something. Ugh....
Has anyone else had a GOOD experience with the Atmel ICE? I'd like to know if maybe I'm not following the right procedure, or if I'm doing something incorrectly. Or maybe the debugWire sysatem is just a POS. It's been a few years since I worked with the JTAG ICE, but I recall that went very smoothly and had hardly any of the problems that I encountered with the current Atmel ICE. Could be that JTAG offers a much better experience.
Thoughts or questions would be welcome. Am I expecting too much? I'd like to "like" this ICE unit, but from what I've seen so far it's not very promising.
-Tony
)
