Probleme beim Debuggen

[Le X. (lex_91)]

Hallo,

ich versuche seit einiger Zeit, eine Debug-Umgebung für meine AVRs zum 
Laufen zu bekommen.

Mein Setup:
- ATmega1284p @ 20 MHz
- AVR-Dragon über JTAG
- Linux Mint 14 / x64
- kompilieren mittels makefile, -Os und -gdwarf-3 sind gesetzt
- avarice als Debug-Server, Aufruf mit "avarice -g -Patmega1284p 
--erase --program -B4000khz --file .build/bin/test.elf :1212"
- ddd als frontend für gdb, Aufruf mit "ddd --debugger "avr-gdb -x 
avr-gdb.conf""
- Inhalt von avr-gdb.conf:

"file .build/bin/test.elf
target remote localhost:1212
load"

So, mein Problem ist bischen blöd zu beschreiben.
Grundsätzlich startet ddd auch, und nach einer recht langen Zeit seh ich 
auch meinen Quelltext. Leider reagiert mir ddd nicht auf meine 
Breakpoints.
Stattdessen wird recht willkiürlich irgendwo gestoppt.

Die Zeile, in der gestoppt wird, markiert mir ddd mit einem roten Pfeil, 
also ganz so als hätte ich einen Breakpoint gesetzt. Nur hab ich das 
nicht. Im Pfeil wird mir allerdings ein Blitz angezeigt.

Kennt jemand dieses Verhalten?
Stimmen meine Tool-Aufrufe?
In der Doku konnte ich dazu nichts finden.
Leider ist das Ganze so nicht zu gebrauchen...

Viele (verzweifelte) Grüße,
lex

[Dr. Sommer (Gast)]

Wenn was nicht funktioniert, immer auf der tiefsten Ebene schauen; das 
bedeutet hier nicht ddd zu verwenden sondern direkt gdb. Da gibts auch 
ein schönes Manual für, und man muss nicht raten was rote Pfeile und 
kleine Blitze bedeuten...
Wenn du -Os oder gar -flto verwendest, wird der Code komplett 
durcheinander geworfen, dann hat die Ordnung der Maschinenbefehle nichts 
mehr mit der Ordnung der C-Befehle zu tun... D.h. mit etwas Pech darfst 
du dann auf Assembler-Ebene debuggen, da der gdb dir nicht mehr sagen 
kann zu welcher C-Zeile der aktuelle Befehl gehört. Wenn dein Programm 
ohne Optimierungen auch funktionier und in den µC passt, solltest du es 
zu Debug-Zwecken mal so versuchen.

[Le X. (lex_91)]

Danke dir erstmal.

Zweimal Nachtrag:

1) mittlerweile auch ohne Optimierung probiert, selbes Ergebniss.

2) Seltsam: anstatt die üblichen Init-Funktionen und zyklischen Tasks 
hab ich mal alles aus der main() herausgenommen.

Meine main() schaut nun so aus:

  DDRB = 0xFF;

  while(1)
  {
    PORTB = 0;
    _delay_ms(3000);
    PORTB = 1;
    _delay_ms(3000);
  }

Trotzdem passiert mir dieses "Blitz-Phänomen". Diesmal bleib ich zB 
immer in einer LCD-Routine hängen, die allerdings garnicht aufgerufen 
wird...

Ansonsten werd ich mal schaun ob das Problem mit avr-gdb ohne 
GUI-Frontend auch auftritt.

Viele Grüße,
lex

[Le X. (lex_91)]

So, ich hab weiter gemacht und mir ist etwas aufgefallen.
Gestern habe ich ja sämtliche Funktionsaufrufe auskommentiert und hatte 
nur noch die Endlosschleife (siehe gestriger Post) in der main(). 
Trotzdem hing der Debugger irgendwo in den LCD-Routinen.
Mittlerweile hab ich nur noch die main.c im makefile eingetragen. D.h. 
der Debugger kann garnix mehr kennen ausser der main().

So, jetzt hänge ich irgendwo im StartupCode. An Adresse 0x08.

Hm, dort liegt doch eigentlich die Vectortabelle für die ISR?
In der Tat steht im Listing:

   0:  0c 94 46 00   jmp  0x8c  ; 0x8c <__ctors_end>
   4:  0c 94 5d 00   jmp  0xba  ; 0xba <__bad_interrupt>
   8:  0c 94 5d 00   jmp  0xba  ; 0xba <__bad_interrupt>
   c:  0c 94 5d 00   jmp  0xba  ; 0xba <__bad_interrupt>
  10:  0c 94 5d 00   jmp  0xba  ; 0xba <__bad_interrupt>
  14:  0c 94 5d 00   jmp  0xba  ; 0xba <__bad_interrupt>
  18:  0c 94 5d 00   jmp  0xba  ; 0xba <__bad_interrupt>
  1c:  0c 94 5d 00   jmp  0xba  ; 0xba <__bad_interrupt>
  20:  0c 94 5d 00   jmp  0xba  ; 0xba <__bad_interrupt>

Jetzt wirds seltsam. ddd bietet ja die Möglichkeit, sich einen 
Assemblerdump anzeigen zu lassen. Dort finde ich:

Dump of assembler code for function __vectors:
=> 0x00000000 <+0>:     ldi     r24, 0x25       ; 37
   0x00000002 <+2>:     ldi     r25, 0x00       ; 0
   0x00000004 <+4>:     movw    r30, r24
   0x00000006 <+6>:     st      Z, r1
   0x00000008 <+8>:     ldi     r24, 0x00       ; 0
   0x0000000a <+10>:    ldi     r25, 0x80       ; 128
   0x0000000c <+12>:    ldi     r26, 0x3B       ; 59
   0x0000000e <+14>:    ldi     r27, 0x45       ; 69

Meinen altbekannten "Stopblitz" finde ich an der Adresse 0x08.

So, irgendwas passt doch hier nicht.
Die elf-Datei, die ich ddd übergebe, ist die allerselbe wie auf dem 
Prozessor aufgespielt wird (und die zum Listing passt).

Dennoch passt der Dump nicht zu meinem Listing.

Kann daher das Problem kommen?

Grüße,
lex

[Dr. Sommer (Gast)]

avarice -g -Patmega1284p --erase --program -B4000khz --file 
.build/bin/test.elf :1212

Äh, kann avarice überhaupt ELF's lesen? Oder spielt das das ELF so am 
stück auf den Controller...

[tom (Gast)]

Hi,

gibt es das mfile utility in deiner avrgcc-installation ? winavr hat das 
mit dabei gehabt seinerzeit.

mit diesem makefile generator mach dir doch mal ein makefile für ein 
kleines testprojekt mit nur main.c mit einer endlos while-schleife und 
einer volatile variable welche inkrementiert wird für deinen 
zielprozessor.

dann rufst du make gdb-config auf und da purzelt dann die nötige 
gdb_init datei raus, heisst __avr_gdbinit in meinem fall.

ach ja, compiler optimierung ausschalten s.o. ;o)

dann make debug aufrufen. wenn du deine makros im makefile bezüglich der 
verwendeten programme (gdb, avarice, insight oder ddd) richtig gesetzt 
hast sind die chance gut das es jetzt tut.

bei mir hat es mit insight als GUI auf dem gdb drauf jedenfalls recht 
fix so geklappt...

gruss, tom.

[Le X. (lex_91)]

Dr. Sommer schrieb:
> Äh, kann avarice überhaupt ELF's lesen? Oder spielt das das ELF so am
> stück auf den Controller...

Dadurch wird der Controller von avarice gleich noch programmiert. Spart 
den avrdude-Aufruf.


Dieses mfile Tool werd ich mir mal ansehn.
Insight habe ich letztens auch mal gebaut, bin aber noch nicht dazu 
gekommen es ausgiebig zu testen.
Spontan hab ich aber gemerkt, dass mir mögliche Breakpoints nicht 
angezeigt wurden (trotz -O0).