Atmel Studio 7, ATMEGA2560/2561 debuggen

[Helge T. (htefs)]

Hallo Allerseits!
Wer keine langen Vorreden lesen will, springt bitte direkt zum letzten 
Abschnitt dieses Postings.

Ich verwende seit geraumer Zeit ATMEGS2560 und ATMEGA2561 für diverse 
Projekte. In der Vergangenheit habe ich immer mit dem uralten AVR Studio 
4 und WinAVR gearbeitet. Als Debugger habe ich den JTAG ICE MK II oder 
den AVR Dragon verwendet. Funktionierte soweit ganz gut und problemlos.
Dann kam Windows 10. Danach hatte ich ein Problem mit dem Compilieren 
das sich aber durch den Austausch einer Datei vom WinAVR beheben lies. 
Allerdings dachte ich, dass es an der Zeit wäre, doch mal zu einer 
neueren Version vom Atmel Studio zu wechseln. Also Studio 7 
heruntergeladen und installiert. Projekt Importieren und Kompilieren 
ging problemlos. Beim Programmieren musste erstmal die Firmware vom JTAG 
ICE MK II aktualisiert werden, was ich auch getan habe. Danach das gute 
Stück neu gestartet, alles nichts Besonderes. Der ATMEGS2561 lies sich 
danach auch programmieren und die Software lief auch. Aber wenn ich mal 
debuggen wollte, bekam ich eine Fehlermeldung (leaveprogmode failed). 
Das Ganze mit dem Dragon probiert, gleiches Ergebnis. Da ich fertig 
werden musste, habe ich das Studio 7 wieder runtergeworfen und das alte 
4-er wieder aufgespielt: Weder der JTAG, noch der Dragon wurden vom 
Studio 4 erkannt. Firmwaredowngrade ging nicht. Also alten Laptop 
vorgekramt (WinXP), Studio 4 war da noch drauf, JTAG und Dragon wurden 
erkannt, Firmwaredowngrade funktionierte, ich konnte erstmal 
weiterarbeiten...
Dann auf der embedded world am Stand von Atmel mal gefragt, ob da ein 
Problem bekannt ist. Die drei befragten Herren waren nicht in der Lage, 
eine vernünftige Auskunft zu geben. "Was? Mit dem alten Ding 
programmieren Sie noch? Da sollten Sie sich vielleicht den neuen ATMEL 
ICE zulegen. Der JTAG ICE MK II ist doch schon mindestens 10 Jahre 
alt..." - "Hier am Stand wird Ihnen keiner helfen können. Da müssen Sie 
mal online einen Case beim Support eröffnen, da sitzen dann die 
Spezialisten, die können garantiert helfen.". Ich habe Beides getan. 
Einen ATMEL ICE gekauft und eine Anfrage an den Atmel Support 
geschrieben. Letzterer fragte noch zusätzliche Infos ab und lies sich 
ein ausführliches Log schicken, danach teilte man mir mit, dass der Fall 
an die interne Abteilung weitergegeben wurde. Seit nichts mehr. Der 
zwischenzeitlich angekommene nagelneue ATMEL ICE brachte auch keine 
Lösung, der steigt mit der gleichen Fehlermeldung aus.
Der Witz am Ganzen ist: Ich kann mit dem Studio 7 und dem JTAG ICE MK II 
"kleinere" Prozessoren, wie den ATMEGA32 oder den ATMEGS1284 debuggen. 
Nur bei den 256-er geht es nicht. Die Installation ist also 
grundsätzlich in Ordnung. Ich habe das Ganze auch noch auf einem 
weiteren Rechner und auf einem "jungfräulichen" Laptop probiert. Das 
Ergebnis blieb immer das Gleiche.

Nun meine eigentliche Frage: Hat hier schon einmal jemand mit dem Atmel 
Studio 7 ein Programm auf einem ATMEGA2560 oder ATMEGA2561 debuggen 
können, oder bin ich der Einzige mit diesem Problem?
Gruß, Helge

[Moby A. (moby-project)]

Hab genau diese Konfiguration (demnächst) im Einsatz,  ich geb Dir dazu 
noch eine Rückmeldung falls hier keine Reaktion mehr kommt!

[Helge T. (htefs)]

Na da bin ich mal gespannt. Sobald sich Atmel mit einer Lösung meldet, 
werde ich das natürlich auch hier verkünden.
Gruß, Helge

[Helge T. (htefs)]

So...
Da ich versprochen habe, hier das Ergebnis der Supportanfrage 
mitzuteilen, werde ich das mal noch nachholen...

Atmel hat sich viel Zeit gelassen und trotzdem keine Lösung gefunden. 
Die konnten das Problem nicht nachstellen. Ich sollte das Studio 
deinstallieren, alles bereinigen und dann neu installieren. Hab ich 
gemacht, hat nichts gebracht. War auch logisch, denn auf dem 
"jungfräulichen" Laptop lief es ja auch nicht.
Ich hatte zwischenzeitlich ein kurzes Testprogramm geschrieben, das ich 
auf allen bei mir vorhandenen ATMEGA ausprobieren wollte. Ich habe ein 
STK500 und dazu verschiedene Aufsätze, so dass ich eine Menge 
Prozessoren testen konnte. Prozessor im Studio ändern, richtigen 
Prozessor auf das Board stecken, neu compilieren, auf den Prozessor 
spielen, Debuggen starten. Ist alles kein großer Zeitaufwand. Ich hatte 
mit den kleinen Prozessoren angefangen und da lief alles, wie gewollt. 
Erstaunlicherweise lief das Testprogramm auch auf den großen 
Prozessoren, auf denen mein "Arbeitsprogramm" nicht laufen wollte. Ich 
dachte erst, das es mit der Größe des Programmes zusammenhängen könnte 
und habe angefangen, mein "Arbeitsprogramm" soweit runterzurüsten, bis 
es die Größe des Testprogrammes hatte. Erstaunlicherweise kam aber immer 
noch die gleiche Fehlermeldung. Die Größe ist also nicht der Auslöser. 
Also habe ich nachgedacht, worin sich das Test- und das Arbeitsprogramm 
unterscheiden und was der Unterschied zu den anderen, auf den kleineren 
Prozessoren getesteten Programmen, ist.
Die Lösung ist recht simpel:

Ich hatte in den Arbeitsprogrammen in der Hauptdatei unter dem #define- 
und include-Teil folgende Zeilen stehen (Beispiel ATMEGS2560):

FUSES = 
    {
        .low = 0xf7,
        .high = 0x9e,
        .extended = 0xfc,
    };

Das hatten wir reingeschrieben, damit die Fuses in der elf-Datei 
auftauchten und beim Flashen mit gesetzt werden. Mit dem Studio 4 hatte 
das nie Probleme gemacht. Wir haben das auch nicht aus der Luft 
gegriffen, denn laut der Info unter folgendem Link ist das so korrekt:
http://www.nongnu.org/avr-libc/user-manual/group__avr__fuse.html

Wenn ich den Abschnitt auskommentiere, funktioniert das Debuggen im 
Studio 7 auch auf dem ATMEGS2560 mit dem ungekürzten Arbeitsprogramm. 
Und das auch mit dem JTAG ICE MK II und dem AVR Dragon.
Ich vermute, dass im Studio 7 erst die OCD-Fuse gesetzt wird und danach 
der FUSES-Abschnitt abgearbeitet und die Fuses entsprechend gesetzt 
werden. Dabei wird die OCD-Fuse wieder resettet und man kann nicht mehr 
debuggen.

Wir leben jetzt damit, dass wir die Fuses nicht mehr in der elf-Datei 
haben. Hatten das sowieso eher selten genutzt. Ich habe die Lösung 
meines Problems trotzdem an Atmel geschickt und die haben das an die 
interne Bearbeitung weitergeleitet. Vielleicht funktioniert das Ganze ja 
wieder in einer der Folgeversionen.

Gruß, Helge


EDIT: Gerade gefunden, das selbst Atmel das in ihrer Beschreibung zur 
AVR-libc hat:
http://www.atmel.com/webdoc/AVRLibcReferenceManual/group__avr__fuse.html