STM32 HSE bypass mode

[Stefan F. (Gast)]

Es geht konkret um die Boards
* Nucleo64-L073RZ
* Nucleo64-F103RB
* Nucleo64-F303RE

Dort ist der HSE Oszillator nicht mit einem Quarz bestückt, sondern mit 
dem 8 MHz Taktausgang des ST-Link verbunden. Man sollte dann also wohl 
den "bypass mode" konfigurieren.

Allerdings ist mir aufgefallen, dass der HSE offenbar genau so gut ohne 
"bypass mode" funktioniert.

Leider konnte ich im Referenzhandbuch keine ausführliche Erklärung 
finden, was genau dieser komische "bypass mode" bewirkt. Außer dass man 
dann den frei gewordenen Pin als normalen I/O verwenden kann.

Ist das alles, oder gibt es noch mehr Unterschiede zwischen diesen 
beiden Modi?

[Koryphae (Gast)]

Eigene Beobachtung: Das funtioniert nur an geraden Tagen die
unmittlebar dem Vollmond folgen.

Das Bit ist nicht umsonst da!

[Stefan F. (Gast)]

Koryphae schrieb:
> Eigene Beobachtung: Das funtioniert nur an geraden Tagen die
> unmittlebar dem Vollmond folgen.

Hmm, bei meinen Versuchen funktionierte es immer, ohne Ausnahme. Ich 
benutze den bypass Modus nie weil meine Zielschaltungen vom ST-Link 
losgelöst funktionieren sollen, als mit Quarz.

Ach misst, ich habe das im falschen Forum gepostet. Hat der Forist noch 
gar nicht bemerkt. haha

[Koryphae (Gast)]

> bei meinen Versuchen funktionierte es immer

Dann waren deine Versuche wohl nicht vollstaendig.
Oder deine Messtechnik taugt nichts.
Oder ...

Hast du z.B. alle PLL-Multiplikatoren/Divisoren
vollstaendig durchpermutiert und die korrekte Funktion
der PLL getestet und nachgewiesen?

Das Bit ist nicht da um Platz zu verbrauchen!

[Stefan F. (Gast)]

Koryphae schrieb:
> Dann waren deine Versuche wohl nicht vollstaendig.

Mag sein, mir reicht ein funktionierendes USB Interface.

[Dr. MCU (Gast)]

Stefan ⛄ F. schrieb:
> Es geht konkret um die Boards
> * Nucleo64-L073RZ
> * Nucleo64-F103RB
> * Nucleo64-F303RE
>
> Dort ist der HSE Oszillator nicht mit einem Quarz bestückt, sondern mit
> dem 8 MHz Taktausgang des ST-Link verbunden. Man sollte dann also wohl
> den "bypass mode" konfigurieren.
>
> Allerdings ist mir aufgefallen, dass der HSE offenbar genau so gut ohne
> "bypass mode" funktioniert.
>
> Leider konnte ich im Referenzhandbuch keine ausführliche Erklärung
> finden, was genau dieser komische "bypass mode" bewirkt. Außer dass man
> dann den frei gewordenen Pin als normalen I/O verwenden kann.
>
> Ist das alles, oder gibt es noch mehr Unterschiede zwischen diesen
> beiden Modi?

Funktionieren tut das Ganze natürlich auch ohne die Aktivierung des 
Bypass Mode.
Den Bypass Mode aktiviert man, wenn man nicht möchte, dass OSC_OUT wild 
schwingt.

Man sollte allerdings das Reference Manual des verwendeten Controllers 
genau lesen, denn ST hat das nicht einheitlich gelöst und z.B. beim 
STM32F446 kann man den frei gewordenen Pin nicht als GPIO nutzen.

[Gerd E. (robberknight)]

Der Oszillatoreingang und der Takteingang im Bypass-Mode sind komplett 
andere Eingangsstrukturen. Der Oszillatoreingang ist ein Komparator, der 
Takteingang ein CMOS-Logikeingang.

Wenn Du jetzt einen 3.3V-CMOS-Pegel auf den Oszillatoreingang gibst, 
überfährst Du den Komparator komplett und treibst ihn damit in die 
Sättigung. Die Zeit bis er da wieder rauskommt ist länger und vermutlich 
auch nicht sauber getestet/spezifiziert, da das kein erwarteter 
Betriebsmodus ist.

Die Folge davon ist daß das vermutlich nicht für alle Takte funktioniert 
für die der Eingang spezifiziert ist und außerdem auch der Jitter höher 
sein dürfte.

[Stefan F. (Gast)]

Schade, dass so etwas nicht im Datenblatt steht. Vielleicht bin ich von 
Atmel (und früher auch Siemens) zu sehr verwöhnt.

[m.n. (Gast)]

Stefan ⛄ F. schrieb:
> Dort ist der HSE Oszillator nicht mit einem Quarz bestückt, sondern mit
> dem 8 MHz Taktausgang des ST-Link verbunden. Man sollte dann also wohl
> den "bypass mode" konfigurieren.

Den "bypass mode" aktiviere ich nur dann, wenn OSC-OUT als GPIO 
gebraucht wird, was nur bei kleinen Gehäusen mit wenig Pins der Fall 
ist.
"Ext. Quarz/Resonator" hat den Vorteil, daß man einen Quarz, einen TCXO 
mit 1 Vss oder auch den MCO eines ST-Link anschließen kann, ohne die 
RCC-Einstellungen zu ändern.

Gerd E. schrieb:
> Der Oszillatoreingang ist ein Komparator, der
> Takteingang ein CMOS-Logikeingang.

Nein. Das ist ein Inverter inkl. Widerstand (RF), wie es für Quarze 
üblich ist.

Stefan ⛄ F. schrieb:
> Schade, dass so etwas nicht im Datenblatt steht.

Im erwähnten F446 steht es im Datenblatt. Ansosnten weiß Mann das 
einfach ;-)

[Stefan F. (Gast)]

m.n. schrieb:
> Im erwähnten F446 steht es im Datenblatt. Ansosnten weiß Mann das
> einfach ;-)

Meinst du dieses?
https://www.st.com/resource/en/datasheet/stm32f446mc.pdf

Da steht genau das gleiche drin, wie bei den von mir genannten Chips. 
Nämlich so gut wie nichts. Vielleicht stelle ich mich beim Suchen blöd 
an, helfe mir mal auf die Sprünge.

[m.n. (Gast)]

"External CLock Source Characteristics" bei mir auf Seite 77 vom F303 
Datenblatt.

[Stefan F. (Gast)]

m.n. schrieb:
> "External CLock Source Characteristics" bei mir auf Seite 77 vom F303
> Datenblatt.

Danke, das deckt sich ziemlich mit dem Datenblatt vom F446. beide 
enthalten aber keine Infos dazu, welche Konsequenzen es haben könnte, 
den Oszillator mit einer externen Quelle (nicht Quarz) zu betreiben. Und 
der innere Aufbau des Oszillator ist auch nicht wirklich dargestellt, 
außer der eine Widerstand zwischen den Pins.

[Dr. MCU (Gast)]

https://www.st.com/resource/en/application_note/cd00221665-oscillator-design-guide-for-stm8afals-stm32-mcus-and-mpus-stmicroelectronics.pdf

[m.n. (Gast)]

Stefan ⛄ F. schrieb:
> beide
> enthalten aber keine Infos dazu, welche Konsequenzen es haben könnte,
> den Oszillator mit einer externen Quelle (nicht Quarz) zu betreiben.

Du wirst auch nirgends einen Hinweis finden, daß diese Chips als 
Babynahrung nicht geeignet sind.
STM32: "sind die zu stark für Dich, bist Du zu schwach" ;-)

[Stefan F. (Gast)]

Dr. MCU schrieb:
> Link zur AN2867

Danke!

Die Mathematik darin ist mir zu hoch, aber immerhin bestätigt das 
Dokument, dass der Oszillator genau so aufgebaut ist, wie bei AVR.

[Hans-Georg L. (h-g-l)]

Stefan ⛄ F. schrieb:
> m.n. schrieb:
>> "External CLock Source Characteristics" bei mir auf Seite 77 vom F303
>> Datenblatt.
>
> Danke, das deckt sich ziemlich mit dem Datenblatt vom F446. beide
> enthalten aber keine Infos dazu, welche Konsequenzen es haben könnte,
> den Oszillator mit einer externen Quelle (nicht Quarz) zu betreiben. Und
> der innere Aufbau des Oszillator ist auch nicht wirklich dargestellt,
> außer der eine Widerstand zwischen den Pins.

https://de.wikipedia.org/wiki/Pierce-Schaltung

[Jay K. (deeplyembedded)]

Hallo zusammen,

ich möchte dieses Thema nochmal hervor holen, da ich gerade genau zu 
dieser Thematik eine Beobachtung gemacht habe, welche für den ein oder 
anderen interessant sein kann:

Ich habe ein Nucleo-L010RB Board, OSC_IN vom STM32 wird mit dem 8MHz 
Ausgangstakt des STM8 vom STLink gefüttert.
Im STM32 habe ich die HSE aktiviert, diese füttert die PLL und es sollen 
32MHz Systemtakt heraus kommen.
Mir ist nun aber aufgefallen dass der Systick Timer um den Faktor 2 zu 
langsam läuft.
Nach der Prüfung aller Register habe ich das Oszi angeworfen und 
gesehen, dass am OSC_IN Pin des STM32 die 8MHz ankommen.
Am OSC_OUT Pin messe ich mit dem Oszi aber nur 4MHz.
Zu bemerken ist hier, dass das HSEBYP Bit NICHT gesetzt ist.
Es scheint also so, als würde der 8MHz Takt vom STLink vom 
HSE-Oszillator auf einen 4MHz Takt "herunter geteilt" werden.
Demnach ist es eben nicht egal, ob das HSEBYP Bit gesetzt ist oder 
nicht.

Nun wollte ich die Gegenprobe machen, habe das HSEBYP Bit gesetzt, 
jedoch laufe ich dann in einen HardFault. Nicht unmittelbar danach aber 
ein paar Codezeilen weiter.
Wenn ich mit dem Debugger steppe passiert der HardFault etwas später, 
aber er tritt auch auf.

Hat jemand eine Idee, woran das liegen könnte?
Anbei der Code der Clock Initialisierung

void Rcc_Init(void)
{
  uint32 xStartUpCnt_u32  = 0;
  uint32 xStateHse_u32  = 0;
  uint32 xStatePll_u32  = 0;
  uint32 xSrcSysClk_u32  = 0;

  LL_RCC_HSE_EnableBypass();
  /* Enable HSE */
  LL_RCC_HSE_Enable();

  /* Wait till HSE is ready and if Time out is reached exit */
  do
  {
    xStateHse_u32 = LL_RCC_HSE_IsReady();
    xStartUpCnt_u32++;
  } while((xStateHse_u32 == 0) && (xStartUpCnt_u32 != RCC_HSE_STARTUP_TOUT));

  if (LL_RCC_HSE_IsReady())
  {
    xStateHse_u32 = (uint32_t)0x01;
  }
  else
  {
    xStateHse_u32 = (uint32_t)0x00;
  }

  if (xStateHse_u32 == (uint32_t)0x01)
  {
      /* Select regulator voltage output Scale 1 mode, System frequency up to 32 MHz */
    LL_APB1_GRP1_EnableClock(RCC_APB1ENR_PWREN);

    while(0u != LL_PWR_IsActiveFlag_VOS());
      LL_PWR_SetRegulVoltageScaling(LL_PWR_REGU_VOLTAGE_SCALE1);
      while(0u != LL_PWR_IsActiveFlag_VOS());

      /* This configures the AHB clock */
      /* HCLK = SYSCLK / 1*/
      LL_RCC_SetAHBPrescaler(RCC_CFGR_PPRE1_DIV1);

      /* Set APB1 & APB2 prescaler*/
    LL_RCC_SetAPB1Prescaler(LL_RCC_APB1_DIV_1);
    LL_RCC_SetAPB2Prescaler(LL_RCC_APB2_DIV_1);

    /* Set up the PLL */
    LL_RCC_PLL_Disable();
    do
    {
      xStatePll_u32 = LL_RCC_PLL_IsReady();
    }
    while(0 != xStatePll_u32);

      /* Configure the main PLL */
      LL_RCC_PLL_ConfigDomain_SYS(RCC_CFGR_PLLSRC_HSE, RCC_CFGR_PLLMUL8, RCC_CFGR_PLLDIV2);

      /* Enable the main PLL */
      LL_RCC_PLL_Enable();
    do
    {
      xStatePll_u32 = LL_RCC_PLL_IsReady();
    }
    while(0 != xStatePll_u32);

    /* Select the PLL as new system clock source */
      LL_RCC_SetSysClkSource(RCC_CFGR_SW_PLL);

      /* Actively wait until PLL has become new system clock source*/
      do
      {
        xSrcSysClk_u32 = LL_RCC_GetSysClkSource();
      }while(RCC_CFGR_SWS != (RCC_CFGR_SWS_Msk & xSrcSysClk_u32));

      SystemCoreClockUpdate();

      /* Enable peripheral clocks */
      LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOA);
    LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOB);
    LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOC);

  }
  else
  {
    for(;;)
    {
      /*Errorhandling*/
    }
  }
}

[Stefan F. (Gast)]

Jay K. schrieb:
> Nun wollte ich die Gegenprobe machen, habe das HSEBYP Bit gesetzt,
> jedoch laufe ich dann in einen HardFault. Nicht unmittelbar danach aber
> ein paar Codezeilen weiter.

Ich glaube du musst vor dem Hochsetzen der Taktfrequenz die Latenz des 
Flash einstellen. Laut reference manual geht das so:

FLASH->ACR |= FLASH_ACR_LATENCY; /* (1) */
while ((FLASH->ACR & FLASH_ACR_LATENCY) == 0);

Oder mit der Funktion LL_FLASH_SetLatency()

[Jay K. (deeplyembedded)]

Hallo Stefan,

das war der entscheidende Hinweis!
Nun ist auch der Zusammenhang klar:
Ohne den Bypass der HSE lief der Oszillator und hat aus dem externen 
8MHz Rechteck einen 4MHz HSE Takt erzeugt. Damit bin ich durch meine PLL 
Settings bei 16MHz Systemtakt gelandet, der noch mit 0 Waitstates vom 
Flash funktioniert.
Das Device lief aber genau um den Faktor 2, den ich gemessen habe, zu 
langsam.

Mit aktivem Bypass war der Systemtakt bei den gewünschten 32MHz, durch 
die 0 Waitstates wurde aber Müll aus dem Flash gelesen und irgendwann 
hats dann geknallt durch eine falsch gelesene Instruction oder Adresse.

Vielen Dank für die schnelle Hilfe.