www.mikrocontroller.net

Forum: Compiler & IDEs ATMEGA mit Eclipse debuggen?


Autor: Markus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.... ???

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
68-gdb-set stop-on-solib-events 1
(gdb) 
68^done
69-target-select remote localhost:4242
(gdb) 
&"Remote communication error: Bad file descriptor.\n"
Remote communication error: Bad file descriptor.
69^error,msg="Remote communication error: Bad file descriptor."
70-gdb-exit
(gdb) 
70^exit

Was ist "Bad file descriptor", wie kann ich das beheben?

Autor: Markus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Compiler Parameter habe ich "-g2 -gstabs -O0" mit drin, daher sollte 
doch das ELF-File richtig sein.

Vielen Dank für eure Antwort.

Autor: Werkann Derkann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
H:\>avr-gdb -version
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-mingw32 --target=avr".

H:\>avarice
AVaRICE version 2.7, Dec 19 2007 20:37:47

Defaulting JTAG bitrate to 1 MHz. Make sure that the target
frequency is at least 4 MHz or you will likely encounter failures
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.

Autor: Hmm... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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!

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)))))

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
- 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...

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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)

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: 900ss D. (900ss)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Boisi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Boisi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Boisi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 900ss als Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, also nicht über das Load-Kommando vom GDB? Das ist ja schade.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Antworten.

Ich habe versucht unter den verschiedenen Konfigurationen das zum Laufen 
zu bekommen, leider ohne Erfolg.
AVaRICE version 2.8, Nov  7 2008 22:02:05

JTAG config starting.
Hardware Version: 0xce
Software Version: 0x80
Reported JTAG device ID: 0x9781
Configured for device ID: 0x9781 at90can128
JTAG config complete.
Preparing the target device for On Chip Debugging.

Disabling lock bits:
  LockBits -> 0xff

Enabling on-chip debugging:
  Extended Fuse byte -> 0xfd
      High Fuse byte -> 0x11
       Low Fuse byte -> 0xef
Waiting for connection on port 10000.
Connection opened by host 127.0.0.1, port 1198.
JTAG ICE communication failed

Ich kümmere mich ein andermal um das ganze, ich muss dringend das 
Projekt fertig bekommen.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas Holland
Bei Menü Project >> Clean werden alle Dateien ausser die .map Datei 
nicht gelöscht. (AVR-Plugin)

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, -e hatte ich natürlich auch probiert.

Hier der output von avarice:
>avarice -g -e -p -v -f ButterflyLCDTest.hex --jtag usb

AVaRICE version 2.8, Nov  7 2008 22:02:05

Defaulting JTAG bitrate to 250 kHz.

JTAG config starting.
Found a device: AVRDRAGON
Serial number:  00:a2:00:00:3f:fe
Reported JTAG device ID: 0x9405
Configured for device ID: 0x9405 atmega169
JTAG config complete.
Erasing program memory.
Erase complete.
Downloading FLASH image to target.................

Verifying FLASH
Error verifying target addr 0000. Expect [0x0c] Got [0x00]
Error verifying target addr 0001. Expect [0x94] Got [0x00]
Error verifying target addr 0002. Expect [0x6d] Got [0x00]
Error verifying target addr 0004. Expect [0x0c] Got [0x00]
[...1877 mal das gleiche...]
Error verifying target addr 07a0. Expect [0xff] Got [0x00]
Error verifying target addr 07a1. Expect [0xcf] Got [0x00]
Error verifying target addr 07a2. Expect [0x03] Got [0x00]
Error verifying target addr 07a3. Expect [0x0f] Got [0x00].

Verification failed!

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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Markus
Connection opened by host 127.0.0.1, port 1198.
JTAG ICE communication failed

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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst die Firmware doch notfalls allemal über ISP neu flashen,
falls das mit dem Bootloader schief geht.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
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
GDB: <qSupported>
->GDB: 
GDB: <?>
->GDB: S05
GDB: <Hc-1>
->GDB: 
GDB: <qC>
->GDB: 
GDB: <qOffsets>
->GDB: 
GDB: <Hg0>
->GDB: 

Dann will avr-gdb wissen, welche Werte in den MCU Registern stehen
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.
GDB: <g>

GDB: (Registers)Read 32 bytes from 0x800000
jtagRead 
command[R, 1]: 52 20 1F 00 00 00 20 20 
response: 91 00 41 
Timed Out (partial response)
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.
9-target-select remote localhost:10000
Remote communication error: No such file or directory.
&"Remote communication error: No such file or directory.\n"
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Word Count   Number of words in package - 1. (word count = 0   [BYTE]
             means 1 word, 1 means 2 words, 255 means 256
             words)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welchen habt Ihr im Einsatz?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für diese SUPER Anleitung!
Ich schaue morgen meine Parameter alle nochmal durch.

Autor: Markus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte gar nichts eingestellt sondern die default Einstellungen ( -g2 
und stabs) beibehalten.

Damit es aber auch ganz klar ist habe ich es jetzt in dem Artikel mit 
aufgenommen.

http://avr-eclipse.sourceforge.net/wiki/index.php/...

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Definitiv, das Debuggen geht mit meinem MK-I Adapter nicht. Vielen Dank 
für die sehr gut gelungene Anleitung.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: MatthiasR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

danke für die Info! Die Fehlermeldung die Markus hatte ist eindeutig die 
selbe die in dem von Dir zitierten Thread besprochen werden.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Morxi Macht murcks (morxi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Korinthenkacker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
haue besser Eclipse in die besagte Tonne, es sei denn, Du hast unendlich 
viel Zeit...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.