Author Topic: Debugging AVR Best Practices  (Read 2482 times)

0 Members and 1 Guest are viewing this topic.

Offline jackpTopic starter

  • Jr. Member
  • **
  • Posts: 13
  • Helpful? 0
Debugging AVR Best Practices
« on: April 28, 2010, 05:18:17 PM »

My development environment is Linux, the avr-gcc toolchain and avrdude/avrispmkii to program (in C/C++) my AVR chip (actually the Axon II Atmega640).  I have used simulavr with avr-gdb - it works but is flaky (crashes a lot when trying to read/write some of the PINs). 

So I've since resorted to changing a couple of lines of code, compiling, reprogramming and verifying functionality via UART rprintfs. 

How does everyone else debug their AVR C/C++ programs?  Is there a "best practice" FAQ? 

(I know about using JTAG to debug directly with the AVR but I wish to avoid dropping money on more HW.)


Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,165
  • Helpful? 111
    • Webbot stuff
Re: Debugging AVR Best Practices
« Reply #1 on: April 28, 2010, 08:02:25 PM »
Its v difficult !!

The AVR simulator is crammed full of bugs. Some timers work, others don't etc etc. I'm not sure if the simulator works from the part description files shipped with AVR Studio - but if it does - then I've already reported a load of errors in them back to ATmel.

So I tend to use printf to a pc to debug my main foreground program (or use LED displays, Bluetooth etc)

For lower level stuff working under interrupts where I need to know exact timings then I still tend to use the simulator. This may require moving code to a timer that is bug free etc etc but that is normally easy to spot.

Webbot Home:
WebbotLib online docs:
If your in the neighbourhood:

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,702
  • Helpful? 173
    • Society of Robots
Re: Debugging AVR Best Practices
« Reply #2 on: April 28, 2010, 10:39:33 PM »
The UART is by far the best way to debug. Whenever I program a robot during the early phase, I have it output sensor data matched with every action the robot decides to make by UART. I often even create a global variable that turns on/off this debugging option.

Occasionally an oscope or multimeter for things the mcu can't measure itself, otherwise I use SoR Scope to have the Axon measure itself in realtime. With SoR Scope, you can monitor all the pins simultaneously and see them graphed as output vs time (data files can be saved for later analysis). With hyperterminal (for UART data) you can save the file for further study.


Get Your Ad Here