Hallo, hier meine 1. Frage, im super Forum für Mikrocontroller. Mein Betriebsystem ist Ubuntu 12.04.2 LTS. Den Atmel AT JTAG ICE3 gibt es bei Reichelt momentan für 115 €. http://www.reichelt.de/Programmer-Entwicklungstools/AT-JTAG-ICE3/3/index.html?;ACTION=3;LA=5;ARTICLE=111112;GROUPID=2969;artnr=AT+JTAG+ICE3 Ich möchte den Atmel AT JTAG ICE3 zum debuggen einsetzen. Ich habe aber nun Bedenken, ob der AT-JTAG-ICE3 sauber unter Linux funktioniert. Das Programm avarice kennt nur maximal --mkII. Siehe auch http://sourceforge.net/p/avarice/feature-requests/6/ Hat jemand hier Erfahungen damit, oder gibt es eine andere (kostengünstige) Möglichkeit ausser Windows? Vorab vielen Dank für die Antworten. Gruß cfi
Hallo AFAIK funktioniert das NICHT. Mit dem AVR Dragon könntest du mehr Glück haben. ISP/PDI/JTAG Programmierung geht zumindest. In System Debugging habe ich noch nie getestet. da1l6
Claus F. schrieb: > Hat jemand hier Erfahungen damit, oder gibt es eine andere > (kostengünstige) Möglichkeit ausser Windows? FTDI basierten JTAG Debugger und OpenOCD.
Claus F. schrieb: > Ich habe aber nun Bedenken, ob der AT-JTAG-ICE3 sauber unter Linux > funktioniert. Es gibt Leute, die sagen, es würde besser funktionieren als unter Atmel Studio. > Das Programm avarice kennt nur maximal --mkII. Du musst die SVN-Version benutzen, es gibt noch keinen Release damit. > Siehe auch http://sourceforge.net/p/avarice/feature-requests/6/ Habe ich gerade geschlossen.
Juergen G. schrieb: > FTDI basierten JTAG Debugger und OpenOCD. Schon probiert, damit einen AVR zu debuggen?
Juergen G. schrieb: > Aber ist JTAG nicht ein Standard? Ja: in seinem ursprünglichen Sinne, als Testschnittstelle. (JTAG = Joined Test Access Group). Auch Downloads darüber sind noch einigermaßen Standard. Die Erweiterung fürs Debuggen ist dagegen nicht standardisiert.
Hallo, danke für die vielen Info's. @Jörg: Ich habe die SVN-Version mit
1 | svn checkout svn://svn.code.sf.net/p/avarice/code/trunk avarice-code |
heruntergeladen. Aber wie in der INSTALL steht ist ein ./configure nicht möglich, da die Datei nicht existiert. Bin ich hier auf dem Holzweg? Gruß cfi
Claus F. schrieb: > Aber wie in der INSTALL steht ist ein ./configure nicht möglich, da die > Datei nicht existiert. Ja, configure ist nicht mit eingecheckt. Die dafür zuständige Beschreibung heißt aus historischen Gründen noch INSTALL-FROM-CVS. Du musst vorher ein ./Bootstrap aufrufen, das generiert (über automake und autoconf) den configure-Script. Solltest du das aus irgendeinem Grunde nicht hinbekommen, kann ich auch mal einen Snapshot veröffentlichen, der dann ein configure enthält.
Danke, hat geklappt, und hier nochmal komplett:
1 | svn checkout svn://svn.code.sf.net/p/avarice/code/trunk avarice-code |
2 | sudo ./Bootstrap |
3 | sudo ./configure |
4 | sudo make |
5 | sudo make install |
6 | |
7 | :/tmp/avarice-code/avarice$ avarice -h |
8 | AVaRICE version 2.13svn20130104, Jun 30 2013 21:26:37 |
9 | |
10 | Usage: avarice [OPTION]... [[HOST_NAME]:PORT] |
11 | |
12 | Options: |
13 | -h, --help Print this message. |
14 | -1, --mkI Connect to JTAG ICE mkI (default) |
15 | -2, --mkII Connect to JTAG ICE mkII |
16 | -3, --jtag3 Connect to JTAGICE3 |
Dann werde ich mir mal den Atmel AT JTAG ICE3 bestellen und dann unter Eclipse versuchen zu debuggen. Vielen Dank für die schnelle Unterstützung. Gruß cfi
Naja, Bootstrap, configure und make musst du nicht als root laufen lassen. ;-)
Jörg Wunsch schrieb: > Du musst die SVN-Version benutzen, es gibt noch keinen Release damit. Hoffentlich erreiche ich dich, Jörg, auf diesem Weg überhaupt ;). Jedenfalls ist das hier einer der "besseren" Threads in Bezug auf JTAGICE3 und Linux bzw. AVaRICE. Zumindest im SVN-Repo von AVaRICE hat sich ja seit über einem Jahr nichts mehr getan. Wie stabil ist der Code denn bzw. gibt es bekannte Probleme damit? Auf der Mailingliste wurden in den letzten Monaten diverse Verbesserungen für den mkII vorgeschlagen und du hattest angekündigt, dich eher oder später, um die Implementierung des EDBG Protokolls zu kümmern. Das bringt mich nämlich gleich zur nächsten Frage: Wird Firmware Version 3.x des JTAGICE3 derzeit überhaupt innerhalb von AVaRICE unterstützt? Konnte da keine zuverlässigen Infos finden, würde aber fast auf "Nein" tippen. Wie gut stehen die Chancen, dass man beim Kauf eines JTAGICE3 noch auf Firmware Version 2.x stößt? Ich stehe derzeit nämlich vor der Entscheidung mir einen Debugger zu holen und bin absolut unentschlossen. Die Verfügbarkeit des mkII lässt zu wünschen übrig (genauso wie der Preis). Im Prinzip hat der JTAGICE3 nur Vorteile, weil schneller und billiger. Allerdings ist mir die Unterstützung unter Linux wichtig und die kann nach meinem Verständnis noch verbessert/optimiert werden. Noch günstiger ist das Atmel ICE mit dem zusätzlichen Vorteil, dass man auch die ARMs von Atmel programmieren/debuggen kann. Hier fehlt innerhalb von AVaRICE aber derzeit jeglicher Support, sodass es nur mittels avrdude als Programmer eingesetzt werden kann. Wie schätzt du die Situation derzeit ein? Würdest du eher eine Empfehlung in Richtung mkII aussprechen, oder hältst du den Support des JTAGICE3 für akzeptabel. Mir macht insbesondere nämlich die neue Firmware Version 3.x Sorgen ... Es dürfen sich natürlich auch gerne andere mit Erfahrungen der Debugger einklinken ;). Wird nur schwer jemanden zu finden, der so tief in der Materie der Infrastruktur drin steckt wie Jörg :). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Es dürfen sich natürlich auch gerne andere mit Erfahrungen der Debugger > einklinken ;) Das ist nett :). Also ich nutze den JTAG ICE 3 unter Linux in Verbindung mit eclipse bzw. Avrdude. Bisher habe ich damit nur geflasht. Hilft dir das? Gruß Max
Karol Babioch schrieb: > Wird Firmware Version 3.x des JTAGICE3 derzeit überhaupt innerhalb von > AVaRICE unterstützt? Konnte da keine zuverlässigen Infos finden, würde > aber fast auf "Nein" tippen. Das ist (leider) korrekt. > Wie gut stehen die Chancen, dass man beim > Kauf eines JTAGICE3 noch auf Firmware Version 2.x stößt? Da hab' ich keine Ahnung. Hängt wahrscheinlich auch davon ab, wie lange das Ding schon im entsprechenden Shop herumlag. > Allerdings ist mir die Unterstützung unter Linux wichtig und die kann > nach meinem Verständnis noch verbessert/optimiert werden. Dann wärst du doch ein prima Kandidat, bei diesem Schritt aktiv mitzuhelfen. ;-) Im Ernst: so sehr schlimm sind die Unterschiede ja gar nicht, es ist eben eine andere Transportschicht oberhalb des USB. Im Großen und Ganzen kann man sich die Unterschiede anschauen, indem man das Diff im SVN von AVRDUDE zieht, als ich es damals implementiert habe. Das Aufwändigste dürfte im Vergleich zu AVRDUDE sein, dass das Event-Handling jetzt anders ist: bei der 2er Firmware wurde dafür ein eigener USB-Endpoint benutzt (was mir seinerzeit ziemliche Klimmzüge beschert hat), bei der CMSIS-DAP-Firmware haben sie aber nur zwei EPs, sodass die Events dann wieder vom Host gepollt werden müssen. Eigentlisch Scheibenkleister, aber was tut man nicht, damit für die schöne Windows-Welt jedes Gerät wie ein “Human Interface” daherkommt ... > Noch günstiger > ist das Atmel ICE mit dem zusätzlichen Vorteil, dass man auch die ARMs > von Atmel programmieren/debuggen kann. Hier fehlt innerhalb von AVaRICE > aber derzeit jeglicher Support, sodass es nur mittels avrdude als > Programmer eingesetzt werden kann. Wobei das Atmel-ICE nahezu automatisch mit unterstützt wird, wenn man die Unterstützung für die CMSIS-DAP-basierte 3er Firmware des JTAGICE3 einbaut. Beide benutzen dann (aus AVR-Sicht) nahezu das gleiche Protokoll.
Max B. schrieb: > Also ich nutze den JTAG ICE 3 unter Linux in Verbindung > mit eclipse bzw. Avrdude. Bisher habe ich damit nur geflasht. Hilft dir > das? Ja, dass avrdude das Gerät unterstützt weiß ich. Zum reinen Programmer möchte das Gerät aber nicht unbedingt degradieren, und den Geschwindigkeitsvorteil kann ich bei meinen Anwendungen nicht wirklich ausspielen. Jörg Wunsch schrieb: >> Wie gut stehen die Chancen, dass man beim >> Kauf eines JTAGICE3 noch auf Firmware Version 2.x stößt? > > Da hab' ich keine Ahnung. Hängt wahrscheinlich auch davon ab, wie > lange das Ding schon im entsprechenden Shop herumlag. Wie sieht es eigentlich mit Downgrades aus? Lassen sich ältere Firmwares einspielen, oder legt einem Atmel da Steine in den Weg? Wie kommt man überhaupt an die Firmware? Wird diese (nur?) mit dem Atmel-Studio vertrieben? Jörg Wunsch schrieb: > Dann wärst du doch ein prima Kandidat, bei diesem Schritt aktiv > mitzuhelfen. ;-) Ja, gerne, wobei ich gerne mit etwas rudimentär funktionierendem anfangen würde ;). Jörg Wunsch schrieb: > Beide benutzen dann (aus AVR-Sicht) nahezu das > gleiche Protokoll. Was sind die Unterschiede bzw. ist das Ganze irgendwo dokumentiert? Soweit ich weiß macht ja Atmel nach wie vor ein Geheimnis aus dem Protokoll und bisherige Erkenntnisse basieren alle auf Reverse Engineering? Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Zum reinen Programmer > möchte das Gerät aber nicht unbedingt degradieren, Mich wuerde interessieren wie bzw. ob das debugging mit JTAG-ICE3 bzw. dem ATMEL-ICE unter Linux funktioniert?! Hat da jemand erfahrung?
Karol Babioch schrieb: > Wie sieht es eigentlich mit Downgrades aus? Lassen sich ältere Firmwares > einspielen, oder legt einem Atmel da Steine in den Weg? Wie kommt man > überhaupt an die Firmware? Wird diese (nur?) mit dem Atmel-Studio > vertrieben? Hm also beim ICE 3 bin ich mir nicht so sicher. Ganz sicher habe ich den MK II schon mehrfach up- und downgegradet. Allerdings immer über das Studio. Evtl. mal in einer VM installieren? Gruß Max
Karol Babioch schrieb: > Wie sieht es eigentlich mit Downgrades aus? Lassen sich ältere Firmwares > einspielen, oder legt einem Atmel da Steine in den Weg? Wie kommt man > überhaupt an die Firmware? Wird diese (nur?) mit dem Atmel-Studio > vertrieben? Die Firmware gibt's offiziell nur mit dem Studio, und auch das Upgradeprotokoll ist nicht dokumentiert. Prinzipiell kannst du natürlich den USB-Traffic mitmeißeln und dann als Replay reinspielen. Downgrade müsste per älteren Atmel-Studio-Versionen schon möglich sein. > Jörg Wunsch schrieb: >> Dann wärst du doch ein prima Kandidat, bei diesem Schritt aktiv >> mitzuhelfen. ;-) > > Ja, gerne, wobei ich gerne mit etwas rudimentär funktionierendem > anfangen würde ;). Dafür hast du ja AVRDUDE. :) > Beide benutzen dann (aus AVR-Sicht) nahezu das >> gleiche Protokoll. > > Was sind die Unterschiede bzw. ist das Ganze irgendwo dokumentiert? Das ursprüngliche JTAGICE3 ist nicht offiziell dokumentiert worden. Die CMSIS-DAP-basierte Variante dagegen wurde dann (nach vielen Jahren ohne jegliche offizielle Doku) offiziell dokumentiert: http://www.atmel.com/webdoc/protocoldocs/ Eine interne Version gab es diesmal sogar vorab, da Atmel ein deutliches Interesse daran hatte, dass AVRDUDE das Protokoll möglichst zeitgleich mit der Vorstellung des Atmel-ICE auf der Embedded in Nürnberg unterstützt. Damit gab es aber indirekt rückwirkend auch eine Doku für die Version 2.x des JTAGICE3, denn es ist nur das Verpacken der Daten über die CMSIS-DAP-Schnittstelle anders als zuvor. Der Transport wiederum ist bei der älteren Firmware sehr ähnlich gelöst wie bereits zuvor beim JTAGICEmkII (mit der Ausnahme, dass Events nun über einen eigenen Endpoint gemeldet wurden). Kaj schrieb: > Mich wuerde interessieren wie bzw. ob das debugging mit JTAG-ICE3 bzw. > dem ATMEL-ICE unter Linux funktioniert? Genau darum dreht sich doch die ganze Diskussion. Kurzfassung: JTAGICE3 Firmware 2.x geht derzeit bereits mit AVaRICE, Firmware 3.x sowie Atmel-ICE derzeit (noch) nicht. Helfende Hände wären natürlich von Vorteil, denn sehr viel Zeit habe ich im Moment nicht übrig, die ich investieren kann. Ich habe aber durchaus auch ein persönliches Interesse, denn erstens könnte ich dann endlich auch das Atmel-ICE zum Debuggen nutzen, und zweitens müsste ich nicht mehr drauf achten, dass mein JTAGICE3 so einen riesigen Bogen um jedwede aktuelle Atmel-Studio-Version macht. ;-)
Jörg Wunsch schrieb: > Prinzipiell kannst du > natürlich den USB-Traffic mitmeißeln und dann als Replay > reinspielen. Habe mit solchen Low-Level-USB Geschichten nur bedingt Erfahrung. Und sofern ich ein Gerät mit Firmware 3.x erwerbe, bringt mir das reine Sniffen ja nichts, sofern Downgrades durch den Bootloader verboten sind. Eine Replay-Attacken könnten theoretisch auch abgelehnt werden. Ich habe Ahnung wie sehr sich Atmel hier quer stellt. Andererseits ist eine wirklich sichere Implementierung in diesem Kontext gar nicht so einfach und das traue ich Atmel auch gar nicht zu. Jörg Wunsch schrieb: > Downgrade müsste per älteren Atmel-Studio-Versionen schon möglich > sein. Muss ich mal sehen, ob man da noch ran kommt. Wie ich mich schon drauf freue gleich mehrere dieser (gigabyte-großen?) Kolosse herunterzuladen und zu installieren (samt notwendigen Komponenten/Updates), um dann ein paar Kilobytegroße Dateien daraus zu extrahieren ... Wie sieht es mit der Unterstützung innerhalb virtueller Maschinen aus? Könnte das Atmel Studio in einer Virtual Box mit dem Gerät kommunizieren (auf einem Linux Host). Hier [1] hast du von Problemen berichtet. Jörg Wunsch schrieb: > Dafür hast du ja AVRDUDE. :) Ich meinte aber grundlegende Debugfunktionen ;). Würde gerne ein Setup haben mit welchem sich zur Not auch arbeiten lässt. Allein schon, um eine Referenz zu haben, wie das alles eigentlich funktionieren müsste. Jörg Wunsch schrieb: > Eine interne Version gab es diesmal sogar vorab, da Atmel ein > deutliches Interesse daran hatte, dass AVRDUDE das Protokoll > möglichst zeitgleich mit der Vorstellung des Atmel-ICE auf der > Embedded in Nürnberg unterstützt. Darf man denn fragen (aus Neugier), warum Atmel sich für Support von avrdude interessiert? Ich dachte die bringen sich nur bei avr-libc und avr-gcc mit ein. Jörg Wunsch schrieb: > und zweitens müsste ich nicht > mehr drauf achten, dass mein JTAGICE3 so einen riesigen Bogen um > jedwede aktuelle Atmel-Studio-Version macht. ;-) Magst du denn das Downgraden zufälligerweise mal probieren ;)? Du könntest ja mit einem Downgrade auf eine ältere 2.x bzw. 1.x Version anfangen, sodass du defintiv wieder zurück auf die aktuell funktionierende Version kommst. Könnte ja sein, dass die mit 3.x es plötzlich verbieten, wobei mich da wundern würde, wenn es vorher möglich war. Derzeit ist das nämlich meine größte Sorge. Mit freundlichen Grüßen, Karol Babioch [1]: Beitrag "JTAG ICE Firmware Update"
:
Bearbeitet durch User
Karol Babioch schrieb: > Andererseits ist eine > wirklich sichere Implementierung in diesem Kontext gar nicht so einfach > und das traue ich Atmel auch gar nicht zu. Atmel ist einer der größten Anbieter wenn es um den Bereich Smartcard geht, und die haben Controller mit Zertifizierung nach FIPS140-1 / FIPS140-2, Zertifizierung nach BSI, und auch sonst mischt Atmel ganz kräftig im Krypto-/Sicherheitsbereich mit (z.B. TPM). Und das macht man bestimmt nicht, wenn man von Sicherheit keine Ahnung hat ;) Atmel ist mit sehr hoher Wahrscheinlichkeit in der Lage, das angesprochene sicher zu implementieren, aber ob sie es auch wollen, ist ein anderer Schuh :) Atmel hat sehr viel mehr zu bieten, als nur die Hobbysparte, nur das sieht man nicht, wenn man nicht in entsprechenden bereichen und an entsprechenden Projekten arbeitet... oder wenn man durch gesetzesänderungen dazu gezwungen wird, sich damit zu beschäftigen -.-* Das nur als kleiner Abriß, was man Atmel schon zutrauen kann ;) Jörg Wunsch schrieb: > Kaj schrieb: >> Mich wuerde interessieren wie bzw. ob das debugging mit JTAG-ICE3 bzw. >> dem ATMEL-ICE unter Linux funktioniert? > > Genau darum dreht sich doch die ganze Diskussion. > > Kurzfassung: JTAGICE3 Firmware 2.x geht derzeit bereits mit AVaRICE, > Firmware 3.x sowie Atmel-ICE derzeit (noch) nicht. Ok, ohne mich jetzt näher damit beschäftigt zu haben, scheint AVaRICE sowas wie OpenOCD zu sein, nur halt auf AVR-Controller beschränkt, ist das soweit richtig?
Karol Babioch schrieb: > Habe mit solchen Low-Level-USB Geschichten nur bedingt Erfahrung. Wenn du Linux als Host und das Windows in einem VMware-Guest hast, dann geht das prima, dieweil Wireshark das Sniffen des USB direkt unterstützt (im Hintergrund wird „dumpcap“ gerufen, wobei zuvor der Modul „usbmon“ geladen worden sein muss). > ..., sofern Downgrades durch den Bootloader verboten sind. Der Bootloader lädt vermutlich alles, was im korrekten Format ankommt. Die Firmware-Version interessiert den wenig. Es ist eben nur das Protokoll nicht offengelegt, und die Firmware selbst nochmal irgendwie verschlüsselt. Aber darum muss man sich bei einem Replay ja erstmal keine großen Gedanken machen. Man will ja nicht die Firmware disassemblieren, sondern sie nur aufs ICE bringen. > Wie sieht es mit der Unterstützung innerhalb virtueller Maschinen aus? > Könnte das Atmel Studio in einer Virtual Box mit dem Gerät kommunizieren > (auf einem Linux Host). Hier [1] hast du von Problemen berichtet. VirtualBox hatte damals bei mir nicht funktioniert, da deren USB-2.0-Unterstützung zu schlecht war. Habe ich seither noch nicht wieder getestet; zumindest ist die EHCI-Implementierung mittlerweile wenigstens kein closed source mehr, sondern standardmäßig in der Opensource-Version mit dabei. Die 2.xer Firmware hatte sich wiederum unter USB 1.1 mit seinen kleineren Endpoint-Größen affig, denn offenbar war sowas bei Atmel nie getestet worden. Die 3.xer Firmware geht auch unter USB 1.1 (ich glaube mich zu erinnern, dass CMSIS-DAP das auch vorschreibt), allerdings ist das nicht sonderlich effektiv, denn es werden immer volle 512 Octets pro Transfer hin und her geworfen, egal, wie viel Inhalt wirklich drin ist. Mit VMware klappt alles, allerdings ist dort nur der VMware Player (ohne „Plus“) kostenlos, und der wird von VMware nicht mehr groß beworben. Im Internet findet man aber die Download-Links noch. > Darf man denn fragen (aus Neugier), warum Atmel sich für Support von > avrdude interessiert? Wenn Kundschaft damit arbeitet, wird es eben plötzlich interessant. ;-) > Ich dachte die bringen sich nur bei avr-libc und > avr-gcc mit ein. Naja, wirklich „eingebracht“ haben sie sich ja auch kaum. Ich war zwar damals selbst noch bei Atmel angestellt, aber nicht im Bereich der AVRs und ihrer Tools, insofern war der Atmel-seitige Support für die Arbeit an AVRDUDE eher mal ein Nebeneffekt (hin und wieder ließ sich schon mal etwas Arbeitszeit investieren, da wir es ja auch für uns selbst benutzt haben). > Magst du denn das Downgraden zufälligerweise mal probieren ;)? Muss ich auch erstmal gucken, wo ich noch eine passende Version her bekommen kann.
Kaj schrieb: > Ok, ohne mich jetzt näher damit beschäftigt zu haben, scheint AVaRICE > sowas wie OpenOCD zu sein, nur halt auf AVR-Controller beschränkt, ist > das soweit richtig? Mit dem Fokus auf das reine Debugging; fürs Programmieren gibt es ja AVRDUDE. Ansonsten passt das so ungefähr. Im Gegensatz zu OpenOCD können AVRs allerdings nur über die Atmel-Tools (JTAGICE, JTAGICEmkII, AVR Dragon, JTAGICE3, Atmel-ICE) debuggt werden, da der Debug-Teil der JTAG-Implementierung als proprietäre Erweiterung gehandhabt wird. Du kannst dir also keinen generischen JTAG-Dongle nehmen, wie sie sonst von OpenOCD unterstützt werden.
Kaj schrieb: > Atmel ist mit sehr hoher Wahrscheinlichkeit in der Lage, das > angesprochene sicher zu implementieren, aber ob sie es auch wollen, ist > ein anderer Schuh :) Das bezweifel sich ganz stark mit dem Verweis auf Smartphones und Spielekonsolen. Dort treiben die Hersteller allerlei Schabernack, um das Einspielen unautorisierter Software bzw. Downgrades zu verhindern - mit nur mäßigem Erfolg. Leider ist es gar nicht trivial so etwas sicher zu implementieren. Außerdem geht dabei immer Flexibilität verloren und die Gefahr beim Flashen einen Brick zu fabrizieren steigt. Jörg Wunsch schrieb: > Der Bootloader lädt vermutlich alles, was im korrekten Format > ankommt. Die Firmware-Version interessiert den wenig. Wenn ich mir das Handbuch so ansehe, dann scheint man hier relativ viele Freiheiten beim Flashen zu haben [1]. Es würde mich wirklich ganz stark wundern, wenn ein Downgrade nicht möglich ist. Jörg Wunsch schrieb: > VirtualBox hatte damals bei mir nicht funktioniert, da deren > USB-2.0-Unterstützung zu schlecht war. Habe ich seither noch nicht > wieder getestet; zumindest ist die EHCI-Implementierung mittlerweile > wenigstens kein closed source mehr, sondern standardmäßig in der > Opensource-Version mit dabei. Ich glaube peripher mitbekommen zu haben, dass sich da mittlerweile einiges getan hat. Hier gilt wohl: Probieren geht wohl über Studieren. Jörg Wunsch schrieb: > Wenn Kundschaft damit arbeitet, wird es eben plötzlich interessant. ;-) Naja, solange dabei etwas Positives (Veröffentlichung von Dokumenten) herauskommt, kann ich damit leben. Jörg Wunsch schrieb: > Naja, wirklich „eingebracht“ haben sie sich ja auch kaum. Ich habe mich erst kürzlich mit einem Atmel Mitarbeiter per E-Mail darüber unterhalten. Er gelobte Besserung und hat darauf verwiesen, dass sie wohl noch einen ganzen Katalog an internen Patches haben, die sie einpflegen wollen. Mal sehen, ob bzw. wann das geschieht. Mich z.B. stört der fehlende Support für ATtiny441/841 ziemlich stark. Selbst ein Jahr nach der Veröffentlichung scheint Atmel nicht daran interessiert zu sein, die paar Patches Upstream einzubringen. In Ihrer eigenen Toolchain (die wiederum nicht auf der neusten gcc Version basiert) ist das natürlich längst geschehen. Aber wem erzähl ich das, und eigentlich ist das auch ein ganz anderes Thema ... Mit freundlichen Grüßen, Karol Babioch [1]: http://www.atmel.com/webdoc/atmelstudio/atmelstudio.AvrStudioUserGuide.FirmwareUpgrade.ManualUpgrade.html
Karol Babioch schrieb: > Wenn ich mir das Handbuch so ansehe, dann scheint man hier relativ viele > Freiheiten beim Flashen zu haben [1]. Wenn sie dieses Tool zusammen mit den Firmware-Dateien wenigstens separat bundeln würden, dann könnte man sich die x-hundert MB für das blöde Studio sparen. ;-) >> Naja, wirklich „eingebracht“ haben sie sich ja auch kaum. > > Ich habe mich erst kürzlich mit einem Atmel Mitarbeiter per E-Mail > darüber unterhalten. Er gelobte Besserung ... Nur als Klarstellung: die Bemerkung oben bezog sich auf AVRDUDE. Beim GCC und der avr-libc sind sie mittlerweile doch recht regelmäßig zugange.
Jörg Wunsch schrieb: > Wenn sie dieses Tool zusammen mit den Firmware-Dateien wenigstens > separat bundeln würden, dann könnte man sich die x-hundert MB für > das blöde Studio sparen. ;-) Ja, ich finde das auch lächerlich. Ist aber für alle anderen Tools (STK500 z.B. auch nicht anders). Apropos STK500: Liegt eigentlich im Lieferumfang des JTAGICE3 ein entsprechender Adapter bei? Angeblich soll sowas ja Teil des Lieferumfangs des STK500 gewesen sein (laut Handbuch), allerdings ist das bei mir nicht der Fall und ich habe mein STK500 damals (2011?) hoch-offiziell bei Reichelt erworben und nicht bei irgendeinem dubiosen eBay Shop chinesischer Herkunft. Falls ein solcher Adapter nicht beiliegt: Wie komme ich an ein solchen ;)? Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Liegt eigentlich im Lieferumfang des JTAGICE3 ein entsprechender Adapter > bei? Welcher denn? Das JTAGICE3 kommt mit einem 10poligen Kabel mit dem popeligen Rastermaß von 1,27 mm und der normalen AVR-JTAG-Belegung. Für dieses liegen Adapter bei auf 10polig JTAG 2,54 mm Rastermaß, 6polig ISP 1,27 mm Rastermaß und 6polig ISP 2,54 mm Rastermaß. Dann gibt's noch das Kabel, bei dem die Drähte auf 10 Steckhülsen geführt sind („Tintenfisch“). Bei Atmel-ICE gibt es außerdem noch einen Adapter auf 20polig JTAG 2,54 mm Raster, ARM-Standard. Nicht unterstützt wird hingegen der neuere, von ARM für Cortex-M vorgeschlagene 10polige JTAG-Verbinder mit ebenfalls 1,27 mm Rastermaß. (Zumindest gab's das bei meinem Atmel-ICE noch nicht; man hat die Adapter aber später nochmal neu entworfen, ursprünglich war das alles ein „Multi-Igel“.) 10polig ISP war nie ein Atmel-Standard (sondern der stammte von Kanda, eingeführt mit dem STK200) und wird daher nicht unterstützt.
Jörg Wunsch schrieb: > Welcher denn? Dieser hier: http://www.atmel.com/webdoc/jtagicemkii/jtagicemkii.connecting_stk500.html Scheint fast so, als dass ich mich direkt an Atmel wenden muss. Geht bestimmt schnell und billig, wenn man als Einzelperson eine einzelnen Adapter braucht ;). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Wenn ich mir das Handbuch so ansehe, dann scheint man hier relativ viele > Freiheiten beim Flashen zu haben [1]. Es würde mich wirklich ganz stark > wundern, wenn ein Downgrade nicht möglich ist. Versuch, einen direkten Downgrade auf 2.21 (2.15 in Atmel-Hex-Notation) zu machen, endet mit einem “GenericError: USB driver attach timeout”. Allerdings funktioniert der Trick, dass man damit die 3.23 (3.17 in Atmel-Notation) anfängt zu laden (die schon drauf war) und dann das JTAGICE3 vom USB abzieht. Damit klemmt das Ding im Bootloader-Modus fest, und von da auch geht auch das Neuflashen mit der 2.21. ;-) (Anschließendes Rückflashen auf 3.23 klappt problemlos.) Gut, also zumindest der Weg klappt.
Jörg Wunsch schrieb: > Versuch, einen direkten Downgrade auf 2.21 (2.15 in Atmel-Hex-Notation) > zu machen, endet mit einem “GenericError: USB driver attach timeout”. Interessant wäre es noch zu wissen, woran das liegt ;). Ist das einfach nur eine Konsequenz von "unrobuster" Programmierung, oder gewollt? Welcher Mikrocontroller wird da eigentlich verwendet bzw. könnte Atmel ggf. den Bootloader selbst neu flashen, um uns in der Zukunft größere Probleme zu bereiten? Jörg Wunsch schrieb: > Gut, also zumindest der Weg klappt. Super, das hört sich gut an. Danke fürs Testen. Ist das Veröffentlichen der Firmwares (und der Anwendung zum Einspielen) eigentlich erlaubt? Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Interessant wäre es noch zu wissen, woran das liegt ;). Vermutlich eher ein „Dreckeffekt“, ggf. auch im Zusammenhang mit der Arbeit aus der VMware heraus, in der ich das gemacht habe. > Welcher Mikrocontroller wird da eigentlich verwendet UC3A > bzw. könnte Atmel > ggf. den Bootloader selbst neu flashen, um uns in der Zukunft größere > Probleme zu bereiten? Henne- und Ei-Problem ;-) Einen Bootloader sich selbst programmieren zu lassen, dürfte zumindest nicht trivial sein. Man sollte ihnen nicht zu viel Bösartigkeit unterstellen. Wenn es gewollt wäre, hätten sie auch in dem atfw.exe einfach so tun können, als würden sie den Upgrade durchführen, es aber trotzdem nicht tun. > Ist das Veröffentlichen > der Firmwares (und der Anwendung zum Einspielen) eigentlich erlaubt? Schätzungsweise nicht, denn du bekommst die Files ja nur als Teil des Atmel Studio, welches du wiederum nur im Ganzen weitergeben darfst.
Karol Babioch schrieb: > Liegt eigentlich im Lieferumfang des JTAGICE3 ein > entsprechender Adapter bei? Wenn ich mich richtig erinnere lag bei meinem bei: - 1x 10 pol. Tintenfischkabel - 1x Adapter für 6 pol. ISP - 1x Adapter für 10 pol. JTAG Siehe hier, das zweite Bild: http://www.reichelt.de/AT-JTAG-ICE3/3/index.html?&ACTION=3&LA=446&ARTICLE=111112&artnr=AT+JTAG+ICE3&SEARCH=JTAG+ICE+3
Jörg Wunsch schrieb: > Henne- und Ei-Problem ;-) Einen Bootloader sich selbst programmieren > zu lassen, dürfte zumindest nicht trivial sein. Ja, und birgt immer die Gefahr einen Briefbeschwerer zu hinterlassen. Ganz unmöglich ist es aber - je nach Plattform - nicht. Jörg Wunsch schrieb: > Man sollte ihnen nicht zu viel Bösartigkeit unterstellen. Ja, da bin ich wohl etwas zu paranoid. Ich wollte nur ganz grundsätzliche "alle" Optionen durchgehen. Ich kann mir kaum vorstellen, dass Atmel sich hier groß einmischen wird. Andererseits hast du ja geschrieben, dass die Übertragung selbst nicht im Klartext stattfindet. Das machen sie ja nicht aus Spaß, sondern um Reverse Engineering (des Protokolls) zu erschweren. Danke jedenfalls nochmal für deine schnelle und kompetenten Antworten. Ich melde mich, sobald ich selbst erste Erfahrungen hab machen können bzw. weitere Fragen aufkommen. Den Thread hast du ja glücklicherweise ganz gut im Auge. Kaj schrieb: > Wenn ich mich richtig erinnere lag bei meinem bei: Ok, danke. Hätte wohl laut Handbuch beim STK500 selbst beiliegen sollen. Muss ich mal gucken, wie ich da jetzt heran komme. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Dieser hier: > http://www.atmel.com/webdoc/jtagicemkii/jtagicemkii.connecting_stk500.html Karol Babioch schrieb: > Ok, danke. Hätte wohl laut Handbuch beim STK500 selbst beiliegen sollen. > Muss ich mal gucken, wie ich da jetzt heran komme. Ich habe so ein Teil da rumliegen, melde dich per PN und ich sende es dir.
Hi >Kaj schrieb: > Wenn ich mich richtig erinnere lag bei meinem bei: >Ok, danke. Hätte wohl laut Handbuch beim STK500 selbst beiliegen sollen. >Muss ich mal gucken, wie ich da jetzt heran komme. Zeig mir mal die Stelle im Handbuch. http://www.atmel.com/images/doc1925.pdf Der Adapter, der in einige Dokumenten auftaucht, wurde z.B. mit dem AVR ICE MKII ausgeliefert. MfG Spess
Hi, spess53 schrieb: > Zeig mir mal die Stelle im Handbuch. Im Handbuch des mkII [1] heißt es: > When connecting to a JTAG target, simply use the ATSTK500_JTAG_ADAPTER, > which is supplied with the STK500 kit and available from www.atmel.com Kann natürlich sein, dass dieser Adapter erst später als Teil des STK500 eingeführt worden ist - bei mir jedenfalls war er nicht dabei. Die anderen aber müssen ja irgendwie auch da ran gekommen sein. > http://www.atmel.com/images/doc1925.pdf Die PDF ist leider ziemlich nutzlos. Es ist überhaupt eine der letzten Handbücher für Tools, die Atmel als PDF veröffentlicht hat. Neuere Controller werden dort nicht mehr aufgeführt. Die aktuelle Version liegt wohl nur dem Studio bei und ist neuerdings auch über [2] erreichbar. Unter "Kit contents" [3] wird der Adapter aber weiterhin nicht aufgeführt. Anscheinend eine Inkonsistenz zwischen den einzelnen Dokumenten. Keine Ahnung wie man offiziell an den Adapter gelangen soll, ohne sich direkt an Atmel zu wenden. Mit freundlichen Grüßen, Karol Babioch [1]: http://www.atmel.com/webdoc/jtagicemkii/jtagicemkii.connecting_stk500.html [2]: http://www.atmel.com/webdoc/stk500/index.html [3]: http://www.atmel.com/webdoc/stk500/stk500.gettingstarted.kitcontent.html
:
Bearbeitet durch User
Karol Babioch schrieb: > Andererseits hast du ja geschrieben, dass die Übertragung selbst nicht > im Klartext stattfindet. Das machen sie ja nicht aus Spaß, sondern um > Reverse Engineering (des Protokolls) zu erschweren. Sie sind da ein gebranntes Kind: die ersten JTAGICEs waren intern sehr einfach aufgebaut (ein ATmega16 und ein paar Pegelwandler), aber man hatte sie damals als “low-cost ICE” für USD 300 verkauft. Der Grund war einfach, dass die ICEs, die sie abgelöst haben, noch FPGAs mit extern aufgebauter Analogperipherie waren (ICE50, ICE200), entsprechend aufwändig und vierstellig teuer. Da erschien ihnen wohl die 300 als “low cost” genug … Dumm nur, dass der Bootloader ein einfacher AVR109-Code war, sodass ganz schnell findige Leute herausfanden, dass man eine „noch lower cost“-Version bauen konnte, indem man unter Verzicht auf die Pegelwandler (damit theoretisch nur für Targets mit Ucc = 5 V) einfach einem ATmega16 den Bootloader reingesetzt hat und dann das AVR Studio angeworfen, welches ihm fröhlich die JTAGICE-Firmware beigebracht hat. ;-) Danach haben sie sich halt mehr Mühe gegeben, komplette Clones nicht mehr so einfach zu machen. Verschlüsseln der Firmware gehörte seither mit dazu. spess53 schrieb: > Der Adapter, der in einige Dokumenten auftaucht, wurde z.B. mit dem AVR > ICE MKII ausgeliefert. Ja, das habe ich auch so in Erinnerung.
Hi Ich tippe eher auf einen Fehler in > which is supplied with the STK500 kit and available from www.atmel.com Warum bei ATMEL erhältlich wenn er mitgeliefert wird? STK500 kenne ich einige aus dem Zeitraum 2001-2012. Dort war nie ein derartiger Adapter dabei. Den originalen, den ich habe, stammt vom AVR ISP MKII. Bei Auktionen zum STK500 auf dieser Webseite ist mir das Teil auch noch untergkommen. >Keine Ahnung wie man offiziell an den Adapter gelangen soll, >ohne sich direkt an Atmel zu wenden. Ein Stück Lochrasterplatte, 10pol-Wannenstecker, ein paar Stiftleisten, etwas Fädeldraht und 30min Arbeit. Macht es seit etlichen Jahren bei mir klaglos. MfG Spess
spess53 schrieb: > Der Adapter, der in einige Dokumenten auftaucht, wurde z.B. mit dem AVR > ICE MKII ausgeliefert. spess53 schrieb: > STK500 kenne ich einige aus dem Zeitraum 2001-2012. Dort war nie ein > derartiger Adapter dabei. Den originalen, den ich habe, stammt vom AVR > ISP MKII. Wie es aussieht handelt sich hier um pure Glück! Ich hab Mal ein STK500 im dem Zeitraum 2001-2012 gekauf und war so ein Ding drin, irgendwann ein JTAG mkII auch aber da war keins drin. In der Firma haben paar JTAG mkII gekauft (vor paar Jahre) und da war doch mindestens auf eine dabei.
Hallo zusammen, eine sehr interessante Diskussion. Ggf. kann ich auch etwas dazu beitragen und vielleicht und hoffentlich auch selbst etwas mitnehmen. Kurz gesagt: ich versuche auch den JTAGICE3 mit avarice unter Linux als Debugger zu benutzen. Das Programmieren meines ArduinoLeonardo über JTAG mit AVRDUDE funktioniert einwandfrei. Avarice habe ich wie Claus beschrieben hat ausgecheckt compiliert und installiert. Wenn ich nun avarice starte erhalte ich die folgende Meldung: avarice -3 --jtag usb :4242// AVaRICE version 2.13svn20130104, Oct 27 2014 21:24:28 Defaulting JTAG bitrate to 250 kHz. avarice has not been compiled with libusb support Als Ergänzung vielleicht noch ein Paar Infos zu meinem JTAGICE3, die AVRDUDE vor dem Programmieren ausspuckt: Programmer Type : JTAGICE3 Description : Atmel AVR JTAGICE3 in JTAG mode ICE hardware version: 2 ICE firmware version: 2.21 (rel. 212) Serial number : J30200030675 Vtarget : 4.96 V JTAG clock megaAVR/program: 100 kHz JTAG clock megaAVR/debug: 100 kHz JTAG clock Xmega: 1000 kHz PDI clock Xmega : 1000 kHz Übrigens das downgraden von der Version 3 auf eine Version 2 fuktioniert mit einem atmel tool und ist hier beschrieben: http://atmel.force.com/support/articles/en_US/FAQ/How-to-downgrade-firmware-version-of-the-JTAGICE3-debbuger-so-that-it-can-work-with-IAR-for-AVR Ich habs bei mir durchgeführt, weil mein ICE noch die Version 1.25 hatte und ich dachte, das es vielleicht daran liegt, weil die Version zu alt ist. Das heisst das tool führte bei mir ein upgrade auf die Version 2 durch. Das AtmelStudio 6.2 verlangt zum debuggen allerdings die Version 3.25 die ich aus den o.b. Gründen nicht einspiele möchte. Ein Erfolg hatte ich dann mit IAR. Hier hat es tatsächlich geklapt. Ich konnte den Leonardo über JTAG mit JTAGICE3 und IAR C-SPY tatsächlich debuggen :-). Das heisst nun für mich, daß meine JTAG-Anbindung und die Hardare funktioniert. Es bleibt nun die Frage wie muß ich avarice compilieren, damit die o.g. Fehlermeldug nicht erscheint und die Kommunikation zum JTAGICE3 aufgebaut wird?
Artur G. schrieb: > Es bleibt nun die Frage wie muß ich avarice compilieren, damit die o.g. > Fehlermeldug nicht erscheint und die Kommunikation zum JTAGICE3 > aufgebaut wird? Du musst eine libusb haben. ;-) Im Ernst: die meisten Linux-Distributionen haben die (meiner Meinung nach blöde) Angewohnheit, dass sie beim Installieren eines Pakets "libfoo" nur die dynamische Bibliothek (libfoo.so.irgendwas) installieren, nicht aber die Headerfiles (und ggf. statische Bibliothek libfoo.a). Zum Compilieren gegen diese Bibliothek braucht man aber die Headerfiles, die du dann typisch in einem Paket namens libfoo-dev oder libfoo-devel findest.
Jörg Wunsch schrieb: > Du musst eine libusb haben. ;-) Hallo Jörg, danke für die schnelle Antwort. Als avarice beim Starten die Fehlermeldung brachte habe ich libusb-devel sofort nachinstalliert. Habe leider den Fehler gemacht, dass ich nur make clean, make und make install auf die Schnelle ausgeführt habe :-). Es war vielleicht schon etwas spät:-) Nun habe ich nochmal alle Schritte wie oben beschrieben ausgeführt. Jetzt sieht es etwas besser aus :-) avarice -3 --jtag usb :4242// AVaRICE version 2.13svn20130104, Oct 28 2014 08:57:33 Defaulting JTAG bitrate to 250 kHz. JTAG config starting. Found a device, serial number: J30200030675 Reported device ID: 0x9587 Configured for device ID: 0x9587 atmega32u4 JTAG config complete. Preparing the target device for On Chip Debugging. Waiting for connection on port 4242. Bin gespannt auf die nächsten Schritte mit avr-gdb unter eclipse... Ich werde berichten, wenn alles läuft...
Artur G. schrieb: > Habe leider den Fehler gemacht, dass ich nur make clean, make und make > install auf die Schnelle ausgeführt habe :-) Yep, die (Nicht-)Existenz der libusb wird jedoch vom configure-Script festgestellt.
Hallo zusammen, das ist hier wirklich ein super Thread. Und es geht genau um das Thema, das mich zur Zeit beschäftigt :-) Artur G. schrieb: > Bin gespannt auf die nächsten Schritte mit avr-gdb unter eclipse... > Ich werde berichten, wenn alles läuft... Leider hören die Beiträge genau da auf, wo ich momentan nicht weiter komme: debuggen mit avr-gdb in eclipse (Kepler) unter Linux. Es gibt Anleitungen im Netz, aber nichts davon bei mir funktioniert. Ich habe AVaRICE Version 2.13svn20130104, ein JTAGICE3 mit 2.x Firmware, ein STK500, einen ATmega32 und eclipse Kepler. Leider erhalte ich nur Fehlermeldungen, wenn ich in eclipse debuggen will. Genaue Fehlermeldungen kann ich gerade nicht posten, da ich nicht an meinem Entwickler-Rechner bin, kann ich später nachholen. Mich würde momentan vor allem interessieren, ob irgendjemand es geschafft hat, mit dem JTAGICE3, avarice und eclipse zu debuggen? Und wenn ja, dann wie?
Sorry dafür, dass ich nicht mehr berichtet habe. Ja, ich habe es tatsächlich geschafft. Es funktioniert zu meiner vollen Zufriedenheit. Mit Eclipse Juno AVaRICE version 2.13svn20130104, JTAGICE3 ICE hardware version: 2, ICE firmware version: 2.21 (rel. 212). Das Target is ein Arduino Leonardo, was über JTAG an JTAGICE3 angebunden ist. Das Letzte was tatsächlich fehlte war die -g Option, die ich explizit angeben musste, obwohl ich unter eclipse als target Debug gewählt habe. Grundsätzlich ist jetzt der Ablauf so, daß ich an der Konsole AVaRICE mit dem Kommando avarice -3 --jtag usb :4242// starte. Dann unter eclipse das Debug-Target. Dann noch die Debug-Ansicht und es geht los...breakpoints setzen und debuggen:-) Das zunächst in aller Kürze. Ich kann gerne meine Eclipse-Einstellungen hier mal posten...vielleicht heute Abend...
:
Bearbeitet durch User
Artur G. schrieb: > Ja, ich habe es tatsächlich geschafft. Es funktioniert zu meiner vollen > Zufriedenheit. Das macht Hoffnung :-) > Das zunächst in aller Kürze. Ich kann gerne meine Eclipse-Einstellungen > hier mal posten...vielleicht heute Abend... Sehr gerne!
Angehängte Dateien:
-
eclipse_debug_avr_1.jpeg
100 KB -
eclipse_debug_avr_2.jpeg
91 KB -
eclipse_debug_avr_3.jpeg
97 KB -
eclipse_debug_avr_4.jpeg
84 KB -
eclipse_debug_avr_c___settings_1.jpeg
130 KB -
eclipse_debug_avr_debug_window.jpeg
100 KB
Hier die screenshots der Debug-Einstellungen unter eclipse (Kepler). Für das Debuggen starte ich avrice wie folgt: avarice -3 --jtag usb :4242// AVaRICE version 2.13svn20130104, Oct 28 2014 08:57:33 Defaulting JTAG bitrate to 250 kHz. JTAG config starting. Found a device, serial number: J30200030675 Reported device ID: 0x9587 Configured for device ID: 0x9587 atmega32u4 JTAG config complete. Preparing the target device for On Chip Debugging. Waiting for connection on port 4242. Connection opened by host 127.0.0.1, port 48400. Danach unter eclipse die entsprechende Debug-Configuration anklicken.Fertig! Zuvor muss natürlich das Projekt mit Debuginfos erzeugt und in das Target geflasht werden. Das mache ich auch über eclipse und den JTAGICE3.
Danke für die ausführliche Beschreibung Artur! Jetzt läuft es bei mir auch :-) Ich hatte doch nicht die richtige Firmware auf meinem JTAGICE3, da war eine 1.x Version drauf... Jetzt habe ich nur noch diesen infinite loop "Unable to retrieve disassembly data from backend" im Disassembly Fenster. Besteht eine Chance das wegzukriegen?
Angehängte Dateien:
Funktioniert der Disassembly View bei irgendjemandem von Euch? Ich finde viele Fehlerberichte im Netz aber keine Lösung.
Ich will mal es hier posten, da ich gerade avarice 2.14 erfolgreich unter Opensuse kompiliert habe.
1 | red@BlechPC:~/iso/Atmel/avarice-2.14> avarice --jtag usb:0117 --mkII :4242 |
2 | AVaRICE version 2.14, Apr 18 2021 20:39:39 |
3 | |
4 | Defaulting JTAG bitrate to 250 kHz. |
5 | |
6 | avarice has not been compiled with libusb support |
Da ging es noch schief. Dann habe ich die Pakete libusb-1_0-devel und libusb-combat-devel installiert.
1 | make clean |
2 | ./configure |
3 | sed -i -e 's/__unused//g' src/jtag*.cc |
4 | make |
5 | sudo make install |
6 | |
7 | red@BlechPC:~/iso/Atmel/avarice-2.14/src> avarice --jtag usb --mkII :4242 |
8 | AVaRICE version 2.14, Apr 18 2021 21:07:03 |
9 | |
10 | Defaulting JTAG bitrate to 250 kHz. |
11 | |
12 | JTAG config starting. |
13 | Found a device: JTAGICEmkII |
14 | Serial number: 00:b0:00:00:20:b2 |
15 | set parameter command failed: NO TARGET POWER |
16 | Failed to activate JTAG debugging protocol |
17 | USB bulk read error: No such device or address (-6) |
18 | red@BlechPC:~/iso/Atmel/avarice-2.14/src> |
Hier meldet es sich der Jtag schon mal.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.