AVR Freaks

I prefer a real debugger!  Of course, "real" varies with the device. And, I really want tools like a profiler and something with trace capability.

I "grew up" (in the embedded world) with an In-Circuit Emulator for 8051 that had these things and really miss profile and trace in the AVR.

Jim

In a recent project, with an STM32, I have used for debugging:

• the IDE debugging tool
• printf to a bluetooth serial port controlled by many #ifdef statements
• comparison with previous project's behaviour
• a 32 channel logic analyser

Another project, a processor emulator, has required

• the IDE debugging tool (GDB)
• printf
• debugging mechanisms in the emulator itself (so the GDB shows me the emulator line by line, and the emulator has a simple change-mode-to-trace when it hits a breakpoint in the code being emulated/executed
• a copy of Tiny Basic for 8080

All good fun...

Neil

Use a port pin and the scope, or maybe stuff a character out the uart.

For many programs, the error is a compile error, so you never even run the thing.  If it compiles properly, it usually runs fine. 

Using care in ensuring your values are within the allowed range & double-checking your logic helps avoid many potential flaws. 

Many things can be found by inspection (why does the compressor come on when the switch is closed, instead of opened.) 

Atmel-ICE can do that on an AVR:

http://atmel-studio-doc.s3-websi...

The amount of time I spend debugging has gone down significantly since I started using test driven development. When I do need to do some debugging, run logs, logic analyzer/oscilloscope observations, and a quick look at the relevant source code are typically enough to get a good handle on what is going on. I'll break out a debugger if those tools end up not being enough.

VOM measurements, Serial prints, LED's, Debugger, scope, and a Logic analyzer are all good, but my number one tool is a sharp pencil and notepad and writing down the details of operation as I observe them.....

Then spending some time to think about the code and relating the observations with what I have witnessed!  

Jim

Sink Data Conversion | Data Visualizer Software User's Guide

QTools: QS Target Component | Application-Specific Data Elements

edit : re QS

QTools: QP/Spy™ Data Protocol

[beginning of second paragraph]

The QP/Spy™ data protocol has many elements of the High Level Data Link Control (HDLC) protocol defined by the International Standards Organization (ISO). 

USBee has an HDLC decoder :

USBee QX 2.0 Mixed Signal Oscilloscope, Logic Analyzer, Signal Generator, Protocol Decoder and Analyzer

[3/4 page]

Debugging is performed by viewing and analyzing the PacketPresenter output and relating it back to the logic analyzer waveforms and decoded bus traffic for the various types of busses. For example, you can see the PacketPresenter display of HDLC communication packets, and correlate that back to the raw byte stream that was decoded from the ASYNC bus, as well as the voltage versus time waveforms of the bus Tx and Rx lines.

I would always prefer to have a proper debugger.

I have been using a "debugger" since the "monitor programs" were created.

Using state machines and the like can be an edge against needing an all out debugger.  When something is going wrong, I can usually tell which state it is in and very quickly figure out what I got backwards, left out, etc. 

Usually the "bugs" I find on AVR are not raw coding mistakes at all, but a misunderstanding of something that needs done ...Oh, the datasheet says, the power driver only comes on when both EN pin AND SYNC pins are high (rather than just EN).  

On the other hand, I did have a pic app years ago that had some very twisted & failing logic...the debugger really stepped in to help (the old "that can't be happening syndrome" )

Many many years ago (like 1986) I was using a debugger which proved to be a mistake.  The monitor debugger inserted an escape hook into ram code, which unfortunately fixed the issue I was having.  So tracing with the debugger indicated the fault was not happening and was impossible.  After 8 hours I realized the debugger was  "fixing " the problem (it prevented an overflow, which prevented a cascade IRQ failure).  The issue was a single missing terminator char in some string processing.

I have noticed that for some people AVRFreaks is their best debugging resource.

Seems that way on a lot of forums, I guess it's easier to ask how to do something then researching and or trying it yourself.

I don't think some people could survive without; ^c and ^v

I should add that, in some cases, debugger is inadequate because it requires halting things to tell what the internal state of the MCU is. Often, timing is so tight that serial data will change the functionality of the device being tested.

In that case, with AVRs anyway, another way is to devote several GPIO pins for debugging. I'll set one pin when it enters a subroutine being checked and clear said pin on exit. This can be done in a very small number of clock cycles; usually with minimal impact on the system. Often, several of these need to be used. Logic analyzer then shows how long code execution takes, what the timing is between entries and exits of a routine and between exit of one routine and entry to another. I can then tell if routines are being called when I expect and take the expected time. 

This method is especially helpful with ISRs as that can reveal when various events occur within the system.

In the systems I work with, things are usually too brief to make an LED useful.

Jim

This method is especially helpful with ISRs as that can reveal when various events occur within the system.

OH YEAH!!!

In the systems I work with, things are usually too brief to make an LED useful.

Toggle the pin each entry to the routine  (to see it being called), then usually much easier to see than a narrow "spike".

Remember the good old days of bondout chip emulators?  $9000 for an 8096 microcontroller emulator...and we thought it was a reasonable deal!

I remember finding out (the hard way) it did not emulate wait states properly.....now which floppy is that code on??

Oh yes. If you take one of my pet feeders to bits, you'll find eight pads on the PCB close to the processor, whose sole purpose is to allow easier soldering to the port pins for a logic analyser or scope. When the code was finished, nothing was talking to them... but I saw no reason to remove the pads :)

Neil