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

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

Kann ich das irgendwie überprüfen?

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:

void __attribute__ ((naked, section(".init8"))) init_mem (void);
  void init_mem (void)
  {
    __asm volatile (
    "sts 0x3B, __zero_reg__"  "\n\t"
    );
  }

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...