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:
1
"file .build/bin/test.elf
2
target remote localhost:1212
3
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
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.
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:
1
DDRB=0xFF;
2
3
while(1)
4
{
5
PORTB=0;
6
_delay_ms(3000);
7
PORTB=1;
8
_delay_ms(3000);
9
}
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
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:
1
0:0c944600jmp0x8c;0x8c<__ctors_end>
2
4:0c945d00jmp0xba;0xba<__bad_interrupt>
3
8:0c945d00jmp0xba;0xba<__bad_interrupt>
4
c:0c945d00jmp0xba;0xba<__bad_interrupt>
5
10:0c945d00jmp0xba;0xba<__bad_interrupt>
6
14:0c945d00jmp0xba;0xba<__bad_interrupt>
7
18:0c945d00jmp0xba;0xba<__bad_interrupt>
8
1c:0c945d00jmp0xba;0xba<__bad_interrupt>
9
20:0c945d00jmp0xba;0xba<__bad_interrupt>
Jetzt wirds seltsam. ddd bietet ja die Möglichkeit, sich einen
Assemblerdump anzeigen zu lassen. Dort finde ich:
1
Dumpofassemblercodeforfunction__vectors:
2
=>0x00000000<+0>:ldir24,0x25;37
3
0x00000002<+2>:ldir25,0x00;0
4
0x00000004<+4>:movwr30,r24
5
0x00000006<+6>:stZ,r1
6
0x00000008<+8>:ldir24,0x00;0
7
0x0000000a<+10>:ldir25,0x80;128
8
0x0000000c<+12>:ldir26,0x3B;59
9
0x0000000e<+14>:ldir27,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
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...
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.
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).
