Atmel AVR debugging

[slateraptor]

So the question for AVR developers out there: How do you debug your code? AVR Dragon perhaps? Some other affordable third-party tool?

[nessatse]

Serial port and terminal, or if timing is tight, oscilloscope, beats any debugger imo.   In all the years I have been doing software development (embedded and other), I have never really found a debugger a necessity.  (possibly because I am too much of a cheapskate to invest in one also).    For the AVR, the closest I have come is occasionally single stepping code in the simulator in AVR Studio.

[mikeselectricstuff]

Serial port and terminal, or if timing is tight, oscilloscope, beats any debugger imo.   In all the years I have been doing software development (embedded and other), I have never really found a debugger a necessity.  (possibly because I am too much of a cheapskate to invest in one also).    For the AVR, the closest I have come is occasionally single stepping code in the simulator in AVR Studio.

It depends very much on what you're debugging - sometimes the ability to break and dump internal state can be pretty essential, other times a scope and/or external data dump/analyse facility is more useful. Neither is a substitute for the other.

[nessatse]

It depends very much on what you're debugging - sometimes the ability to break and dump internal state can be pretty essential,

I'll concede on that.  There are definitely times when a debugger would make  life significantly simpler, but there are always workarounds, even if that involves nothing more than a good night's sleep 

[Gall]

Mostly no debugging at all. I use some special C++ techniques that almost guarantee working code immediately after compiling.

I check some algorithms by compiling the same code for x86 sometimes.

[cybergibbons]

The state of AVR debugging is a mess - it's really hard to work out which bits of kit work and which don't. It's only compounded by the fact that actual AVR kit and software often don't work either.

That said, I've not yet found the need for it on any of the 8-bit AVR micros. The processor is simple, the interrupt handling is fairly transparent, the peripherals are also basic. Using the serial output is normally fine for most issues (excepting timing, and watch out for println not representing data as you expect), then you often have LEDs (4 LEDs can show so much information!) and finally, for timing issues, you can put a scope or logic analyser on an output.

[Psi]

Yeah, I just used the serial port to write any data out that i want to inspect.
Or, if it's more time critical, i use one or two digital outputs connected to the scope. One digital output can provide information on two separate events by either toggling or pulsing in code. (either you get a rise/fall edge or a short pulse)
So with a two channel scope you can view 4 events and their relationships.

[McMonster]

One of the main reasons I've pushed myself into ARMs earlier than I planned is the half-assed debugging possibility on AVRs. Sadly, this is a great microcontroller family but Atmel does not give a damn about it. I never really needed debugging so far but the more projects I do the more I feel I'll need it someday.

I've recently started an AVR project with quite complex software part and I know I'm going to implement debugging capability in software, but I fear it may not be enough. I've also started using splint (C code analysis tool that scans the code for possible bugs and problems), which by the way made me realize I'm a crippled programmer after 4 years of Java. I've written a complete circular linked list module for AVR before realizing there's no garbage collector in C. It would be a major pain in the ass to figure out why my code doesn't work without splint.

[slateraptor]

Thanks for all the input.

I was fully aware of Atmel's development offerings and limitations, but seeing as how I'm not hip with the die-hard AVR fanatics, I wasn't sure if there was something out there that I didn't know about; standard debugging techniques go without saying. The question just kind of popped into mind because I've recently acquired a proper JTAGICE mkII unit, and despite the fact that it seems like everyone and their mother has developed an Atmel uC these days, I simply found it difficult to believe that most anyone less than serious would be willing to drop that kind of $$$ on such a dedicated dev tool. Not having one at my disposal in the past has really only served to deter me from developing Atmel uC's with as much confidence as, say, an MSP430 + FET430UIF. As an aside, the size of the unit alone has caught me completely off guard...didn't realize just how BIG the damn this is!

the ability to break and dump internal state

Exactly why I refuse to dabble (unless absolutely necessary) without a proper debugger.

I've written a complete circular linked list module for AVR before realizing there's no garbage collector in C.

I feel like every time a Java coder mentions his beloved garbage collector, a bastard child is born into this world out of negligence.

[McMonster]

I've written a complete circular linked list module for AVR before realizing there's no garbage collector in C.

I feel like every time a Java coder mentions his beloved garbage collector, a bastard child is born into this world out of negligence.

I never loved it, I just always had it for last 4 years. I'm starting to recover, but a few initial runs of splint made me feel sad and lonely.

[mikeselectricstuff]

Not used it in a while, but I've found that JTAG ICE Mk.II works very well under IAR's embedded workbench - far less flaky than under AVR Studio.

Debugwire is a pretty neat system - AFAIK the only debug system that doesn't use either any IO pins or chip resources. It's a minor fiddle enabling and disabling it, but as long as you keep connections short and well grounded it works very well.   

[amspire]

I love the hardware debuggers - in theory anyway. In practice, my micro project usually is full of interrupt routines for clocks, and to get real time interaction with its environment. In many of my projects, the micro is spending over half its processing time in interrupts.

Basically interrupts and hardware debugging just do not work together well at all. At best, you set up a break point, and once the break point is triggered, you can look at some registers, but you then have to restart the micro anyway as the interrupt handling will be screwed. Just about everything a hardware debugger can do, I can do using debug statements in code, writing debug info to a LCD screen if there is one, and using the serial port for dumping bytes. With my own debug statements, the only resources the micro needs to assign to debugging are the resources I choose to give to debugging.

If I am stuck, then I will probably have to go to an emulator to be able to single step the code, but setting up an emulator can be hard work, particularly when you have to set up files to simulate the real time inputs on pins and an emulators does not show a display on the LCD screen, set the voltage on an external DAC, etc.

I would think a hardware debugger is great when you are learning to program and you are not sure how parts of the micro are actually working, but you get past that stage quickly.  Then I just find it is just not much use.

If your task happens to do a mass of complex processing without needing interrupts, then yes - hardware debugging would be great. That is just not the kind of project I find myself doing.

Richard.

[nessatse]

Here is a really cool add-on for AVR Studio 4 - http://www.helmix.at/hapsim/.  It interfaces with the simulator and emulates standard character LCD's as well as buttons, LED's and the AVR UART.

[slateraptor]

Here is a really cool add-on for AVR Studio 4 - http://www.helmix.at/hapsim/.  It interfaces with the simulator and emulates standard character LCD's as well as buttons, LED's and the AVR UART.

Thanks but no thanks as a matter of principle. Either way, the add-on appears to be rather basic.

I'm of the opinion that high-level abstractions like said add-on create more problems than they actually solve, and they definitely don't do someone in a learning phase any favors. It's enough that high-level functions like println() mentioned below tell you absolutely nothing about the assumed protocol or efficiency of data being transmitted, let alone satisfying timing requirements or even understanding something as fundamental as address/data bus multiplexing.

At best, you set up a break point, and once the break point is triggered, you can look at some registers...

That's all I really need. Often times, knowing that an interrupt subroutine has triggered has been enough to isolate issues, but the ability to see register states easily is never a bad thing. That being said, I definitely need to use debug statements more often and, as one previous partner pointed out, annotate the crap out of my bit-wise and mixed assembly habits.

[nessatse]

Thanks but no thanks as a matter of principle. Either way, the add-on appears to be rather basic.

I'm of the opinion that high-level abstractions like said add-on create more problems than they actually solve, and they definitely don't do someone in a learning phase any favors.

It is actually a very useful little addon, and the simulation appears to be pretty accurate.  For example, I recently developed a LCD library that involved custom characters and saved many hours using the emulator instead of hundreds of flash download cycles while tweaking the software.


Granted, its not going to debug realtime or hardware issues, for that amspire has pretty much summed it up.

[Mechatrommer]

i hope there is a simple and quick interface that can toggle button/pin state, sending in serial/parallel data into the mcu input during PC simulation (stimulator file? yet to read how), i hope this hapsim (downloaded for keeping) will do it better than stop/break and type in the input state for every pins in the mcu or changing register values in the avr4 toolview windows (which still can be improved, not sure in avr5 but i heard more problems than solutions). until next time when i get to my programming desk. i never got too complicated, so for now if i want to see an unexpected interrupt happening, i just embed the "halting/debug/assertion code" and produce some serial output to some selected pin(s) and see it in the scope (or led blinks) if its triggered.