Hallo, ich möchte den PB8 (Boot0 pin) des STM32G4 als GPIO Output nutzen. Gem. Datenblatt kann er dies sofern nSWBOOT0 = 0. Dieses sei angeblich factory default auf 0 ist aber bei mier aktuell gem Debuger auf 1. Ich nutze den Cube/HAL. Wie kann ich im Cube das einstellen, dass er dieses register korrekt setzt. Falls nicht möglich: Wie setze ich dieses Register möglichst fachgerecht auf den benötigten Wert im user code?
:
Bearbeitet durch User
Konnte nSWBoot0 nun mit dem Programmer auf 0 setzen. Ist im debugger dann auch 0. Der GPIO Output funktioniert aber nachwievor nicht. An was könnte es sonnst noch liegen?
Max schrieb: > Hallo, ich möchte den PB8 (Boot0 pin) des STM32G4 als GPIO Output > nutzen. Gibt es nur einen G4? Wenn nein, dann bitte angeben welchen.
Max schrieb: > Wie setze ich dieses Register möglichst fachgerecht > auf den benötigten Wert im user code? Um nicht das Rad neu erfinden zu müssen: welche Bemühungen hast du den unternommen diesen GPIO zu konfigurieren?
Einfach den Pin in CubeMX auf GPIOOutput setzen. Um den Rest kümmert sich CubeMX.
Harry L. schrieb: > Einfach den Pin in CubeMX auf GPIOOutput setzen. > Um den Rest kümmert sich CubeMX. Habe ich von beginn an gemacht gehabt. Wastl schrieb: > Gibt es nur einen G4? Wenn nein, dann bitte angeben welchen. STM32G431C8Tx Wastl schrieb: > Um nicht das Rad neu erfinden zu müssen: welche Bemühungen > hast du den unternommen diesen GPIO zu konfigurieren? Ich habe im Cube den Pin auf GPIO output. Ich nutze die HAL GPIO funktionen welche bei allen anderen pins funktionieren. Ich habe sichergestellt, dass auch der richtige port/pin beim Aufruf der Hal funktionen verwendet werden. Ich habe den Zustand von nSWBOOT0 im debuger geprüft und diesen mit dem programmer auf 0 gesetzt (war auf 1). Nochmals getestet mit dem Ergebnis: Nachwievor kein GPIO Output am besagten pin. Im debuger ist nSWBOOT0 nun auf 0.
:
Bearbeitet durch User
Dann wird da vermutl. irgend ein Jumper den Pin auf Pegel ziehen. Ein 10k Widerstand gegen GND tuts auch.
Harry L. schrieb: > Dann wird da vermutl. irgend ein Jumper den Pin auf Pegel ziehen. > Ein 10k Widerstand gegen GND tuts auch. Bin nicht sicher ob ich dich korrekt verstehe. Der Pin soll als Output betrieben werden. Der uC läuft soweit und bootet nachwievor korrekt. Spannung ist wenige mV und der uC wird nicht warm etc. also nichts dass auf ein Hardware Problem hindeuten würde.
Max schrieb: > Harry L. schrieb: >> Dann wird da vermutl. irgend ein Jumper den Pin auf Pegel ziehen. >> Ein 10k Widerstand gegen GND tuts auch. > > Bin nicht sicher ob ich dich korrekt verstehe. Der Pin soll als Output > betrieben werden. Der uC läuft soweit und bootet nachwievor korrekt. > Spannung ist wenige mV und der uC wird nicht warm etc. also nichts dass > auf ein Hardware Problem hindeuten würde. Damit der µC aus dem Flash startet, muß der Pin nach dem Einschalten LOW-Pegel haben. Das geht entweder mit einem Jumper (z.B. auf dem Bluepill-Board) oder eben mit einem Widerstand. Sobald der µC gestartet ist, kannst du den Pin überschreiben. Das geht natürlich nicht, wenn der via Jumper fest mit GND verbunden ist.
Max schrieb: > Ich habe im Cube den Pin auf GPIO output. > .................. Wäre es zueviel verlangt statt deiner buntfarbenen Prosa einen Code für Initialisierung und Ansprechen des Pins zu liefern, sowie die main.h zu deinem Code?
Harry L. schrieb: > Damit der µC aus dem Flash startet, muß der Pin nach dem Einschalten > LOW-Pegel haben. ich habe nSWBOOT0 nun auf 0 damit er dies ignoriert und ich diesen Pin als GPIO benutzen kann (dies besagt zumindest die ST Doku, G4 ist anders als bluepill). Anyway Pin ist auf 0 und hat eine ohmische Last nach GND. (Er soll schlussendlich auch als Output diese last Treiben). Wastl schrieb: > main.h zu deinem Code? kein problem ich habe ein kleines BSP gemacht in welchem ich 2 Outputs setze. Davon funktioniert der PB8 nicht. Projekt komplett im Anhang.
Max schrieb: > PB8OutTest.7z (1,27 MB) Kann nichts Fehlerhaftes oder Auffälliges entdecken. Allenfalls ist die Last an dem problematischen Pin zu stark oder es ist da ein Kurzschluss .... Max schrieb: > Anyway Pin ist auf 0 und hat eine ohmische Last nach GND. Ja welche denn nun? Muss das auch geheim bleiben?
Wastl schrieb: > Max schrieb: >> PB8OutTest.7z (1,27 MB) > > Kann nichts Fehlerhaftes oder Auffälliges entdecken. Allenfalls > ist die Last an dem problematischen Pin zu stark oder es ist > da ein Kurzschluss .... > > Max schrieb: >> Anyway Pin ist auf 0 und hat eine ohmische Last nach GND. > > Ja welche denn nun? Muss das auch geheim bleiben? Nei ist nicht geheim, habe dies nur als orthogonal zum Problem betrachtet und daher nicht weiter ausführlich aufgeführt: Last am Pin: 10kOhm gegen GND + Eingang in ein Treiber (hochohmig). Ist identisch mit 7 weiteren GPIO Pins. Bis auf den besagten Pin funktionieren alle. Lötung des Pins scheint sauber, kein Kurzschluss gegen GND gemessen (mit Multimeter wenn uC ohne Versorgung). Das einzige was auffällig ist: Gem. ST werden alle uC mit nSWBOOT0 = 0 ausgelieferet, meiner war bei meiner ersten beachtung auf 1 (wurde zuvor mehrfach CUBE/Debug benutzt). 1. Schreibt der Cube dieses bit? (falls ja: bug im cube, denn er hat es gem ST Doku falsch gesetzt) 2. Da dieses Bit bei mir 1 war: Hat sich in den revisionen der G4 etwas geändert? Hat jemand einen G4 (oder G0 habe irgendwo gelesen, dass die diesbez identisch sind) und könnte bitte testen ob er bei BOOT0 einen GPIO output machen kann und am pin dann auch eine 1 sieht?
:
Bearbeitet durch User
Max schrieb: > Das einzige was auffällig ist: Gem. ST werden alle uC mit nSWBOOT0 = 0 > ausgelieferet, meiner war bei meiner ersten beachtung auf 1 (wurde zuvor > mehrfach CUBE/Debug benutzt). Aus dem Reference Manual:
1 | The BOOT0 value may come from the PB8-BOOT0 pin or from an nBOOT0 |
2 | option bit depending on the value of a user nBOOT_SEL option bit |
3 | to free the GPIO pad if needed. |
Will heissen du musst das <nBOOT_SEL option bit> richtig setzen.
Wastl schrieb: > Max schrieb: >> Das einzige was auffällig ist: Gem. ST werden alle uC mit nSWBOOT0 = 0 >> ausgelieferet, meiner war bei meiner ersten beachtung auf 1 (wurde zuvor >> mehrfach CUBE/Debug benutzt). > > Aus dem Reference Manual:The BOOT0 value may come from the PB8-BOOT0 pin > or from an nBOOT0 > option bit depending on the value of a user nBOOT_SEL option bit > to free the GPIO pad if needed. > > Will heissen du musst das <nBOOT_SEL option bit> richtig setzen. Danke, nun gem. der Doku die ich gesehen habe wars nSWBOOT0 anyway dies hats auch nicht gebracht. Hab nun bereits über einen Tag verheizt, ich nehme einfach einen anderen GPIO. Evtl. löst ja ST da Problem mal in einigen Jahren damits direkt vom CUBE aus geht.
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.