avr toolchain compilerfehler?

[Adib (Gast)]

Hallo Leute,

nachdem ich für die Toolchain von AVR geworben habe 
(avr-toolchain-installer-3.3.0.710-win32.win32.x86.exe), saß ich heute 
den ganzen Tag über einen (Compiler)-Fehler.

Ich benutze in einem Funktionsaufruf einen konstanten String:
 printf("hello world");
Der Fehler ist, dass im printf nur komisches Zeug ankommt.

Beim AVR gcc werden diese Strings ja vor der main in den RAM kopiert und 
von dort referenziert. Das geschieht mittels "_copy_data".

Komischerweise hat diese Funktion eine falsche Quellen-Addresse. Das 
Ziel ist ok, die Länge auch.

Dadurch kommt im printf nur Schotter an.

Ich habe jetzt mal:
- mit AVR- STudio 5 compiliert: funktioniert.
- dem AVR Studio 5 das Toolchain Verzeichnis vom AVR Toolchain 3.3.0.710 
zugewiesen: Fehler lässt sich reproduzieren.
- das Toolchain-Verzeichnis vom Studio 5 in das Toolchain-Verzeichnis 
vom Studio 4 kopiert: funktioniert.

Hat irgendeiner von euch ähnliche Erfahrung mit diesem Compiler von 
Atmel? Ist das ein bekannter Fehler?

Grüße, Adib.
--

[Johann L. (gjlayde)]

Da musst du Atmel fragen, die haben das Ding gebastelt und rumgepatcht.

Ebenso wie genannte _copy_data. Im offiziellen avr-gcc heisst diese 
Function __do_copy_data.

[C/C++ (Gast)]

Adib schrieb:
> Ich benutze in einem Funktionsaufruf einen konstanten String:
>  printf("hello world");
> Der Fehler ist, dass im printf nur komisches Zeug ankommt.

Was passiert denn, wenn du die printf() mit den richtigen Parametern 
aufrufst?
printf("%s", "hello world");

[Adib (Gast)]

Das printf war jetzt nur als "Beispiel" zu verstehen. In meinem Programm 
sende ich Parameterdaten an einen GPS Empfänger:

serial_write_str(1, (unsigned char *)"$PMTK251,115200*1F");

Das Problem ist, das an der Stelle wo der String eigentlich stehen 
sollte hat die __do_copy_data Funktion nur Datenkauderwelsch hinkopiert.
Alle konstanten Strings sind Müll. Was gehen würde ist ungefähr:
serial_write(1, '$');
serial_write(1, 'P');
serial_write(1, 'M');
serial_write(1, 'T');
...

Wollt auch nur wissen, ob das ein bekanntes Problem der Toolchain ist 
...

Ich habe mir jetzt den Compiler vom AVR Studio 5 kopiert. Damit geht 
genau der gleiche Quellcode. Vorher hatte ich mit Winavr2010 gearbeitet. 
Das ging auch.

Adib.
--

[Johann L. (gjlayde)]

Adib schrieb:
> Das printf war jetzt nur als "Beispiel" zu verstehen.

Märchencode ist immer schlecht. In 99.9% der Fälle steckt der Fehler 
nämlich in den Pünktchen-Pünktchen-Pünktchen.


Wird denn .data auch brav ins hex-File kopiert?

[Adib (Gast)]

ich habe mit srec_cat das hex nach bin convertiert und konnte am Ende 
ebend jene Strings entdecken, die in den Funktionsaufrufen direkt 
plaziert werden.


Ich habe versucht diese Pünktchen bzw. den "zwischen Stuhl und 
Schreibtisch" -Faktor zu eliminieren, indem ich wie beschrieben 
vorgegangen bin. Ich habe auch jeweils neue Projekte erstellt (ohne 
spezielle Optionen).

__do_copy_data hat aber von einem anderen Speicherbereich gelesen.

LG der Adib.
--

[Jörg W. (dl8dtl) (Moderator)]

Adib schrieb:
> __do_copy_data hat aber von einem anderen Speicherbereich gelesen.

Dann mach's konkret, eine Minimalbeispiel und die daraus generierte
ELF-Datei.

[Walter S. (avatar)]

oder das Assembler-Listing zeigen

[Jörg W. (dl8dtl) (Moderator)]

Walter S. schrieb:
> oder das Assembler-Listing zeigen

Nö, lieber die ELF-Datei.  Ich mag diesen .lss-Mischmasch nicht, da
drin erkennt man am Ende eigentlich gar nichts mehr.  Die vom
Compiler generierte Assemblerquelle (Option -S) hilft hier auch
nicht weiter, da die ganze Kopierroutine ja erst beim Linke dazu
kommt.

[Adib (Gast)]

Ich habe mal mit einem Minimalbeispiel probiert. Und kann ich es nicht 
reproduzieren.

Im Anhang einige Screenshots und die elf Datei sowie das Flash-Image.
Den Projekt-Code kann ich dir leider nur ausserhalb des Forums schicken.
Wenn du dir das antuen willst.

Und hier der erste Teil aus der lss: die Addresse hier wird auch vom 
__do_copy verwendet.

canue.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         0000006c  00800200  00010e3a  00010ece  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  1 .text         00010e3a  00000000  00000000  00000094  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .bss          0000076c  0080026c  0080026c  00010f3a  2**0
                  ALLOC
  3 .stab         00000804  00000000  00000000  00010f3c  2**2
                  CONTENTS, READONLY, DEBUGGING
  4 .stabstr      00000115  00000000  00000000  00011740  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_aranges 000002a8  00000000  00000000  00011855  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_pubnames 00001830  00000000  00000000  00011afd  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_info   00008e69  00000000  00000000  0001332d  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_abbrev 00001cde  00000000  00000000  0001c196  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_line   00008cc6  00000000  00000000  0001de74  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_frame  00000b70  00000000  00000000  00026b3c  2**2
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_str    00001e66  00000000  00000000  000276ac  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_loc    00000852  00000000  00000000  00029512  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_pubtypes 000005ca  00000000  00000000  00029d64  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_ranges 00000098  00000000  00000000  0002a32e  2**0
                  CONTENTS, READONLY, DEBUGGING


Adib.

[Adib (Gast)]

Ich glaube ich habe dir doch einen Denkfehler:
- AVRStudio zeigt mir die Word Addresse x8733
- das liegt dann auf einer Byte Addresse bei x10e3a

Dann hätte aber die Copy Funktion doch einen ELPM Befehl nehmen müssen? 
(Screenshot)
So sehe ich nur die 16Bit LPM.

Also doch ein Fehler im Compiler?

Adib.
--

[Johann L. (gjlayde)]

Adib schrieb:

> Dann hätte aber die Copy Funktion doch einen ELPM Befehl nehmen müssen?
> (Screenshot)
> So sehe ich nur die 16Bit LPM.
>
> Also doch ein Fehler im Compiler?

Nein.

Alle offiziell unterstützten avr-gcc geben ELPM aus — vorausgesetzt 
natürlich, -mmcu= ist korrekt gesetzt:

http://gcc.gnu.org/viewcvs/trunk/libgcc/config/avr/lib1funcs.S?content-type=text%2Fplain&view=co

...und 4.6 auch:
http://gcc.gnu.org/viewcvs/branches/gcc-4_6-branch/gcc/config/avr/libgcc.S?content-type=text%2Fplain&view=co

...und 4.5 auch:
http://gcc.gnu.org/viewcvs/branches/gcc-4_5-branch/gcc/config/avr/libgcc.S?content-type=text%2Fplain&view=co

...und 4.4 auch:
http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/gcc/config/avr/libgcc.S?content-type=text%2Fplain&view=co

[Stefan E. (sternst)]

LPM statt ELPM im Startup-Code ist ein bekanntes Problem der 
Atmel-Toolchain.

Siehe z.B. hier:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=108702

[Johann L. (gjlayde)]

Stefan Ernst schrieb:
> LPM statt ELPM im Startup-Code ist ein bekanntes Problem der
> Atmel-Toolchain.

Schon seltsam das. Deren Toolchain setzt offenbar auf 4.5 auf, in deren 
Original ein ELPM steht. Und zwar schon seit Anfang 2008.

Und davor merken die Quellen an, daß der Startup-Code aus der avr-libc 
die RAMPZ-Fälle — also solche mit Flash > 64KiB und ELPM — behandelt.

Da fragt man sich, auf welchen verschlungenen Wegen das ELPM wieder aus 
dem Code verschwand...