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.
> Ich verstehe nur irgendwie nicht, warum.
Wir auch nicht, weil der Code ist ja geheim.
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.
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?
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.
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
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.
> 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?
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.
Johannes O. schrieb: > Was heißt "hängt"? Wahrscheinlich steckt die CPU im Hard Fault Handler, der ein wenig zu sparsam ausgestaltet ist.
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
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.
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.