Hallo zusammen, seit kurzem arbeite ich mich in die STM32F4-Familie mit dem STM32F407 DISCOVERY Board ein. Alles schön und gut. Ich bin mit CooCox CoIDE eingestiegen und bin dann zu STM32 Workbench gewechselt. Um mich NOCH nicht mit der Einstellung der Clocks und der Waitstates und allem drum und dran befassen zu müssen wollte ich mir die system_stm32f4xx.c zunächst automatisch generieren lassen. Da das Excel-Sheet von STM mit Libre-Office offensichtlich nicht kompatibel ist musste ich wohl oder übel für diese Aufgabe auf CubeMX umsteigen. Dort habe ich alle gewünschten Prescaler eingestellt, den externen Takt via Quarz eingestellt und gehofft, dass mir die passende system_stm32f4xx.c ausgespuckt wird; was aber nicht der Fall ist. Es wird weiterhin lediglich der interne 16MHz-Oszillator genutzt und der externe Quarz und die PLL bleiben ungenutzt. (Festgestellt habe ich es dadurch, dass ich beim SPI den Prescaler 256 eingestellt habe und die Taktfrequenz bei ziemlich genau 62,26kHz liegt; das ist eben 16MHz / 256). Ich habe euch einmal die CubeMX-Datei, die stm32f4xx.c und die Reports-Datei als angehängt; in der Reports-Datei sieht man, wie ich den Clock-Tree konfiguriert habe. Habe ich etwas essentielles übersehen?
Die Takt Konfiguration findet in der main.c mit SystemClock_Config(); statt. Ausserdem hast du SWD oder JTAG nicht aktiviert.
Die Funktion "SystemClock_Config();" gibt es bei mir nicht; und so weit ich mich erinnere hat es bei Coocox auch gereicht, dass ich lediglich die Werte für PLL_M und PLL_N und die Prescaler anpasse; denn bei Coocox hat alles einwandfrei funktioniert. Liegt es wohl daran, dass man bei STM32Workbench nur per Würgaround dazu bringen kann, ausschließlich mit dem CMSIS-Treibern zu arbeiten. Ein weiteres Detail, was mich irritert ist dies, dass sämtliche erzeugten Dateien den aktuellen Zeitstempel tragen; bis auf die system_stm32f4xx.c - diese trägt grundsätzlich den Zeitstempel vom letzten Update. Und danke für den Tipp mit JTAG - Das habe ich mittlerweile nachgetragen!
:
Bearbeitet durch User
Stefan S. schrieb: > Liegt es wohl daran, dass man bei STM32Workbench nur per Würgaround dazu > bringen kann, ausschließlich mit dem CMSIS-Treibern zu arbeiten. Ich glaube du hast da etwas nicht ganz verstanden. Mit SW4STM32 oder gar Coocox hat das ganze überhaupt nichts zu tun. Allenfalls hat es was mit der StdPeriphLib und HAL zu tun. CubeMX ist mit STs HAL verkoppelt, weshalb auch oft die Rede von Cube/HAL ist. Dabei generiert dir CubeMX Code bestehend aus irgendwelchen HAL-Funktionen, unter anderem auch für das PLL-Setup. Die von CubeMX generierte Funktion dafür nennt sich SystemClock_Config() und wird zu Beginn der main() aufgerufen. Zu Zeiten der SPL wurde die PLL-Konfiguration noch (wie von ARM ursprünglich mal vorgesehen) in der SystemInit() vorgenommen.
Christopher J. schrieb: > Ich glaube du hast da etwas nicht ganz verstanden. Mit SW4STM32 oder gar > Coocox hat das ganze überhaupt nichts zu tun. Allenfalls hat es was mit > der StdPeriphLib und HAL zu tun. Ja das meinte ich - da hatte ich mich vielleicht etwas unsauber ausgedrückt. Christopher J. schrieb: > Die von CubeMX generierte Funktion dafür nennt sich > SystemClock_Config() und wird zu Beginn der main() aufgerufen. Zu Zeiten > der SPL wurde die PLL-Konfiguration noch (wie von ARM ursprünglich mal > vorgesehen) in der SystemInit() vorgenommen. Christopher J. schrieb: > Die von CubeMX generierte Funktion dafür nennt sich > SystemClock_Config() und wird zu Beginn der main() aufgerufen. Okay, wenn ich das richtig verstanden habe, müsste ich die Funktion SystemClock_Config() von CubeMX übernehmen; was mir aber auch wiederum Magenschmerzen bereitet, da CubeMX sicherlich die HAL-Libs haben will. Gibt es denn eine andere Möglichkeit, sich zumindest die grundlegende Taktkonfiguration erzeugen zu lassen? Zur Not könnte ich noch die system_stm32f4xx.c von Coocox missbrauchen, da mir die beim Durcharbeiten ganz gut gefallen hat - aber das ist irgendwie sehr unbefriedigend.
Mal ehrlich, in der Zeit, in der Du da so rumgebastelt hast, hättest Du auch die paar Seiten im Datasheet und Ref.-Manual lesen können und gleich noch was gelernt. Wo ist denn da Dein Problem? Hier steht zum Beispiel eine Beispiel-Initialisation: Beitrag "Re: STM32F4 SPI Problem" Die Paar Bits bekommst Du bestimmt auch gesetzt, ohne vorher Hunderte von Megabytes an Software zu installieren, auszuprobieren und dann doch festzuhängen ;) Bei Fragen stehen wir Dir gerne zur Verfügung. Aber glaub mir, die Clock- und Waitstate-Initialisation ist trivial...
John Doe schrieb: > Mal ehrlich, in der Zeit, in der Du da so rumgebastelt hast, hättest Du > auch die paar Seiten im Datasheet und Ref.-Manual lesen können und > gleich noch was gelernt. Zugegeben, die letzten Posts waren mehr so "auf die Schnelle", da mir die Zeit gefehlt hatte. Jetzt habe ich mir ein paar Stunden Zeit genommen und das Ref-Manual diesbezüglich intensiv(er) durchgearbeitet und mittlerweile scheint es zu klappen. Irgendwie schien es mir bisher komplizierter, als es letztlich war. Wie dem auch sei, ich bedanke mich bei allen, die sich die Zeit genommen haben den Thread zu lesen und zu antworten. Wenn ich noch Fragen haben sollte, dann melde ich wieder! :)
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.