Forum: Mikrocontroller und Digitale Elektronik [Nucleo-F103] memset hängt


von floete (Gast)


Lesenswert?

Hallo,

ich habe das Problem, dass bei mir auf meinem Nucleo Board die Funktion 
memset aus <string.h> dafür sorgt, dass sich der µC aufhängt und nichts 
mehr macht bis zu einem Reset.
Ich kompiliere mit folgenden Optionen:
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mno-thumb-interwork -mfpu=vfp 
-msoft-float -mfix-cortex-m3-ldrd
Wenn ich die Funktion durch eine eigene Schleife ersetze, dann 
funktioniert es.
Ich verstehe nur irgendwie nicht, warum.

Danke für jede Hilfe.

von g457 (Gast)


Lesenswert?

> Ich verstehe nur irgendwie nicht, warum.

Wir auch nicht, weil der Code ist ja geheim.

von floete (Gast)


Lesenswert?

g457 schrieb:
>> Ich verstehe nur irgendwie nicht, warum.
>
> Wir auch nicht, weil der Code ist ja geheim.

Was willst du denn für Code haben?
Den memset Aufruf?
Ich habe es bereits zu 99.99% auf diesen Aufruf beschränken können und 
wenn nur dieser durch eine for-Schleife ersetzt wird und der Rest bleibt 
genau gleich, dann funktioniert alles.
Den Code für memset kannst du wie gesagt öffentlich im Internet im 
Header <string.h> bzw. dem entsprechenden Sourcefile finden.

von Darth Moan (Gast)


Lesenswert?

floete schrieb:
> Den Code für memset kannst du wie gesagt öffentlich im Internet im
> Header <string.h> bzw. dem entsprechenden Sourcefile finden.

Dir ist aber schon klar, dass im Header nur ein Prototype steckt und
kein Code?
Hast du die richtige Lib dazugelinkt?
Was steht im .map file?
Was passiert, wenn du mit dem Debugger hinein stepst?
Niemand kennt deine Buildumgebung, vielleicht hat er ein unresolved 
symbol
einfach auf eine Art default error Funktion gemapped?

von Jim M. (turboj)


Lesenswert?

floete schrieb:
> Was willst du denn für Code haben?

Ein kompilierbares Beispiel das den Fehler zeigt wäre schön.

floete schrieb:
> Ich kompiliere mit folgenden Optionen:
> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mno-thumb-interwork -mfpu=vfp
> -msoft-float -mfix-cortex-m3-ldrd

Und wie linkst Du den Code? Der LD nimmt sich gerne mal die falsche 
Lib, falls man ihn nicht korrekt füttert. Das geht übrigens einfacher 
wenn man GCC als Linker Frontend benutzt.

von Luther B. (luther-blissett)


Lesenswert?

Nur vorsichtshalber gefragt: memset Parameter nicht verwechselt? 
Passiert mir nämlich manchmal ;)

1
memset(p,sizeof(p),-1);

Versucht 2^32 bytes zu schreiben.

: Bearbeitet durch User
von floete (Gast)


Angehängte Dateien:

Lesenswert?

Darth Moan schrieb:
> floete schrieb:
>> Den Code für memset kannst du wie gesagt öffentlich im Internet im
>> Header <string.h> bzw. dem entsprechenden Sourcefile finden.
>
> Dir ist aber schon klar, dass im Header nur ein Prototype steckt und
> kein Code?
Deswegen "bzw. dem entsprechenden Sourcefile.

> Hast du die richtige Lib dazugelinkt?
Was wäre denn die richtige? Ich habe die Standardlib genommen, die immer 
dazugelinkt wird.

> Was passiert, wenn du mit dem Debugger hinein stepst?


> Niemand kennt deine Buildumgebung, vielleicht hat er ein unresolved
> symbol
> einfach auf eine Art default error Funktion gemapped?

Über unresolved symbols sollte sich der Linker aber ja eigentlich 
beschweren.

Jim M. schrieb:
> floete schrieb:
>> Was willst du denn für Code haben?
>
> Ein kompilierbares Beispiel das den Fehler zeigt wäre schön.

Wie gesagt, man nehme einfach eine leere main mit nur einer Anweisung 
und das Programm wird sich aufhängen. Mit einer Funktion, die danach 
eine LED aufblinken lässt, kann man z.B. überprüfen, ob der µC es durch 
memset schafft. Das ist aber bei mir nicht der Fall.

> floete schrieb:
>> Ich kompiliere mit folgenden Optionen:
>> arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mno-thumb-interwork -mfpu=vfp
>> -msoft-float -mfix-cortex-m3-ldrd
>
> Und wie linkst Du den Code? Der LD nimmt sich gerne mal die falsche
> Lib, falls man ihn nicht korrekt füttert. Das geht übrigens einfacher
> wenn man GCC als Linker Frontend benutzt.

Linker options sind nur --specs=nosys.specs und -T linkerscript.ld
Das Skript habe ich angehängt, sollte das Standardscript für den STM32 
sein.

von g457 (Gast)


Lesenswert?

> Was willst du denn für Code haben?

Deinen natürlich, was denn sonst. Vorzugsweise so auf ein Minimum 
reduziert, dass das Problem ein-eindeutig reproduzierbar und der Code 
doch Minimal ist. Und compilierbar.

> Den Code für memset kannst du wie gesagt öffentlich im Internet im
> Header <string.h> bzw. dem entsprechenden Sourcefile finden.

Echt?

von Johannes O. (jojo_2)


Lesenswert?

Poste mal bitte das ELF file inkl. Symbole.

Was heißt "hängt"?

Es gab teils Probleme (hier) mit der Toolchain, so dass ARM Code in 
Thumb binaries eingefügt wurde, genau für solche Funktionen. Das führt 
dann natürlich zum Crash. Ohne weitere Informationen kann man das 
erstmal nicht ausschließen.

von Markus F. (mfro)


Lesenswert?

Johannes O. schrieb:
> Was heißt "hängt"?

Wahrscheinlich steckt die CPU im Hard Fault Handler, der ein wenig zu 
sparsam ausgestaltet ist.

von floete (Gast)


Angehängte Dateien:

Lesenswert?

g457 schrieb:
>> Den Code für memset kannst du wie gesagt öffentlich im Internet im
>> Header <string.h> bzw. dem entsprechenden Sourcefile finden.
>
> Echt?

Echt.

Anbei einmal ein Minimalbeispiel.
Kompilieren:
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mno-thumb-interwork -mfpu=vfp 
-msoft-float -mfix-cortex-m3-ldrd *.c *.s -c
Linken:
arm-none-eabi-gcc -T linkscript.ld --specs=nosys.specs *.o

von temp (Gast)


Lesenswert?

Ich kann das mit deinen Compiler/Linker-Schaltern nachvollziehen. 
Allerdings steht in meinen Linkerfile noch folgendes zusätzlich:

GROUP
(
  crti.o
  crtn.o
  crtbegin.o
  crtend.o
)

Dem Linker musste dann zusätzlich -nostartfiles übergeben werden.

-std=c99 vermisse ich auch beim gcc.

So sieht es am Ende bei mir aus und damit geht es:

arm-none-eabi-gcc -g -mcpu=cortex-m3 -mthumb -mno-thumb-interwork 
-mfpu=vfp -std=c99 -msoft-float -mfix-cortex-m3-ldrd *.c *.s -c
arm-none-eabi-gcc -g -nostartfiles -T linkscript.ld --specs=nosys.specs 
*.o -o blink.elf

Über die genauen Gründe denke ich heute aber nicht mehr nach. Kommt 
sicher auch auf deine Toolchain an.

von Jim M. (turboj)


Lesenswert?

temp schrieb:
> arm-none-eabi-gcc -g -nostartfiles -T linkscript.ld --specs=nosys.specs
> *.o -o blink.elf

Da fehlen die ganzen ARM Spezifischen Schalter für den CPU Typ. Die 
nutzt der Linker zur Auswahl der korrekten Library, ansonsten wird die 
Variante mit ARM Instuktionssatz eingelinkt. Das gibt dann natürlich 
einen Fault.

von temp (Gast)


Lesenswert?

Jim M. schrieb:
> temp schrieb:
>> arm-none-eabi-gcc -g -nostartfiles -T linkscript.ld --specs=nosys.specs
>> *.o -o blink.elf
>
> Da fehlen die ganzen ARM Spezifischen Schalter für den CPU Typ. Die
> nutzt der Linker zur Auswahl der korrekten Library, ansonsten wird die
> Variante mit ARM Instuktionssatz eingelinkt. Das gibt dann natürlich
> einen Fault.

Ja das stimmt, hatte es gestern nur im Simulator. Hier ist noch einiges 
Oberfaul.

von temp (Gast)


Lesenswert?

Die einzige Ursache sind die fehlenden Schalter "-mcpu=cortex-m3 
-mthumb" beim Linken. Damit gehts dann:

arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mno-thumb-interwork -mfpu=vfp 
-msoft-float -mfix-cortex-m3-ldrd *.c *.s -c
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -T linkscript.ld 
--specs=nosys.specs *.o

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.