Hallo,
Ich habe vieles gefunden, aber keine Lösung für mein Problem.
Ich möchte gerne mit Eclipse meinen AT90CAN128 debuggen.
Folgendes habe ich installiert:
- Windows XP
- Eclipse 3.4.1
- http://avr-eclipse.sourceforge.net/updatesite/
- CDT
- WinAVR
Mit "avrdude" klappt auch der Download
(avrdude -pc128 -cjtag1 -PCOM1 -Uflash:w:File.hex:a)
"AvaRice" startet auch:
(avarice.exe -1 -j /dev/com1 -P at90can128 :1212)
Aber was muss ich beim AVR-GDB für "Commands" einstellen?
Anbei ein Screenshot des Fensters.
Vielen Dank im Voraus.
Oder habe ich bei der Installation des PlugIn's einen Fehler gemacht?
Oder braucht es ein extra PlugIn zum Debuggen?
In einem anderen Forum-Beitrag habe ich schon gelesen über die
Debugger-Einstellung, aber das Debug-Fenster sah im angehängten Bild
anders aus.
Siehe: Beitrag "Re: Debuggen in Eclipse geht nicht GDB <-> AVaRICE problem"
In den Commands habe ich folgendes eingetragen:
file c:\....\....elf
target remote localhost:3333
load
Aber immer beim Verbindungsaufbau des AVR-GDB zum "AvaRice" stürzt
dieser ab und ist weg.
Hmm.... ???
Ich habe nun den gleichen Eclipse-Dialog. Auf einem anderen PC hat die
Installation des Eclipse-Plugins korrekt funktioniert.
Nun starte ich AVaRICE über eine Dos-Box, der wartet auf die GDB
verbindung.
Dann über Eclipse den AVR-GDB.
Sofort bricht die Verbindung zusammen und beide Programme beenden sich.
In der Console stehen folgende Meldungen:
1
68-gdb-setstop-on-solib-events1
2
(gdb)
3
68^done
4
69-target-selectremotelocalhost:4242
5
(gdb)
6
&"Remote communication error: Bad file descriptor.\n"
7
Remotecommunicationerror:Badfiledescriptor.
8
69^error,msg="Remote communication error: Bad file descriptor."
9
70-gdb-exit
10
(gdb)
11
70^exit
Was ist "Bad file descriptor", wie kann ich das beheben?
Anbei der Screenshot der Eclipse Einstellung.
unter "Connection" ist TCP localhost 4242 eingetragen.
Den AVaRICE starte ich so:
avarice.exe -1 -P at90can128 --jtag /dev/com1 :4242
1. In alten WINAVR-Versionen vor 200712.. war noch ein gdb ohne
AVR-Patch dabei. Bitte prüfe, ob ein avr-gdb -version mind. Version 6.6
ausgibt. Mit älteren Versionen hatte ich definitiv keinen Erfolg. Bei
mir sind folgende Versionen installiert:
1
H:\>avr-gdb -version
2
GNU gdb 6.6
3
Copyright (C) 2006 Free Software Foundation, Inc.
4
GDB is free software, covered by the GNU General Public License, and you are
5
welcome to change it and/or distribute copies of it under certain conditions.
6
Type "show copying" to see the conditions.
7
There is absolutely no warranty for GDB. Type "show warranty" for details.
8
This GDB was configured as "--host=i686-pc-mingw32 --target=avr".
9
10
H:\>avarice
11
AVaRICE version 2.7, Dec 19 2007 20:37:47
12
13
Defaulting JTAG bitrate to 1 MHz. Make sure that the target
14
frequency is at least 4 MHz or you will likely encounter failures
15
controlling the target.
2. Versuch's mal mit -gdwarf-2 statt mit -gstabs.
3. Die Fehlermeldung deutet auf ein Problem mit der TCP-Verbindung zu
avarice hin. Bitte prüfe auf der "Connection" Seite, ob da auch wirklich
Type:[TCP]; Hostname: [localhost] und Port number: [4242] steht.
Oder statt Eclipse das AVR-Studio nehmen und sich die grauen Haare
sparen. Eclipse ist auf jedem Rechner ein rumgefrickel ohne gleichen bis
erstmal alles einigermaßen läuft...
Ich hab's hin bekommen. Der AVaRICE benötigt noch zusätzlich Parameter
des ELF Files, Erase und Programmieren.
Die Versionen hab ich die gleichen, nur der AVaRICE ist neueren Datums.
Ich habe Eclipse schon erfolgreich mit Codesourcery und Arm-Elf laufen.
Also habe ich den GCC WinAVR Compiler noch installiert und kann mit der
gleichen Umgebung arbeiten (Alles in einem Verzeichnis, 1GB).
Nur halt gibts beim AVR kein OpenOCD sondern andere Tools, die man
anders benutzen muss. Einmal graue Haare bekommen beim aller ersten
Einrichten (hab ich eh schon viele) und dann viele Jahre benutzen. Das
Schöne an der Eclipse-Umgebung ist, mann kann es einfach ohne was zu
installieren kopieren. Einfach nur die PATH-Einträge setzen, fertig.
Doch zu meiner letzten Frage:
Im AVR-Studio kann man doch direkt online alle SFR Register sehen.
Geht das, wenn ja wie mit dem AVR-Plugin für Eclipse?
Oder braucht es noch eine Einstellung?
So auf die schnelle hab ich nichts gefunden.
Vielen Dank für eure Antwort
Markus wrote:
> Ich hab's hin bekommen. Der AVaRICE benötigt noch zusätzlich Parameter> des ELF Files, Erase und Programmieren.
Danke für den Hinweis. Ich habe gerade angefangen mich mit dem JTAG
Debuggen auseinanderzusetzen und bis jetzt nur teilweise Erfolg gehabt.
> Doch zu meiner letzten Frage:>> Im AVR-Studio kann man doch direkt online alle SFR Register sehen.> Geht das, wenn ja wie mit dem AVR-Plugin für Eclipse?> Oder braucht es noch eine Einstellung?> So auf die schnelle hab ich nichts gefunden.
Ich glaube nicht, dass es mit den Eclipse Bordmitteln geht. Aber so
etwas wäre natürlich sehr hilfreich und ich werde mal schauen, ob ich
für Version 2.4 des Plugins etwas in die Richtung implementieren kann.
LG
Thomas (AVR Eclipse Plugin Maintainer)
@Thomas Holland: Vielen Dank für Ihre Antwort.
Im moment nutze ich Eclipse nur noch als Editor, richtig debuggen klappt
nur mit AVRStudio.
Unter Eclipse:
Es ist schon lästig, der Debugger bleibt immer wieder hängen,
Variablenwerte werden nicht richtig/gar nicht angezeigt, immer muss mit
AvaRice das Projekt geladen werden bevor debugt werden kann, Reset vom
Controller gibt es auch nicht (nur Neustart Debug-Session).
Somit muss ich auch den Compiller vom AVRStudio (GCC) nutzen. Wenn ich
mit Eclipse compilliere, dann kann zwar AVRStudio die ELF Datei öffnen
und laden, aber die C-Dateien sehe ich nicht, nur einen Dissassembler
Code und das ist auch Witzlos.
In der Debug-Ansicht gibt es auch eine "Register" Ansicht. Da stehen die
Rxx Register drin. Da wäre es sinvoll auch die anderen SFRs mit
aufzunehmen. Blos zeigt der Debugger da nix an (alles 0).
Also das einzige was mit dem AvaRice und AVR-GDB geht ist das
durchsteppen, bis er mal wieder abstürzt.
Obwohl ich als Compiller Optimierung "-O0" angegeben habe.
Mit AvrDude kann ich das Projekt schon auch laden, nur debuggen geht
darüber, glaube ich nicht.
Der Einzige Prozessor, mit dem ich zufriedenstellend mit Eclipse
debuggen kann ist der Cortex M3 Prozessor mit Codesourcery
(ARM-NONE-EABI-GDB.exe), über Olimex ARM-USB-JTAG und OpenOCD.
Wenn es die Firma Atmel tatsächlich in 2 Jahren noch geben sollte, dann
besteht auch noch Hoffnung dass ein AVR-GDB.exe der Version 7.1 geben
wird und ein AvaRice 3.1 die dann besser funktionieren. Aber bis dahin
würde ich die Version 2.4 des genialen AVR-Eclipse Plugins auf Eis
legen, nur so als Tipp, Sie werden nicht nur graue Haare bekommen, nein,
die werden Ihnen auch noch raus fallen...
Als Editor ist Eclipse natürlich unschlagbar. Somit nutze ich:
- Eclipse
- WinAVR GDB
- AVRStudio
- "Atmel AVR ISP MKI" (von Olimex den "AVR-JTAG", seriell)
Alternativ könnten Sie die Atmel DLL für debuggen nutzen, aber das wird
wohl auch alles Spregen, siehe ^graue Hare und so.
Wenn hier jemand mit einem MKII bessere Erfahrungen gesammelt hat, dann
würde ich so einen besorgen, daran soll es nicht liegen.
Markus wrote:
> Somit muss ich auch den Compiller vom AVRStudio (GCC) nutzen. Wenn ich> mit Eclipse compilliere, dann kann zwar AVRStudio die ELF Datei öffnen> und laden, aber die C-Dateien sehe ich nicht, nur einen Dissassembler> Code und das ist auch Witzlos.
Das liegt daran, dass der Debugger vom Studio andere Debug-Infos
(dwarf-2) benötigt. Du musst dann halt das Makefile (oder entsprechende
Einstellungen in Eclipse) anpassen.
> In der Debug-Ansicht gibt es auch eine "Register" Ansicht. Da stehen die> Rxx Register drin. Da wäre es sinvoll auch die anderen SFRs mit> aufzunehmen. Blos zeigt der Debugger da nix an (alles 0).
Du kannst dir doch im Debugger sicherlich den Inhalt vom SRAM anschauen,
oder? Da sollten dann auch die SFRs mit drin sein.
(dwrarf-2): Hab ich auch getestet, irgendwie hat das auch nicht
geklappt.
SRAM anschauen: Ja, und die ganze Zeit im Datenblatt nach den HEX
Adressen suchen und zählen und so.
Auch mit einer Pipette kann man einen Garten gießen, die ideale
Beschäftigung wenn ich mal Rentner bin.
Die ständigen ungewollten GDB/AvaRice hänger sollten auch verschwinden.
Wenn zumindest bei einer endenden GDB-Verbindung nicht gleich AvaRice
sich automatisch schließen würde, sondern wie der OpenOCD einfach da
bleibt und auf die nächste Verbindung wartet, dann wäre alles auch schon
einfacher.
Wie schon geschrieben, ich nutze gerne Eclipse. Hr. Holland wird sicher
einiges beitragen, dass man damit ordentlich debuggen kann!
(Auf das freue ich mich schon jetzt...)
Denn VOR dem debuggen muss man erst mal Kompillieren können, und das ist
mit dem AVR Plugin wirklich sehr gut gelungen!
Hallo Markus,
ich habe es mir noch nicht richtig angeschaut, aber ich vermute dass die
Probleme beim Debuggen mit Eclipse von der Schnittstelle Eclipse <->
avr-gdb/avarice herrühren.
Ich will nichts versprechen, aber ich hoffe mal das die Probleme lösbar
sind. Bis vor zwei Tagen hat mir noch die Hardware gefehlt um selbst mit
JTAG zu debuggen, aber jetzt habe ich alles zusammen und schon mal die
ersten Tests gefahren.
Mein erster Eindruck ist, dass der Eclipse Debugger via avr-gdb Befehle
an avarice schickt die dieser nicht versteht und mit einem sofortigen
Abbruch quittiert.
Aber da sind sicher noch einige Tests nötig um raus zu finden woran es
genau hakt.
BTW: Gibt es für das Debuggen des Cortex M3 ein spezielles Plugin?
Wenn nicht dann hätte ich noch die Frage, welche Debug Configuration Du
(erfolgreich) benutzt:
- "Local C/C++ Application" oder
- "GDB Hardware Debugging" oder
- eine der Zylin Konfigurationen aus dem "Zylin embedded" Plugin?
LG
Thomas
P.S. graue Haare habe ich schon einige, da kommt es auf ein paar mehr
oder weniger nicht an :-)))))
Hi Thomas,
was fehlen dir genau für Infos? Vielleicht kann ich sie dir geben?
Ich debugge ja schon eine Weile mit Eclipse und kann mich nicht
beklagen.
Nutze JTAG ICE MkII.
Allerdings habe ich auch ab und an "Hänger", was scheinbar bei mir an
einer gestörten TCP/IP Kommunikation zwschen AVR-GDB und AVaRice liegt.
Wenn das passiert, dann geht auf meinem Rechner plötzlich nichts mehr
mit TCP/IP und er verhält sich auch merkwürdig (neu booten).
Das passier nur, wenn ich debugge, sonst läuft der Rechner 1A. Also ich
vermute, dass es schon an den AVR-Debug-Tools liegt.
Register ansehen geht mit Eclipse auch, hab grad nur nicht im Kopf wie.
Ich meine es gibt einen View, der sich "Register" nennt. Dort findet man
alles (zumindest bei einem ATMEGA16/32/64).
Das AVaRICE sich beendet nach beenden von AVR-GDB ist blöd, könnte das
Plugin aber retten indem es AVaRICE dann bei einer Debugsession aufruft.
Warum es sich beendet kann Jörg Wunsch sicher beantworten. Vielleicht
ließt er hier mit.
Was mich aber echt nervt ist, das Single- und Procedure-Step nicht
sauber laufen. Bei Procedurestep geht er trotzdem in die Unterroutine.
Aber ich meine das macht er auch im Studio. Da hatte ich auch solche
Probleme. Also ATMEL, haut in die Tasten :-)
Das der Chip jedesmal neu programmiert werden muß mit AVaRICE stimmt so
nicht. Man kann ihm das über Parameter mitteilen, ob der Chip
programmiert wird oder nicht. Ich habe zwei Aufrufe in den "External
Tools" bei Eclipse eingebaut. Einer der AVaRICE nur zum Debuggen aufruft
und einen der auch vorher neu programmiert, falls ich neu übersetzt
habe. Das könnte das Plugin auch erledigen. Seitdem Du ARVDUDE
eingebunden hast, programmiere ich damit. Geht deutlich schneller als
mit AVaRICE. NICE! :-)
Am WE habe ich sicher mal Zeit, dir die nötigen Infos zu geben. Erzähl
mal, was dir nicht klar ist. Evtl. kann ich ja helfen.
Ciao und wie immer guten Flug :-)
900ss
PS. Und ich kann auch nur nochmal betonen, dass Plugin ist bisher
Spitze.
Auf das Du noch lange die Motivation hast, daran zu arbeiten.
Falls Du mal wieder hier sein solltest, ich geb einen aus. Prost :-)
- Standard Eclipse Installation 3.4.1
- dann mit Help >> SW-Updates... Zylin installiert
- Codesourcery Light als Compiller/debugger
Richtig debuggen geht hier auch nur mit der -O0 Optimierung. Bei anderen
Optimierungsstufen fasst der Compiller ev. mehrere C-Zeilen zusammen.
Der OpenOCD ist V1131 von der MT Homepabe.
Für den GDB Debugger müssen entsprechende Monitor-Befehle eingegeben
sein, damit wird z.B. im Prozessor der WDT abgestellt usw.
Die Schnittstelle avr-gdb <> avarice ist das Problem. Ich hatte ähniche
Probleme mit OpenOCD <> arm-elf-gdb beim LPC2368 Chip, aber die neue
OpenOCD Version funktioniert damit auch. Schlussendlich läßt sich das
Problem auf avarice beschränken. Denn der gdb debugger ist ja schon
sowas wie ein Standard und der avarice ist die Schnittstelle zwischen
TCP/IP-GDB-Protokoll und JTAG.
PS: dann kommt also nur noch der Haarausfall...
Danke für die Infos zum Debuggen. Wie ihr seht stehe ich da noch am
Anfang und muss mich noch einarbeiten. Aber noch habe ich ein paar Tage
frei und werde diese entsprechend ausnutzen (um endlich 2.3 fertig zu
stellen :-))
Hat schon jemand AVaRICE 2.8 ausprobiert?
Die Liste der Bugfixes ist lang und vielleicht läuft es ja besser als
sein Vorgänger.
Thomas
Moin Moin,
so, ich habe mal etwas rumprobiert und da ich ein paar Fortschritte
gemacht habe möchte ich hier einen kurzen Zwischenbericht geben.
Environment:
- WinAVR-20081124rc3 mit avarice 2.8
- Eclipse 3.4 mit CDT 5.0.1
- AVR Eclipse Plugin 2.3beta1 (+ ein paar Bugfixes, aber nichts was mit
debugging zu tun hat)
- aus dem CDT Paket das optionale Plugin "Eclipse C/C++ GDB Hardware
Debugging"
Wer es noch nicht kennt: Das "GDB Hardware Debugging" Plugin ist eine
Nachprogrammierung des Zylin Plugins durch die offizielle CDT Truppe.
Es ist auf der CDT Ganymede Update-Site (
http://download.eclipse.org/tools/cdt/releases/ganymede ) als optionales
Feature zu finden.
Hardware:
- AVR Butterfly über JTAG an AVR Dragon
Dann AVaRICE wie folgt gestartet:
1
avarice --dragon --ignore-intr --jtag usb :4242
(Upload des Projektes auf den Butterfly hatte ich vorher mit avrdude
gemacht)
Die Einstellungen für die Eclipse Debugger Configuration entsprechend
der angehängten Screenshots.
Debugging gestartet und es läuft! Ich habe jetzt ca. eine Stunde damit
rumgespielt und es sind keine Fehler aufgetreten und avarice ist nicht
einmal abgestürzt (Ausnahme: s.u.).
Ich kann in Funktionen reinspringen, sie überspringen, Breakpoints
setzen und sowohl im C Code als auch im Assembler Code steppen.
Register, Memory und Variablen werden alle - soweit ich es erkennen kann
- korrekt angezeigt.
Das einzige was nicht geht ist ein Restart. Wenn man auf den Restart
Button drückt schickt Eclipse ein "-exec-run" Befehl los, woraufhin sich
avarice verabschiedet.
Um einen Soft-Reset zu erreichen habe ich als Workaround einfach im
Register View den PC auf "0" gesetzt und dann auf den Run Button
gedrückt. Funktioniert einwandfrei, ist aber nur ein Soft-Reset mit den
damit verbundenen Nebenwirkungen (kein Reset der I/O Register).
Dazu vielleicht noch eine Frage an die Experten (Jörg?): Gibt es eine
Möglichkeit per AVaRICE einen Hard Reset auszulösen?
Ansonsten bin ich sehr zufrieden mit dem Ergebnis. Es ist eine gute
Basis auf der ich jetzt weitere AVR spezifische Funktionen aufbauen kann
(I/O Register View wäre da mein erstes Ziel)
Eine Frage hätte ich noch. Das Steppen ist auffallend langsam. Ist das
JTAG Systemimmanent oder liegt es an dem niedrigen JTAG Takt (habe den
Default von 250KHz belassen)?
Thomas
Ich debugge gerade nich mit AVRStudio. Da ist es auch sehr träge, der
Einzel-Stepp Modus.
Vielen Dank für diese Tipps, ich werde es gleich morgen mal unter
Eclipse versuchen.
Ein View dieser Register wäre echt eine riesige Hilfe!
Es ist warscheinlich schon ziemlich Aufwändig alle Register aller Atmels
rein zu bekommen.
Ich nutze den AT90CAN128.
> Es ist warscheinlich schon ziemlich Aufwändig alle Register aller Atmels> rein zu bekommen.> Ich nutze den AT90CAN128.
Schau Dir doch mal den "AVR Device Explorer" View am. Wenn der
AT90CAN128 dabei ist, dann hat das Plugin schon die Adressen aller
Register (allerdings nicht die Namen der einzelnen Bits, da es deutlich
schwieriger ist die aus den AVR Include Dateien konsistent auszulesen)
Thomas Holland wrote:
>> Wer es noch nicht kennt: Das "GDB Hardware Debugging" Plugin ist eine
Das war wohl bei schon immer defaultmäßig mit installiert. Habe es
gerade geprüft. Auch eine alte Eclispeinstallation habe ich wieder
ausgegraben dort war es auch enthalten. Habe es aber glaube ich nie
explizit installert.
> Die Einstellungen für die Eclipse Debugger Configuration entsprechend> der angehängten Screenshots.
Ich habe das gerade probiert mit deiner Methode. Läuft bei garnicht. Es
macht irgendwas mit dem AVaRICE aber zum debuggen kommt er nicht. Es
wird auch nicht auf die DEBUG-Perspective in Eclipse umgeschaltet.
Ich benutze sonst nicht "GDB Hardware debugging" sondern "C/C++ Local
Application". Damit geht es gut. Sehr merkwürdig. Ich habe auch AVaRICE
2.8 verwendet. Das steppen "Step into" und "Step over" geht allerdings
wenn ich eine Debugsession am laufen habe. Das hatte ich schon ewig
nicht mehr versucht, weil es immer nur ärger machte. Hatte immer RUN mit
Breakpoints verwendet. Jetzt scheint es gut zu klappen. Ob es auch schon
in AVaRICE 2.7 so ging? Keine Ahnung ;-)
> Debugging gestartet und es läuft! Ich habe jetzt ca. eine Stunde damit
Solange du nicht immer wechselst zwischen Debugging und editieren, d.h.
das Debuggen immer startest und stoppst (wegen Neuprogrammierung) geht
es auch "recht rund".
> Das einzige was nicht geht ist ein Restart. Wenn man auf den Restart> Button drückt schickt Eclipse ein "-exec-run" Befehl los, woraufhin sich> avarice verabschiedet.
Es gibt irgendene Option beim AVaRICE "--reset-srst External reset
through nSRST signal.", die ich aber nicht verstehe.
> Eine Frage hätte ich noch. Das Steppen ist auffallend langsam. Ist das> JTAG Systemimmanent oder liegt es an dem niedrigen JTAG Takt (habe den> Default von 250KHz belassen)?
Das liegt an dem niedrigen Takt. Ich habe hier gerade einen AVR mit
16MHZ betrieben und die Option -B4000000 mit übergeben. Dann flutscht
es.
Ah ja, ich benutze den ICE MkII über die serielle Schnittstelle.
Gruß
900ss
PS. Hast auch sonst noch einen Elektrobrief von mir.
Nachtrag:
Eben mußte ich meine Rechner neu booten. Es ließen sich die normalen
Anwendungen nicht mehr beenden. Das tritt ausschließlich auf, wenn ich
mit AVaRICE und Eclipse debugge. Und es liegt auch nicht an meiner
Windowsinstallation, da ich es auch auf einer alten Installation
(anderer Rechner) genauso hatte. Das ist echt nervig. Aber vielleicht
nutze ich irgendein Tool (welches immer im Hintergrund läuft ), was dazu
beiträgt. Das kann ich nicht sagen.
900ss D. wrote:
> Thomas Holland wrote:>>>> Wer es noch nicht kennt: Das "GDB Hardware Debugging" Plugin ist eine>> Das war wohl bei schon immer defaultmäßig mit installiert. Habe es> gerade geprüft. Auch eine alte Eclispeinstallation habe ich wieder> ausgegraben dort war es auch enthalten. Habe es aber glaube ich nie> explizit installert.
Edit: Hab gerade geschaut und im "Eclipse for C/C++" Paket von
eclipse.org ist das "GDB Hardware Debugging" Plugin nicht dabei und muss
separat installiert werden.
> Ich habe das gerade probiert mit deiner Methode. Läuft bei garnicht. Es> macht irgendwas mit dem AVaRICE aber zum debuggen kommt er nicht.
Welche Versionen von Eclipse, avr-gdb und avarice?
Ich hatte alle auf dem allerneusten Stand (winAVR-20081124rc3, Eclipse
3.4.1 = CDT 5.0.1). Vielleicht klappt es nur in dieser Kombination.
Ansonsten: schick mir doch mal den Output von avr-gdb, des Eclipse mit
"verbose GDB output" generiert. Vielleicht kann ich erkennen was daran
anders ist als bei mir (hab allerdings erst ab Sonntag Abend wieder Zeit
dafür)
> Es> wird auch nicht auf die DEBUG-Perspective in Eclipse umgeschaltet.
Das tut's bei mir übrigens auch nicht. Ist wohl ein Bug im CDT.
> Ich benutze sonst nicht "GDB Hardware debugging" sondern "C/C++ Local> Application". Damit geht es gut. Sehr merkwürdig.
Ist eigentlich nicht merkwürdig, da die "Debug-Engine" bei beiden gleich
ist. Die genauen Unterschiede kenne ich auch nicht. Irgendwann werde ich
mal den GDB output der beiden Konfigurationen vergleichen um zu sehen
worin eigentlich der Unterschied besteht. Ich vermute mal das die
Unterschiede nur in der Initialisierung bestehen.
> Solange du nicht immer wechselst zwischen Debugging und editieren, d.h.> das Debuggen immer startest und stoppst (wegen Neuprogrammierung) geht> es auch "recht rund".
Na ja, bei Editierungen muss ja sowieso neu geflashed werden, da ist
ohnehin ein Neustart fällig.
Ein Restart wäre vielleicht interessant wenn man zu weit gesteppt hat
und wieder zu einer früheren Stelle zurück gehen möchte.
>>> Das einzige was nicht geht ist ein Restart. Wenn man auf den Restart>> Button drückt schickt Eclipse ein "-exec-run" Befehl los, woraufhin sich>> avarice verabschiedet.
Ich muss zur Ehrenrettung von avarice sagen, dass dieser "Fehler" nicht
an avarice liegt, sondern an avr-gdb. Als Folge des "-exec-run" schickt
avr-gdb ein <k> Befehl an avarice, woraufhin sich dieser pflichtgemäß
selbst 'killed'. Leider ist gdb ein ziemliches Brocken, da habe ich noch
nicht nachvollziehen können warum gdb das macht.
>> Es gibt irgendene Option beim AVaRICE "--reset-srst External reset> through nSRST signal.", die ich aber nicht verstehe.
Ich auch nicht. Wenn ich die Kommentare im avarice Source Code richtig
verstehe dann hat es was mit dem Programmiermode zu tun, bei dem mit
--reset-srst die Reset Leitung im Target anders angesteuert wird.
>>> [Steppen langsam]>> Das liegt an dem niedrigen Takt. Ich habe hier gerade einen AVR mit> 16MHZ betrieben und die Option -B4000000 mit übergeben. Dann flutscht> es.
Dann muss ich doch mal schauen was für einen Takt der Butterfly hat.
Vielleicht kann ich ja noch ein bisschen beschleunigen.
LG
Thomas
Thomas Holland wrote:
> Welche Versionen von Eclipse, avr-gdb und avarice?
Die aktuellen jeweils, also die gleiche Kombination, die du auch nutzt.
> Ansonsten: schick mir doch mal den Output von avr-gdb, des Eclipse mit> "verbose GDB output" generiert. Vielleicht kann ich erkennen was daran> anders ist als bei mir (hab allerdings erst ab Sonntag Abend wieder Zeit> dafür)
Muß ich mal erzeugen, dann pappe ich es dir an eine Nachricht.
>> Solange du nicht immer wechselst zwischen Debugging und editieren, d.h.>> das Debuggen immer startest und stoppst (wegen Neuprogrammierung) geht>> es auch "recht rund".>> Na ja, bei Editierungen muss ja sowieso neu geflashed werden, da ist> ohnehin ein Neustart fällig.
Und genau das stoppen und wieder neustarten läßt das Zeugs irgendwann
wacklig werden. Hab noch nicht rausbekommen, was es genau ist.
>> Ein Restart wäre vielleicht interessant wenn man zu weit gesteppt hat> und wieder zu einer früheren Stelle zurück gehen möchte.>
Aktuelle Debugumgebungen können das mittels "Set Instruction Counter".
Da kann man eine Sourcecodezeile anwählen :-) Natürlich alles im Rahmen.
Also nicht plötzlich von einer Funktion in eine andere setzen. Man muß
schon ein bischen wissen, was man da tut.
>>>>> Das einzige was nicht geht ist ein Restart. Wenn man auf den Restart>>> Button drückt schickt Eclipse ein "-exec-run" Befehl los, woraufhin sich>>> avarice verabschiedet.>> Ich muss zur Ehrenrettung von avarice sagen, dass dieser "Fehler" nicht> an avarice liegt, sondern an avr-gdb. Als Folge des "-exec-run" schickt> avr-gdb ein <k> Befehl an avarice, woraufhin sich dieser pflichtgemäß> selbst 'killed'. Leider ist gdb ein ziemliches Brocken, da habe ich noch> nicht nachvollziehen können warum gdb das macht.
Dann sollte in AVaRICE eine Option, dass es nicht auf en <k> reagiert.
Dann muß man ihn halt abschießen oder was weiß ich. Muß ich mich mal mit
Jörg in Verbindung setzen.
Was die Geschindigkeit des Debuggens auch beeinflußt sind die Fenster,
die man in Eclipse auf hat. Wenn man z.B. das Disassemblerfenster auf
hat, dann merkt man schon deutlich. Und memory u.s.w. natürlich auch, da
ja alles nach jedem Step refresht wird. Und die Infos müssen ja alle aus
dem AVR gesaugt werden.
900ss
>Edit: Hab gerade geschaut und im "Eclipse for C/C++" Paket von>eclipse.org ist das "GDB Hardware Debugging" Plugin nicht dabei und muss>separat installiert werden.
Woher kann ich das bekommen. Link?
Bei mir klappt das debuggen nicht.
Ich habe den AvaRice.exe mit den Parametern gefüttert:
-1 -P at90can128 --ignore-intr -j /dev/com1 :4242
Wenn ich die Parameter nehme:
-1 -P at90can128 -f MyFile.elf --ignore-intr -j /dev/com1 :4242
Dann geht das Debuggen, aber auch nicht richtig. Erstmal lädt der das
Projekt runter, dann Register sind immer alle "0" und erneutes Play
lässt alles abstürzen.
Ich würde das gerne noch mit dem "GDB Hardware Debugging" Plugin testen.
> Woher kann ich das bekommen. Link?
Siehe weiter oben, in meinem Beitrag mit den Screenshots.
Update Site: http://download.eclipse.org/tools/cdt/releases/ganymede>> Bei mir klappt das debuggen nicht.>> Ich habe den AvaRice.exe mit den Parametern gefüttert:> -1 -P at90can128 --ignore-intr -j /dev/com1 :4242>> Wenn ich die Parameter nehme:> -1 -P at90can128 -f MyFile.elf --ignore-intr -j /dev/com1 :4242
-P habe ich weggelassen da avarice die MCU (bei mir) sowieso richtig
erkennt.
-f file.elf hatte ich auch probiert, aber mit den selben Problemen wie
bei dir.
Aber braucht avarice die .elf überhaupt? Solange man nicht mit avarice
flashed sehe ich keinen Grund avarice das File zu geben. Zumindest bei
mir funktioniert es ohne (den upload des Programms zum Target mache ich
mit avrdude)
So, bin jetzt übers Wochenende die bucklige Verwandtschaft besuchen, am
Montag schaue ich dann ob Du erfolg hattest :-))
Thomas
@Markus
Da es soviele Probleme gibt mit dem AVaRICE/GDB habe ich nochmal meine
aktuellen Konfigurationsdialoge für Eclipse in den Anhang gepackt.
Ich arbeite seit ca. 1 Jahr so und es klappt eigentlich gut bis auf die
Probleme, die ich oben beschrieben habe (mag aber auch ein spezielles
Problem bei mir sein). Grundsätzlich geht es aber zufriedenstellend
(auch schnell).
Ich nutze Eclipse 3.4.1 Ganymede, CDT 5.0.1. Ich habe zwar diese GDB
Hardware Debug Tools installiert, aber ich nutze sie nicht.
Der Aufruf von AVaRICE sieht bei mir wie folgt aus:
avarice -2 -B4000000 --jtag /dev/com4 :4242
Bei Dir sollte es sein:
avarice -1 -Bxxxxxxx --jtag /dev/com1 :4242
wobei du xxxx durch AVR-Clockfrequenz/4 erstzen mußt.
Also Z.B. Takt 4MHz --> 1000000
Laut Help vom AVaRICE gehen beim JTAG ICE MkI nur folgende Werte
1000/500/250/125 kHz. Wobei du diese wohl auch in Hz angeben mußt.
Du kannst die -B Option auch weglassen, dann arbeitet er default
mit 250KHz, dein AVR sollte dann max. 1MHz Clock haben.
Alle anderen Optionen brauchst du eigentlich nicht.
Den AVR mußt du VORHER programmieren und auch die Fuses setzen.
Wie du Eclipse konfigurierst, findest du im Anhang. Das GDB Hardware
Debugging habe ich nicht vernünftig zum laufen bekommen. Ich arbeite
schon seit ca. 1 Jahre mit der Lösung wie hier beschrieben und es klappt
recht gut.
Nochwas, irgendwo auf eclipse.org habe ich gelesen, dass die CDT nicht
mit einfachen entpacken des ZIP-Files in Eclipse installiert werden
können.
Du mußt das über die Update-Sites in Eclipse machen oder dir gleich das
Eclipsepaket mit dem integrierten CDT runterladen und installieren.
Dann probier mal.
Gruß
900ss
Hallo,
ich bin auch auf Eclipse umgestiegen und versuche zur Zeit den GDB
HardwareDebugger zu verwenden.
Hier meine SW Versions: Eclipse 3.4.1 mit CDT 5.0.1
AVR Plugin V2.2.0
WinAVR-20081124rc3 mit avarice 2.8
Außerdem verwende ich den AVRDragon und arbeite mit einem ATMega128
Board.
Das Compilieren und Flashen (über AVRDUDE) funktioniert.
Zum Debuggen bin ich wie von Thomas Holland beschrieben vorgegangen.
Projekt compiliert => Hex-File in ATMega geflashed => AVARICE gestartet
=> Einstellungen für GDB HWDebuger laut T. Holland => Debugging startet
mit folgendem Error:
AVARICE
****************************************************
D:\Technik\Software\WinAVR\bin>avarice --dragon -B4000000 --ignore-intr
--jtag u
sb :4242
AVaRICE version 2.8, Nov 7 2008 22:02:05
JTAG config starting.
Found a device: AVRDRAGON
Serial number: 00:a2:00:00:13:2a
Reported JTAG device ID: 0x9702
Configured for device ID: 0x9702 atmega128
JTAG config complete.
Preparing the target device for On Chip Debugging.
Disabling lock bits:
LockBits -> 0xff
Enabling on-chip debugging:
Extended Fuse byte -> 0xff
High Fuse byte -> 0x19
Low Fuse byte -> 0xbf
Waiting for connection on port 4242.
Connection opened by host 127.0.0.1, port 2813.
cannot read program counter
GDB HWDebugger Console
****************************************************
No symbol "new" in current context.
target remote localhost:4242
Remote connection closed
tbreak main
Cannot access memory at address 0x20c
continue
The program is not being run.
Hat jemand ne Idee was da falsch läuft bzw. wo mein Fehler liegt?!?!?
Ciao
Boisi
Boisi wrote:
> Zum Debuggen bin ich wie von Thomas Holland beschrieben vorgegangen.> Projekt compiliert => Hex-File in ATMega geflashed => AVARICE gestartet> => Einstellungen für GDB HWDebuger laut T. Holland => Debugging startet> mit folgendem Error:>>> AVARICE> ****************************************************> D:\Technik\Software\WinAVR\bin>avarice --dragon -B4000000 --ignore-intr
Wo hast du die Option -B4000000 her? Habe ich bei Thomas Holland nicht
gefunden. Wenn Du weißt was sie bedeutet findest du den Fehler evtl.
selbst wenn es denn daran liegt. Das kannst nur du beurteilen wenn du
weißt, was sie bedeutet. Nur du kennst deine Hardware.
Die Bedeutung ist hier im Thread beschrieben.
Thomas, übrigens scheint das Problem weg zu sein, dass sich bei
mehrmaligen Starten/Stoppen AVARICE nicht mehr richtig verhält und bei
mir meinen ganzen Rechner durcheinander bringt. Es scheint an der von
mir verwendeten Portnummer 4242 zu liegen. Wenn ich 10000 verwende, dann
klappt es bis jetzt jedenfalls stabil. Ich konnte allerdings kein
Programm entdecken, welches die Nummer benutzt. Nun egal.... mal
abwarten. Es klappt super inzwischen. Wenn jetzt noch dein Plugin den
AVR unterstützt, ich meine mit Registeranzeige, deren Bitbedeutung
u.s.w., oh man das wäre ja ein Traum :-)
Hallo,
natürlich habe ich das ganze erst mal ohne die Option -B4000000
ausprobiert. Mit dem gleichen Ergebnis.
Ich habe ein ATMega128 Board mit 16MHz Takt. Laut den Berichten oben
dürfte das ok sein. Dabei geht es ja nur um die Schnelligkeit des
Debuggens.
So wie es aussieht startet ja erstmal alles an. Durch den Fehler "No
symbol "new" in current context" in der Console von Eclipse wird dann
wohl die Verbindung zum AVARICE disconnected. ?!?!?
Ciao
Boisi
Boisi wrote:
> Hallo,>> natürlich habe ich das ganze erst mal ohne die Option -B4000000> ausprobiert. Mit dem gleichen Ergebnis.
Du hast geschrieben, du hast es so gemacht, wie Thomas beschrieben hat.
Stimmt aber nicht. Durch falsche Angaben suchen andere Leute dann länger
nach deinem Fehler.
> Ich habe ein ATMega128 Board mit 16MHz Takt. Laut den Berichten oben
OK, wollte nur sicher sein, das deine Hardware mit der -B4000000 auch
klar kommt. Und dass du verstehst, wofür die Option ist :-)
> dürfte das ok sein. Dabei geht es ja nur um die Schnelligkeit des> Debuggens.
So ungefähr. Mehr als 1/4 der Controllertaktfrequenz darfst du
einstellen aber es funktioniert dann nicht mehr. Wird also auch nicht
mehr schneller ;-)
Der Fehler ist, dass der Dragon den MEGA128 nicht debuggen kann. Nur
devices <= 32kB Flash. Programmieren kann er die größeren Devices wohl.
Mußt wohl mal shoppen gehen und dir 'n ICE MkII holen ;-)
Hallo,
das war natürlich ein guter Tip. Ich hab jetzt mein OLIMEX AVR-JTAG-USB
Teil angeschlossen und siehe da, es geht.
Wobei ich zu meiner Verteidigung sagen muß, dass das Debuggen unter
AVRStudio mit dem AVRDragon und nem ATMega128, bei dem lediglich <32k
belegt waren funktioniert hat.
Egal jetzt läuft's. Danke nochmal.
Ciao
Boisi
Hallo,
wenn ich es richtig lese dann scheint das debuggen jetzt bei den meisten
mehr oder weniger zu funktionieren.
Wenn noch jemand Probleme hat dann würde es für die Fehlersuche helfen,
wenn ihr in Eclipse den "verbose GDB output" aktiviert und dessen Output
(im Console View) mitschickt. Nur damit kann man den richtigen Auslöser
eines Abbruchs richtig zuordnen.
Zum Beispiel könnte man dem Log Auszug weiter oben von boisi ...
>GDB HWDebugger Console>****************************************************>No symbol "new" in current context.>target remote localhost:4242>Remote connection closed
... vermuten, dass 'No symbol "new" in current context' der Auslöser für
den Abbruch ist. Das ist aber eine normale Meldung und kommt auch wenn
alles funktioniert.
Der wahre Abbruchgrund war irgendwas anderes, was aber nicht angezeigt
wurde und zwischen den Zeilen "target remote..." und "Remote connection
closed" passiert ist. (in diesem Fall war es >32K flash am Dragon).
Je nach Situation könnte evtl. auch das avarice debug log hilfreich sein
(option -d), allerdings ist es sehr voluminös und sollte nur
auszugsweise oder als .zip angehängt werden.
Thomas
Mal eine Frage dazu: Geht das beim avr-gdb plus avarice gar nicht, dass
man beim Start der Debug-Session den Code gleich in den Flash bringt?
Ich kenn das vom msp430-gdb und msp430-gdbproxy so, dass man in Eclipse
halt einstellt, dass der vor den Debug noch
monitor erase main
load program.elf
macht, und dann lädt der automatisch das aktuelle Elf-File, und startet
anschließend die Debug-Session.
Übrigens: Das Restart-Problem gibts da auch. Eclipse bzw. GDB schickt
ein exec-reset oder sowas, und der proxy erwartet aber ein monitor
restart. Also schmiert die ganze Geschichte beim Drücken des Buttons ab.
Ansonsten sehr zuverlässig und schnell.
@Christian R.
Dem AVaRICE kann man in der Kommandozeile mitteilen, das er einen
Hexfile flashen kann, danach startet er dann die Debugsession. Geht also
auch.
Doch, 'load' geht auch (theoretisch)
Wenn Du die "GDB Hardware Debugging" Konfiguration nimmst, dann kannst
Du im 'Startup'-Tab entweder 'Load Image' aktivieren und dort entweder
die elf oder die hex Datei auswählen. Oder oben im leeren Textfeld Dein
'load filename' eingeben, wobei Du unter Windows die Backslashes doppelt
eingeben musst ('\' -> '\\')
Bei der ersten Variante benutzt Eclipse übrigens den GDB Befehl
'restore' und nicht 'load', das Ergebnis sollte aber das selbe sein
(s.u.)
Oben habe ich theoretisch geschrieben, weil es bei mir nicht
funktioniert! In der Kombinatation avr-gdb 6.8 -> avarice 2.8 -> Dragon
JTAG -> Butterfly
schreibt avarice falsche Daten ins Flash.
Ich bin gerade am suchen woran es liegen könnte, aber es scheint mir ein
Timing problem bei avarice zu sein. Im avarice debug output tauchen jede
Menge "recv: timeout" und "got wrong sequence number, xx != xx+1"
Meldungen auf.
Im Endeffekt werden die 32 Bytes ab 0x60 bei 0x00 ins flash geschrieben
und danach wir nur jeder vierte 32 Byte Block geflashed, alle anderen
Blöcke dazwischen bleiben unprogrammiert.
Werde das Problem mal in der avarice Maillist platzieren, vielleicht hat
da jemand eine Ahnung woran es liegen könnte.
Avarice mit der option "--program --file filename.hex/.elf" geht bei mir
übrigens gar nicht. Obwohl laut avarice debug output alle Daten
erfolgreich ins flash geschrieben werden ist selbiges hinterher komplett
leer.
Thomas
Thomas Holland wrote:
> Avarice mit der option "--program --file filename.hex/.elf" geht bei mir> übrigens gar nicht. Obwohl laut avarice debug output alle Daten> erfolgreich ins flash geschrieben werden ist selbiges hinterher komplett> leer.
Hi Thomas,
ich habe gerade verschiedene Variationen zum Flashen mit AVaRICE
probiert.
Wenn Du -e wegläßt, wird der Chip vor dem programmieren nicht gelöscht
und danach steht natürlich Schrott im Flash wenn es nicht gelöscht war.
Du mußt zum Programmieren auch -e angeben, wenn das Flash nicht gelöscht
ist. Folgende Zeile löscht das Flash, programmiert es dann und danach
kommt ein Verify (-v).
-v kan man auch weglassen.
avarice -2 -e -p -v -f LEDUhr.hex -B4000000 --jtag /dev/com4
[Edit] Es geht auch so, dann löscht er und programmiert danach.
Aber es gibt kein verify.
avarice -2 -e -f LEDUhr.hex -B4000000 --jtag /dev/com4
Gruß
900ss
Avarice schreibt bei mir definitiv nichts ins flash (bzw. müll wenn man
es über gdb macht)
Was ich nur nicht weiss: liegt es an meinem Setup oder ist es ein
generelles Problem. Ich habe es jedenfalls gerade unter Linux probiert
mit dem selben resultat => daran liegt es also nicht.
Grundsätzlich muss es funktionieren, denn sowohl avrdude als auch
AVR-Studio haben bei mir keine Probleme über den Dragon und JTAG einen
Butterfly zu programmieren.
Ich mach mal einen neuen Thread auf um zu erfragen ob es sich um ein
grundsätzliches Problem mit avarice handelt oder ob es bei anderen mit
ähnlicher Konstellation funktioniert.
Du musst avarice mit "-d" starten um genauere Informationen zu bekommen
warum die Kommunikation versagt hat. Ohne "-d" können wir dem Problem
nicht näher kommen.
> Bei Menü Project >> Clean werden alle Dateien ausser die .map Datei nicht> gelöscht. (AVR-Plugin)
Das ist leider Prinzipbedingt so und mit meinem aktuellen Kenntnisstand
von CDT nicht zu beheben. Lösch einfach das ganze Ausgabe-Verzeichnis.
Das ist genau so schnell und zuverlässig.
@Markus
es reicht jetzt echt. Ich danke dir für das Vertrauen. Siehe
Beitrag "Re: avarice + dragon: Flash programmieren geht nicht"
Ich hatte oben alle Einstellungen gepostet und die nutze ich und andere
schon sehr lange. Es funktioniert genauso so. PUNKT.
Wenn es bei dir nicht läuft dann hat es andere Ursachen aber es liegt
nicht an den Einstellungen.
Wenn Thomas dich hier fragt, du möchtest bitte avarice mit "-d" starten
um genauere Informationen zu bekommen dann ist das schon etwas was du
machen solltest, damit wir sehen, was schief läuft. Ich könnte dann auch
mal drüber schauen.
Aber da müßtest du dich ja bemühen.
So machst du die es etwas einfach. Willst alles vorgesetzt bekommen,
bekommst es auch und wenn es nicht läuft sind die anderen zu dumm und
wir fragen noch jemand anderes (Jörg).
Wenn du zu faul bist hier Infos zu deinen Problemen zu liefern, dann
wundere dich nicht, wenn hier auch nichts mehr kommt.
-d kann ich machen, aber erst morgen, ich habe die Hardware leider nicht
zu hause.
Ich hab die Einstellungen genau so eingegeben, auch den Port mal von
4242 auf 10000 umgestellt. (Deine Posts vom Ende letzter Woche ...)
Ich starte Avarice, ok ist da.
Ich starte AVR-GDB, der kommt, denn verschwinden beide.
Es gibt auch nicht so viele Parameter, man kann eigentlich nichts falsch
machen. Ich mache morgen von allem mal Screenshots und zippe die
zusammen.
Die Fragen an Jörg sind schon berechtigt, finde ich, denn beim
ARM-ELF-GDB und OpenOCD geht ohne solche monitor und andere Parameter
gar nichts! Auch klappt es nicht wenn man von den Programmen eine
falsche Version verwendet. So muss ich für den Cortex die OpenOCD
Version R247 und für den ARM7 die Version V1190 verwenden.
Leider muss ich in meiner Firma auch Arbeiten und habe ein Projekte das
bis morgen Abend laufen muss (!), denn am Mittwoch soll IBN stattfinden,
daher seid mir bitte nicht böse, wenn ich die Tests mit Eclipse nicht so
Zeitnah durchführen kann.
Ich aktiviere für den AVR-GDB dann auch gleich Verbose-Out, dann sieht
man nochmals mehr.
Markus wrote:
>> Die Fragen an Jörg sind schon berechtigt, finde ich,
Ja dann viel Glück.
> denn beim> ARM-ELF-GDB und OpenOCD geht ohne solche monitor und andere Parameter> gar nichts!
Dann nimmst du an, wir hätten dir diese Infos verschwiegen bzw. nicht
alles ausführlich genug geschildert. Ja dann mußt du andere fragen.
> Auch klappt es nicht wenn man von den Programmen eine> falsche Version verwendet.
Zusammenspielende Versionen wurden hier auch genannt.
Liest du eigentlich, was hier geschrieben wird?
Ja, natürlich, diese Versionen gabe ich auch geladen und installiert.
Bevor ich diesen Thread aufgemacht habe, hab ich selbst schon ein paar
Tage "Probiert". (Und ein IAR Projekt auf GNU umgestrickt).
Ich bin mir sicher, dass hier niemand was verschwiegen hat oder wie auch
immer, aber kann es nicht sein, dass ich noch in irgend welchen anderen
Projekteinstellungen noch irgendwo ein häckchen setzen muss, das bei mir
aus irgend einem Grund (den ich vieleicht auch selbst verschuldet habe)
nicht gesetzt ist?
Sowas könnte ich doch ganz leicht herausfinden, wenn ich irgendwo ein
Demo Eclipse Projekt mit nur einer while(1); in der main() laden könnte.
Also mal ehrlich, diese 3 Screenshots, damit hätte nur ein Blinder
Probleme. Es muss zwischen Deiner und meiner Konfiguration doch noch
irgend wo der Hund begraben sein.
Ich hatte auch mal meinen MK1 Adapter im Verdacht.
Anbei ein ZIP mit allen Screenshots und Debug-Ausgaben in TXT Dateien.
Es sind alle Screend, von denen ich denke, die könnten Auswirkungen
haben.
Version vom November, RC3. AVR Plugin V2.2, Eclipse 3.4.1, CDT 5.0.1
Ich danke im Vorraus, für eure Unterstützung.
Markus wrote:
> Ich hatte auch mal meinen MK1 Adapter im Verdacht.
Das könnte schon sein:
JTAG ICE communication failed
91 00 41
Timed Out (partial response)
Vielleicht kannst du ja die Firmware mal neu flashen?
Ich selbst besitze seit geraumer Zeit kein JTAC ICE mkI mehr, insofern
kann ich die entsprechenden Codeteile weder in AVRDUDE noch in AVaRICE
noch irgendwie testen. Ich kann bei Modifikationen am Code nur hoffen,
dass da nichts kaputt geht.
Vielleicht gibt's ja in deiner Gegend jemanden, der dir mal ein JTAG
ICE mkII leihen kann?
Vielen Dank für Deine Antwort.
Ich schaue mal nach einem MKII, kann mich leider erst morgen darum
kümmern. Ich muss heute dringend die SW fertig kriegen.
Also ich habe das Teil:
http://olimex.com/dev/images/AVR/AVR-JTAG.jpg
Bei FW-Update habe ich schon ein bischen bamel dass es nicht klappt, ein
Kollege hat schon mal ein Teil "zerschossen".
Markus,
da hast Du Dir ja wahnsinnig Mühe gegeben alles zu Dokumentieren. Ich
habe mir mal alles Durchgeschaut und es ist in Eclipse alles richtig
Konfiguriert.
Da Du Dir so viel Mühe gegeben hast, habe ich mich auch mal hingesetzt
und habe den Output von avr-gdb und avarice gründlich analysiert.
Am Anfang ist alles gut. Eclipse schickt an avr-gdb den Befehl sich mit
avarice zu verbinden
1
9-target-select remote localhost:10000
Nachdem die TCP Verbindung aufgebaut wurde schickt avr-gdb ein paar
Statusanfragen, die aber avarice allesamt nicht kennt und ignoriert
1
GDB: <qSupported>
2
->GDB:
3
GDB: <?>
4
->GDB: S05
5
GDB: <Hc-1>
6
->GDB:
7
GDB: <qC>
8
->GDB:
9
GDB: <qOffsets>
10
->GDB:
11
GDB: <Hg0>
12
->GDB:
Dann will avr-gdb wissen, welche Werte in den MCU Registern stehen
1
GDB: <g>
avarice sendet den entsprechenden JTAG Befehl los und wartet auf 0x1F
Bytes, bekommt aber nur 3 Bytes von Deinem Olimax geliefert => timeout.
Ich habe hier den avarice output etwas aufgeräumt, da avarice (durch
async I/O oder durch Bufferflushes) ein paar irrelevante ausgaben
eingefügt hat.
41 am Ende der 'response' ist übrigens der Code für RESP_OK. Damit zeigt
der Olimax das für ihn die Ausgabe der Bytes zu Ende ist. Also sind
entweder 29 Bytes zwischendrin verloren gegangen (unwahrscheinlich) oder
der Olimax hat den Befehl "52 20 1F 00 00 00 20 20" falsch
interpretiert.
1
GDB: <g>
2
3
GDB: (Registers)Read 32 bytes from 0x800000
4
jtagRead
5
command[R, 1]: 52 20 1F 00 00 00 20 20
6
response: 91 00 41
7
Timed Out (partial response)
8
JTAG ICE communication failed
Damit ist für avarice Schluss. Es beendet sich und avr-gdb gibt eine (in
dem Zusammenhang irreführende) Fehlermeldung aus, was den Eclipse
Debugger ebenfalls zum Abbruch bewegt.
1
9-target-select remote localhost:10000
2
Remote communication error: No such file or directory.
3
&"Remote communication error: No such file or directory.\n"
4
9^error,msg="Remote communication error: No such file or directory."
Da ja avarice Grundsätzlich mit Deinem Olimax redet scheint es weder ein
Hardware noch ein Synchronisationsproblem zu sein. Vielleicht hilft da
wirklich ein Update der Firmware.
Thomas
P.S. @Jörg: Hat es irgendeinen Grund, warum avarice beim AT90CAN128 nur
31 Register-Bytes lesen möchte? Bei mir (Dragon => Atmega169) liest
avarice an der selben Stelle 32 Bytes aus dem Registerfile.
Thomas Holland wrote:
> P.S. @Jörg: Hat es irgendeinen Grund, warum avarice beim AT90CAN128 nur> 31 Register-Bytes lesen möchte?
Hat nix mit dem Controller zu tun. Ich musste mir auch erst einmal
die AVR060 wieder zu Gemüte führen, die ist einfach so dämlich
implementiert: die Anzahl der Bytes wird mit 1 weniger angegeben,
vermutlich, damit man 256 Bytes als 0xFF anfordern kann.
1
Word Count Number of words in package - 1. (word count = 0 [BYTE]
Vielen Dank für die Umfassende Analyse.
Ich würde mir gleich einen MKII raus lassen. Ich habe ein USB Teil von
Olimex noch zur Hand, der tut aber nur bei meinem Kollegen auf einem
Uraltrechner, bei mir nicht. Nun ist die Frage wechen soll ich nehmen?
Der "usbprog v3.0 (Adapter vormontiert)" von Embedded Projects sieht
nicht schlecht aus (nutzbar für AVR und ARM und Cortex :-)
oder lieber den "AVR-ISP500 - USB STK500v2" von Olimex
beide kosten ca. 30 EUR.
Dabei vavorisiere ich den ersten. Habt Ihr den auch im Einsatz oder soll
ich was anderes nehmen.
Wichtig ist, dass das ganze dann eben auch mit AVR-DUDE und AVaRICE
zusammenspielt.
Markus wrote:
> Welchen habt Ihr im Einsatz?JTAG ICE mkII ist JTAG ICE mkII. OK, es gibt mittlerweile einen
chinesischen Clone, aber das ist ein 1:1-Klau des Atmel-Teils bis
auf das JTAG-Kabel, und als wirklich ,,günstig'' würde ich den
Preis trotzdem nicht bezeichnen (gemessen daran, dass du dafür
natürlich keinerlei Garantie oder Support des Herstellers hast).
Du könntest mit einem AVR Dragon noch Glück haben. Offiziell kann
das Teil zwar keine Controller > 32 KiB Flash-ROM debuggen, aber es
gibt irgendwo einen Hack für AVR Studio, mit dem es trotzdem geht.
Da der Hack ausschließlich aus einer modifizierten DLL für AVR Studio
besteht, scheint es, dass die Firmware des Dragon sich mittlerweile
nicht mehr dagegen sträubt, einen Controller > 32 KiB zu debuggen.
Damit sollte AVaRICE das von Haus aus können, da es selbst die
Limitierung nie eingebaut hatte. Probiert habe ich das aber noch
nicht.
In jedem Fall reichen die 32K nicht aus, ich hab grad 54K, die Chancen
stehen nicht schlecht, dass es über 64K werden.
Beim DLL-Patch steht für mich die Frage im Raum, wenn Atmel die DLL
ändert, dann kann ich nicht mehr Updaten und das ganze funktioniert
nicht mehr.
Den "usbprog v3.0" von diesem Shop hat noch niemand zum debuggen
genutzt?
Markus wrote:
> Beim DLL-Patch steht für mich die Frage im Raum, wenn Atmel die DLL> ändert, dann kann ich nicht mehr Updaten und das ganze funktioniert> nicht mehr.
Ich denke, du willst mit Eclipse (und damit GDB/AVaRICE) debuggen,
was interessiert dich dann die AVR-Studio-DLL?
%-~
> Den "usbprog v3.0" von diesem Shop hat noch niemand zum debuggen> genutzt?
Du meinst das all-in-one-Eigenbau-Teil, bei dem man an Hand der
Firmware entscheiden kann, ob man es für einen ARM oder einen AVR
benutzen will? Dafür gibt's zumindest eine JTAG-ICE-mkII-kompatible
Firmware, aber benutzt habe ich sie selbst noch nicht.
Die AVR Studio DLL interessiert mich soweit, wie habe noch viele andere
Projekte, die kann ich nicht alle umstricken auf Eclipse.
Ja, genau das Teil meine ich. Von der Beschreibung her ist das genau das
Teil was ich bräuchte. Eine Hardware mit dem ich Cortex und AVR machen
könnte (nur andere FW drauf).
Bei uns in der Firma könnten wir gleich mehrere davon brauchen, nur
wüsste ich gerne ob das Debuggen auch geht, bevor wie Geld ausgeben.
Ich habe mich mal rangesetzt und habe eine ausführliche Anleitung zum
Thema AVR Debugging mit Eclipse geschrieben. Mit vielen Screenshots und
einem Abschnitt zur Fehlersuche.
Zu finden auf der AVR Eclipse Homepage hier:
http://avr-eclipse.sourceforge.net/wiki/index.php/Debugging
Ich hoffe mal, dass damit das Thema für viele etwas transparenter und
einfacher wird.
@Markus: ich habe übrigens Dein Problem auch mit verarbeitet. Leider nur
in der 'Troubleshooting' Sektion als Beispiel für einen möglichen Fehler
(ohne Lösungsmöglichkeit)
Thomas
Eine Kleinigkeit fehlt noch in der Anleitung, die Einstellung des
Compillers, siehe Anhang. (stabs dwarf-2 stabs+).
Wenn man das falsch einstellt, geht das debuggen auch nicht richtig
(zumindsest nach meinem Wissen).
Was hast Du eingestellt?
Markus wrote:
> Definitiv, das Debuggen geht mit meinem MK-I Adapter nicht. Vielen Dank> für die sehr gut gelungene Anleitung.
Markus verbreitet Blödsinn.
Für alle die das hier lesen, damit sie sich nicht einen JTAG ICE MkII
kaufen weil sie denken, ein MkI tut es nicht. Ich habe gerade für diesen
Test nochmal meinen MkI aus dem Schrank geholt und es probiert. Das
Debuggen geht auch mit dem MkI. Alles andere ist schlicht Quatsch. Der
MkI ist ja auch zum debuggen gebaut worden. Er kann natürlich nicht
soviele Devices, wie der MkII. Eine Liste der Devices gibt es in der
AVR-Studio-Hilfe.
Nur damit es keine Missverständnisse gibt: Markus hatte weiter oben
geschrieben, dass er einen Olimex MkI clone hat mit dem es nicht geht.
Mit dem original Atmel MkI geht es offensichtlich, wahrscheinlich auch
mit einigen anderen Clonen.
Und der Vollständigkeit halber: mit dem Dragon geht debuggen auch, nur
das flashen mit avarice geht nicht (dafür aber mit avrdude).
900ss schrieb:
> Markus wrote:> > Definitiv, das Debuggen geht mit meinem MK-I Adapter nicht.> > Vielen Dank für die sehr gut gelungene Anleitung.> Markus verbreitet Blödsinn.
Naja, völliger Blödsinn ist das nicht, auch wenn die Pauschalaussage
"Debuggen geht mit dem MK I gar nicht" etwas voreilig und falsch ist.
Grundsätzlich kann man mit dem Mk I mit Avarice debuggen, allerdings
funktioniert wohl die Kombination Mk I - Avarice - AT90CAN128 nicht (s.
dazu auch Beitrag "at90can128 mit jtag ice mk1 und avarice debuggen").
Wie im ersten Post zu lesen ist, benutzt auch Markus einen AT90CAN128...
Thomas Holland schrieb:
> Nur damit es keine Missverständnisse gibt: Markus hatte weiter oben> geschrieben, dass er einen Olimex MkI clone hat mit dem es nicht geht.>> Mit dem original Atmel MkI geht es offensichtlich, wahrscheinlich auch> mit einigen anderen Clonen.
Das ist allerdings ziemlich unwahrscheinlich - da alle diese Clones
(einschließlich Olimex) eine praktisch funktionsgleiche Hardware und
eine identische Firmware (die vom "Original") haben. Ich gehe davon aus,
daß das Debuggen eines AT90CAN128 mit Avarice (mit AVRStudio ist es kein
Problem, s. Beitrag "at90can128 mit jtag ice mk1 und avarice debuggen")
auch mit einem originalen Mk I nicht funktioniert.
Wenn tatsächlich jemand die Kombination AT90CAN128 - Avarice - JTAGICE
MkI (erstmal egal ob Original oder Clone) zum Laufen bekommen hat, wäre
ich an einer entsprechenden Erfolgsmeldung sehr interessiert - und würde
alles was ich oben geschrieben habe, zurücknehmen und das Gegenteil
behaupten ;-)
@ Jörg Wunsch:
Ist die Sache damals eigentlich im Sande verlaufen, oder hatte Frank W.
(oder jemand anders) mal die Kommunikation zwischen AVRStudio und dem
JTAGICE mitgeschnitten?
Matthias
Ich habe letzte Woche Montag von shop.microcontroller.net einen USB-JTAG
3.0 Adapter bestellt und auch gleich mit Paypal bezahlt.
Erst am Mittwoch habe ich die Bestätigung des Zahlungseinganges erhalten
und bis heute noch kein Gerät.
Ich dachte schon, dass es deutlich schneller gehen würde, denn mit
Paypal ist das Geld doch innerhalb von wenigen Minuten gebucht :(
Ich werde irgendwann mal wieder schreiben, sollte das Teil mich doch
noch erreichen.
Seit heute bin ich stolzer Besitzer eines USBprog Teils!
Über parallelport und avrdude konnte ich leider keine Boot-Firmware
einspielen (Fehlermeldung: Device ID does not match...). Dann habe ich
meinen MKI Clone mit den JTAG Pins manuell verlötet, dann gings mit
AvrStudio.
So. Ich habe ein Board mit einem AT90CAN128 drauf und davon die JTAG
Pins TCK, TMS, TDO, TDI und GND herausgeführt.
Weiß jemand welche Software ich in den USBprog einspielen sollte? Also
bei der JTAGICE2 Version kann sich der Chip nicht am Windows anmelden,
die "AVRISP mk II" Version scheint zu funktionieren.
Aber an welche Pins des USBprog verbinde ich die Signale, so dass ich
debuggen kann?
Vielen Dank für eure Unterstützung.
Auch wenn der Thread schon älter ist...
Immer wenn es interessant für michm wird verlaufen die Threads im Sande.
Hab mich jetzt von oben bis unten durchgelesen und dann... schluss.
Speziell wenn es um den USBprog v3 geht sind die Infos sehr spärlich.
Ich möchte ihn auch zum Programmieren aus Eclipse heraus nutzen. Doch so
langsam bekomme ich das Gefühl das dieser dafür schlichtweg ungeeignet
ist. Ich hau das Ding in die Tonne :D
Thread beobachten
Seitenaufteilung abschalten