STM32 HSE bypass mode

Stefan F. Gast #6624688
Lesenswert?
• ▲
▼ 
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?
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Stefan F. Gast #6624728
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Koryphae Gast #6624801
Lesenswert?
• ▲
▼ 
> 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!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dr. MCU Gast #6624904
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Gerd E. #6624941
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
m.n. Gast #6624963
Lesenswert?
• ▲
▼ 
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 ;-)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan F. Gast #6624976
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
m.n. Gast #6624999
Lesenswert?
• ▲
▼ 
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" ;-)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Hans-Georg L. #6628731
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jay K. #7161859
Lesenswert?
• ▲
▼ 
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

1
void Rcc_Init(void)

2
{

3
  uint32 xStartUpCnt_u32  = 0;

4
  uint32 xStateHse_u32  = 0;

5
  uint32 xStatePll_u32  = 0;

6
  uint32 xSrcSysClk_u32  = 0;

7


8
  LL_RCC_HSE_EnableBypass();

9
  /* Enable HSE */

10
  LL_RCC_HSE_Enable();

11


12
  /* Wait till HSE is ready and if Time out is reached exit */

13
  do

14
  {

15
    xStateHse_u32 = LL_RCC_HSE_IsReady();

16
    xStartUpCnt_u32++;

17
  } while((xStateHse_u32 == 0) && (xStartUpCnt_u32 != RCC_HSE_STARTUP_TOUT));

18


19
  if (LL_RCC_HSE_IsReady())

20
  {

21
    xStateHse_u32 = (uint32_t)0x01;

22
  }

23
  else

24
  {

25
    xStateHse_u32 = (uint32_t)0x00;

26
  }

27


28
  if (xStateHse_u32 == (uint32_t)0x01)

29
  {

30
      /* Select regulator voltage output Scale 1 mode, System frequency up to 32 MHz */

31
    LL_APB1_GRP1_EnableClock(RCC_APB1ENR_PWREN);

32


33
    while(0u != LL_PWR_IsActiveFlag_VOS());

34
      LL_PWR_SetRegulVoltageScaling(LL_PWR_REGU_VOLTAGE_SCALE1);

35
      while(0u != LL_PWR_IsActiveFlag_VOS());

36


37
      /* This configures the AHB clock */

38
      /* HCLK = SYSCLK / 1*/

39
      LL_RCC_SetAHBPrescaler(RCC_CFGR_PPRE1_DIV1);

40


41
      /* Set APB1 & APB2 prescaler*/

42
    LL_RCC_SetAPB1Prescaler(LL_RCC_APB1_DIV_1);

43
    LL_RCC_SetAPB2Prescaler(LL_RCC_APB2_DIV_1);

44


45
    /* Set up the PLL */

46
    LL_RCC_PLL_Disable();

47
    do

48
    {

49
      xStatePll_u32 = LL_RCC_PLL_IsReady();

50
    }

51
    while(0 != xStatePll_u32);

52


53
      /* Configure the main PLL */

54
      LL_RCC_PLL_ConfigDomain_SYS(RCC_CFGR_PLLSRC_HSE, RCC_CFGR_PLLMUL8, RCC_CFGR_PLLDIV2);

55


56
      /* Enable the main PLL */

57
      LL_RCC_PLL_Enable();

58
    do

59
    {

60
      xStatePll_u32 = LL_RCC_PLL_IsReady();

61
    }

62
    while(0 != xStatePll_u32);

63


64
    /* Select the PLL as new system clock source */

65
      LL_RCC_SetSysClkSource(RCC_CFGR_SW_PLL);

66


67
      /* Actively wait until PLL has become new system clock source*/

68
      do

69
      {

70
        xSrcSysClk_u32 = LL_RCC_GetSysClkSource();

71
      }while(RCC_CFGR_SWS != (RCC_CFGR_SWS_Msk & xSrcSysClk_u32));

72


73
      SystemCoreClockUpdate();

74


75
      /* Enable peripheral clocks */

76
      LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOA);

77
    LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOB);

78
    LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOC);

79


80
  }

81
  else

82
  {

83
    for(;;)

84
    {

85
      /*Errorhandling*/

86
    }

87
  }

88
}
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan F. Gast #7161899
Lesenswert?
• ▲
▼ 
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:
1
FLASH->ACR |= FLASH_ACR_LATENCY; /* (1) */

2
while ((FLASH->ACR & FLASH_ACR_LATENCY) == 0);


Oder mit der Funktion LL_FLASH_SetLatency()
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jay K. #7161990
Lesenswert?
• ▲
▼ 
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.
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren