I'm moving to AtmelStudio/ Eclipse programming enviroments from the good old arduino IDE.
I mostly work on Attiny chips ( 45/85 ) and as my project are getting more complex, i'm in need of something that could help me debug them. the AVR simulator included in atmel studio is quite useful but i'd like to have a tool to debug directly the chips i program.
Since i'm quite new to this enviroments ( and also to debugging, till now i relied on serial prints and flashing leds ) , i'd like to know if there are debugging instruments for this little ICs out there.
I did some googling about but i could not find anything compatible with tiny85 ( lots of for atmegas instead )
I got the dragon and, dont buy it, me and other stories I read prove that it is easy to brick. Anyway, I read a lot of stuff about debugWire and 8bit micros, it is more trouble than gain imo.
mart256:
I got the dragon and, dont buy it, me and other stories I read prove that it is easy to brick. Anyway, I read a lot of stuff about debugWire and 8bit micros, it is more trouble than gain imo.
Yeah, i read it too......my problem is that i work mostly on interfacing these ICs to other microcontrollers on I2C....and i do not know other ways to scope the behavior of these communications...
nicostak:
Yeah, i read it too......my problem is that i work mostly on interfacing these ICs to other microcontrollers on I2C....and i do not know other ways to scope the behavior of these communications...
Id use a second avr with i2c and uart, i2c connected to tiny and uart connected to pc, and then Id print serial statements according to the i2c signals. Like serial debugging.
mart256:
Id use a second avr with i2c and uart, i2c connected to tiny and uart connected to pc, and then Id print serial statements according to the i2c signals. Like serial debugging.
I acted just like this till now(firstly simulated the comm with an arduino board ) . But i need to interface Attiny with an MCU that not comes from atmel and i'm experiencing a lot of timing problems. From this the need for a hardware debugger.
Dragon is much older than Atmel ICE, doesn't do ARM, and is about the same price. There shouldn't be any reason to get a dragon...
One idea is to get at Atmel 328p Xplained Mini eval board. These are about $12 and include a debug interface. It might be possible to connect the debugger to a tiny85 instead of the on-board 328p, but ... most timing debugging should be possible using the larger chip (move the code to the tiny85 as the last step, after it's all working.)
mart256:
Anyway, I read a lot of stuff about debugWire and 8bit micros, it is more trouble than gain imo.
Anybody that makes a statement like that has never properly set up their environment to use source level debugging.
Once you use source level debugging with breakpoints and being able to look at variables, doing things like print/printf debugging will seem like stepping back into the stone age.
Many people never bother to take the time to learn how to setup and use their source level debugging tools like gdb.
The other thing that can make it difficult to impossible is that Windows sucks for doing embedded development given it lacks even basic tools like a shell, so setting things up for Windows adds yet another layer of complexity and difficulty and sometimes you just can't get there when limiting yourself to using Windows.
I have used the AVR dragon and GUI source level debugging using debugwire on Attiny45/85 and atmega328.
It is pretty cool to source level debug a tiny 8 pin part.
I used the ddd gui on top of gdb running on linux with an AVR dragon.
In fact I even rigged up setup way back on Arduino 1.0 to source level debug arduino sketches.
The mods necessary to do it for Arduino are easier on newer IDEs since the IDE as of 1.5 no longer hard codes all tools and command line options.
With Arduino, given the way the IDE works it is is a real pain to get everthing in place to start a debuging session but once set up you do sketch uploads and debugging pretty easily.
Debugwire is not particularly fast but it does work.
When using your own makefiles from the command-line you can create you own phony targets and rules to set up everything and so it is much easier to get all the tools in place and talking than when trying to get it working with Arduino sketches.
The key to source level debugging is to learn the tools and learn how to use them.
The good news is many of the basic and common tools used for embedded development like the gnu tools and make haven't changed in 30 years so once you learn them you can carry the skills with you for quite some time and the same tools are used across many different processors, so you don't have to learn new tools when switching to different processors.
westfw:
Dragon is much older than Atmel ICE, doesn't do ARM, and is about the same price. There shouldn't be any reason to get a dragon...
I would second that.
I have a dragon, and if it died today, I wouldn't buy another one. I'd get the ICE.
I bought the Dragon for the source level debugging, and ISP programming. I didn't need the high voltage programming.
Turns out that the ISP programming on the dragon is pretty slow, much slower than a $2 USBasp ISP programmer. So I only use the dragon for source level debugging and rarely for ISP or debugwire programming.
Also, you can't use a Dragon to burn a bootloader using the Arduino IDE.
This is because of a bug in avrdude. In over 6 years I've not been able to get a 6 line patch into avrdude or a small simple work around put into the IDE.
So unless you are willing to patch your avrdude code and build your own version, you won't be able to use it to burn a bootloader with the Arduino IDE.
You can use it to upload sketches using ISP or debugwire. The issue is the way the IDE burns its fuses during the bootloader update that triggers the bug in avrdude.
For me what really sucked from the beginning with the Dragon is that not only did the Dragon not come in a case, but it didn't even come with cables. I had make a case for the Dragon before I even starting using it, just to ensure I didn't accidentally fry it:
Hi, thank you all for all of this precious informations.
As Westfw and Bill suggested, i'll surely go for an Atmel-Ice. I read too many posts about fried Dragons ( as also mart256 reported). I develop timing-critical applications and get the real context of my software step by step is now very important for me.
@westfw: i've started like these , interfacing the other MCU to an arduino with serial.prints but when i switched to attiny i discovered that they're reacting a little bit different.
Is there any documentations about debugwire and how to setup it with atmel ice?
Not really That's what I meant when I said it was "very proprietary." The datasheet has some really brief explanations of the physical setup, but nothing on the actual commands (for example.) (Similarly, the AVRs that implement JTAG don't explain what it is you're supposed to SEND over the JTAG link.) Grr. I don't understand it; Atmel is pretty open with a lot of their stuff, but not AVR debugging.
The protocol on the OTHER side of the ICE is documented, I think. "AVaRice" was an Atmel JTAG ICE to GDB bridge that worked with the older products, and I think the new version uses a modified CMSIS-DAP protocol.(Rumor has it that the Atmel ICE is an EDBG chip (like on Arduino Zero) in a box. That's documented here: http://www.atmel.com/webdoc/protocoldocs/ch01s01.html
(actually, I'm not sure that there is 3rd-party software that talks to Atmel ICE yet.)
and how to setup it with atmel ice?
If you're using Atmel Studio, it's easy. It will see the ICE in the debugger setup, and you select that before your click the "debug" button(s)
If the Atmel ICE now requires using Windows and AS, then that would be an absolute non starter and deal killer for me.
After a quick google and looking around I was unable to determine if the ICE can be used on real operating systems using normal open source embedded development tools like eclipse, gdb, gnu tools etc...
So far it sounds like it is only working on Windows with AS. And also sounds like Atmel has moved in a direction that breaks avarice and makes it more difficult to get it to work again.
That is really disappointing.
That changes my entire opinion of the product as it would be nothing but a paper weight for me without being able to use it for source level debugging on linux. And no, having to use Windows in a VM does not count as that is still using Windows.
bperrybap:
If the Atmel ICE now requires using Windows and AS, then that would be an absolute non starter and deal killer for me.
After a quick google and looking around I was unable to determine if the ICE can be used on real operating systems using normal open source embedded development tools like eclipse, gdb, gnu tools etc...
So far it sounds like it is only working on Windows with AS. And also sounds like Atmel has moved in a direction that breaks avarice and makes it more difficult to get it to work again.
That is really disappointing.
That changes my entire opinion of the product as it would be nothing but a paper weight for me without being able to use it for source level debugging on linux. And no, having to use Windows in a VM does not count as that is still using Windows.
--- bill
You better get a cheap maple mini and debug it with a stlink clone, ive heard it runs on openocd.
If you ever have tried using DebugWire, you must have run into the problem of bricking your fuse settings by not regularly returning from debug mode.
The Dragon supports parallel programming which allows you resetting the fuses. A quick search about the ICE did not reveal this capability, any experience?
derVernichter:
If you ever have tried using DebugWire, you must have run into the problem of bricking your fuse settings by not regularly returning from debug mode.
In five years, I've not yet bricked an AVR to need high voltage programming.
That's what I meant when I said it was "very proprietary." The datasheet has some really brief explanations of the physical setup, but nothing on the actual commands (for example.) (Similarly, the AVRs that implement JTAG don't explain what it is you're supposed to SEND over the JTAG link.) Grr. I don't understand it; Atmel is pretty open with a lot of their stuff, but not AVR debugging.