Inquiry regarding the RCC_OscInitStruct.HSEState setting.

[Daecheol]

Hello,

I am using the Nucleo-H767ZI board. On this board, I am working with both a version that uses an external oscillator and one that does not. My question is whether it is normal for the firmware to work regardless of the following settings:

RCC_OscInitStruct.HSEState = RCC_HSE_ON; // Version with external oscillator

RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS; // Version without external oscillator

As far as I know, the system should not work if these settings differ depending on whether the external oscillator is present or not. However, in my current situation, the system works regardless of these settings. I've seen cases where it doesn't work, but most of the time it functions without issues, even with different settings.

I would like to know if it is acceptable to use these settings when they differ.

Thank you.

[Andrew Neil]

Sounds like it's never actually using the external source at all, but always using an internal source.

---

@Daecheol wrote:

On this board, I am working with both a version that uses an external oscillator (sic?) and one that does not. .

---

Do you actually mean an external oscillator, or just an external crystal ?

---

@Daecheol wrote:

RCC_OscInitStruct.HSEState = RCC_HSE_ON; // Version with external oscillator

---

That would be the setting for an external crystal - not an external oscillator.

---

@Daecheol wrote:

RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS; // Version without external oscillator

---

That would be the setting for an external oscillator.

Addendum - on "oscillator" vs "crystal":

https://community.st.com/t5/stm32-mcus-products/stm32f4-osc-problem/m-p/663214/highlight/true#M241308

https://community.st.com/t5/stm32-mcus-products/stm32f4-osc-problem/m-p/663588/highlight/true#M241449

https://community.st.com/t5/stm32-mcus-products/stm32f4-osc-problem/m-p/664136/highlight/true#M241592 

[Daecheol]

Hello,

Andrew.

Thank you for your response.

It seems there may have been some misunderstanding in my previous message. The component is a crystal, not an oscillator. I understand that the default setting for the Nucleo-F767ZI board is to use the clock output from the X1 on the ST-LINK. I am not sure if this clock is from an oscillator or a crystal, but when using this default setting,

I set RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;.

When I attach a crystal to X3, I set RCC_OscInitStruct.HSEState = RCC_HSE_ON;

What I’m curious about is whether it’s normal for the system to work properly regardless of which of the above two settings is used, whether the board has a crystal attached to X3 or is used in the default configuration without the crystal.

Thank you.

[Andrew Neil · Accepted solution]

---

@Daecheol wrote:

I understand that the default setting for the Nucleo-F767ZI board is to use the clock output from ...  the ST-LINK.

---

That is generally the case on Nucleo boards.

---

@Daecheol wrote:

I am not sure if this clock is from an oscillator or a crystal

---

As far as the STM32H767ZI is concerned, that's irrelevant - it's just an externally-generated clock signal.

---

@Daecheol wrote:

when using this default setting,

I set RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;..

---

That's correct - you are bypassing the oscillator circuitry of the STM32H767ZI, and just feeding in a "ready-cooked" clock signal.

---

@Daecheol wrote:

When I attach a crystal to X3, I set RCC_OscInitStruct.HSEState = RCC_HSE_ON;

---

That's correct - in this case, you are using the internal oscillator circuitry of the STM32H767ZI to generate your clock signal.

---

@Daecheol wrote:

What I’m curious about is whether it’s normal for the system to work properly regardless of which of the above two settings is used, whether the board has a crystal attached to X3 or is used in the default configuration without the crystal.

---

If you use the wrong one, the HSE won't work - but the chip can "fall-back" to using an internal oscillator.

[TDK]

By default, the chip can use an 8 MHz signal (HSE bypass) that comes from the ST-Link.

If you solder X3, you need to also open SB149 and close SB8 and SB9 in order to use the HSE. Otherwise, your crystal is not actually connected to anything and trying to use it will result in the chip using the HSE Bypass signal instead.

> What I’m curious about is whether it’s normal for the system to work properly regardless of which of the above two settings is used, whether the board has a crystal attached to X3 or is used in the default configuration without the crystal.

If a (bypass) clock signal is present, as in the default configuration, generally either setting will work.

If a crystal is present, only RCC_HSE_ON will work.

(As a note, the 8 MHz signal coming from the ST-Link is from its internal HSI default, but it can be changed by the st-link firmware updater to use HSE at 8.333 MHz.)

[Daecheol]

If the HSEState setting is incorrect when using an external crystal (X3), you mentioned that the HSI will operate.

Does this mean that the internal oscillator is used as a backup even if you haven't explicitly set to use the HSI in the code? 

So does this mean that the SYSCLK, which was set according to the HSE, will be adjusted differently based on the HSI RC clock?

Thank You.

[Daecheol]

If using X3, I am following the guide provided in the UM1974 document.

HSE on-board oscillator from X3 crystal (not provided): for typical frequencies and
its capacitors and resistors, refer to the STM32 microcontroller datasheet and to the
Oscillator design guide for STM8S, STM8A and STM32 microcontrollers Application
note (AN2867) for the oscillator design guide. The X3 crystal has the following
characteristics: 8 MHz, 8 pF, 20 ppm. It is recommended to use NX3225GD-8.000MEXS00A-
CG04874 manufactured by NIHON DEMPA KOGYO CO., LTD. The
configuration must be:
– SB148 and SB163 OFF
– SB8 and SB9 ON
– C37 and C38 soldered with 4.3 pF capacitors
– SB112 and SB149 OFF

In this case, even if I set HSEState to RCC_HSE_BYPASS, the Nucleo-F767ZI operates normally.

Thank you.

[TDK]

If you don't have an error handler implemented, the call to change the clock will fail but the call to Error_Handler will just return and the clock will be unchanged. Whether that allows "normal" operation or not depends on what your code is doing, but it will not be using HSE bypass if the clock signal is not present.

Should be able to debug your code and step through to understand what is happening.