RCC_CR.HSEBYP not reset by Software Reset

[waclawek.jan]

Experimenting with STM32F427 and STM32F446 I found out, that the RCC_CR.HSEBYP bit is *not* reset by Software reset. It is reset only by NRST and Power-On reset.

While applications where this could lead to problems (i.e. where HSE clock source is changed on-the-fly and software after performing Software reset relies on reset state of this bit) are probably very rare, it may result in an "interesting" surprise if one stumbles upon it, and deserves to be documented.

Can ST please confirm/explain and document?

Thanks,

JW

[TDK]

Confirmed on an STM32F429 as well. Weird. HSEON behaves as expected. HSEBYP does not.

[waclawek.jan]

Thanks for confirming this.

JW

 

[mƎALLEm]

Hello,

---

@waclawek.jan wrote:

It is reset only by NRST 

---

I've just tested it: even with NRST, RCC_CR.HSEBYP = 1 after reset. 

It's reset only after Power on reset. 

Could you test again and confirm?

[waclawek.jan]

I've just tested it: even with NRST, RCC_CR.HSEBYP = 1 after reset.

It's reset only after Power on reset.

I've retested, and indeed, NRST did not reset HSEBYP.

I don't remember what did I do differently last time, so that I came to that conclusion. It even might have been a different revision of the 'F427. I also don't have the 'F446 hardware at hand to try.

Nonetheless, it's still something which may deserve to be investigated deeper and documented.

Thanks,

JW

[mƎALLEm]

I will raise that behavior internally. I'll get back to you for any news. Internal ticket number for follow-up: 223857 

Thank you

[mƎALLEm]

Hello @waclawek.jan 

I've got an internal feedback regarding your question:

The HSEBYP bit is reset only during a Power-On Reset (POR) and not during a regular system reset. This is because when an application uses the HSE_BYPASS mode, if a reset occurs, the entire RCC and RESET block must maintain an active clock source to ensure that the STM32 microcontroller can restart properly.
Afterwards, the internal clock (such as the HSI) will be automatically selected as the default clock upon restart. This mechanism acts as a protection for the clock source in case of an external reset (NRST pin). Without the propagation of a valid clock source, the STM32 restart would be compromised.
This behavior is common to all STM32 families, and the RCC block design is implemented accordingly.

We are discussing on whether this behavior will be documented and how.

Hope that answers your question

 

[waclawek.jan]

Hi @mƎALLEm ,

Thanks for the explanation.

> We are discussing on whether this behavior will be documented and how.

How is "whether" a question at all?

And isn't the description of RCC_CR.HSEBYP bit in the RCC registers subchapter the right place to document it?

On this note, it would also be nice to have a list of all peripheral registers bits throughout the whole STM32, which are not uniformly reset by all reset sources.

JW

 

[mƎALLEm]

Hello,

I understand your standpoint but I cannot commit at this moment on whether it will be updated on the documentation. This is a decision that needs to be taken by internal teams. knowing that it's a behavior that is shared by all STM32 not in one STM32 family. 

I will keep you informed by the decision when it is taken.