Liebe Forengemeinde, so peinlich es mir auch ist - ich bekomme gerade ein einfaches LED-Blinken auf meinem STM32F429I-DISCO - Board nicht ans Laufen (Achtung: es ist NICHT das neuere DISC1 Board, sondern noch das alte DISC0 Board). Hintergrund: ich war schon einmal ganz passabel "drin" im Thema STM32, habe dann aber viele Jahre nichts mehr in dieser Richtung gemacht => alles vergessen. Nun möchte ich wieder etwas einsteigen und diesmal die Segnungen neuer Tools (hier: STM32CubeIDE unter MacOS) nutzen. Also habe ich: - STM32CubeIDE installiert - Den ST-Link/v2 auf dem Board auf den neuesten Stand gebracht - Ein neues "STM32 Projekt" in der IDE angelegt und dabei das Board "STM32F429I-DISC1 ausgewählt (mein DISCO gab's leider nicht zur Auswahl). - In der main.c lediglich die while-Schleife angepasst: <Code> /* USER CODE BEGIN WHILE */ while (1) { HAL_GPIO_WritePin(GPIOG, GPIO_PIN_13, GPIO_PIN_SET); HAL_Delay(1000); HAL_GPIO_WritePin(GPIOG, GPIO_PIN_13, GPIO_PIN_RESET); HAL_Delay(1000); /* USER CODE END WHILE */ /* USER CODE BEGIN 3 */ } /* USER CODE END 3 */ </Code> - Abschließend natürlich kompiliert und auf das Board geflashed (das scheint zu funktionieren - jedenfalls blinkt die Flash-LED und das Original-Demoprogramm ist auch verschwunden) Leider blinkt aber nichts. Jetzt stehe ich gerade etwas auf dem Schlauch ... Ach ja: auf einem STM32F4-discovery-Board habe ich das Gleiche (natürlich mit leicht angepasstem Port und Pin) ebenfalls ausprobiert - funktionierte direkt auf Anhieb. Habt Ihr vielleicht eine Idee, warum es beim STM32F429I-DISC0 Board nicht funktioniert/blinkt? Sachdienliche Dateien habe ich angehängt - wenn Ihr mehr Infos benötigt - einfach Bescheid geben. Viele Grüße Igel1
Andreas S. schrieb: > Habt Ihr vielleicht eine Idee, warum es beim STM32F429I-DISC0 Board > nicht funktioniert/blinkt? Dein IOC File beinhaltet keine Initialisierungen für deine LED. Daher wird der generierte Code auch keine Initialisierungen vornehmen.
:
Bearbeitet durch User
Da fehlt die Initialisierung des gpio, den kann man nicht einfach so verwenden. Gehe in das CubeMX Tool bzw öffne das .ioc im Projekt und setze in der grafischen Ansicht den PIN auf Output, dem kannst du mit User Label auch einen passenden Namen geben. Beim Speichern wird dann der Code für die Initialisierung generiert.
J. S. schrieb: > dem kannst du mit User Label auch > einen passenden Namen geben. ... und diesen Namen sollte man dann auch verwenden um HAL_GPIO_WritePin(.....); aufzurufen.
Andreas S. schrieb: <Code> </Code> Diese beiden Schlüsselwörter schreibt man mit eckigen Klammern. Andreas S. schrieb: > Habt Ihr vielleicht eine Idee, warum es beim STM32F429I-DISC0 Board > nicht funktioniert/blinkt? Du hättest nach dem Start von CubeMX auch gleich dein Eval- Board auswählen können, dann hätte dir CubeMX gleich alle Hardware, die auf dem Board vorhanden ist, initialisiert. Dann hättest du nur noch aussuchen müssen welche LED wie benannt ist um mit <HAL_GPIO_WritePin(.....);> den richtigen Portpin ansprechen zu können.
https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/stm32cubemx-and-cubeHhal-basics.html zum Auffrischen der Basics
Ich hab dir mal ein Beispiel für eine .ioc-Datei mit den Standard-Einstellungen für dein Board generiert, und dein Blinky entsprechend angepasst.
>HAL_GPIO_WritePin(LD3_GPIO_Port, LD3_Pin, GPIO_PIN_SET); >HAL_Delay(1000); >HAL_GPIO_WritePin(LD3_GPIO_Port, LD3_Pin, GPIO_PIN_RESET); >HAL_Delay(1000); oder: HAL_GPIO_TogglePin(LD3_GPIO_Port, LD3_Pin); HAL_Delay(1000);
Markus H. schrieb: > oder: > > HAL_GPIO_TogglePin(LD3_GPIO_Port, LD3_Pin); > HAL_Delay(1000); Hilft dem TO aber kein Stück weiter, und deshalb hab ich mich ganz bewust auf seinen Code bezogen.
Immer wieder toll, wie hilfsbereit Ihr doch seid! Da gibt es ja noch Hoffnung für mich ... Vorab: Trotz Eurer Hilfe konnte ich das Problem noch nicht lösen - ich hoffe daher, Ihr haltet mir noch etwas länger das Händchen hier in diesem Thread. Jetzt zu den Details: - mir ist ein saudummer Fehler unterlaufen: ich hatte schnell vor dem Post noch ein neues Projekt angelegt, um Euch saubere Dateien schicken zu können. Nur dabei hatte ich wohl vergessen, nach Auswahl des Boards auf "Initialize all peripherals with their default Mode" zu drücken. - völlig korrekt und folgerichtig kamen dann Eure Anmerkungen, dass ich den GPIO-Port & Pin ja erst einmal initialisieren müsse, was man wohl per CubeMX macht. Das hatte ich in meinen Vorversuchen (die auch alle nicht liefen) jedoch schon getan und trotzdem blinkte nichts. - jetzt habe ich das Projekt gerade nochmals neu aufgesetzt und dabei schön brav auf "Initialize all peripherals with their default Mode" gedrückt und dann meine main.c angepasst. Leider wieder kein Blinken. Habe die main.c und auch die *.ioc Datei hier nochmals angehängt (EDIT: bitte NICHT die Datei TestMySTM32F429-Disc0_v005.ioc nehmen, sondern die Datei TestMySTM32F429-Disc0_v005.ioc.orig - man kann leider keine Anhänge hier im Forum löschen - daher musste ich es so machen). - Dann habe ich meine *.ioc und main.c sogar durch Harry L.'s Dateien ersetzt (danke Harry!), das Projekt gecleaned, neu compiliert und geflashed - wieder kein Blinken. Hmmm - habe nach wie vor keine Idee, woran es liegen könnte (meine einzige Idee: mein DISC0 Board läuft nicht unter der DISC1 CubeMX-Konfiguration) Habt Ihr noch weitere Ideen? Viele Grüße Igel1 PS: danke auch an Markus H. für seinen Link "zum Auffrischen der Basics" - ich glaube, da muss ich nochmals durch ...
:
Bearbeitet durch User
Andreas S. schrieb: > (meine > einzige Idee: mein DISC0 Board läuft nicht unter der DISC1 > CubeMX-Konfiguration) Diese Idee ist ganz sicher falsch.
Angehängte Dateien:
-
Discovery_F429__DSCN8125.JPG
230 KB
Andreas S. schrieb: > Habt Ihr noch weitere Ideen? Ist es ganz sicher dieses Board im Anhang? Oder doch ein Nucleo F429?
Dazu muss man schon die Schaltpläne vergleichen, bzw. warum gibt es die alte Config nicht mehr? ST hat da meist auch Application Notes wo die Änderungen gelistet sind. In der neuen Config sind auch Devices drin die nicht für das Blinky gebraucht werden, die kann man zur Sicherheit auch erstmal rausnehmen. Und dann ist es ja einfach den Debugger zu starten, da sieht man auch ob es bis in die main loop geht.
Also bei mir läuft der Code auf Basis von TestMySTM32F429-Disc0_v005.ioc Im Anhang ein lauffähiges Hex File. Die Modifikation damit eine LED blinkt:
1 | /* Infinite loop */
|
2 | /* USER CODE BEGIN WHILE */
|
3 | while (1) |
4 | {
|
5 | /* USER CODE END WHILE */
|
6 | MX_USB_HOST_Process(); // das sollte in der Schleife drin sein |
7 | |
8 | /* USER CODE BEGIN 3 */
|
9 | HAL_GPIO_WritePin(GPIOG, GPIO_PIN_13, GPIO_PIN_SET); |
10 | HAL_Delay(500); |
11 | HAL_GPIO_WritePin(GPIOG, GPIO_PIN_13, GPIO_PIN_RESET); |
12 | HAL_Delay(500); |
13 | }
|
Wastl schrieb: > Wer sagt das? Der TO, siehe erster Beitrag. Eventuell ist es einen älteren F4Cube Package drin, aber an an den LED Pins scheint sich nichts geändert zu haben. Nur das die STLink Hardware auf einen neueren Stand gebracht wurde.
J. S. schrieb: > Eventuell ist es einen älteren F4Cube Package drin, Das lässt CubeMX gar nicht zu, es wird immer das neueste, aktuelle Package automatisch heruntergeladen (solange man am Internet hängt).
J. S. schrieb: > Der TO, siehe erster Beitrag. Ok, da war ich etwas voreilig. Das Disc0 Board wird nicht mehr gelistet wenn man die Board Selection aufruft. Also mein Versuch den Code laufen zu lassen bezieht sich auf das STM32F429-Disc1 Board. Aber mit dem Original TestMySTM32F429-Disc0_v005.ioc des TO generiert.
Angehängte Dateien:
also ich kann auch die älteste Version 1.0.0 installieren, aber auch die enthält auch kein F429-Disco. Aber da die Unterschiede bei IO doch nicht Signifikant sind ist es auch egal, dafür muss man sich nicht die alten Versionen antun.
:
Bearbeitet durch User
Angehängte Dateien:
-
IMG_3139.jpeg
240 KB
Hier noch ein Foto von meinem Board mit der Bezeichnung: stm32f429I-DISCO Auf der Rückseite gibt es noch einen Aufkleber: MB1075B-01 213370547 Prozessor: 32F429ZIT6U
Andreas S. schrieb: > Hier noch ein Foto von meinem Board mit der Bezeichnung: Warum hast du noch nicht mein Blinky getestet?
Wastl schrieb: > Andreas S. schrieb: >> Hier noch ein Foto von meinem Board mit der Bezeichnung: > > Warum hast du noch nicht mein Blinky getestet? Weil ich gerade mit meiner besseren Hälfte eine Heißluftfritteuse kaufen war :-) ... und weil ich schlicht über die Jahre vergessen habe, wie ich so ein HEX-File in den Prozessor reingeschoben bekomme ... (bin gerade selbst darüber geschockt). Anyway - inzwischen läuft mein Blinky - Auflösung kommt im nächsten Post.
Andreas S. schrieb: > ... und weil ich schlicht über die Jahre vergessen habe, wie ich so ein > HEX-File in den Prozessor reingeschoben bekomme ... STM32CubeProgrammer installieren, hex oder bin per Drag & Drop auf das Fenster ziehen und einen Button drücken.
Leute, Leute - Ihr seid die Besten! J.S. (jojo) hat mich auf den Trichter gebracht: Ich hatte Euch vorenthalten, dass ich bereits vor meinem ersten Post den Debugger gestartet hatte und mich gewundert hatte, dass der nicht in der main-loop ankam. J.S. hat mir dann die Augen geöffnet: der Debugger muss also in irgendwelchen Peripherie-Initialisierungsroutinen hängengeblieben sein. Na - zum Glück hatte ich ja noch mein versehentlich völlig uninitialisiertes Projekt aus meinem ersten Post. Dort habe ich nun einfach einmal nur den GPIO-Pin PG13 im CubeMX eingeschaltet (eigentlich genau das, was Ihr mir auch geraten hattet) - und schon funktioniert's! Mein Problem scheint also nicht die fehlende eine Initialisierung für den PG13 gewesen zu sein, sondern die Auswahl aller Initialisierungsroutinen, die ich per Klick auf "Initialize all peripherals with their default Mode" stets alle aktiviert hatte - und irgendwo in einer von denen (habe gerade keine Lust, das nochmals genauer zu untersuchen) scheint ein Bug begraben zu sein. Na das ist ja mal ein schöner Start wieder zurück in die Welt der STM32 mit all ihren super neuen Cube-MX-clicki-bunti-hast-Du-nicht-gesehen Tools. DICKES DANKESCHÖN in die Runde - ihr wart mal wieder in Hochform (... ich eher nicht ...) - was würde ich nur ohne Euch machen! Viele Grüße Igel1
Am Anfang von main sind ja die calls für die _init() der verschiedenen Devices. Nach dem Post von Wastl müsste es das USB sein was da Ärger macht wenn es nicht behandelt wird. Also mal das Neue ioc probieren und USB_init auskommentieren (solange es nicht benutzt werden soll).
Andreas S. schrieb: > und > irgendwo in einer von denen (habe gerade keine Lust, das nochmals > genauer zu untersuchen) scheint ein Bug begraben zu sein. Ja schon klar! Wieder mal ein Fall von "Hersteller hat fehlerhaften Code geliefert und Anfänger findet endlich nach 10 Jahren den Fehler und rettet die Welt". Am Öl kann's nicht gelegen haben, es war ja keins drin.
:
Bearbeitet durch User
Das war aber gar nicht nett, Wastl. Und ich hab nachgeguckt: Öl war doch drin.
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.