mikrocontroller.net

Forum: Compiler & IDEs EXTMEMOPTS "killt" printf ? ?


Autor: Uwe Seidel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

nachdem ich mir jetzt die Nächte um die Ohren gehauen hab:
sobald ich mit :
EXTMEMOPTS = -Wl,--section-start=.noinit=0x802000

die Startadresse verändere wird printf vollständig ignoriert.
(printf soll daten aus dem ext. ram senden)
Nehm ich extmomopts wieder raus , geht wieder alles.
Das Datenarray ist mit Sicherheit so groß , dass es in den ext. RAM
hineinreicht. So oder so wird von "extern" gelesen. Ich kann in jedem
Fall die Daten holen und versenden. aber mit printf NUR wenn
EXTMEMOPTS = -Wl,--section-start=.noinit=0x802000 nicht an ist.

Hab ich was überlesen , verpasst , vergessen ???

Ciao Uwe

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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. ;-)

Autor: Uwe Seidel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok , ich stells nachher mit dem Code mal in GCC.

Uwe

Autor: Jörg Wunsch (Gast)
Datum:

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

Autor: Uwe Seidel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Uwe Seidel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe Seidel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-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.

Autor: Uwe Seidel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe Seidel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uwe Seidel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf sowas in der Art hab ich ja schon gewartet. :-)

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

Uwe

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-)

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?

Autor: Uwe Seidel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.