Hallo,
ich hab ein Nucleo-F103RB. Ich verwende den Startup Code von Eclipse mit
der ARM Non-Eabi Tool Chain
https://github.com/kicer/stm32f10x-gcc/blob/master/STM32F10x_StdPeriph_Lib_V3.5.0/Libraries/CMSIS/CM3/DeviceSupport/ST/STM32F10x/system_stm32f10x.c
Laut Datenblätter kann man den Prozessortakt von HSI (intern) oder HSE
(extern) generieren. Für HSE muss man z.B. 8 MHz einen Quartz an die
entsprechenden Pins löten.
Mein Nucleo-F103RB (C-03) hat aber nur den 32k Quartz angelötet (X1). X3
fehlt.
Der Startup Code aber aktiviert HSE über die RCC Register und wartet
darauf das er bereit ist (HSE_RDY). Ich bin mit dem Debuggerschrittweise
durchgegangen und der Code wird wirklich ausgeführt und es gibt sogar
eine Abzweigung, falls HSE nicht bereit ist -> da komm ich aber nicht
rein.
1
staticvoidSetSysClockTo72(void)
2
{
3
__IOuint32_tStartUpCounter=0,HSEStatus=0;
4
5
/* SYSCLK, HCLK, PCLK2 and PCLK1 configuration ---------------------------*/
6
/* Enable HSE */
7
RCC->CR|=((uint32_t)RCC_CR_HSEON);
8
9
/* Wait till HSE is ready and if Time out is reached exit */
Wie also kann mein Prozessortakt von HSE kommen, wenn ich den Quartz gar
nicht auf dem Board habe?
Warum läuft der Code fehlerfrei als wenn ein externer 8 MHz Quartz
arbeitet?
Ich schließe darauf, dass der Prozessor deshalb mit dem unpräziseren
internen HSI getaktet wird, verstehe den Code aber trotzdem nicht.
Hallo Tom,
für die Taktgeschichten rate ich das CubeMX-Tool von ST zu benutzen,
auch wenn man den HAL-Code später nicht benutzt.
Man kann bequem in der grafischen Oberfläche die Taktquellen auswählen
und sich dann die Parameter rausziehen.
Man sieht auch sehr schön den Zusammenhang der ganzen Taktpfade.
Tom schrieb:> Hier noch ein Bild von einem Nucleo-F103RB, der beide Quartz> angelötet hat (siehe unten, links: 32k, rechts: 8M)> https://img.conrad.de/medias/global/ce/4000_4999/4...>> Der rechte ist bei mir nicht drauf
Nachdem der HSE nicht anschwingt kommt der automatische Fallback in den
HSI.
Tom schrieb:> Ich schließe darauf, dass der Prozessor deshalb mit dem unpräziseren> internen HSI getaktet wird, verstehe den Code aber trotzdem nicht.
HSEStatus bleibt auf 0 nachdem StartUpCounter auf Timeout gelaufen ist.
Anschließend wird der 8 MHz HSI als Referenztakt verwendet.
(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· schrieb im Beitrag
#4958966:
> Vermutlich bekommt er 8 MHz vom MCO des JTAG-Controllers...
So wird es wohl sein. Standardmäßig sind die Nucleo-64 Boards, also
F103RB, F4x1RE, usw. alle so verschaltet, dass OSC IN des Controllers
mit dem MCO des ST-Link verbunden ist. Der ST-Link hat ja einen externen
8 MHz Quarz und über den MCO-Pin werden eben diese 8 MHz für die
anderweitige Nutzung ausgegeben. Genau genommen würde es in dieser
Konfiguration überhaupt nichts bringen, wenn du X3 bestücken würdest,
weil du vorher entsprechende Lötbrücken auf der Board-Unterseite ändern
musst. Sinn macht das eigentlich nur, wenn du den ST-Link vom Rest des
Boards abtrennen und trotzdem noch die HSE nutzen willst. Genaueres
findest du in der Doku auf der ST-Webseite.
Noch so am Rande:
Normalerweise konfiguriert man die HSE im "bypass mode", wenn man den
HSE-Takt von einer externen Quelle bekommt. Der Controller muss ja
keinen externen Quarz anregen und man kann sich den Ausgang zum Quarz
sparen bzw. anderweitig verwenden. Funktionieren tut es aber wohl
meistens (immer?) wenn man den Bypass-Mode nicht explizit konfiguriert.
Der Controller versucht dann vermeintlich über OSC Out einen Quarz
anzuregen und bekommt auch einen Takt an OSC In zurück. Zwar nicht den
vom Quarz sondern den vom Ausgang des ST-Link aber das scheint dem wohl
zu reichen.
>HSEStatus bleibt auf 0 nachdem StartUpCounter auf Timeout gelaufen ist.>Anschließend wird der 8 MHz HSI als Referenztakt verwendet.
Nein, laut Debugging ist der StartUpCounter auf 1, danach wird die
Schleife sofort verlassen. Das Timeout trifft NICHT ein!
HSEStatus wird auf 1 gesetzt (alles mit Debugger schrittweise
durchgelaufen) - DAS ist es ja was mich verwirrt.
Wenn das Timeout eintreffen würde,dann würde er sofort in folgende
Abzweigung springen und keinen Programmcode ausfuehren - was er NICHT
tut:
Zeile 1011 der obigen C-Datei
1
if(HSEStatus==(uint32_t)0x01)
2
{
3
4
5
6
7
8
....
9
10
else
11
{/* If HSE fails to start-up, the application will have wrong clock
12
configuration. User can add here some code to deal with this error */
13
}
Ja der ST-Link hat auch einen 8 MHz Quartz, aber ist der nicht viel zu
weit weg vom Mikrocontroller? Soll man Quartz nicht immer so nah wie
möglich an die Pins anbringen?
>Nachdem der HSE nicht anschwingt kommt der automatische Fallback in den>HSI.
Diese Abfrage aber hier gibt true zurueck:
1
HSEStatus=RCC->CR&RCC_CR_HSERDY;
>Man sieht auch sehr schön den Zusammenhang der ganzen Taktpfade.
Im Datenblatt des Mikrocontrollers gibt es ein "Clock Tree", mit dem man
die Pfade auch gut nachvollziehen kann - ist mein erster Anlaufpunkt
wenn es um Takte geht.
>der ST-Link hat ja einen externen>8 MHz Quarz und über den MCO-Pin werden eben diese 8 MHz für die>anderweitige Nutzung ausgegeben.
Das kann ich jetzt bestätigen. Auf Seite 64 ist das deutlich zu sehen:
http://www.st.com/content/ccc/resource/technical/document/user_manual/98/2e/fa/4b/e0/82/43/b7/DM00105823.pdf/files/DM00105823.pdf/jcr:content/translations/en.DM00105823.pdf
Dort wird der MCO Ausgang vom ST Link Controller auf den OSC - Pin über
eine Lötbrücke geführt. Beide Lötbrücken (von und zu F103RB) sind
"closed" also verlötet.
Der OSC - Out ist floating ohne den Widerstand ("N/A"), d.h. High
Impedance.
Also kommt der HSE als "external source" wie beim Dateianhang zu sehen.
Meine letzte Frage:
Was passiert, wenn ich den Quellcode auf einem Mikrocontroller
kompiliere, der auf keinen Nucleo Board sitzt d.h. ohne ST-Link und ohne
externen 8 MHz Quartz?
Wird dann HSE_RDY nicht triggern und meine main würde nie ausgeführt
werden?
Der 32kHz Quarz ist am LSE Oszillator angeschlossen.
Der Quarz für den HSE Oszillator ist (bei meinem Board) nicht bestückt.
Du kannst den HSE Eingang wahlweise mit einem Quarz, Keramik Resonator
oder mit dem 8Mhz Ausgang des ST-Link verbinden. Im Manual
(http://www.st.com/resource/en/user_manual/dm00105823.pdf) steht, welche
Lötbrücken dazu einzustellen sind.
Schau Dir mal das Bild aus CubeMX an, wo der interne Schaltkreis zur
Takterzeugung dargestellt ist: http://stefanfrings.de/stm32/index.html
Wenn du auf mehr als 24Mhz gehst, beachte die blauen Angaben zur
maximalen Taktfrequenz. Die stehen natürlich auch irgendwo im
Referenz-Handbuch des Mikrocontrollers.
Der Flash kann maximal 8Mhz!
Der I/O Baugruppe APB1 kann nur 36Mhz.
Für den Flash musst du 2 Wait States einstellen, sonst stürzt der
Controller ab.
> Für meine Verhältnisse ist aber der 8 MHz Quartz des ST-Link schon> weit weg vom Mikrocontroller, oder wie seht ihr das?
Nein, das ist schon Ok. Bei 8Mhz muss man sich da keine Sorgen machen.
Stefan U. schrieb:> Der Flash kann maximal 8Mhz!
Falsch!
Aus rm0008:
The Flash memory access time is adjusted to the fHCLK frequency (0 wait
state from 0 to 24 MHz, 1 wait state from 24 to 48 MHz and 2 wait states
above)
Tom schrieb:> Nein, laut Debugging ist der StartUpCounter auf 1, danach wird die> Schleife sofort verlassen. Das Timeout trifft NICHT ein!
Dann hat er auch einen HSE-Takt!
Christopher J. schrieb:> Der ST-Link hat ja einen externen> 8 MHz Quarz und über den MCO-Pin werden eben diese 8 MHz für die> anderweitige Nutzung ausgegeben.
Und genau diese 8 MHz werden über die Lötbrücken SB16 und SB50 an OSC_IN
geschaltet.
Tom schrieb:> Warum läuft der Code fehlerfrei als wenn ein externer 8 MHz Quartz> arbeitet?
Weil Du einen ext. 8 MHz Takt verwendest. Dabei ist es unerheblich, ob
OSC_IN und OSC_OUT auf ext. Quarz oder ext. Takt (bypass) programmiert
sind.
>> Der Flash kann maximal 8Mhz!> Falsch!
Oh ja, ich habe mich verschrieben. Ist mir auch gerade ausgefallen. Es
sind 24Mhz. 8Mhz wäre auch verwunderlich wenig. Ich finde ehrlich gesagt
auch die 24Mhz enttäuschend.
Stefan U. schrieb:> Es> sind 24Mhz. 8Mhz wäre auch verwunderlich wenig. Ich finde ehrlich gesagt> auch die 24Mhz enttäuschend.
Wenn Du einen µC ohne wait-states haben möchtest: RX63/RX631.
Die laufen mit 100 MHz und sind sehr feine Teile, nur hier nahezu
unbekannt ;-)
m.n. schrieb:> RX63/RX631.
Ja schaut gut aus ...
m.n. schrieb:> nur hier nahezu unbekannt ;-)
Sind ja offensichtlich auch noch sehr neu.
Wenn man mal fremdgehen möchte: Kann man bei Renesas auch
auf einen Support zum schmerz-armen (ich wollte schmerzfrei
vermeiden) Einstieg hoffen wie bei den STM32 Controllern
(bezüglich zu Verfügung stehender Tools ....)?
STM Apprentice schrieb:> m.n. schrieb:>> RX63/RX631.>> Ja schaut gut aus ...
Endlich mal einer, der das zur Kenntnis nimmt ;-)
> m.n. schrieb:>> nur hier nahezu unbekannt ;-)>> Sind ja offensichtlich auch noch sehr neu.
Nee, die sind schon älter, es sind nur die neueren Ausführungen der
RX6xx-Reihe.
Aber sieh Dir aus Spaß den RX71M an. Der ist erst zwei Jahre alt, stellt
die STM32 funktional voll in den Schatten, wenn es auf die Feinheiten
ankommt.
Aber das wird jetzt schwer OT.
m.n. schrieb:> Aber das wird jetzt schwer OT.
Wenn es um Performance geht bin ich gerne schnell OT.
... und was bitte könntest du informativ noch zum zweiten
Teil meines letzten Beitrags (Frage) sagen? (Danke ...)
m.n. schrieb:> Aber sieh Dir aus Spaß den RX71M an.
Den Spass hab' ich mir gegönnt und er gefällt mir sehr.
Insbesondere die 240 Mhz und 512 KByte SRAM ohne extra
externen Aufwand ist seeeehr vielversprechend.
Jetzt fehlt noch das "easy-going" wie bei den STMs.
STM Apprentice schrieb:> Wenn man mal fremdgehen möchte: Kann man bei Renesas auch> auf einen Support zum schmerz-armen (ich wollte schmerzfrei> vermeiden) Einstieg hoffen wie bei den STM32 Controllern> (bezüglich zu Verfügung stehender Tools ....)?
Ja, aber derzeit und hierzulande mit Hindernissen. Die Demo-Boards sind
schwer zu finden und zu beschaffen. In der Regel braucht man einen
Distibutor, weil Renesas offensichtlich nur an Industriekunden (z.B.
Automobil) interessiert ist.
Es gibt aber eine Software-Plattform (E2Studio auf Eclipse-Basis) mit
Renesas Compilern. Von KPIT gibt es GCC-Compiler gratis dazu. Früher
hieß die IDE HEW (für Hitachi Embedded Workbench, dann bei Renesas
High-Performance Embedded Workbench), die mir sehr gefallen hat!
Es gibt hauseigene Debugger aber auch JLink von Segger speziell für RX.
Ein einfacher RX210 reicht zum Einstieg:
https://www.renesas.com/en-us/products/boards-and-kits/boards-and-kits/device/YRPBRX210.htmlhttp://uk.rs-online.com/web/p/processor-microcontroller-development-kits/9031482/
Etwas für den RX62:
https://www.renesas.com/en-us/products/boards-and-kits/boards-and-kits/device/YRPBRX62N.html
Die Umfangreicheren Boards beginnen mit YRDKRX--, wobei -- für den
jeweiligen Typen steht. Früher bequem von DK oder Future Electronic zu
beziehen. Glyn dürfte auch passende Boards anbieten - ohne, daß ich
jetzt explizit nachsehe.
Im japanischen/US-Raum gibt es SAKURA-Boards, die soetwas wie Arduino
mit RX sind. Beispiel: http://sakuraboard.net/gr-sakura_en.html.
Große Überraschung Sakura bei Conrad: bitte selber suchen, da beim Link
Spam vermutet wird.
Ein Forum von Renesas gibt es auch (war mal besser):
http://renesasrulz.com/renesas_forum_home/
Die Datenblätter zu den µCs finde ich ausgesprochen gut, die µC selber
sind Edelteile, wenn es auf spezielle Funktionen ankommt (Timing vom
ext. Bus, DMA-Controller arbeitet auch "rückwärts",...) und die
Pinzuordnung zu den Ports ist nicht wild durcheinander gewürfelt.
ABER RX-µCs sind kein Mainstream und selbst bei Distributoren meist
nur mit Wartezeit zu beschaffen. Für mich hatte das dann eines Tages die
Konsequenz, auf STM32F407 umzusteigen: an jeder Ecke ohne Wartezeit sehr
günstig (Future Electronic) zu bekommen.
Danke für die Antworten.
Also erwartet der gezeigte Startup Code zwingend, dass der verwendete
Mikrocontroller einen externen Quartz ODER einen externen Takt für HSE
besitzt.
Tom schrieb:> Also erwartet der gezeigte Startup Code zwingend, dass der verwendete> Mikrocontroller einen externen Quartz ODER einen externen Takt für HSE> besitzt.
Wenn kein HSE-Takt vorhanden ist, läuft er mit HSI weiter, ohne die PLL
zu benutzen.
> Funktionieren tut es aber wohl> meistens (immer?) wenn man den Bypass-Mode nicht explizit konfiguriert.
Mindestens bei den STM32L053 und STM32F030 fing dann irgendwann
die PLL zu "eiern" an.
Mann sollte es sich also nicht angewoehnen.
> > Jetzt fehlt noch das "easy-going" wie bei den STMs.
Das Eintragen von Speichermappings und Eigenschaften
und div. andere Dinge, die natuerlich der Komplexitaet
des Controllers (z.B. SH-3) geschuldet sind, kann einem
bei der Renesas-HEW schon den Nerv rauben.
Easy ist da auch nichts.
Vielleicht verirrt sich ein neuer RX ja auch mal zu mir.
Jemand eine Idee welche Genauigkeit (ppm) der 8 MHz Quarz des ST Link µC
hat?
Das Nucleo 64 Handbuch hat keine näheren Angaben. Oder wo ich etwas dazu
finden könnte, Datenblätter vom Quarz usw
Tom schrieb:> Jemand eine Idee welche Genauigkeit (ppm) der 8 MHz Quarz des ST Link µC> hat?
Geh mal von 50 - 100 ppm Abweichung bei Raumtemperatur aus.
> Im Nucleo64 Handbuch wird für den optionalen X3 Quartz 20> ppm empfohlen
Ja empfehlen kann man viel wenn der Tag lang ist. Das heisst aber noch
lange nicht, dass die selbst ihre eigenen Empfehlungen verwenden.
(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· schrieb im Beitrag
#4960512:
>> Funktionieren tut es aber wohl>> meistens (immer?) wenn man den Bypass-Mode nicht explizit konfiguriert.>> Mindestens bei den STM32L053 und STM32F030 fing dann irgendwann> die PLL zu "eiern" an.> Mann sollte es sich also nicht angewoehnen.
Gut zu wissen. Für mich roch das auch schon so ein bisschen nach Ärger
und hatte mich anfangs gewundert, dass es überhaupt funktioniert hat.
Naja, kostet ja nichts das vernünftig zu konfigurieren.
Hier noch eine kleine Ergänzung von mir.
Der obige Startup-Code erwartet, dass der Mikrocontroller mit einen HSE
hat. Ist dies nicht der Fall, wird in den Else-Zweig gesprungen statt
den PLL und alle weiteren Clocks (inkl. HCLK) zu konfigurieren.
Der Else-Zweig ist aber leer.
Wenn jemand die Hardware-Version "C-01" (µC hat kein HSE/LSE) besitzt
und den Quellcode von Eclipse verwendet hat zwei Möglichkeiten für
richtige Clocks:
-Die entsprechenden Lötbrücken auf dem Board schließen, um den ST-Link 8
MHz Quarz indirekt mit dem µC zu verbinden und einen HSE geben
-Die SetSysClock Funktion umschreiben, dass statt HSE der HSI mit dem
PLL usw. konfiguriert wird (Zeile 1011).
Mir will nicht einleuchten, warum im Startup-Code bei fehlendem HSE die
Clockkonfiguration abgebrochen wird.
Man könnte doch alternativ nach dem Timeout einfach alles mit HSI
konfigurieren ...
Vorallem ist der Startup Code gut versteckt in den system Ordner
WELCHER Startupcode denn? Da gibt es ja so viele verschiedene, da kommt
selbst das Hauseigene SW4STM mit drei verschiedenen Layer an (CMSIS, HAL
und StdPeriph) Dann kommt CubeMX um die Ecke welche ganze fünf Stück zur
Verfügung gibt... und da sind dann die ganzen Derivate ala CoIDE und
Keil noch nicht mal mit drinne.
Thread beobachten
Seitenaufteilung abschalten