Hallo,
ich versuche seit drei Tagen mittels Debugwire einen ATTiny unter Linux
zu debuggen, aber ich komme mittlerweile einfach nicht mehr weiter.
Meine debugging Toolchain habe ich mir mittlerweile komplett selbst
gebaut (Eclipse-4.2.0; Avarice-2.13 mit/ohne --enable-target-programming
Option; GDB-7.6). Ich habe den AVRice mkII (fw7.35) über USB im Einsatz.
Ich kann (nur innerhalb einer Funktion) steppen und Register/Variablen
auslesen.
Aber ich bekomme die Breakpoints nicht zum funktionieren. Ich kann sie
im GDB setzen, diese werden jedoch komplett ignoriert. Avarice gibt
keinerlei debugging Info. Der Controller läuft einfach vor sich hin.
Ich habe extra Windows mit Atmel Studio aufgesetzt. Nach ein bisschen
gefriemel funktionieren die Breakpoints im Atmel Studio wie sie sollen.
Mir ist klar, dass für das Setzen von (SW) Breakpoints per DW ein
reflash notwendig ist, jedoch ist mir nicht klar wie ich das korrekt mit
Eclipse/GDB/Avarice durchführen kann.
Wenn ich versuche per GBD/Eclipse per Avarice zu flashen bricht Dieser
ab:
1
jtagWrite(): numByte does not match page size
Im Netz finde ich keine Hinweise mehr. Anscheinend bin ich mit meinem
Problem alleine oder ich sitze einem echt blöden Denkfehler auf...
Für einen heißen Tipp wäre ich extrem dankbar.
Dies ist das Ende des Debuglogs von Avarice beim fehlgeschlagenen Laden
des Flashfiles durch GDB.
Es scheint, als ob die Abfrage auf die Pagesize in jtag2rw.cc daneben
geht.
1
GDB: Write 32 bytes to 0x700
2
jtagWrite
3
command[0x04, 1]: 04 B0 20 00 00 00 00 07 00 00 8B 83 1C 82 CE 01 02 96 62 E0 DB DC 89 83 89 81 CA 5F CD BF DF 91 CF 91 08 95 CF 93 DF 93 CD B7
4
recv: 0x1b
5
recv: 0x43
6
recv: 0x00
7
recv: 0x01
8
recv: 0x00
9
recv: 0x00
10
recv: 0x00
11
recv: 0x0e
12
sDATA: reading 1 bytes
13
read: 80
14
recv: 0x53
15
recv: 0xed
16
CRC OK
17
Got message seqno 67 (command_sequence == 67)
18
response: 80
19
->GDB: OK
20
GDB: <M720,e:dd2781e0df91cf910895f894ffcf>
21
22
GDB: Write 14 bytes to 0x720
23
jtagWrite jtagWrite(): numByte does not match page size
Habe mittlerweile den Debug mit manuellen Stops ohne Breakpoints mit
Hilfe eines Logic analyzers und ein paar Klimmzügen durchgeführt und
alles läuft wie gewünscht.
Trotzdem schade iwie...das schränkt schon ein bisschen ein.
Ich werde mich für meine nächsten Projekte an einem ARM heranwagen. Hier
scheint immerhin IP kein Problem zu sein, dazu viel mehr uumpf fuers
Geld.
Bist du sicher, dass "GDB" mit der Option "avr" konfiguriert wurde?
Ich weiss nicht wie du für dein Betriebsystem die Toolchain erzeugt hat?
Aber unter Linux muss auf alle alle Fälle die Target-Option explizit
angegeben werden:
configure --prefix=/usr/local/avr --target=avr --enable-languages=c,c++
--disable-werror
und GDB heisst nun "avr-gdb".
Stefan R. schrieb:> Mir ist klar, dass für das Setzen von (SW) Breakpoints per DW ein> reflash notwendig ist, jedoch ist mir nicht klar wie ich das korrekt mit> Eclipse/GDB/Avarice durchführen kann.
Du gibst einfach "b zeilennummer" oder "b funktionsname" ein, ganz
normal. Um das Neuflashen der entsprechenden Page kümmert sich der
Dragon selbst. Wichtig ist halt nur, dass die Debug-Sitzung sauber
beendet wird, denn falls du noch Breakpoints gesetzt hast am Ende,
muss der Dragon ja den originalen Inhalt wieder zurückschaufeln.
Flashen eines gesamten Images per debugWIRE geht im Prinzip auch
(zumindest von AVRDUDE aus), ist allerdings langsamer als mit ISP
und meiner Erfahrung nach auch nicht so zuverlässig. Allerdings
funktioniert die Logik hinter dem "load"-Kommando erst in der
allerneuesten AVaRICE-Version (aus dem SVN) einigermaßen brauchbar.
Es wird dabei auf einen Mechanismus zurückgegriffen, den es im GDB
erst seit Kurzem gibt (offenbar von der ARM-Schiene reingekommen) und
mit dem man wieder vernünftig ohne irgendwelche Ratespiele weiß, wann
der letzte Schreibbefehl vom GDB durch ist, sodass man bei einem
seitenweise zu beschreibenden Speicher auch die letzte Seite noch
ordentlich rüberbekommt.
Hallo,
danke fuer die Unterstuetzung.
Die Toolchain habe ich mir aus dem (den) SVN gebaut (avarice, wie auch
gdb). Den GDB habe ich mit der 'AVR' Option gebaut (auch mit standard
'avr-gdb' aus der Debian Repo getestet).
Ich kann auch prima soweit alles machen, Register und Variablen auslesen
step/next usw., nur er bleibt am Breakpoint nicht stehen (er setzt sie
aber anstandslos). Keine Reaktion des Controllers an breakpoints an
denen es eigentlich keinen Weg vorbei gibt. Auch Positionen, an denen
ich manuell stoppen kann werden mit Breakpoint ueberfahren.
Alles kompiliert ohne Optimierung, debug mit stabs, bzw stabs+ GBD
extensions - nix.
Flashen konnte ich per DW nur augenscheinlich. Wenn ich das identische
File nochmals mit DW flashe (wie per ISP zuvor) sieht alles prima aus.
Wenn ich zuvor jedoch irgendwas an den Sourcen geändert habe, bricht er
nach dem Flash per DW bei der Verifikation mit Fehler ab. Es scheint als
wuerde er den ROM nicht ueberschreiben.
Irgendwas ist sehr komisch bei mir...
Stefan R. schrieb:> Ich habe den AVRice mkII (fw7.35) über USB im Einsatz.
Was ist das eigentlich für ein Teil?
Da es ja mit dem Atmel Studio geht, bliebe immer noch der Weg, die
USB-Kommunikation des Studios zu tracen und gegen die Aktionen von
AVaRICE zu vergleichen.
Ich kann mit dem SVN-Stand auch nochmal einen debugWIRE-Controller
testen, just in case.
Das ist (war) der erste offizielle DW faehige Debugger von Atmel
(http://www.atmel.com/tools/AVRJTAGICEMKII.aspx).
Hatte das Teil bisher allerdings noch nicht viel in Gebrauch und wenn,
dann mit JTAG.
Wenn du mir ein Howto verlinkst, wie ich unter Windows die USB Komm
mitlogge und welcher Teil davon fuer dich von Interesse ist dann mache
ich das gerne.
Aber ich scheine mit meinem Problem alleine zu sein und fuer mich ist
das im Mom. kein Thema mehr. Von daher unterstuetze ich gerne die
Toolentwicklung, aber es eilt mir nicht.
Stefan R. schrieb:> Das ist (war) der erste offizielle DW faehige Debugger von Atmel> (http://www.atmel.com/tools/AVRJTAGICEMKII.aspx).
OK, ein JTAGICEmkII.
Sollte auf jeden Fall gehen.
> Wenn du mir ein Howto verlinkst, wie ich unter Windows die USB Komm> mitlogge und welcher Teil davon fuer dich von Interesse ist dann mache> ich das gerne.
Unter Windows selbst kann man snoopypro benutzen, ist allerdings
etwas fummelig bei der Auswahl der Geräte. Solange du nur maximal
ein JTAGICE hast, sollte das aber klappen.
Falls dein Windows in einer VM unter Linux läuft, kannst du mit
Wireshark auf dem Linux-Host sniffen. Das geht recht zuverlässig,
und ich habe Scripts, wie man dann aus einem vorgefilterten und
als XML exportierten Paket-Datenstrom die interessante
ICE-Kommunikation darstellen kann.
> Aber ich scheine mit meinem Problem alleine zu sein und fuer mich ist> das im Mom. kein Thema mehr.
OK, interessant wäre es trotzdem, falls du mal Zeit hast. (Gern auch
als Bugreport bei sourceforge.net, mit den Trace-Daten im Anhang.)
An sich hat sich debugWIRE bis aufs komplette Programmieren des
Flashs darüber bislang erstaunlich unzickig gehabt.
Thread beobachten
Seitenaufteilung abschalten