STM32 falsche Taktfrequenz

[Stefan F. (Gast)]

Ich versuche gerade zum ersten mal, die Taktquelle zu konfigurieren. 
Mein Projekt benutzt nur die CMSIS (kein HAL, keine SPL).

// 64Mhz using the HSI Oscillator
WRITE_REG(RCC->CFGR,RCC_CFGR_PLLSRC_HSI_Div2 + RCC_CFGR_PLLMULL16);

Aber meine LED blinkt viel langsamer, als erwartet (verglichen mit einem 
hoffentlich äquivalenten Programm unter Verwendung von CubeMX). 
Irgendwas fehlt noch, oder?

Ich habe noch gar keine Erfahrung mit STM32, also seid bitte nicht 
genervt, wenn ich blöde Fragen stellen.

[Arduinoquäler (Gast)]

> Ich habe noch gar keine Erfahrung mit STM32, also seid bitte nicht
> genervt, wenn ich blöde Fragen stellen.

Für welchen Controller? Falls es der F103 ist, dann geht nur
24, 36, 48, 56 oder 72 Mhz, 64 gerade nicht.

Ich zerfiesele das Register Geschubse nicht, wenn es die Vorlage
von STM bereits macht, da mache ich mir lieber andere Sorgen.

Schau dir doch mit dem Debugger den Verlauf von SystemInit()
in der Datei system_stm32f10x.c an, da kannst du jeden Schritt
sehen, herauskopieren, modifizieren etc.

[Stefan F. (Gast)]

Hat sich erledigt, ich hab's dank Google doch noch selbst gefunden.

// 64Mhz using the HSI oscillator with PLL and APB lowspeed prescaler 2
WRITE_REG(RCC->CFGR,RCC_CFGR_PLLSRC_HSI_Div2 + RCC_CFGR_PLLMULL16 + RCC_CFGR_PPRE1_DIV2);

// Flash latency 2 wait states
MODIFY_REG(FLASH->ACR, FLASH_ACR_LATENCY, FLASH_ACR_LATENCY_2);

// ENABLE PLL
SET_BIT(RCC->CR, RCC_CR_PLLON);

// WAIT until PLL is ready
while(!READ_BIT(RCC->CR, RCC_CR_PLLRDY)) {}

// Select PLL as clock source
MODIFY_REG(RCC->CFGR, RCC_CFGR_SW, RCC_CFGR_SW_PLL);

Es fehlte noch, die PLL einzuschalten und als Taktquelle auszuwählen. 
Und damit sich der µC dabei nicht aufhängt, musste ich noch die wait 
states erhöhen.

Bei der Gelegenheit habe ich auch noch herausgefunden, dass einige 
Komponenten (APB) nur mit maximal 36Mhz getaktet werden dürfen, weswegen 
ich dazu den Prescaler auf 2 setze.

Die LED blinkt jetzt mit der erwarteten Geschwindigkeit.

Ist das jetzt so richtig?

[Stefan F. (Gast)]

> Für welchen Controller? Falls es der F103 ist, dann geht nur
> 24, 36, 48, 56 oder 72 Mhz, 64 gerade nicht.

Upps, das hast du gut geraten. Ja, es ist der STM32F103rBT6.

Wieso sollten 64Mhz nicht gehen? 8Mhz /2 *16 sind doch 64Mhz. Das ist 
auch die Default-Vorgabe in CubeMx.

> Ich zerfiesele das Register Geschubse nicht

Ist Ok, aber genau das will ich ja hiermit lernen. Den HAL Kram werde 
ich erst benutzen, wenn ich die Grundlagen verstanden habe. Ich kann mir 
den Aufwand leisten, da es nur ein Hobby ist.

> Schau dir doch mit dem Debugger den Verlauf von SystemInit()
> in der Datei system_stm32f10x.c an.

Guter Vorschlag. Das problem hat sich inzwischen erledigt, aber ich 
merke mir das mal für künftige ähnliche Fälle.

By the way: Die Prozedur zum Ändern der Taktfrequenz erinnert mich sehr 
an Atmels Xmega.

[Stefan F. (Gast)]

Ich habe allerdings immer noch nicht verstanden, warum man das in der 
speziellen Funktion SystemInit() machen soll, und nicht in main().

[TMK (Gast)]

Ich habe auch erst kürzlich mit STM32 begonnen, entwickle mit Eclipse. 
Beinahe alle Beispiele (egal ob Register-Zugriff, CMSIS oder HAL) setzen 
die Clock in main(). Das ist natürlich in jedem Falle ok.
Es gibt allerdings einen Vorteil, wenn man die Clock vorher setzt, unso 
so von den 8/16 Mhz weg kommt: Performance beim Starten.
Schreibt man nur C-Code, ist es fast egal, bei C++ kann es sich aber 
lohnen. Konstruktoren für globale Objekt werden vor main() aufgerufen, 
und das läuft dann mit full speed. Man benötigt allerdings dann den 
richtigen Startup-Code und muss _initalize_hardware_early 
implementieren.