Hallo zusammen,
ich reihe mich in die Schlange der Personen ein, bei denen der Aufruf
von s(n)printf bei Umwanldung einer beliebigen Ganzzahl (kein float) in
einem HardFault mündet. Leider kann ich den Grund dafür nicht finden.
Soll heißen, wenn ich den Code Step-by-Step mit dem Debugger durchgehe,
komme ich bis zum Aufruf von snprintf(). Danach hängt alles, bis ich den
Debugger interrupte, woraufhin ich mich in der HardFault Schleife
wiederfinde. Ein schrittweise Step-In in die snprinft() Funktion klappt
ebenfalls nicht, da ich sofort in oben beschriebener Schleife hänge.
Ich hoffe ihr könnt mir weiterhelfen.
Verwendet werden in meiner Umgebung:
- CubeMX zur Erzeugung des "Basiscodes" sowie der Chip Konfiguration
- CLion als IDE für die eigentliche Entwicklung
- cmake i.V.m. arm-none-eabi-gcc für die Kompilierung
- openocd für das flashen und debuggen mit einem ST-Link v2
Der Quellcode wurde vollständig durch cubeMX erstellt, somit gehe ich
davon aus das die "üblichen" Probleme (bspw. eine falsche
Implementierung von _sbrk ausgeschlossen sind, da dann ja alle davon
betroffen wären). Habe diese trotzdem in der syscalls.c kontrolliert und
sie entspricht den gängigen Varianten.
Weiterhin habe ich die Toolchain bereits gegen die vorkompilierte von
arm ausgetauscht, jedoch ohne Änderung im Ergebnis.
Die linker Datei (STM32F103C8Tx_FLASH.ld) stammt ebenfalls original aus
dem cubeMX. Auch der (häufig) vorgebrachte Vorschlag testweise heap und
stack von 0x200/0x400 auf 0x1000 zu erhöhen bracht keine Änderung.
Folgend einmal sowohl die main.c (enthält den Testaufruf von snprintf)
sowie die von CLion erzeugte CMakeList. Hierbei handelt es sich um die
einzigen beiden Änderungen (Aufruf von snprintf() in main.c) und die von
CLion erstellte CMakeList von dem von cubeMX erzeugten Basisdaten.
main.c
Gut, ich gebe offen zu, dass mir die einfache Verwendung von snprintf()
zur Umwandlung einer int zu einem char[] einfach praktisch erschien und
ja auch unterstützt wird (wenn sie auch nicht die
platzsparenste/schnellste Methode darstellt). Da Geschwindigkeit/Platz
bei meine Programm keine Rolle spielt (da ausreichend vorhanden).
Das ich mir die Chip-Konfiguration (Timer, GPIOs, usw.) von cubeMX
erzeugen lasse scheint anscheinend auch ein Problem darzustellen. Hier
sehe ich allerdings ohne begründete Argumente keinen Grund die
Hardwarekonfiguration "per Fuß" durchzuführen, wenn der Hersteller
dieser Hardware extra eine Software geschrieben hat, die das (ich setze
mal fehlerfrei voraus) übernimmt.
Michael F. schrieb:> Was sagen denn CFSR und HFSR über den Grund für den Hard Fault?
Hat leider etwas gedauert, aber hier die beiden Register sobald er in
den HardFault geht.
samuel schrieb:> Bitte vergleiche doch mal deine CMakeLists.txt mit der von CubeMX> generierten Makefile. Sind wirklich alle Flags identisch, insb. die für> den Linker?
Oh Mann, da sieht es ja aus wie Kraut und Rüben...
Anscheinend kann cLion zwar STM32, aber keine Makefiles lesen. Zumindest
sehe ich da doch grössere Abweichungen.
CFlags die im Makefile vorhanden sind, aber in CMakeList fehlen:
Bin jetzt nicht der Experte was die C/LD Flags angeht, aber so eine
große Abweichung sollte doch nicht vorkommen da cLion seine Vorgaben ja
von cubeMX bekommt.
Anscheinend ist die "ach so ausgereifte" STM32 Unterstützung doch nicht
so toll. Immerhin ist mein Anwendungsfall ein int in char umzuwandeln
nun doch nicht so speziell.
pegel schrieb:> €199.00 /Benutzer 1. Jahr>> €159.00 /2. Jahr>> €119.00 /ab dem 3. Jahr>> Wau. Ist das fürs Hobby oder Zwang?> Nur für STM32?
Hobby. Allerdings nicht nur für STM32. Die Einzellizenz für Nutzer
(nicht Firmen) liegt bei €89 / Jahr. Und dann hat man die Version
dauerhaft (auch wenn man nicht mehr zahl, man kriegt halt nur keine
neueren Versionen mehr).
Hab damals mit python (pyCharm IDE) und Java (IntelliJ) angefangen
(beides gratis Community Versionen vom selben Hersteller). Und in die
IDE hab ich mich verguckt. Das Handling ist einfach bei allen gleich.
Wollte deshalb für C/C++ auch eine IDE mit selben Funktionsumfang und
Handling haben, dann fühlt man sich gleich zuhause.
Das die STM32 können war da nur "der Bonus".
Also hätte ich jetzt das Problem, würde ich:
${FPU_FLAGS} ersetzen durch -mfloat-abi=soft
-std=gnu99 ersetzen durch -std=gnu11
und hinter -specs=nano.specs noch -lc -lm einfügen und probieren.
pegel schrieb:> Also hätte ich jetzt das Problem, würde ich:> ${FPU_FLAGS} ersetzen durch -mfloat-abi=soft> -std=gnu99 ersetzen durch -std=gnu11>> und hinter -specs=nano.specs noch -lc -lm einfügen und probieren.
Danke! Das war die Lösung.
Habe "lc -lm" ergänzt und die FPU_FLAGS mfloat-abi=soft gesetzt (war
leer).
Und schon ist er trotz nicht mehr gecrasht.
Schaut schonmal sehr gut aus, werde das morgen mal genauer testen und
dann ein Update geben.
Ich möchte mich bei allen bedanken für die Hilfe.
Mir leuchtet nur nicht ein wieso die Flags falsch sind, da er sie ja von
cubeMX ausliest. Dann müssten die ja bei ALLEN falsch sein (cubeMX ist
der offizielle Weg in cLion die Quellen zu erzeugen).