Hallo Leute, ich versuche mich derzeit an einem Projekt mit einem kleinen STF32F042, den ich über USB (VCP) anspreche. USB Code mit CubeMX generiert, der STM hat keinen Quarz sondern holt sich den Takt vom USB. Das funktioniert im Debug-Modus hervorragend, wenn ich als Release kompiliere meldet sich der STM aber am USB nicht korrekt an. Hat jemand eine Idee, woran das liegen könnte? Danke, Alex
Vielleicht ein Timing Problem, irgendetwas läuft zu schnell. Da war doch was mit einer ID Nummer, die der PC dem µC zuweist. Der µC muss diese Zuweisung bestätigen, darf aber erst danach die ID Nummer anwenden (in ein Register schreiben). Vielleicht hat es damit zu tun. Jemand hat hier mal empfohlen, die Kommunikation mit Wireshark zu analysieren, ich konnte mit der Flut an Output allerdings nichts anfangen. Als bei mir mal USB nicht funktionierte, kam ich besser mit zahlreichen Debug-Meldungen klar, die ich ins Programm einfügte. Mit Debug Meldungen konnte die Pakete (ohne Details) protokollieren, die hin und her gesendet wurden. Da habe ich dann die guten Fälle mit den schlechten verglichen und bin so ziemlich schnell auf die fehlerhafte Stelle gekommen. Vielleicht bringt dich diese Vorgehensweise auch weiter. Ist einen Versuch wert.
Stefanus F. schrieb: > Jemand hat hier mal empfohlen, die Kommunikation mit Wireshark zu > analysieren, ich konnte mit der Flut an Output allerdings nichts > anfangen. Man muss halt genau schauen was zum eigenen Gerät gehört. Wireshark kann da schon sehr hilfreich sein. Das Gerät an einem Linux-PC anschließen und die Kernel-Meldungen ansehen (dmesg) ist ebenfalls sehr nützlich. pegel schrieb: > Das hört sich an, als wurde etwas wichtiges weg-optimiert. Gut möglich. Vielleicht enthält die ST Library fehlerhaften Code, welcher sich auf Undefined Behaviour verlässt, von dem der Compiler annehmen darf, dass es nie auftritt, und es so wegoptimiert...
Schönen Abend! Hab mittlerweile rausgefunden, dass das Verhalten etwas mit den Optimierungs-levels zu tun hat. Was genau die Ursache ist, ist mir aber noch nicht klar. Alex
Alex schrieb: > Hab mittlerweile rausgefunden, dass das Verhalten etwas mit den > Optimierungs-levels zu tun hat. Das hast du schon gestern in den Eröffnungsbeitrag geschrieben.
Angehängte Dateien:
-
IF-FLAG.jpg
50 KB
Ich komme langsam zu der Erkenntnis, dass ich mit der Entwicklungsumgebung des STM nicht wirklich zurechtkomme. CubeIDE 1.0.2 Ich wollte versuchen rauszufinden, bei welchen Einstellungen es nicht/funktioniert und hänge hier: Hab in der while(1) eine Abfrage eines flags, das in der USB-RX-Callback Funktion gesetzt wird. Wenn das Flag gesetzt ist, wird aus dieser IF der empfangene String zurückgeschickt. Funktioniert in den Optimization-Modes O0 und Og problemlos. In allen anderen Ox meldet sich das Ding am USB zwar an (hatte es das letzte mal nicht gemacht), und auch das Emfangs-Flag wird gesetzt nachdem ich etwas sende. Allerdings springt er nie in die if rein (Bild). Da steh ich mit Fehlersuche dann irgendwie an. Selbst wenn in der IF nichts anderes gemacht wird, als das Flag wieder zu löschen... Kurzum, ich bin grad nichtmal in der Lage, sinnvolle Fragen zu stellen. Mit der Ausnahme nach einem Einstiegs-Tutorial
Alex schrieb: > Hab in der while(1) eine Abfrage eines flags, das in der USB-RX-Callback > Funktion gesetzt wird. Ist das Flag wenigstens überall als volatile deklariert?
Das Flag ist als globale Variable in einer globals.h definiert, die überall eingebunden ist.
Alex schrieb: > Das Flag ist als globale Variable in einer globals.h definiert, > die überall eingebunden ist. Also ohne volatile, sonst hättest Du das bestätigt. Wenn Du eine Variable benutzt, um Daten zwischen Interrupt und Applikation auszutauschen, MUSS sie als volatile deklariert sein - ansonsten kann der Compiler das u.U. wegoptimieren.
Bingo! Danke Nop! ...ich hätt beim assembler bleiben sollen... mit diesem Erfolgserlebnis leg ich mich jetzt schlafen... Danke nochmal!
Hallo Leute, ich steck schon wieder fest :-( Ich möchte mit dem STM via USB Gleitkomma-Daten austauschen. sprintf/sscanf oder atof.. Sobald in den Einstellungen "Use float with printf from newlib-nano (-u _printf_float)" aktiviert ist, gibt es errors wegen RAM/FLASH overflow. Durch Suchen hab ich threads gefunden, in denen Probleme wegen einem Fehler im Linker-Skript diskutiert wurden, das trifft aber bei meinem STM32F042 nicht zu... ( https://community.st.com/s/question/0D50X0000AnrcyjSQA/how-to-use-float-in-printf ) Hat hier jemand eine Idee dazu? Um RAM freizumachen hätte ich mal versucht, die USB Buffer (USB CDC *x Buffer Size) von den 1000 Bytes zu reduzieren. Das hat aber keinen Effekt. Laut .map-file belegen die Buffer immer 2* 1000 Bytes im RAM, egal was im Codegenerator eingestellt ist. Vielen Dank für jede Hilfe, Alex
Wie viel RAM und Flash hast du denn frei und um welchen STM32 geht es? http://stefanfrings.de/stm32/stm32l0.html#newlib (M0) http://stefanfrings.de/stm32/stm32f1.html#newlib (M3) http://stefanfrings.de/stm32/stm32f3.html#newlib (M4F) Der Flash-Bedarf variiert ziemlich stark, je nach Cortex Variante.
Der STM32F042F6P6 hat 32k Flash 6k RAM compiler -Os ohne "-u _printf_float": text data bss dec hex filename 13372 380 5492 19244 4b2c testUsb.elf mit "-u _printf_float" (ohne einem printf-aufruf!) region `RAM' overflowed by 200 bytes Den FLASH-Overflow kann ich nicht mehr reproduzieren, im RAM belegt der USB-Buffer schon mal 2k, die restlichen USB-Sachen locker nochmal 2k, meine eigenen Daten 0x78 ;-)
Du brauchst ungefähr 1,5kB (mit reduzierter Performance nur 0,5kB) und 4,3kB FLASH. Mit Fließkomma kommen weitere 9kB FLASH dazu. Dein RAM ist auf jeden Fall rappelvoll (data + bss). Das kriegst du nur gelöst, indem du dein Programm umschreibst. Eventuell hast du ein paar Strings oder Arrays, die niemals verändert werden und daher durch das Schlüsselwort "const" direkt aus dem FLASH geladen werden können. Dadurch wird RAM frei. Die folgenden Optionen helfen eventuell, den FLASH Bedarf zu reduzieren. Compiler: -Os -ffunction-sections Linker: -Wl,--gc-sections -lm Die USB CDC Implementierung von W.S. ist wesentlich schlanker und das kannst du den Pufferspeicher wirksam verkleinern, falls das dann noch nötig sein sollte. Ich vermute mal, dass der gleiche Code wie vom STM32L0 geht:http://stefanfrings.de/stm32/stm32l0.html#vcpnohal
Ja, der RAM ist zu voll, aber den belegt der USB-Teil (codegenerator) und die newlib-float. Meine Daten beschränken sich auf 120 Byte! Deshalb hab ich ja versucht, die USB buffer kleiner zu machen, was aber nicht geht. Selbst wenn mein code keinen Speicher belegt, ginge sich das also nicht aus. Mein Fazit derzeit: USB + Float ist mit 6k RAM nicht zu machen. Find ich ziemlich unglaublich.
Alex schrieb: > USB + Float ist mit 6k RAM nicht zu machen. Doch, mit dem Code von von W.S. geht das. http://stefanfrings.de/stm32/stm32l0.html#vcpnohal
Noch zwei Linker Optionen, die eventuell helfen FLASH zu sparen: -specs=nano.specs -specs=nosys.specs
ich wollte mit dem kleinen STM ein Tool, dass es bereits mit einem AVR gibt, um eine Funktion erweitern (die ich dort nicht mehr reinkriege). Aber die Grund-Funktionalität des 4k Flash / 256Byte RAM - AVR-Dings ist standardmäßig nicht in den 32k/6k STM unterzubringen. WTF?
Alex schrieb: > Ich möchte mit dem STM via USB Gleitkomma-Daten austauschen. > sprintf/sscanf oder atof.. Du könntest das auch einfach als 32bit-Rohwerte schicken und nicht als Strings. Dann muß man nur noch Endianess richtig beachten, aber sowohl x86 als auch ARM sind da eh identisch.
Alex, hör auf zu meckern und schau Dir die Infos an, die ich Dir gegeben habe. Du meckerst in Wahrheit über deine eigenen Fehlentscheidungen. Als Anfänger muss man damit rechnen. Dass ein zusammengeklicktes Programm auf Basis der Cube HAL nicht optimal ist, sollte niemanden wundern. Falls es für dich neu war, dann weißt du es wenigstens jetzt. Und jetzt kommt die AHA-Erkenntnis Nr 2: Die generische newlib-nano braucht in jeder Hinsicht sehr viel mehr Speicher, als die speziell für AVR hand-optimierte avr-libc, insbesondere bezüglich stdio und float. Warum zwängst du das alles auf diesen mickrigen Mikrocontroller?
Ich habe noch eine Bitte: Mach für neue Probleme bitte ein neues Thema auf. Ewige Fortsetzungs-Geschichten werden schnell unübersichtlich.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.