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!
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):
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.