EXTMEMOPTS "killt" printf ? ?

(Die Frage gehört wohl besser ins GCC-Forum.)

Ohne die exakten Details ist da kaum eine Aussage möglich.  Versuch'
doch mal, den Fehler auf das Minimum runterzubrechen, das man zum
Nachvollziehen des Fehlers benötigt.  (Vermutlich wird's Dir dann
sowieso wie Schuppen aus den Haaren fallen. ;-)

Ok , ich stells nachher mit dem Code mal in GCC.

Uwe

Wir sind bereits magisch ins GCC-Forum umgezogen worden. ;-)
Hat wohl der Webmaster getan...

Hi,
also da ist irgendwo der Wurm so dermaßen drin, dass ich es nicht
finde.
Ursprünglich war der Code viel viel größer, aber schon diese
rudimentären Dinge funktionieren nicht.
Also eine Urache ist irgendwie in .noinit: Sobald ich .noinit
mit einer neuen Startadresse versehe kommt vom ext. RAM nur noch ne
hochlaufende Zahl. Könnte auch der Pointer innerhalb des Arrays sein.
(Aber warum sollte es ?)
Zum zweiten:
Sobald ich auch nur ansatzweise Text in printf mit übergebe außer den
formatstrings und Argumenten , geht garnichts mehr, dann wird die
kompl. Anweisung "ignoriert".

Makefile ist dabei ansonsten ist da ja nichts dran.

Vielleicht kann mir ja jemand mal vor´s Hirn hauen.

Danke

Eins fällt mir auf, wenn ich auf die Symboltabelle gucke
(avr-nm -n smarttest.elf):

00800110 B __iob
00800116 B __brkval
00800118 B __flp
0080011a B __bss_end
[Ende des internen RAM]

00802000 B la
00802fa0 B __heap_start
...

Hmm, Dein Heap landet auf dem externen RAM (ein Seiteneffekt davon,
daß Du .noinit verschiebst).  fdevopen() und floating point vfprintf()
benutzen beide malloc(), brauchen also den Heap.

Bist Du Dir denn sicher, daß Dein externer RAM funktioniert?

Kannst ja mal den Heap nach intern verlegen.  Genaue Syntax habe ich
nicht im Kopf, aber im Kapitel über malloc() in der Doku
niedergeschrieben. ;-)

Also der ext. Ram funktioniert höchstwarscheinlich.
Ich hab mal ein Array mit 10000Werten angelegt. konnte alle Werte
wieder zurücklesen. Deswegen im Code die 3Zeilen zum extern lesen.

Wobei das jetzt auch nicht mehr geht.... zuviel durcheinanderverändert.


Den Heap werd ich mal nach intern verschieben. Könnte schon ein Ansatz
sein. Ich hatte erst den Verdacht, das die Auswertung der Formatstrings
irgendwie den Fehler verursacht, hat sich aber noch nicht bestätigt.

Bis später

Uwe

Hab jetzt selber mal nachgeschaut:

000010ff W __stack
00800100 D __data_start
00800100 D __malloc_margin
00800102 D __malloc_heap_start     <- was ist das denn ?
00800104 D __malloc_heap_end
00800106 B __bss_start
00800106 D __data_end
00800106 D _edata
00800106 b brkval
00800108 b flp
0080010a B br
0080010c B __iob
00800112 B __bss_end
00800112 B la
00804f32 B __heap_start
00804f32 B _end
00810000 ? __eeprom_end

auf jeden Fall bekommen ich bei:

EXTMEMOPTS = -Wl,--section-start=.noinit=0x802000
,-Wl,--defsym=__malloc_heap_start=0x800400,--defsym=__malloc_heap_end=0x 
800600

Linking: smarttest.elf
avr-gcc -mmcu=atmega128 -I. -g   -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=smarttest.o  -std=gnu99
-Wp,-M,-MP,-MT,smarttest.o,-MF,.dep/smarttest.elf.d smarttest.o
--output smarttest.elf -Wl,-Map=smarttest.map,--cref
-Wl,--section-start=.noinit=0x802000
,-Wl,--defsym=__malloc_heap_start=0x800400,--defsym=__malloc_heap_end=0x 
800600
  -lm
avr-gcc:
,-Wl,--defsym=__malloc_heap_start=0x800400,--defsym=__malloc_heap_end=0x 
800600:
No such file or directory
C:\winavr\utils\bin\make: *** [smarttest.elf] Error 1

langsam wird das nervig.

Ciao Uwe

-Wl leitet für den C-Compiler eine Option ein, bei der er den Rest an
den Linker weitergibt.  In diesem Rest sollte nicht nochmal -Wl drin
sein. ;-)

Am besten eine separate -Wl,dies,jenes für jede Linkeroption.

Och nö , oder ;-)
die Fehlermeldung ist wech..

Mittlerweile kann ich auch ohne Probleme printf benutzen. hab jetzt
_malloc_heap_ und __heap nach "intern" verlegt. Scheint zu helfen.

Allerdings scheint doch noch ein temporärer HW-Fehler da zu sein.
Sieht nach ner Knobelaufgabe aus.
So wie früher in der Lehre: welche Ltg sind wohin kurzgeschlossen,
damit dieser Fehler auftritt....
Ist eben doch sch.... wenn man schnell ne Adapterplatine baut und noch
eine dazu usw... irgendwann ist mal schluss

Ich danke Dir erstmal für die Tipps mit dem Heap. Hab auch an sowas
gedacht.. wär aber nieeee auf die Idee gekommen den Heap zu
verschieben.

Falls ich nicht weiterkomme , bin ich wieder hier zum betteln ;-)

Ciao
Uwe

Hi,
wollte nur nochmal den Endstand melden, vielleicht haben ja andere auch
mal so ein Problem.
Falls der ext. SRAM keinen Schaden durch einen kaputten octal-Latch
erlitten hat.... ;-) sollte es kein Problem geben , außer man lässt den
heap_ und _malloc_heap extern. Dann tauchen zuweilen Probleme mit
"Anwendungen" , die malloc()(z.B. printf) benutzen, auf. Welche, wann
usw.
keine Ahnung . Aber danke mal an alle für die Hilfe.

Uwe

Das kann ich so allgemein nicht stehen lassen: ich habe malloc() sehr
wohl ausgiebig auch mit externem Speicher getestet.
Selbstverständlich funktioniert das alles auch damit.

Wenn Du damit ein Problem hast, solltest Du es wohl besser
analysieren.

Auf sowas in der Art hab ich ja schon gewartet. :-)

Darauf kannst Du dich verlassen, das finde ich schon raus, woran das
liegt.

Uwe

:-)

Bist Du Dir sicher, daß Dein address latch schnell genug ist?  Vor
allem bei höheren Taktfrequenzen am ATmega128 sind die
timing-Forderungen recht knapp bemessen.

Hast Du mal probiert, ob sich die Situation bessert, wenn Du mit wait
states arbeitest?

Hi.
hatte anfangs den Verdacht, dass das Timing kritisch ist.
Lt. Datenblättern bin ich im grünen Bereich, zumal ich eh nur mit 8Mhz
arbeite, weil das Grafikdisplay sonst am Limit ist und ich dann dort
überall Waitstates gebraucht hätte. Trotzdem hab ich mal welche im
Speicher-timing gesetzt aber es ist nicht besser geworden. War auch
unwahrscheinlich weil ja die "richtigen" Daten sauber rüberkommen.
Ich bleib aber mal dran.

Uwe