Hallo, ich habe ein WINAVR20100110 Projekt ins neue AVR Studio5 portiert. Das hat erst einmal ohne Probleme funktioniert, das Projekt wurde ohne Fehlermeldungen und Warnungen übersetzt. Die größe des Codes beträgt ca 121260 byte. Der Code lief allerdings nicht auf dem atxmega128A1 Controller. Beim Debuggen (mit JTAG MKII) stellte ich fest, das keinerlei Register gesetzt werden, und damit der Programmcode schon in der Systemtakt setzten Funktion hängen bleibt. Mein erstes Kommando in diesem Projekt, OSC.XOSCCTRL = OSC_XOSCSEL_XTAL_16KCLK_gc; hat keine Auswirkungen, selbst der Disassembler zeigt jedoch die korrekten Arbeitsschritte an. Das Register ändert seinen Inhalt aber nicht. Reduziere ich den Code auf 65535byte (<2^16byte) läuft das Programm ohne Probleme. Übersetzt ich das Programm mit dem alten WINAVR20100110 Compiler und debugge die elf Datei, funktioniert das Programm problemlos. Das sind meine Compiler Optionen im AVR Studio -DF_CPU=32000000 -I"../src/optional" -I"../src" -Os -fpack-struct -fshort-enums -g3 -Wall -c -std=gnu99 -Werror-implicit-function-declaration -Wpointer-arith -mrelax -Wno-pointer-sign -Wno-comment -mmcu=atxmega128a1 Kennt jemand das Problem, mach ich etwas Falsch?
Basti schrieb: > Übersetzt ich das Programm mit dem alten WINAVR20100110 Compiler und > debugge die elf Datei, funktioniert das Programm problemlos. Dann schreib' einen Bugreport an Atmel.
Also, ich wollte mal einen Programmteil an einen Flash-Platz größer 2^16 positionieren. Einführung der Programmcodesegementierung. Das ging nicht: Ich habe mir das so erklärt, dass der Flash-Speicher der Megas 16-Bit breit ist. Demzufolge belegt eine Adresse 2 Byte des Flashs. Das Mega (ob nun mit x 0der nicht) kennt als niedrigste Programmspeiecheraddresse die 0x0 und als höchste die 0xFFFF. Zunächst war mir das gleichgültig. Nur als ich mit Funktionspointer angefangen habe, zu programmieren, stimmten die Pointeradressen, die über über den Debugger auslesen konnte, mit denen aus dem lst-File nicht überein. Wenn ich die Adressen mit 2 multipliziert hatte, paßte die Angabe aus den SW-Build. Vielleicht wäre das eine plausible Erklärung.
Jörg Wunsch schrieb: > Dann schreib' einen Bugreport an Atmel Hab ich bereits gemacht, biser noch keine Antwort. Ich wollte mich vorallem mal umhören, ob es noch andere mit diesem Problem gibt. Ansonsten muss dier Fehler ja an mir liegen... cskulkw schrieb: > Zunächst war mir das gleichgültig. Nur als ich mit Funktionspointer > angefangen habe, zu programmieren, stimmten die Pointeradressen, die > über über den Debugger auslesen konnte, mit denen aus dem lst-File nicht > überein. Wenn ich die Adressen mit 2 multipliziert hatte, paßte die > Angabe aus den SW-Build. > > Vielleicht wäre das eine plausible Erklärung. Wenn ich dich richtig verstehe besteht das Problem aber nur beim Debuggen. In meinem Fall läuft das gesammte Programm nicht. Ausserdem funktioniert das setzten der Register nichteinmal ohne Funktionsaufruf direkt in der main Funktion....
Basti schrieb: > Wenn ich dich richtig verstehe besteht das Problem aber nur beim > > Debuggen. In meinem Fall läuft das gesammte Programm nicht. > > Ausserdem funktioniert das setzten der Register nichteinmal ohne > > Funktionsaufruf direkt in der main Funktion.... Hi Basti, nein, dann hast Du mich falsche verstanden. Die Textausgabe im LSt-File gibt die Addresse in 8-bit-Organisation aus. Tatsächlich ist der Speicher 16-Bit strukturiert. Der Debugger hat die realen Werte im Register angezeigt. Nur das wird dir hier wohl nicht weiter helfen. Sag mal wie ist das denn mit dem Bootloader organisert? Wenn Dein Code knapp am max. Limit liegt, dann muß doch irgendwo noch der Bootloader hin. Weil in den FUSE-Bits kann man den doch nicht deaktivieren. Hat ev. da der neue Compiler ein Problem? Kannst Du ggf. den 2560 einsetzen, um zu überprüfen, dass es nicht an der max. Speichergrenzen liegt?
Basti schrieb: > Jörg Wunsch schrieb: >> Dann schreib' einen Bugreport an Atmel > > Hab ich bereits gemacht, biser noch keine Antwort. Nichtmal eine Ticket-Nummer? Du solltest mal explizit nachfragen, ob du eine neuere Version der AVR Toolchain beta-testen kannst.
Hi, der Bootlaoder hat eine extra Speicherbereich, nach dem "normalen" Code. Mit dem WinAVR Compiler gab es auch keine Probleme den Bootloader zu erstellen und dort abzuglegen. Mit dem AVR Studio 5 und der Atmel Toolchain habe ich es noch nicht getestet. Es scheint ein Problem mit der Toolchain von ATMEL zu sein. Die Antwort von Atmel hat mich auch nicht vielt weiter gebracht: Hi Sebastian This might be a problem with gcc. Because gcc uses 16bit pointers you can have problems addressing instructions and/or data in the upper part of memory. See the following two threads on avrfreaks for (alot of) details: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=93874 http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=106714 I see you are already using the -mrelax option to gcc. I will keep this ticket open, and keep looking at it. Please report if you find this useful. Es liegt also an den Adressräumen größer 16Bit, aber so richtig weiter bringt mich das jetzt auch nicht... Ich habe jetzt nocheinmal nachgefragt, wie ich weiter vorgehen soll. Bisher habe ich noch keine Antwort..
Basti schrieb: > Es liegt also an den Adressräumen größer 16Bit, aber so richtig weiter > bringt mich das jetzt auch nicht... Du solltest sie nochmal drauf stoßen, dass es ja mit dem alten WinAVR funktioniert hat, folglich kein grundsätzliches Problem deines Codes sein kann (natürlich mal vorausgesetzt, dass das Compilat auch bereits mit WinAVR größer als 64 KiB geworden war).
Jörg Wunsch schrieb: > Du solltest sie nochmal drauf stoßen, dass es ja mit dem alten > WinAVR funktioniert hat, Ja das hab ich gemacht. Sie wollten von mir das Projekt haben, um sich das ganze selbst anzuschauen. Hab ihnen ein Beispielprojekt gesendet, das mit WinAVR geht und mit dem AVR Studio nicht. Die WinAVR Programme sind immer etwas größer als die AVR Studio Varianten (bei mir jedenfalls). Wenn ich eine Antwort bekomme melde ich mich nochmal.
Ok ich habe eine Atnwort. Das ganze ist ein Fehler im Ammel Framework
und schient schon seit April bekannt zu sein, warum das bisher nicht
gefixed wurde, weiß ich auch nicht.
Hi Sebastian.
I'm sorry for the delay, but now I finally found the solution for you.
There is a bug in the software framework used by AS5, where the RAMPZ
register is set to 1 before entering main. This is what causes your
instructions to fail. It only applies to designs > 64K. The workaround
is to clear the register in the start of your main:
asm ("out 0x3B,r0");
For more details, see the bug report:
http://asf.atmel.no/bugzilla/show_bug.cgi?id=521
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.