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
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):
1
FUSES=
2
{
3
.low=0xf7,
4
.high=0x9e,
5
.extended=0xfc,
6
};
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
Eine eigene Frage?
Dieser Thread ist über 10 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
