Forum: Mikrocontroller und Digitale Elektronik STM32H745 - Cortex-M7 auf 480MHz takten


von Johannes K. (krjdev)


Lesenswert?

Hallo liebe Community!

Eine Newbie-Frage:
Muss man auf was besonders achten wenn ich den Takt von 64MHz von der 
HSI mit der PLL auf 480MHz anhebe und den Cortex-M7 damit speise, oder 
sollte das problemlos funktionieren? Zugegeben eine etwas blöde Frage, 
aber ist halt doch von der Frequenz sehr viel mehr als der Default-Takt 
nach dem Reset.

Mir ist schon klar, dass ich auch auf die Busgeschwindigkeiten und 
Peripherie auch achten muss, damit diese nicht die maximale 
Geschwindigkeit überschreiten.

Hab derzeit das Board Nucleo-H745ZI-Q daheim, wo ich das ausprobieren 
möchte.

Nachtrag:
Ich verwende für meine Lernprojekte nicht die STMCubeIDE. Nur VIM als 
Editor (Quelldateien, Linkerskripte, Makefiles) , die offiziellen GNU 
Toolchains (GCC, binutils) von der ARM Webseite und GNU make reichen 
mir. Auch keine externen Standard C Bibliotheken wie newlib oder uclib. 
Also reine Bare-Metal Lernprojekte.

von Stefan F. (Gast)


Lesenswert?

Von den kleineren Modellen kenne ich es so, dass man vorher mindestens 
die Wait-States für den Flash Zugriff einstellen muss. Teilweise muss 
man auch die Takt-Teiler für die Peripherie ändern.

Schau dir das in Cube MX an, auch wenn du es am Ende selbst 
programmierst.

Bist du sicher, dass dieser Bolide für Newbies eine gute Wahl ist?

von Johannes K. (krjdev)


Lesenswert?

Vielen lieben Dank!

Stefan ⛄ F. schrieb:
> Von den kleineren Modellen kenne ich es so, dass man vorher mindestens
> die Wait-States für den Flash Zugriff einstellen muss. Teilweise muss
> man auch die Takt-Teiler für die Peripherie ändern.

Okay, dass mit den Wait-States für den FLASH hab ich ehrlich gesagt 
nicht gewusst bzw. gedacht.

> Schau dir das in Cube MX an, auch wenn du es am Ende selbst
> programmierst.

Wird glaube ich besser sein, bevor ich den RCC (Reset and Clock 
Controller) selbst ohne ST's HAL einstelle.

> Bist du sicher, dass dieser Bolide für Newbies eine gute Wahl ist?

Wird vermutlich stimmen. :) Aber was die ARM Architektur betrifft bin 
ich nicht mehr neu. Zwar nicht von STMicroelectronics aber von Rockchip 
(ARMv8 - Cortex-A53) und Xilinx (ZYNQ-7000 - Cortex-A9) habe ich doch 
ein wenig Erfahrung gesammelt. Allerdings immer mit der Verwendung mit 
U-Boot. Was das Basis-Setup durchgeführt hat. Gut, keine M-Profile...

Wobei ich zugeben muss, dass die Dokumentation im allgemeinen von ST 
schon TOP ist.

von PittyJ (Gast)


Lesenswert?

Ich habe meine ersten Projekte mit StmCubeIDE gemacht. Die automatischen 
Tools erzeugen alle Initialisierungen, die man für Clock, SPI, I2C etc 
braucht.
Später bin ich zu eigenem Make und G++ gewechselt.
Die HAL verwende ich weiterhin, weil sie viele Sachen (Uart-Senden, Spi 
Master) sehr einfach macht. Warum sollte ich das selbst 
nachprogrammieren, und auf die gleiche Lösung kommen.
Die HAL liegt auch im Sourcecode vor, da kann man gut noch mal 
reinschauen.

von Johannes K. (krjdev)


Lesenswert?

PittyJ schrieb:
> Die HAL verwende ich weiterhin, weil sie viele Sachen (Uart-Senden, Spi
> Master) sehr einfach macht. Warum sollte ich das selbst
> nachprogrammieren, und auf die gleiche Lösung kommen.

Ich bin ehrlich: Da ich nicht mehr in der Berufswelt bin aufgrund einer 
Krankheit, will ich alles selber machen. Auch weil mein großes Ziel ein 
eigener Mikrokernel ist. Habe jetzt im Moment zu viel Zeit. Wenn ich 
noch in der Berufswelt stehen würde, dann würde ich auch auf bestehende 
Bibliotheken und IDE's zurück greifen, die mir die Arbeit erleichtern. 
Wäre auch nicht anderes zeitlich möglich.

> Die HAL liegt auch im Sourcecode vor, da kann man gut noch mal
> reinschauen.

Ja, ich weiß. Hab ich schon auf dem offiziellen ST-GitHub Profil 
gefunden.

von Leopold N. (leo_n)


Lesenswert?

Achte auch darauf, dass im PWR Block das Voltage Level aus VOS0 
eingestellt sein muss. Ich hatte da mal ein Problem, bei dem die 
Chiprevision allerdings verhindert hatte, dass ich die vollen 480MHz 
nutzen konnte. War ein STM32H753BIT6 Revision Y, da stand im Errata 
Sheet dann, dass aufgrund eines Die-Fehlers nicht VOS0 eingestellt 
werden kann und somit dann auch nur 400 MHz statt 480 MHz genutzt werden 
konnten. Musste dann bei ST extra Revision V bestellen, die hatte das 
Problem dann nicht mehr.

von Johannes K. (krjdev)


Angehängte Dateien:

Lesenswert?

Leopold N. schrieb:
> Achte auch darauf, dass im PWR Block das Voltage Level aus VOS0
> eingestellt sein muss. Ich hatte da mal ein Problem, bei dem die
> Chiprevision allerdings verhindert hatte, dass ich die vollen 480MHz
> nutzen konnte. War ein STM32H753BIT6 Revision Y, da stand im Errata
> Sheet dann, dass aufgrund eines Die-Fehlers nicht VOS0 eingestellt
> werden kann und somit dann auch nur 400 MHz statt 480 MHz genutzt werden
> konnten. Musste dann bei ST extra Revision V bestellen, die hatte das
> Problem dann nicht mehr.

Okay, vielen Dank! Hab mal die Errata für den STM32H745 überflogen, aber 
nicht spezielles Betreff des PWR Blockes gefunden.
https://www.st.com/resource/en/errata_sheet/es0445-stm32h745747xig-and-stm32h755757xi-device-limitations-stmicroelectronics.pdf

Was ich nicht verstehe, wenn ich den Cortex-M7 mit einer Frequenz von 
480MHz betreibe, dass das folgende Betreff der Bus-Matrix steht:

In addition the CPU clock frequency can be equal to the bus matrix clock 
frequency, but the maximum frequency for the bus matrix is limited to 
200 MHz.

Limitiert auf 200MHz. Wobei auf der nächsten Seite im Reference Manual 
(Anhang - STM32H745_SCGU.png), beim Blockschaltbild, dann aber maximal 
240MHz steht. Auch im Dokument bei den maximalen Frequenzen von den 
Busen (AXI, AHB, APB) steht 240MHz (Anhang - STM32H745_FREQ.png).

Verstehe ich derzeit nicht wirklich...

EDIT:
Hoppla, APB hat eine maximale Frequenz von 120MHz (nicht 240MHz)...

: Bearbeitet durch User
von Leopold N. (leo_n)


Lesenswert?

Ich glaub, das ist einfach nur nicht einheitlich geschrieben worden.
Die haben den Cortex M7 von 400MHz aufm STM32F7 auf 480MHz aufm STM32H7 
aufgebohrt. Da werden die die Manuals wohl einfach kopiert haben und 
entsprechende Zahlen geändert haben. War bei meinem Chip auch nicht 
alles ganz konsistent.

von utzutr (Gast)


Lesenswert?

TIP:

bau dir gleich ein linkerfile mit den passenden ram sections

die H7xx sind ein krampf was memory sections und domains angeht
ohne MPU läuft da kaum was richtig wenn man DMA nutzen will

cache abschalten hilft  .. ist dann aber halt arschlahm

von m.n. (Gast)


Lesenswert?

Leopold N. schrieb:
> 400MHz aufm STM32F7

Nein. Die F7xx laufen typisch mit 216 MHz.
Die H7xx liefen zunächst mit 400 MHz wurden mit Revisionen auf 480 MHz 
erweitert und neuere Versionen (H723 zum Beispiel) "rennen" dann gleich 
mit 550 MHz.
400 MHz Versionen laufen aber auch mit 480 MHz; die Stromaufnahme ist 
dabei etwas höher.

Johannes K. schrieb:
> Okay, dass mit den Wait-States für den FLASH hab ich ehrlich gesagt
> nicht gewusst bzw. gedacht.

Die sind zunächst auch unkritisch, da nach /RESET das Timing auf 
maximale Waitstates (0xF) eingestellt ist.
Ohne transparentes Debugging solltest Du nicht an den PLL-Registern 
drehen. Das kann trotz genauer Datenblätter sonst sehr frustig werden.

von Leopold N. (leo_n)


Lesenswert?

m.n. schrieb:
> Leopold N. schrieb:
>> 400MHz aufm STM32F7
>
> Nein. Die F7xx laufen typisch mit 216 MHz.
> Die H7xx liefen zunächst mit 400 MHz wurden mit Revisionen auf 480 MHz
> erweitert und neuere Versionen (H723 zum Beispiel) "rennen" dann gleich
> mit 550 MHz.
> 400 MHz Versionen laufen aber auch mit 480 MHz; die Stromaufnahme ist
> dabei etwas höher.

Oh ja, stimmt. Hatte es nicht mehr genau im Kopf, nur dass da sowas war 
:)

von Johannes K. (krjdev)


Lesenswert?

m.n. schrieb:
> Ohne transparentes Debugging solltest Du nicht an den PLL-Registern
> drehen. Das kann trotz genauer Datenblätter sonst sehr frustig werden.

Hab gerade im RCC gesehen, dass es auch angeblich möglich ist die PLL 
Ausgabe auf die MCO Ausgänge umzuleiten. Somit könnte ich die PLL mal 
versuchen auf einen bestimmten Wert einzustellen und einfach mal mit 
meinem Oszilloskop über den MCO Prescaler (kann leider damit nur maximal 
250MHz) nachmessen, bevor ich die PLL Ausgabe als System Clock auswähle.

Würde das funktionieren?

von Malte _. (malte) Benutzerseite


Lesenswert?

m.n. schrieb:
> 400 MHz Versionen laufen aber auch mit 480 MHz; die Stromaufnahme ist
> dabei etwas höher.
...meistens zumindest. Ich hatte mal ein "übertaktetes" Exemplar, wo man 
dann im Debugger sehen konnte, dass der Absturz durch einen nicht 
korrekt ausgeführten Assemblerbefehl verursacht wurde. Auf einem anderem 
Exemplar oder auf dem selben mit 400MHz gings dann.

Die erlaubte Spannungstoleranz für den Core bei 480MHz ist übrigens auch 
geringer.

von Johannes K. (krjdev)


Angehängte Dateien:

Lesenswert?

Malte _. schrieb:
> Die erlaubte Spannungstoleranz für den Core bei 480MHz ist übrigens auch
> geringer.

Hhmm... Kommt drauf an wo die VCORE Spannung herkommt laut Datenblatt.

Wenn man die internen Spannungsregler (LDO) verwendet, dann sind die 
Toleranzen sogar höher. Wenn man allerdings die Spannung extern zuführt, 
dann sind sie in der Tat sehr gering bei 480MHz.

Bitte 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
Noch kein Account? Hier anmelden.