changed the stm32f1xx_hal_rcc.c to handle the HSE init properly

[LordGuilly]

changed the stm32f1xx_hal_rcc.c to handle the HSE init properly when BYPASS is done before XTAL

Description

after issue #4753 and first PR #4755 , this would be a proposed more general solution

Status

READY

Migrations

If this PR changes any APIs or behaviors, give a short description of what API users should do when this PR is merged.

NO

Related PRs

#4755

Todos

• Tests
• Documentation

Deploy notes

Haven'f fully tested (because my board is fixed with the define config!), but it's essentially the changes pulled out from #4755 done in a different way, to make it follow the issues flagged by the ST drivers team

Steps to test or reproduce

[jeromecoutant]

Hi
It's quite hard to change this file...

If you look at the header of this HAL_RCC_OscConfig function, we can read:
"Transition HSE Bypass to HSE On and HSE On to HSE Bypass are not supported by this macro."

So you tried to solve the transition HSE Bypass to HSE On, but what about the other way...?

My second point is the deep sleep procedure, because SetSysClock is called again. We are wondering if resetting the HSE is correct or not.

@bcostm @LMESTM @adustm

[LordGuilly]

Hi,
this was a tentative "general" fix for the issue reported in the other PR.
I missed that comment, but given the init sequence is Bypass/HSI/HSI, not sure if the HSE to bypass will ever be a real use case. (Actually I don't see much sense in the current init sequence, given the osc config will be determined by HW, and will not change!)
I haven't tried the deepsleep scenario, but this change should also affect the BYP to HSE transition (that's the reason the flags are checked in the 'if'), otherwise would do the same flow (whether it's fully correct or not, different story).
How can I see the build errors? The link seems to be broken, and I tried building at my local repo, no idea why it failed in CI
Regards,
Sebastian

[0xc0170]

How can I see the build errors? The link seems to be broken, and I tried building at my local repo, no idea why it failed in CI

we will restart that jenkins CI, there was one device unresponsive, was fixed a while ago.

[jeromecoutant]

Not approved by ST driver team
ST_INTERNAL_REF 35827

[AnotherButler]

@LordGuilly Thanks for the PR.

Also, we recommend our contributors follow Chris Beam’s seven rules of great commit messages to keep the commit history clear. We find the commit.template feature particularly helpful.

To match this format, please change the start of your subject line from "changed" to "Change", and shorten the subject if possible. We use the PR subject lines in our release notes. Thanks for your contributions.

[0xc0170]

@LordGuilly @jeromecoutant what is the status? Is there a way to resolve this?

[LordGuilly]

I think it can probably be discarded, and trust the STM driver team will provide a fix. Otherwise, it will be a waste of time.

[theotherjimmy]

@LordGuilly I'm going to close this PR, as it will not come in as is and we want the ST team to provide the fix. Let's track this is #4753