avr toolchain compilerfehler?

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");

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

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

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.

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