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 */
1
/* 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.
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.
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.
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 ...
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.
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.
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.
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.
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.
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!
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).
