Problem mit strcpy() der avr-libc

[Sascha Weitkunat (Gast)]

Hallo,

ich hab massive Probleme mit besagter Funktion, vielleicht alles nur
Phantomfehler durch das AVR-Studio, denn es gibt ja nicht wirklich viel
falsch zu machen. Schon hierbei versagt die Funktion:

// -------------------------------------------------------------------
#include <avr/io.h>
#include <string.h>

int main(void)
{
  char buf[32];
  strcpy(buffer, "test-test");

  for (;;)
  {
  }

  return 0;
}
// -------------------------------------------------------------------

Ich denke mal das Problem ist der Simulator des AVR-Studios, ich
kompiliere zuerst mit 'make all' und erzeuge dann die .cof per 'make
extcoff', die nun erzeugte .cof lade ich im AVR-Studio 4 und erhalte
sehr verwirrende Ergebnisse... Mal wird 'buffer' garnicht angetastet,
mal mit wirren Zahlen überschrieben. Ich habe 'buffer' ganz normal im
Watch-Fenster aufgeblättert. Sind das bekannte, nicht zu verhindernde,
Probleme des Studios oder muss man da noch irgend einen Workaround
machen?

[Sascha Weitkunat (Gast)]

Und es geht weiter...
Natürlich hat die Buffer-Variable in obigen Beispiel in beiden fällen
den gleichen Namen ;)

Das Problem tritt schon bei einer rudimentären Zuweisung wie dieser
hier auf:

// -------------------------------------------------------------------
char insert[] = "test-test";
// -------------------------------------------------------------------

Das entstehende Array wird vom AVR-Studio auch richtig erkannt,
ebenfalls dass es eine Größe von 10 Zeichen besitzt, nur der Inhalt ist
gänzlich falsch, alle Stellen werden mir FFh initialisiert.

Ich wäre sehr an der Aufklärung dieses absolut tollen Phänomens
interessiert, da das AVR-Studio zum simulieren von in C geschriebenen
und mit WinAVR kompilierten Programmen recht reizvoll erscheint -
sollte es denn zuverlässig funktionieren.

Der zu Simulierende Controller ist übrigens ein ATmega32, ich benutze
die neuste WinAVR Version und das AVR-Studio 4.07.

[Peter Fleury (Gast)]

Die neueste Version von AVRStudio ist Version 4.08 !

Es wird doch fast jeden Tag in diesem Forum darauf hingewiesen dass man
für WinAVR Version 4.08 und make extcoff benutzen soll ! Ist das so
schwierig ?

[Sascha Weitkunat (Gast)]

Hallo Peter,

dass die neuste Version des AVR-Studios die 4.08er ist, ist schon
ersichtlich, nur habe ich eher einer nicht-Beta vertraut, anscheinend
ein Fehler.

Liegt der Fehler denn nun direkt im Studio oder bei der Kooperation von
Extcoff und dem Studio? Sorry dass ich ein scheinbar schon so oft
behandeltes Thema anschneide, aber das bestehende Problem habe ich
bisher noch gar nicht mitbekommen.

[Joerg Wunsch (Gast)]

> nur habe ich eher einer nicht-Beta vertraut

Es gibt keine AVR-Studio 4 Version, die nicht beta wäre. :-/

> Liegt der Fehler denn nun direkt im Studio oder bei der Kooperation
> von Extcoff und dem Studio?

Letzteres.  AVR Studio lädt standardmäßig nur den Inhalt von .text,
der GCC legt aber die Initialisierungsdaten für die Variablen in .data
ab (wie in der Unix-Welt halt üblich), der Startup-Code liest sie
hinter dem Ende von .text.  Daher mußt Du ja beim Erstellen des
hex-Files auch sowohl .text als auch .data (in dieser Reihenfolge)
angeben.

Die kommerziellen AVR-C-Compiler kennen alle kein .data sondern nur
.bss (nichtinitialisierte Daten).  Die initializer für die
initialisierten Daten legen sie dann selbst innerhalb .text an.  AVR
Studio bis 4.07 liest nur .text ein, ab 4.08 nun kann es, wenn es den
GCC als Quelle erkennt (funktioniert prinzipbedingt nur bei
`extcoff')
auch .data mit einlesen.

Diese Verfahrensweise (nur .text bzw. nun auch .data lesen) ist auch
der Grund, warum man damit keine beliebigen sections (z. B.
.bootloader) debuggen kann.

[Peter Fleury (Gast)]

> Sorry dass ich ein scheinbar schon so oft
>behandeltes Thema anschneide, aber das bestehende Problem habe ich
>bisher noch gar nicht mitbekommen.

Folgende Threads haben genau dieses besprochen:

AVR-GCC und Studio 4.07 - C-Struct's :
http://www.mikrocontroller.net/forum/read-2-54407.html

Studio 4.08, GCC 3.3.1 + C-structs
http://www.mikrocontroller.net/forum/read-2-56844.html