Hallo! Ich habe folgendes Problem mit meinem ATxmega128A1: Mir kommt vor als ob ich an eine Art Dateibegrenzung stoßen würde, da ich nur eine bestimmte Anzahl an Files zu meinem (relativ großen Projekt) hinzufügen kann. Vorweg: Ich verwende das AVR Studio 6.0.1843, zum programmieren verwende ich das AVR JTAGICE mkII. Immer wenn ich ein File (egal ob .c oder .h) weiter hinzufüge (Build-Action auf "Compile") und neu compiliere führt der µC die ersten paar Programmzeilen aus und springt anschließend ins Disassembly. Egal ob mit oder ohne debuggen. Setzte ich die Build-Action in den Properties wieder auf "None" so arbeitet der µC wieder normal. Laut Compiler-Output ist der Datenspeicher erst zu ca. 50% und der Programmspeicher erst zu ca. 70% ausgelastet. Es sind keine Errors oder Warnings aufgetreten. Ich hoffe mir kann jemand helfen, da ich schon ziemlich am verzweifeln bin. Mit freundlichen Grüßen Bernhard Uhl
:
Verschoben durch Moderator
Hat den wirklich niemand einen Tipp oder eine Idee wie man mein Problem lösen könnte? Mit freundlichen Grüßen Bernhard Uhl
Vielleicht läuft dein Stack ja auch über!? Das zeigt der der Compiler nämlich nicht an
Naja, du könntest mal die lokalen Variablen einer Funktion als global deklarieren. Dann tauchen sie mit beim Compilieren mit auf. Sowas kann schnell passieren wenn du größere Arrays etc. lokal deklariert.
Ich habe bereits den Großteil der Variablen global deklariert. Ich arbeite außerdem sehr viel mit Funktionspointern. Diese haben übrigends im Fehlerfall (eine Datei zu viel eingebunden) alle die Adresse 0xFF. Mitlerweile muss ich immer mehr Files auf Build-Action "None" setzen und riesige Codesegmente (mit Funktionen, die in den exkludierten Files definiert sind, etc.) auskommentieren um überhaupt weiterarbeiten zu können. Mit freundlichen Grüßen Bernhard Uhl
Hallo! Mittlerweile habe ich das Problem selbst gelöst und möchte es, für alle die das selbe Problem haben, hier beschreiben: Es lässt sich auf einen kleinen Bug des AVR-Studios zurückführen, genauer gesagt im Umgang mit dem Z-Pointer. Dieser ist beim ATxmega128A1 (und auch bei anderen µC's von Atmel) 3 byte, also 24 bit groß, um den Programm- bzw. Flashspeicher (128 kB) sowie auch größere externe Datenspeicher (bis zu 16MB) richtig adressieren bzw. anbinden zu können. Wenn nun das Programm größer wird, der Programmspeicher mehr als 65536 byte ausgelastet ist und somit alle 3 byte des Z-Pointers zum Adressieren benötigt werden tritt der erwähnte Bug auf, da er diesen Pointer NICHT selbstständig zurücksetzt: Will der µC jz aber auf den Datenspeicher (8 kB groß) zugreifen, benötigt er nur maximal 2 byte des Z-Pointers. Da aber zuvor schon alle 3 byte benötigt hatte sind alle auf irgendeinen Wert gesetzt. Der Comiler, der in einem 64-bit System (oder auch 32-bit System) arbeitet sieht hierbei kein Problem. Der µC benützt jedoch zur Adressierung des Datenspeichers nur 16 bit, benützt daher fälschlicherweise nicht die unteren 2 byte sondern die oberen 2 byte des Z-Pointers. Somit kann das Programm nie richtig funktionieren. Abhilfe hierbei schafft folgender Code in der Init-Section:
1 | void __attribute__ ((naked, section(".init8"))) init_mem (void); |
2 | void init_mem (void) |
3 | {
|
4 | __asm volatile ( |
5 | "sts 0x3B, __zero_reg__" "\n\t" |
6 | );
|
7 | }
|
Dieser Code setzt das oberste byte des Z-Pointers (RAMPZ) nach dem Abrufen der Daten vom Flash-Speicher wieder auf 0 zurück. Weiters muss man darauf achten, keinerlei Funktionen zu verwenden, die as Register RAMPZ beschreiben, und falls doch es wieder zurücksetzen. Dies erklärte auch meine Problem mit einem File mehr. Dieses verursachte das der Programmspeicher größer als 65536 byte wurde. Dies verursachte die Verwendung des später nicht mehr zurückgesetzten Registers RAMPZ. Ich habe das Problem bei folgenden Versionen des AVR-Studions festgestellt: - 5.0.**** - 5.1.**** - 6.0.**** Mit freundlichen Grüßen Bernhard Uhl
Bernhard Uhl schrieb: > Es lässt sich auf einen kleinen Bug des AVR-Studios zurückführen, Nein, gewiss nicht, sondern eher der AVR-Toolchain die dort mitgeliefert wird. Hab's daher mal nach "GCC" geschoben.
Bernhard Uhl schrieb: > Es lässt sich auf einen kleinen Bug des AVR-Studios zurückführen, > genauer gesagt im Umgang mit dem Z-Pointer. Dieser ist beim ATxmega128A1 > (und auch bei anderen µC's von Atmel) 3 byte, also 24 bit groß, Der Z-Pointer ist immer noch 16 Bits groß (es gibt kein Register R32), er wird jedoch mit einem Core-SFR zu einem 24-Bit Zeiger konkateniert. > Wenn nun das Programm größer wird, der Programmspeicher mehr als 65536 > byte ausgelastet ist und somit alle 3 byte des Z-Pointers zum > Adressieren benötigt werden tritt der erwähnte Bug auf, da er diesen > Pointer NICHT selbstständig zurücksetzt: Siehe http://gcc.gnu.org/PR52461 behoben in 4.7.1. Der Bug entstand durch die Xmega-Implementierung in 4.7.0. > Der µC benützt jedoch zur Adressierung des Datenspeichers nur 16 bit, > benützt daher fälschlicherweise nicht die unteren 2 byte sondern die > oberen 2 byte des Z-Pointers. Nö, er benutzt immer noch 24 Bits, greift aber mit dem falschen RAMPZ dann auf den externen RAM zu. > Dies erklärte auch meine Problem mit einem File mehr. Dieses verursachte > das der Programmspeicher größer als 65536 byte wurde. Dies verursachte > die Verwendung des später nicht mehr zurückgesetzten Registers RAMPZ. > > Ich habe das Problem bei folgenden Versionen des AVR-Studions > festgestellt: > - 5.0.**** > - 5.1.**** > - 6.0.**** Für die atmel-Toolchain musst du deren Bug-Orakel befragen, falls sowas existiert. M.W. gibt es von Atmel noch keinen avr-gcc 4.7. Und wie zeitnah Probleme behoben werden bzw. Updates bereitgestellt werden, weiß ich als nicht-AS-Nutzer auch nicht.
Danke für die Aufklärung, hab ich falsch interpretiert...
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.