AVR debuggen unter linux

[Thomas W. (lodentoni)]

Hallo,

ich bin mitlerweile an dem Punkt angekommen, an dem mir printf-debugging 
nicht mehr ausreicht. Um noch mehr lernen zu können brauche ich mehr 
Mittel. Ich arbeite unter Linux (OpenSuse) und möchte auch damit 
debuggen. Ich bastle viel mit ATMega-AVR (hauptsächlich ATMega644) und 
möchte in naher Zukunft erste Experimente mit Cortex M3 machen. Was mir 
noch fehlt sind Antworten auf einige Fragen die ich habe. Wenn mir da 
einer Helfen könnte wär das super.

Mein aktueller Stand ist, das ich drei Dinge benötige um unter Linux 
cross-debuggen zu können:
1. JTAG Interface
2. gdb debug server
3. debugger frontend (gdb, Insight, DDD)

Eine Funktionale Kombination scheint JTAG-ICemk2 + avarice + DDD zu 
sein. Die 300€ für das Gerät kann ich mir aber nicht leisten.

Daher habe ich mir hier bei mikrocontroller.net einige Links zu 
debuggern angeschaut. Auf den meisten Herstellerseiten gibts aber nur 
Windows Treiber und Software, was mir nicht weiter hilft. Irgendwie bin 
ich beim Olimex AVR-JTAG-USB hängen geblieben. Allerdings steht da nur 
dass er die selben Controller wie das Original unterstützt. Auf der 
Atmel Homepage gibt es aber dazu keine Datenblätter. Weiß einer wo man 
die unterstützten Controller in Erfahrung bringt?

Des weiteren würde mich interessieren welche gdb server es gibt, und 
welche Hardware sie unterstützen. Ich habe oft vom avarice gelesen, 
allerdings noch keine liste mit unterstützter Hardware gefunden. Es gibt 
eine Sourceforge Seite aber keinerlei Infos.


Wär schön wenn jemand ein paar Tipps / Alternativen für mich hat.

Vielen Dank, toni

[... (Gast)]

Thomas Weinhold schrieb:
> Irgendwie bin
> ich beim Olimex AVR-JTAG-USB hängen geblieben. Allerdings steht da nur
> dass er die selben Controller wie das Original unterstützt. Auf der
> Atmel Homepage gibt es aber dazu keine Datenblätter. Weiß einer wo man
> die unterstützten Controller in Erfahrung bringt?

Vergiß den am besten ganz schnell wieder.
Die unterstützten µC sind: ATmega16, ATmega32, ATMega323, ATmega162, 
ATmega169, ATmega128
Steht aber auch so im auf der Seite verlinkten user guide:
http://www.olimex.com/dev/pdf/avr-usb-jtag.pdf

Bei Atmel ist dazu nichts mehr zu finden, weil das Teil schon seit 
etlichen Jahren obsolet ist und dafür nichts mehr entwickelt wird.

Wenn Dir das ICEmkII zu teuer ist, warum dann kein Dragon? Zumindest 
unter Windows wird der auch von avarice unterstützt.

[... (Gast)]

Thomas Weinhold schrieb:
> Ich habe oft vom avarice gelesen,
> allerdings noch keine liste mit unterstützter Hardware gefunden.

Hier mal ein paar Ausgaben von avarice 2.9 aus WinAVR-20100110:

>avarice -h
AVaRICE version 2.9, Jan  7 2010 22:42:57

Usage: avarice [OPTION]... [[HOST_NAME]:PORT]

Options:
  -h, --help                  Print this message.
  -1, --mkI                   Connect to JTAG ICE mkI (default)
  -2, --mkII                  Connect to JTAG ICE mkII
  -B, --jtag-bitrate <rate>   Set the bitrate that the JTAG box communicates
                                with the avr target device. This must be less
                                than 1/4 of the frequency of the target. Valid
                                values are 1000/500/250/125 kHz (mkI),
                                or 22 through 6400 kHz (mkII).
                                (default: 250 kHz)
  -C, --capture               Capture running program.
                                Note: debugging must have been enabled prior
                                to starting the program. (e.g., by running
                                avarice earlier)
  -c, --daisy-chain <ub,ua,bb,ba> Daisy chain settings:
                                <units before, units after,
                                bits before, bits after>
  -D, --detach                Detach once synced with JTAG ICE
  -d, --debug                 Enable printing of debug information.
  -e, --erase                 Erase target.
  -E, --event <eventlist>     List of events that do not interrupt.
                                JTAG ICE mkII and AVR Dragon only.
                                Default is "none,run,target_power_on,target_sleep,target_wakeup"
  -f, --file <filename>       Specify a file for use with the --program and
                                --verify options. If --file is passed and
                                neither --program or --verify are given then
                                --program is implied.
  -g, --dragon                Connect to an AVR Dragon rather than a JTAG ICE.
                                This implies --mkII, but might be required in
                                addition to --debugwire when debugWire is to
                                be used.
  -I, --ignore-intr           Automatically step over interrupts.
                                Note: EXPERIMENTAL. Can not currently handle
                                devices fused for compatibility.
  -j, --jtag <devname>        Port attached to JTAG box (default: /dev/avrjtag).
  -k, --known-devices         Print a list of known devices.
  -L, --write-lockbits <ll>   Write lock bits.
  -l, --read-lockbits         Read lock bits.
  -P, --part <name>           Target device name (e.g. atmega16)

  -p, --program               Program the target.
                                Binary filename must be specified with --file
                                option.
  -r, --read-fuses            Read fuses bytes.
  -R, --reset-srst            External reset through nSRST signal.
  -V, --version               Print version information.
  -v, --verify                Verify program in device against file specified
                                with --file option.
  -w, --debugwire             For the JTAG ICE mkII, connect to the target
                                using debugWire protocol rather than JTAG.
  -W, --write-fuses <eehhll>  Write fuses bytes.
  -x, --xmega                 AVR part is an ATxmega device.
HOST_NAME defaults to 0.0.0.0 (listen on any interface).
":PORT" is required to put avarice into gdb server mode.

e.g. avarice --erase --program --file test.bin --jtag /dev/ttyS0 :4242


>avarice -k
AVaRICE version 2.9, Jan  7 2010 22:42:57

List of known AVR devices:

Device Name       Device ID     Flash    EEPROM
---------------   ---------   -------   -------
at90can128           0x9781   128 KiB     4 KiB
at90can32            0x9581    32 KiB     1 KiB
at90can64            0x9681    64 KiB     2 KiB
at90pwm2             0x9381     8 KiB   0.5 KiB
at90pwm216           0x9483    16 KiB   0.5 KiB
at90pwm2b            0x9383     8 KiB   0.5 KiB
at90pwm3             0x9381     8 KiB   0.5 KiB
at90pwm316           0x9483    16 KiB   0.5 KiB
at90pwm3b            0x9383     8 KiB   0.5 KiB
at90usb1287          0x9782   128 KiB     4 KiB
at90usb162           0x9482    16 KiB   0.5 KiB
at90usb646           0x9682    64 KiB     2 KiB
at90usb647           0x9682    64 KiB     2 KiB
atmega128            0x9702   128 KiB     4 KiB
atmega1280           0x9703   128 KiB     4 KiB
atmega1281           0x9704   128 KiB     4 KiB
atmega1284p          0x9705   128 KiB     4 KiB
atmega128rfa1        0xA701   128 KiB     4 KiB
atmega16             0x9403    16 KiB   0.5 KiB
atmega162            0x9404    16 KiB   0.5 KiB
atmega164p           0x940A    16 KiB   0.5 KiB
atmega165            0x9407    16 KiB   0.5 KiB
atmega165p           0x9407    16 KiB   0.5 KiB
atmega168            0x9406    16 KiB   0.5 KiB
atmega168p           0x940B    16 KiB   0.5 KiB
atmega169            0x9405    16 KiB   0.5 KiB
atmega16hva          0x940C    16 KiB   0.2 KiB
atmega2560           0x9801   256 KiB     4 KiB
atmega2561           0x9802   256 KiB     4 KiB
atmega32             0x9502    32 KiB     1 KiB
atmega323            0x9501    32 KiB     1 KiB
atmega324p           0x9508    32 KiB     1 KiB
atmega325            0x9505    32 KiB     1 KiB
atmega3250           0x9506    32 KiB     1 KiB
atmega3250p          0x956E    32 KiB     1 KiB
atmega325p           0x955D    32 KiB     1 KiB
atmega328p           0x950F    32 KiB     1 KiB
atmega329            0x9503    32 KiB     1 KiB
atmega3290           0x9504    32 KiB     1 KiB
atmega3290p          0x950C    32 KiB     1 KiB
atmega329p           0x9503    32 KiB     1 KiB
atmega32c1           0x9586    32 KiB     1 KiB
atmega32hvb          0x9510    32 KiB     1 KiB
atmega32m1           0x9584    32 KiB     1 KiB
atmega32u4           0x9587    32 KiB     1 KiB
atmega406            0x9507    40 KiB   0.5 KiB
atmega48             0x9205     4 KiB   0.2 KiB
atmega48p            0x920A     4 KiB   0.2 KiB
atmega64             0x9602    64 KiB     2 KiB
atmega640            0x9608    64 KiB     4 KiB
atmega644            0x9609    64 KiB     2 KiB
atmega644p           0x960A    64 KiB     2 KiB
atmega645            0x9605    64 KiB     2 KiB
atmega6450           0x9606    64 KiB     2 KiB
atmega649            0x9603    64 KiB     2 KiB
atmega6490           0x9604    64 KiB     2 KiB
atmega88             0x930A     8 KiB   0.5 KiB
atmega88p            0x930F     8 KiB   0.5 KiB
attiny13             0x9007     1 KiB   0.1 KiB
attiny167            0x9487    16 KiB   0.5 KiB
attiny2313           0x910A     2 KiB   0.1 KiB
attiny24             0x910B     2 KiB   0.1 KiB
attiny25             0x9108     2 KiB   0.1 KiB
attiny261            0x910C     2 KiB   0.1 KiB
attiny43u            0x920C     4 KiB   0.1 KiB
attiny44             0x9207     4 KiB   0.2 KiB
attiny45             0x9206     4 KiB   0.2 KiB
attiny461            0x9208     4 KiB   0.2 KiB
attiny48             0x9209     4 KiB   0.1 KiB
attiny84             0x930C     8 KiB   0.5 KiB
attiny85             0x930B     8 KiB   0.5 KiB
attiny861            0x930D     8 KiB   0.5 KiB
attiny88             0x9311     8 KiB   0.1 KiB
atxmega128a1         0x974C   136 KiB     2 KiB
atxmega128a1revd      0x9741   136 KiB     2 KiB

>

[Roland H. (batchman)]

Warum reicht die printf-Methode nicht mehr aus? Ein Protokoll in Form 
eines "log files" ist m. A. nach jedem Debugger überlegen, auch weil es 
später in der Produktionsphase unschätzbare Dienste erweisen kann. 
Spätestens unter Hochlast mit vielen Threads geht's eh nicht anders. 
Aber jeder Jeck ist anders :-)

Abgesehen davon, wenn die Reise Richtung Cortex-M3 gehen soll, dann 
kaufe Dir ein STM32VL Discovery. Kostet 13 EUR inkl. Programmierer und 
Debugger via USB. gdb-Anbindung unter Linux, alles als Open-Source. Aber 
rechne mit Problemen, die arm-utilities sind noch nicht ganz ausgereift, 
ich hab's inzwischen stabil am Laufen und bin sehr zufrieden.

Alternativ ein LPCXpresso für 24 EUR. NXP legt diesem eine Code Red IDE 
Umgebung bei. Damit soll wohl Debugging funktionieren, mir kam dieses 
Ding nicht auf die Platte, da es zwingend mit root-Rechten zu 
installieren ist und ggf. z. B. libusb überschreibt. Auch mit dem Teil 
bin ich sehr zufrieden.

In beiden Fällen soll es sogar möglich sein, den Programmierer/Debugger 
auch "separat" einsetzen zu können. Da musst Du ggf. selbst 
recherchieren.

Wenn ich mir diese Preise ansehe, dazu die Leistung des Cortex-M3, dann 
stellt sich die Frage nach AVR-Debugging nicht mehr. Es gibt nur ein 
Hindernis, und das nennt sich DIP.

[Thomas W. (lodentoni)]

Das ist doch mal eine Aussage.

Ich denke wenn avarice den Dragon unter Windows unterstützt wird das 
auch unter Linux funktionieren. Der Dragon an sich hat ja eine lange 
Liste von unterstützten Controllern, das finde ich gut.

Muss man noch irgend etwas beachten, ein Datenblatt für den Dragon 
scheint es ja nicht zu geben? An sonsten werde ich mir das Gerät wohl 
zulegen.

Vielen Dank für die Info!

[Thomas W. (lodentoni)]

Roland H. schrieb:
> Warum reicht die printf-Methode nicht mehr aus? Ein Protokoll in Form
> eines "log files" ist m. A. nach jedem Debugger überlegen, auch weil es
> später in der Produktionsphase unschätzbare Dienste erweisen kann.
> Spätestens unter Hochlast mit vielen Threads geht's eh nicht anders.
> Aber jeder Jeck ist anders :-)
>
> Abgesehen davon, wenn die Reise Richtung Cortex-M3 gehen soll, dann
> kaufe Dir ein STM32VL Discovery. Kostet 13 EUR inkl. Programmierer und
> Debugger via USB. gdb-Anbindung unter Linux, alles als Open-Source. Aber
> rechne mit Problemen, die arm-utilities sind noch nicht ganz ausgereift,
> ich hab's inzwischen stabil am Laufen und bin sehr zufrieden.
>
> Alternativ ein LPCXpresso für 24 EUR. NXP legt diesem eine Code Red IDE
> Umgebung bei. Damit soll wohl Debugging funktionieren, mir kam dieses
> Ding nicht auf die Platte, da es zwingend mit root-Rechten zu
> installieren ist und ggf. z. B. libusb überschreibt. Auch mit dem Teil
> bin ich sehr zufrieden.
>
> In beiden Fällen soll es sogar möglich sein, den Programmierer/Debugger
> auch "separat" einsetzen zu können. Da musst Du ggf. selbst
> recherchieren.
>
> Wenn ich mir diese Preise ansehe, dazu die Leistung des Cortex-M3, dann
> stellt sich die Frage nach AVR-Debugging nicht mehr. Es gibt nur ein
> Hindernis, und das nennt sich DIP.

Also Multithread versuch ich erst garnicht auf dem AVR. Ein OS mit 2kB 
RAM dürfte schwierig werden. Auch das printf debugging funktioniert nur 
dann, wenn es nicht printf ist, das man debuggen will ;) .
Die ersten Experimente mit Cortex M3 werden noch etwas dauern. Von daher 
lohnt es sich für mich schon noch für den AVR Geld auszugeben (wenn es 
im Rahmen bleibt).
Die DIP Problematik sehe ich nicht. Für den Einstieg hatte ich an ein 
Starterkit gedacht. Für richtige Projekte mach ich auch schon mal ein 
Platinendesign.
Für so ein discovery Board bin ich nicht zu begeistern. Mir ist es 
lieber wenn ich zwei Geräte habe: Einen Programmierer/Debugger und das 
Target. Wenn die Teile aber seperat einsetzbar sind wäre das für 
Hobby/Educational Zwecke Ok, Das schau ich mir dann aber an wenn die 
Zeit reif ist.

Ich danke Dir auf jeden Fall.