How do people debug sketchs ?

Greetings; I've been busy playing with my first Mega 2560 all week and wondering how other people are debugging their sketches?

I was able to get remote tracing for my board by using the EthernetUDP class, as documented on my site

However it seems that someone should have figured out how to put a breakpoint in a sketch. Does this exist and I have just overlooked it?

No, you didn't miss it. Debugging a sketch is pretty old school. Most basic is use of the serial monitor & some strategically placed serial.print statements. Using leds as indicators is another. Signal analyzers have their uses & you can use i2c if serial's speed is interfering with your sketch (not so much of an issue since 1.0). In other words, no breakpoints, watching variables or any of that nice modern stuff.

The trick is not to put any errors into your sketch in the first place. There are not many things you can't track down using serial print.

I've found that if I write my applications first creating small functions that I can pretest, then later when combining them all into a main sketch there are not that many problems, and if there are a few simple serial prints can usually track it down in short order. Good troubleshooting skills is also using good analytical logical thinking to kind of know where and where not to look for problems based on the symptom you are seeing. I'm sure modern software debug tools are very powerful but I was of age when such tools were either non-existent or very few, so had to learned to use other 'tools'.


I'd agree getting in right the first time is always best; but this is often more theory than practice as external factors come into play.

Yes you can printf your way to a solution, but gdb/windbg are 100x faster.

From looking at the avr-libc-user-manual.pdf that comes with the Arduino 1.0 toolkit, it sounds like Amtel has a collection of hardware debuggers that work great for these scenarios. Has anyone reviewed which work better than others?

I tried to respond but the forum ate my response:,85590

(page 5)

windbg are 100x faster

No. Not unless you are very very poor at what you are doing.

wasntnate: Yes you can printf your way to a solution, but gdb/windbg are 100x faster.

No, it isn't. Proof, or it didn't happen.

I've only really resorted to a hardware jtag debugger once to debug a problem with the DDR controller setup on an ARM bootloader I wrote for some custom hardware. Besides that blinking an LED, serial output, and printf() have always done the job pretty quickly. Software debuggers like gdb are great for doing a postmortem on a core dump for user-space apps.

You could have a look at this AVT simulator:

You can run gdb against it and get source level debugging. Probably useful for some things.

There are JTAG interfaces as well, but Arduino lacks a JTAG header.

[quote author=Nick Gammon link=topic=91637.msg688735#msg688735 date=1329123596]

wasntnate: Yes you can printf your way to a solution, but gdb/windbg are 100x faster.

No, it isn't. Proof, or it didn't happen.[/quote] Whether or not a debugger is faster depends a lot on knowing where the error is occurring, and how that error is manifesting itself. With hardware, you generally don't know either of those things.

Whether or not a debugger is faster also depends on your skill at using a debugger. I can muddle my way through using a debugger. I don't get a lot of practice, though, because I find printing stuff is necessary to get a general idea where the program is going wrong, and by the time I've isolated the section of the code in error, the error in the code is glaringly obvious.

Someone did it here:

Mind you, you have to buy an AVR Dragon board, and if you are using an Arduino remove the Reset pin from the onboard circuit (debugging is done by the Reset pin).

Apart from the cost and mucking around though, a lot of problems people have with their Arduino programs is timing. Things blink too fast, too slow, switches don’t debounce etc.

Stopping the program at a breakpoint not only completely hides this sort of behaviour, it introduces its own timing problems. How can you test a loop that is supposed to do something every second, if you spend 5 minutes in a debugger staring at it?

Plus the debugging must necessarily slow things down - I can’t believe that it can check for breakpoints, or memory locations changing, without impacting on the performance. So debugging might introduce “phantom” problems that don’t occur when you are not debugging.

Heisenbugs... or those which are better understood than debugged :-)

Nick and Paul,you guys raise a lot of good points about using source line debuggers. Very often, they are not the best way to find an issue. But other times, they are. The ability to set breakpoints, inspect variables, trap certain error conditions and so on can be a tremendous help. I can't say I know how often such a tool is used in embedded applications, but I do know that in a PC environment, even if a RTOS is used, they are commonly used.

What I have done is, for more complex algorithms, write the code, test it in a PC based compiler / debugger, then out it into teh Arduino code.

For those still learning C/C++, they can be a great help understanding what your code is doing. Although for this purpose, I don't recommend debugging on an Arduino.

Watcom C++ can be used to perfect algorithms than can then be put into your Arduino code. Watcom C++ was a fantastic compiler in its day, and not cheap. Now its available as open source and its still an excellent compiler. So its free, even with the source debugger.

Properly used, and under the right cirumstances, I like gdb. I even did a fairly lengthy page on how to use it:

There is a certain amount of time you have to invest in using a debugger properly, time which might be better spent on the "real" problem, unless you are absolutely stuck.

The thing is that as debugging tools got better programmers got worse. Debugging tools enabled poor programmers to produce (eventually) working code. Such was the commercial need for working code that this became almost the norm.

Debugging tools enabled poor programmers to produce (eventually) working code.

No, Visual Basic did that.

Visual Basic did a lot of things. Like train people to ignore capitalization.

I knew of a company that planned to write a whole financial system in Visual Basic. I said "you DO know that the B in Basic stands for 'Beginners' don't you?". Beginners All-purpose Symbolic Instruction Code.

Visual Basic did a lot of things. Like train people to ignore capitalization

I thought that was down to SMS :stuck_out_tongue_closed_eyes: