JTAGICE mkII AVR32Studio bleibt beim Debuggen bei 61% hängen

[Michael Sonst (Gast)]

Hallo,
bevor ich mich mit meinem Anliegen an ATMEL wende, zunächst hier einmal 
die Frage, ob andere mit dem mkII Probleme haben?!

Nach etwas umständlichem Installationsprozedere von AVR32Studio (Ließ 
sich nur mit Eclipse CDT + manueller Installation über Marketplace 
installieren) lässt sich der AT32UC3A3256 nun zumindest (wenn auch recht 
langsam) Programmieren. Nebenbei habe ich festgestellt, dass sich der 
Prozessor nicht mit der im JTAG vorhandenen Firmwareversion Chip-Erasen 
lässt, die neue Versionsnummer der Firmware irgendwie seltsam aussieht, 
die zum EVK1104 beigelegte Studioversion veraltet ist (bzw. das Board 
noch garnicht unterstützt) usw ;-)

Zum Hauptproblem:
Leider bekomme ich nur den Debugger nicht zum Laufen. Lade ich mein 
Demoprojekt (z.B. USART Demo) bleibt der Progressbar im Studio bei 61% 
"hängen" und es tut sich (auch 10min später) nichts mehr. Nur 
terminieren der Aktion hilft da noch.

Da Debuggen bei einem JTAG doch irgendwie dazu gehört, meine Frage, ob 
dieses Problem bei euch auch besteht, wie ihr es evtl. gelöst habt und 
wie "zufrieden" ihr mit einem 200€ teuren Debugger seid, der dermaßen 
langsam und gefühlsmäßig nebenbei produziert daher kommt. Gibt es noch 
andere Stolpersteine?



Grüße
Michael

[me (Gast)]

Weil du die UART-Demo anführst - bleibt die Processbar vielleicht nur 
deswegen an einer Stelle stehen, weil der Debugger auf das Flag wartet, 
in dem angezeigt wird, dass ein Zeichen empfangen wurde? Dass er also 
dort wartet?
Ich hatte das gleiche Problem in meiner IDE im debugging-mode. Habe dann 
einfach das Flag zur Fuss getoggelt und dann gings weiter.

[Michael Sonst (Gast)]

Welches Flag meinst du denn?
Das Programm ist ja noch nichtmal auf dem Prozessor, so wie das 
aussieht.. nach einem Reset des Prozessors müsste ja sonst zumindest das 
Programm wieder anlaufen.

Grüße
Michael

[me (Gast)]

Mein uC war allerdings ein ATmega32, das Flag(Bit) um das es in meinem 
Fall ging, war das USART Receive Complete Bit: RXC. Da ich das Programm 
nur im Debugger laufen hatte, hat er eben ewig auf das Löschen dieses 
Bits gewartet.
Nach dem Löschen dieses per Eingabe Bits gings dann weiter.
Ich kenne den AT32UC3A3256 jedoch (noch) nicht, denke aber, dass es dort 
ähnlich sein wird.

[Michael Sonst (Gast)]

Mit verlaub, aber dein Fehler ist ja schon einen Schritt weiter, oder 
verstehe ich dich falsch?

Bei mir kommt das Programm garnicht erst komplett in den Controller und 
es
sind keine BP gesetzt, befinde mich noch im AVR View in Eclipse. Der BP 
in main wurde noch nicht angesprungen (gesetzt in Properties) usw..

Grüße
Michael