Nucleo64 -STM32L476RG Problem mit HSE-Clock

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

Hallo,
wenn ich in CubeMx den RCC Code für HAL generiere funktioniert ein 
einfaches blinken in der main einwandfrei. Sobald ich den RCC Code für 
LL generiere startet die HSE nicht und bleibt hängen.

Was ich im Internet gefunden habe trifft alles nicht zu.

Gibt es bei den LowPower Versionen noch irgend einen anderen Trick ?
Auch das aktivieren des Clock Sicherheitssytems bringt nichts.
Am Board kann es auch nicht liegen, sonst würde es mit der HAL nicht 
funktionieren.


// hier der erzeugte LL code

main.c

  LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_SYSCFG);
 
  // das sollte doch genügen 
  LL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_PWR); 

  NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);

  SystemClock_Config();

  MX_GPIO_Init();

  while (1)
  {
  LL_GPIO_SetOutputPin(LD2_GPIO_Port, LD2_Pin);
  LL_mDelay (500);
  LL_GPIO_ResetOutputPin(LD2_GPIO_Port, LD2_Pin);
  LL_mDelay (500);
  }

}


void SystemClock_Config(void)
{

  LL_FLASH_SetLatency(LL_FLASH_LATENCY_4);
  while(LL_FLASH_GetLatency()!= LL_FLASH_LATENCY_4)
  {

  }
  LL_PWR_SetRegulVoltageScaling(LL_PWR_REGU_VOLTAGE_SCALE1);

  LL_RCC_HSE_EnableBypass();
  LL_RCC_HSE_Enable();

//!!!! hier bleibt er hängen !!!!!!!! 

   /* Wait till HSE is ready */
  while(LL_RCC_HSE_IsReady() != 1)
  {
    Error_Handler();
  }
  LL_RCC_PLL_ConfigDomain_SYS(LL_RCC_PLLSOURCE_HSE, LL_RCC_PLLM_DIV_1, 20, 
  LL_RCC_PLLR_DIV_2);
  LL_RCC_PLL_EnableDomain_SYS();
  LL_RCC_PLL_Enable();

   /* Wait till PLL is ready */
  while(LL_RCC_PLL_IsReady() != 1)
  {

  }
  LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_PLL);

   /* Wait till System clock is ready */
  while(LL_RCC_GetSysClkSource() != LL_RCC_SYS_CLKSOURCE_STATUS_PLL)
  {

  }
  LL_RCC_SetAHBPrescaler(LL_RCC_SYSCLK_DIV_1);
  LL_RCC_SetAPB1Prescaler(LL_RCC_APB1_DIV_1);
  LL_RCC_SetAPB2Prescaler(LL_RCC_APB2_DIV_1);

  LL_Init1msTick(80000000);

  LL_SetSystemCoreClock(80000000);
  LL_RCC_SetUSARTClockSource(LL_RCC_USART3_CLKSOURCE_PCLK1);
}

[pegel (Gast)]

Was mir auffällt ist das
Error_Handler(); bei while(LL_RCC_HSE_IsReady() != 1) .

Er soll doch einfach nur warten und nicht in den Error_Handler gehen, 
oder?

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

pegel schrieb:
> Was mir auffällt ist das
> Error_Handler(); bei while(LL_RCC_HSE_IsReady() != 1) .
>
> Er soll doch einfach nur warten und nicht in den Error_Handler gehen,
> oder?

Im Normal Fall ja, aber ich hab zum Testen die LED in der main Schleife 
langsam blinken lassen und im Error Handler schnell blinken lassen um zu 
sehen ob es vielleicht am Debugger liegt aber da kommt er auch im 
Run-Mode nicht hin weil einfach das HSE-Ready bit nicht gesetzt wird.
Auch das zusätzliche setzen des Clock-Enable vom Port H (HSE Oszillator 
Eingang) hat nichts gebracht.

Habe mir jetzt die neueste CubeIde heruntergeladen ... das gleiche 
Spielchen. Mit einem STMF446 Nucleo64 Board funktioniert alles bestens.
Das scheint echt an der L-Version zu liegen.

Ein Register Vergleich zwischen HAL und LL Version von RCC und Power 
Registern im Debugger hat auch nichts neues ergeben.

[pegel (Gast)]

Hans-Georg L. schrieb:
> und im Error Handler schnell blinken lassen

Als Endlosschleife?
Bedeutet dann aber, dass LL_RCC_HSE_IsReady() niemals Ready wird.

[pegel (Gast)]

Sind auf dem Board alle Jumper richtig?
Also Bypass des MCO vom ST-Link, kein HSE Quarz?

[pegel (Gast)]

Ich habe einfach mal ein Blinky gebaut, ohne viele Änderungen.
Einfach Bypass in LL.
Kannst ja mal probieren.

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

pegel schrieb:
> Hans-Georg L. schrieb:
>> und im Error Handler schnell blinken lassen
>
> Als Endlosschleife?
> Bedeutet dann aber, dass LL_RCC_HSE_IsReady() niemals Ready wird.

Vergiss den Error Handler der ist schon lange wieder raus

Das Board ist ok die RCC-HAL Version funktioniert ja.

>Ich habe einfach mal ein Blinky gebaut, ohne viele Änderungen.
> Einfach Bypass in LL.
 Was hast du ausser :

  LL_RCC_HSE_EnableBypass();
  LL_RCC_HSE_Enable();

noch gemacht ?

Ein bin bringt mich nicht weiter ...

[pegel (Gast)]

Läufts denn?

[pegel (Gast)]

Hans-Georg L. schrieb:
> Ein bin bringt mich nicht weiter ...

Es hat einen Grund, weshalb ich das Erstellt habe.
Mir ist da etwas aufgefallen ...

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

pegel schrieb:
> Läufts denn?

Nein läuft auch nicht.

[pegel (Gast)]

Gut.
Dann hat sich meine Theorie nicht bestätigt.

Ich hatte etwas mit den Pins bei der Graphischen Darstellung vermutet,
aber bevor ich die Software beschuldige wollte ich lieber eine 
Bestätigung.

[Stefan F. (Gast)]

Wenn du den ST-Link nicht abgetrennt hast, ist der externe Takteingang 
(HSE) mit dem Taktausgang des ST-Link verbunden. Hast du versucht, einen 
Quarz anzuschließen, oder wie ist deine Schaltungstechnische Situation?

In deinem Code sehe ich spontan keinen Fehler, deswegen frage wegen der 
Hardware nach.

[pegel (Gast)]

Ich denke wenn HAL funktioniert, ist es Zeit sich die LL Beispiele 
anzusehen.

~/STM32Cube/Repository/STM32Cube_FW_L4_V1.16.0/Projects/NUCLEO-L476RG/Ex 
amples_LL/

Vielleicht:
RCC/RCC_UseHSEasSystemClock
?

[Stefan F. (Gast)]

pegel schrieb:
> Ich denke wenn HAL funktioniert, ist es Zeit sich die LL Beispiele
> anzusehen.

Ich glaube der Code von der HAL fällt automatisch auf den HSI zurück, 
wenn der HSE nicht startet.

Siehe 
https://github.com/STMicroelectronics/STM32CubeL4/blob/master/Drivers/STM32L4xx_HAL_Driver/Inc/stm32l4xx_hal_conf_template.h 
Zeile 102

[pegel (Gast)]

Stefan ⛄ F. schrieb:
> Ich glaube der Code von der HAL fällt automatisch auf den HSI zurück,
> wenn der HSE nicht startet.

Das könnte man am MCO testen.
HSE->Frequenz stabil
HSI->Frequenz geht so

[m.n. (Gast)]

Stefan ⛄ F. schrieb:
> Ich glaube der Code von der HAL fällt automatisch auf den HSI zurück,
> wenn der HSE nicht startet.

Beim Umschalten auf HSE muß man doch zuvor testen, ob der Takt überhaupt 
vorhanden ist. Kann man da nicht gezielt breakpoints setzen, um zu 
sehen, wo es hakt? Selber habe ich hier keine L-Version zu liegen.

[Stefan F. (Gast)]

m.n. schrieb:
> Beim Umschalten auf HSE muß man doch zuvor testen, ob der Takt überhaupt
> vorhanden ist. Kann man da nicht gezielt breakpoints setzen, um zu
> sehen, wo es hakt?

Das hat der TO ja gemacht. Und es hakt daran, dass der HSE nicht "ready" 
meldet.

Bei HAL Code könnte man nach dem Startup die Register (RCC_PLLSOURCE) 
auslesen um zu sehen, ob er nun auf HSE läuft, oder auf HSI zurück 
gefallen ist.

[Johannes S. (Gast)]

Es gibt kein zurückfallen auf HSI im HAL. Wenn Timeout, dann Fehler. Den 
kann man selber behandeln im SystemClockInit.

https://github.com/ARMmbed/mbed-os/blob/2f87d59c7f2eed226ff82df72d2724b0ac122177/targets/TARGET_STM/TARGET_STM32L4/STM32Cube_FW/STM32L4xx_HAL_Driver/stm32l4xx_hal_rcc.c#L559-L566

Aber warum tut man sich das mit LL überhaupt an? Damit der Controller 
vielleicht eine μs schneller startet? Ist der Speicher voll und man 
erhofft sich eine Handvoll Bytes zu sparen? Und dafür das ganze Wissen 
das in HAL steckt ignorieren?

Edit:
ich sehe da aber auch keinen grossen Unterschied, wenn im HAL code nicht 
noch irgendwelche andere pwr oder clocks eingeschaltet werden. Wenn der 
HAL Code mit CubeMX generiert wurde, wie sieht da das clock init und low 
level init aus?

[Stefan F. (Gast)]

Johannes S. schrieb:
> Es gibt kein zurückfallen auf HSI im HAL. Wenn Timeout, dann Fehler.

Ja Ok. In diesem Fall bleibt er auf HSI, denn das ist der von der 
Hardware vorgegebene Default.

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

Johannes S. schrieb:
> Aber warum tut man sich das mit LL überhaupt an? Damit der Controller
> vielleicht eine μs schneller startet? Ist der Speicher voll und man
> erhofft sich eine Handvoll Bytes zu sparen? Und dafür das ganze Wissen
> das in HAL steckt ignorieren?
>
Ich habe es einfach mal ausprobiert ein funktionierendes Programm von 
HAL auf LL um zu stellen und mich gewundert das es nicht funktioniert. 
Dann habe ich alles auf ein Blinky reduziert mit dem gleichen Ergebnis.

Der Cube Mx generierte Code funktioniert für LL und HAL auf einem 
STM476RE einwandfrei. Auf einem STML476RG funktioniert der generierte LL 
Code nicht.
Beides habe ich auf den jeweiligen Nucleo64 Boards getestet.

[Johannes S. (Gast)]

Hans-Georg L. schrieb:
> Ich habe es einfach mal ausprobiert

gut, probieren darf man :)

Hier ist noch ein LL Beispiel, das HSE Timeout sieht etwas anders aus:
https://github.com/STMicroelectronics/STM32CubeL4/blob/master/Projects/NUCLEO-L476RG/Examples_LL/RCC/RCC_UseHSEasSystemClock/Src/main.c

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

Die L Versionen funktionieren etwas anders als die F -Versionen.

Da kann man jede Kleinigkeit abschalten um Strom zu sparen und für den 
Ausfall des Clocks gibt es das Clock security system (CSS) damit kann 
man auf einen anderen Clock bei Ausfall HSE umschalten. Das wird im 
CUBEx LL und HAL Code nicht aktiviert.

Auszug aus dem Ref. Manual:

6.2.10
Clock security system (CSS)
Clock Security System can be activated by software. In this case, the 
clock detector is
enabled after the HSE oscillator startup delay, and disabled when this 
oscillator is stopped.
If a failure is detected on the HSE clock, the HSE oscillator is 
automatically disabled, a clock
failure event is sent to the break input of the advanced-control timers 
(TIM1/TIM8 and
TIM15/16/17) and an interrupt is generated to inform the software about 
the failure (Clock
Security System Interrupt CSSI), allowing the MCU to perform rescue 
operations. The CSSI
is linked to the Cortex®-M4 NMI (Non-Maskable Interrupt) exception 
vector.
Note:
Once the CSS is enabled and if the HSE clock fails, the CSS interrupt 
occurs and a NMI is
automatically generated. The NMI will be executed indefinitely unless 
the CSS interrupt
pending bit is cleared. As a consequence, in the NMI ISR user must clear 
the CSS interrupt
by setting the CSSC bit in the Clock interrupt clear register 
(RCC_CICR).
If the HSE oscillator is used directly or indirectly as the system clock 
(indirectly means: it is
used as PLL input clock, and the PLL clock is used as system clock), a 
detected failure
causes a switch of the system clock to the MSI or the HSI16 oscillator 
depending on the
STOPWUCK configuration in the Clock configuration register (RCC_CFGR), 
and the
disabling of the HSE oscillator. If the HSE clock (divided or not) is 
the clock entry of the PLL
used as system clock when the failure occurs, the PLL is disabled too.

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

Johannes S. schrieb:
> Hans-Georg L. schrieb:
>> Ich habe es einfach mal ausprobiert
>
> gut, probieren darf man :)
>
> Hier ist noch ein LL Beispiel, das HSE Timeout sieht etwas anders aus:
> 
https://github.com/STMicroelectronics/STM32CubeL4/blob/master/Projects/NUCLEO-L476RG/Examples_LL/RCC/RCC_UseHSEasSystemClock/Src/main.c

Wenn man bei dem Beispiel die Timeout Überwachung weglässt wird da nur 
vor dem Umschalten das Clock security system (CSS) zusätzlich aktiviert.

Mich interessiert im Moment nicht die Fehlerbehandlung sondern nur warum 
der HSE beim LL Code nicht startet.

[Johannes S. (Gast)]

Das CSS sollte aber optional sein. Es wird in dem o.g. Beispiel auch 
verwendet, kann man ja mal auskommentieren. Im HAL Code ist es ja auch 
nicht per default drin bzw. wird aktiviert wenn man es in der clock 
config mit EnableCSS einschaltet.

was da auch ein bisschen beim Testen hilft ist der MCO, kann man HSE da 
drauf legen?

[pegel (Gast)]

Ich habe mit einem L053 ein Blinky gebaut.
Funktioniert wie gewohnt.

Der Code sieht dem des L4 sehr ähnlich.

[Stefan F. (Gast)]

Hans-Georg L. schrieb:
> Mich interessiert im Moment nicht die Fehlerbehandlung sondern nur warum
> der HSE beim LL Code nicht startet.

Hinterfrage doch erstmal, ob der HSE beim anderen Code wirklich 
aktiviert wurde? Weil: Wenn nicht, dann könnte es ein Hardwareproblem 
sein.

Du hast meine Rückfrage zur Schaltung noch nicht beantwortet. Was hast 
du an die HSE Pins angeschlossen und was hast du von ihnen abgetrennt?

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

Johannes S. schrieb:
> Das CSS sollte aber optional sein. Es wird in dem o.g. Beispiel auch
> verwendet, kann man ja mal auskommentieren. Im HAL Code ist es ja auch
> nicht per default drin bzw. wird aktiviert wenn man es in der clock
> config mit EnableCSS einschaltet.
>
Das sehe ich auch so. Ok ich könnte es aktivieren und schauen ob der 
Interrupt vom CSS kommt.

> was da auch ein bisschen beim Testen hilft ist der MCO, kann man HSE da
> drauf legen?

Ja das geht.

Aber ich denke das der Clock aus irgend einem Grunde nicht ankommt und 
einfach nicht läuft sonst müsste ja irgendwann das Ready Bit kommen.

Der Osc Eingang wird nirgends umprogrammiert und steht wie er soll auf 
AnalogInput.

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

Stefan ⛄ F. schrieb:
> Hans-Georg L. schrieb:
>> Mich interessiert im Moment nicht die Fehlerbehandlung sondern nur warum
>> der HSE beim LL Code nicht startet.
>
> Hinterfrage doch erstmal, ob der HSE beim anderen Code wirklich
> aktiviert wurde? Weil: Wenn nicht, dann könnte es ein Hardwareproblem
> sein.
>
> Du hast meine Rückfrage zur Schaltung noch nicht beantwortet. Was hast
> du an die HSE Pins angeschlossen und was hast du von ihnen abgetrennt?

Stefan lies doch mal ;-)

Das gleiche Board (Hardware) läuft mit dem gleichen Code nur mit dem 
Unterschied das die RCC Configuration einmal mit HAL und einmal mit LL 
erzeugt wird. An den Pins ist da nichts geändert der HSE Takt kommt 
immer von STLink mit 8Mhz.

Wenn ich mit dem Debugger durch steppe und mir die Register anschaue ist 
bei beiden Versionen das Bypass und das Enable Bit vom HSE gesetzt.

[Stefan F. (Gast)]

Dein Cube HAL Code wartet eine gewisse Zeit, bis der HSE Oszillator 
ready ist. Und nur dann schaltet er auf diesen Oszillator um. Wenn 
nicht, läuft das Board weiter durch HSI getaktet.

Dein LL Code wartet für immer darauf, dass der HSE Oszillator ready 
wird. Wenn der Oszillator nicht ready wird, bleibt er an dieser Stelle 
hängen.

Zur Kontrolle ist also uninteressant, ob der HSE eingeschaltet wurde. 
Das ist auf jeden Fall bei beiden Codes der Fall. Interessanter ist, ob 
der Cube HAL Code in den Timeout gelaufen ist. Prüfe dazu folgende Flags 
vom RCC:

SWS: Set and cleared by hardware to indicate which clock source is used 
as system clock.

Wenn SWS=PLL ist, dann prüfe dessen Quelle in:

PLLSRC: Main PLL, PLLSAI1 and PLLSAI2 entry clock source

Ich vermute, dass entweder SWS=HSI16 ist, oder SWS=PLL und PLLSRC=HSI16. 
Da wäre die Situation nach einem Timeout.

[Johannes S. (Gast)]

Stefan ⛄ F. schrieb:
> Prüfe dazu folgende Flags
> vom RCC:

das kann man einfacher haben weil HAL_RCC_OscConfig() dann mit 
HAL_TIMEOUT zurück kommt, siehe meinen github Link. Und im Fehlerfall 
läuft der Cube Code normalerweise in einen Errorhandler.
Der ist default allerdings leer und der Code wird fröhlich weiter 
ausgeführt.

[Johannes S. (Gast)]

aus dem Errata:

PH0/PH1 is controlled by the GPIOH registers when HSE is enabled
Description
The PH0 and PH1 GPIO configuration is not bypassed when the HSE is enabled. The
oscillator can stop if the I/Os are not configured in analog mode.
Workaround
PH0 and PH1 must be configured in analog mode (reset value) when HSE is enabled.

verstehe ich so das PH default ok ist, aber da muss dann doch sicher PH 
clock aktiviert werden?

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

Johannes S. schrieb:
> aus dem Errata:
>

> PH0/PH1 is controlled by the GPIOH registers when HSE is enabled
> Description
> The PH0 and PH1 GPIO configuration is not bypassed when the HSE is 
> enabled. The
> oscillator can stop if the I/Os are not configured in analog mode.
> Workaround
> PH0 and PH1 must be configured in analog mode (reset value) when HSE is 
> enabled.
>

>
> verstehe ich so das PH default ok ist, aber da muss dann doch sicher PH
> clock aktiviert werden?

Hatte ich schon probiert und geprüft das PH0 und PH1 auf Analog input 
sind.
Das war es leider auch nicht.

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

Ich habe jetzt mal bei mir den Code von dem LL Beispiel 
RCC_UseHSEasSystemClock eingebaut und er läuft wie erwartet in das 
Timeout und blinkt als Fehlercode.
Das ist zwar schön, der Fehler wird jetzt behandelt ... aber nicht die 
Frage wie macht man es richtig mit der LL ohne in den Timeout zu laufen 
;-)

[Stefan F. (Gast)]

Also hatte ich Recht, dass dein HSE Oszillator nicht funktioniert.

> wie macht man es richtig mit der LL ohne in den Timeout zu laufen

Indem man den Hardwarefehler korrigiert.

[pegel (Gast)]

Hast Du kein Oszi oder Frequenzzähler?
Damit kannst Du Prüfen, ob am Pin5 überhaupt etwas ankommt.

[pegel (Gast)]

Bzw. Stiftleiste links außen Pin 29, PH0.

[pegel (Gast)]

Das mit der Stiftleiste nehme ich zurück, weil:
SB55 Default:open

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

Es hat sich geklärt ...

Stefan, du hattest doch recht !
Und auch alle anderen die darauf getippt haben.

Warum allerdings von 4 Nucleo144 und 2 Nucleo64 Bords die ich hier habe 
ausgerechnet eines den HSE Clock anders configuriert hat verstehe ich 
auch nicht so richtig. Die sind alle neu und es war auch nicht zu 
erkennen, das da jemand herum gelötet hat.
Vertrauen ist gut Kontrolle ist besser ;-)

Messen kann man den Takt, bei den Nucleo Boards am besten an der nicht 
bestückten Brücke zum externen HSE Quarz.

Bei so schnell mal was testen vergisst man oft die Fehlerbehandlung und 
das hat sich hier gerächt ...