Hallo, Bei einem aktuellen Projekt setze ich erstmals den mega32u4 ein und habe damit schwierigkeiten beim Debuggen. Da ich nach einem Tag des suchens und probierens noch keinen Schritt weiter bin, frage ich euch um Rat - Vielleicht hatte jemand schon etwas ähnliches oder ich stehe einfach nur auf dem Schlauch. Die Umgebung: - Linux (Gentoo) - Target: Arduino-Leonardo als Eval-Board mit angebauter JTAG-Schnittstelle. Einfachste Test-Firmware (Port an - Port aus - loop, funktioniert soweit :-) Clock auf 8MHz Quarz umgebaut. - Debugging: Atmel JTAG ICE mkII, Firmware 7.28 bzw. 6.x - avarice 2.10 bis 2.13 - avr-gdb 7.6 bzw. 7.2 - Fuses: # low fuse: 1101 1101 (crystal 8MHz) LFUSE = 0xdd # HFUSE: 0001 1001 (ocd on, jtag on) HFUSE = 0x19 # EFUSE: 1111 1100 (bod 2.4V, HWB disabled) EFUSE = 0xcc # LBB: 1111 1111 (no lock) LBB = 0x3f Das Problem: Avarice wird gestartet, erkennt das Device: $ avarice -d -R -2 -j usb -B 200 :4242 AVaRICE version 2.13, Nov 15 2012 23:51:06 JTAG config starting. Found a device: JTAGICEmkII Serial number: 07:00:00:00:34:57 Reported JTAG 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. Soweit sieht also gut aus. Dann starte ich avr-gdb und versuche zu avarice zu connecten: (gdb) target remote localhost:4242 Genau dann verabschiedet sich avarice mit einem Kommunikationsfehler: Connection opened by host 127.0.0.1, port 46588. Failed to read target memory space: JTAG ICE timeout exception USB bulk read error: Broken pipe USB daemon died Die Debug-Ausgaben findet ihr in der angehängten Datei. Bisher getestet: - Das Debugging mit dem AVR-Studio 6.x funktioniert auf der selben Hardware am selben Entwicklungsrechner in der VMWare. - Verschiedene versionen der ICE-Firmware, von avr-gdb und von avarice (2.10 bis 2.13) erzeugen fast identische Fehler. - Verschiedene Bitraten (25k bis 2000k) - JTAG-Verbindungen doppelt nachgeprüft - Spannungsversorgung am uC ist hinreichend stabil Jetzt bin ich ratlos. Ich kenne die ICE-Tools nicht so genau, dass ich damit etwas anfangen könnte. Leider werde ich auch nicht schlau, ob avarice mir mitteilen möchte, dass der Fehler im Bereich der JTAG-Schnittstelle oder bei der Kommunikation zum ICE passiert. Die Signale auf der JTAG-Schnittstelle sehen jedenfalls noch sehr gut aus. Hat jemand eine Idee dazu? Viele Grüße, Sven
Noch ein Update: Eben habe ich das selbe nochmals auf einem Debian-System getestet. Sprich: avarice-2.13 installiert und gestartet. Beim Connect durch avr-gdb passiert der selbe Fehler. Unterschied: Auf dem System sind die Rechte nicht passend, daher habe ich avarice (zum Test!) als root gestartet. Im Anhang übrigens nochmal das selbe Protokoll, nur mit Browser-Freundlicherer Datieendung....
Sven Queisser schrieb: > - Das Debugging mit dem AVR-Studio 6.x funktioniert auf der selben > Hardware am selben Entwicklungsrechner in der VMWare. Kannst du dessen USB-Traffic mal sniffen? Das sollte mit Wireshark mittlerweile gehen. Dann könnte man mal vergleichen, was das Atmel Studio anders macht als AVaRICE. Ich würde dich bitten, dann einen Bugreport bei sourceforge.net einzukippen, das Logfile hier und dann auch das Wireshark-Tracefile bitte mit anhängen. Danke!
Den entsprechenden Bug gibt es jetzt unter: https://sourceforge.net/tracker/?func=detail&aid=3587834&group_id=39505&atid=425407 Grüße Sven
svenq schrieb: > Den entsprechenden Bug gibt es jetzt unter: Danke, hatte schon eine Mail bekommen. ;) Wenn du jetzt noch den USB-Trace vom Atmel Studio hättest, stünden die Chancen nicht schlecht, das zu finden. Ich habe leider selbst keinen U4-Controller zum Testen zur Verfügung (und andere scheint das nicht in der Form zu treffen).
Sven Queisser schrieb: > ... hatte ich eben angehängt. Danke, die Mail dafür hatte ich noch nicht vorliegen. Werde ich mir mal anschauen, mal sehen, was da anders läuft.
Hmm, seltsam. Ob das an der Studio-6-Firmware liegt? Der wesentliche Unterschied ist, dass AVaRICE noch das "klassische" CMND_SET_DEVICE_DESCRIPTOR benutzt, wie es in der Appnote AVR067 dokumentiert ist. Atmel Studio 6 benutzt das undokumentierte Kommando 0x36. Dieses ist mir bislang nur im Zusammenhang mit Xmegas über den Weg gelaufen, scheint aber nun offenbar allgemein auch für Mega-AVRs benutzt zu werden. Leider wird es hier neben der bereits früher beim Xmega beobachteten Variante (bei der danach ein Parameter 0x0002 kommt, gefolgt von Lage und Länge der Speicherbereiche) noch zusätzlich mit 0x0080, 0x0081, 0x0088 und 0x0089 benutzt, denen jeweils weitere Bytehaufen folgen. Vermutlich ist das die "IO bitmap", die sonst im device descriptor übertragen worden ist, allerdings finde ich keine 1:1-Abbildung der entsprechenden Parameter aus dem alten (Studio 4) XML, und im neuen XML finde ich gleich gar nichts dergleichen (oder ich habe noch nicht die dazugehörige XML-Datei gefunden :-/). Ich nehme mal an, du kannst AVaRICE vom Sourcecode aus bauen, ich werde da mal versuchen, ob ich einen entsprechenden Patch zusammen- hacken kann.
Hättest du die Chance, die Firmware auf eine V6.x runterzuziehen (AVR Studio 4), und damit mal zu testen, ob das dann funktioniert? Nicht, dass das Problem noch ein ganz anderes ist ...
Hmm, ob du wohl am gleichen Problem leidest wie diese Leute hier: Beitrag "Porbleme mit JTAGICE mkii" Deine 7.28er Firmware entspricht ja dem, was das Studio als 7.1c bezeichnen würde und scheint damit verbuggt zu sein ... Wobei, unterm Atmel Studio gehte es bei dir (anders als in jenem Thread).
Jörg Wunsch schrieb: > Atmel Studio 6 benutzt das undokumentierte > Kommando 0x36. Scheint übrigens identisch zu dem zu sein, was sie beim JTAGICE3 benutzen (AVaRICE Feature Request 3586529). Dort sieht das so aus (für einen ATmega1284):
1 | 0x01 --> 0e 00 0c 00 12 01 00 02 00 1f 00 01 00 00 02 00 |
2 | ^^^^^^^^^^^^^^^^^^^^ |
3 | 00 00 00 00 00 fe 00 00 00 01 00 10 08 03 01 00 |
4 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
5 | 00 00 31 22 21 1f 20 57 46 |
6 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ |
7 | 0x82 <-- 0e 0c 00 12 80 00 |
Bei dir:
1 | 0x02 --> 1b 05 00 23 00 00 00 0e 36 02 00 1f 80 00 00 80 |
2 | ^^^^^^^^^^^^^^ |
3 | 00 00 00 00 00 00 00 3f 00 00 00 01 00 04 04 03 |
4 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
5 | 01 00 00 00 31 22 21 1f 20 57 46 b9 b4 |
6 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
7 | 0x82 <-- 1b 05 00 01 00 00 00 0e 80 13 95 |
Jörg Wunsch schrieb: > Hättest du die Chance, die Firmware auf eine V6.x runterzuziehen > (AVR Studio 4), und damit mal zu testen, ob das dann funktioniert? > Nicht, dass das Problem noch ein ganz anderes ist ... Das hatte ich getestet. Ich hatte so ziemlich als erstes die Firmware per AVR-Studio 4.19 geflasht. Das ist jedenfalls eine 6.??. Der Fehler war gleich bis sehr ähnlich. Daran scheint es also nicht zu liegen.
Sven Queisser schrieb: > Daran scheint es also nicht zu liegen. Hmm, schade. Gut, dann werde ich das nochmal genauer vergleichen.
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.