STM32F1: Reihenfolge Clock Config

[Rene K. (xdraconix)]

Ich stehe hier vor einem kleinen "Wald" Und zwar geht es um die 
Reihenfolge der Click Konfiguration.

Im Resetzustand ist ja der HSI an und wird als Sysclock genutzt. In 
welcher Reihenfolge muss ich nun auf HSE und PLL umstellen?!

Wenn ich nach dem Ablaufplan gehe dann folgend:

1.) HSEON in FCC_CR
2.) bis HSERDY in FCC_CR eingeschwungen / gesetzt ist
3.) PLLSRC in FCC_CFGR auf HSE (1)
4.) PLLMUL setzten (MUL9 für 72Mhz)
5.) SW auf PLLCLK
6.) APB1 auf DIV2..


Sooo... Mein Problem ist nun: WANN muss / darf ich den PLL in RCC_CR 
einschalten?! Zwischen Punkt 4 und 5 - wenn ja: muss ich warten bis 
PLLRDY gesetzt ist bevor ich SW umstelle? Die Waitstates und den Flash 
Prefetch darf ich komplett vor der Timer Init ins FLASH_ACR schreiben 
oder danach?!

Danke für die Tipps ?

[Niklas G. (erlkoenig)]

Rene K. schrieb:
> Zwischen Punkt 4 und 5 - wenn ja:
Ja.

Rene K. schrieb:
> muss ich warten bis
> PLLRDY gesetzt ist bevor ich SW umstelle?
Ja.

Rene K. schrieb:
> Die Waitstates und den Flash
> Prefetch darf ich komplett vor der Timer Init ins FLASH_ACR schreiben
> oder danach?!
Davor, sonst wird genau zwischen den Operationen auf den Flash zu 
schnell zugegriffen.

Hier ein Beispiel:
https://github.com/Erlkoenig90/f1usb/blob/master/sys/clockconf.c

Schritt 6 sollte vor 5 erfolgen, sonst läuft der APB1 zwischendurch zu 
schnell.

[STM Apprentice (Gast)]

Rene K. schrieb:
> Danke für die Tipps

Warum einfach wenn's umständlich auch geht?

Jede vernünftige IDE generiert dir beim Kreiren eines
neuen Projektes den Code der Takteinstellung schon mit.
Das ist dann meist der Weg den STM schon mit seinen
Code-Libraries vorgegeben hat. Den braucht man dann nur
noch nach seinem eigenen Geschmack ändern.

Dieser Teil findest sich in <system_stm32f10x.c> für
deinen Fall.

[Rene K. (xdraconix)]

Niklas G. schrieb:
> Schritt 6 sollte vor 5 erfolgen, sonst läuft der APB1 zwischendurch zu
> schnell.

Super, danke dir! :-D



@STM Apprentice

Ich nutze keine HAL/StdPeriph oder CMSIS in diesem Projekt, ich mach mir 
meine eigenen benötigten Header dafür. Im übrigen genau aus diesem 
Grund: um es zu verstehen. ;-) Aber danke für die Info.

[Niklas G. (erlkoenig)]

Du kannst im STM32CubeMX-Programm übrigens auch den Clock-Tree 
konfigurieren und die automatische Berechnung der Parameter nutzen, und 
die dann in den eigenen Code übernehmen. So spart man die manuelle 
Rechnerei und wird die SPL/HAL los.

[Stefan F. (Gast)]

Wenn du die Taktfrequenz erhöhst (z.B. von 8Mhz auf 64Mhz), musst du die 
Prescaler und Waitstate für den Flash einstellen, bevor du die höhere 
Taktfrequenz mit SW aktivierst.

Wenn du die Taktfrequenz verringerst, musst du zuerst die niedrigere 
Taktfrequenz mit SW aktivieren und erst danach die Prescaler ändern.

Und natürlich muss die PLL gestartet und bereit sein, bevor man sie 
nutzen kann.

Ich glaube, bei Cube HAL ist es gar nicht vorgesehen, die Taktfrequenz 
zur Laufzeit hin und her zu wechseln.

Vergiss die Waitstates für den Flash nicht, falls du über 24Mhz gehst.

[Rene K. (xdraconix)]

Stefan, ja das ist mir bewusst mit den Waitstates. Diese muss ich immer 
umstellen / anpassen bevor ich SW ändere.

Im Grunde, sollte man wirklich zur Laufzeit den Takt ändern wollen, wäre 
es ja sinnvoller die Waitstates immer vor SW auf 2 zu stellen und dann 
danach auf den richtigen Wert einzustellen um etwaige Probleme aus dem 
Weg zu gehen.