Fix crash caused by using higher MSI range as sysclk on STM32WL

[andelf]

I have an STM32WLE5 module with no HSE, the official C demo code uses MSI range11. It worked with embassy about 1 year ago. (ref: https://andelf.github.io/blog/2023/01/23/stm32wl-lora-with-rust-embassy/ )

Now after I porting the old code to the current embassy main branch, I got an error after BD is initiated:

ERROR probe_rs::architecture::arm::core::armv7m: The core is in locked up status as a result of an unrecoverable exception

The minimal reproduce code:

    let mut config = embassy_stm32::Config::default();
    {
        use embassy_stm32::rcc::*;
        config.rcc.msi = Some(MSIRange::RANGE48M);
    }
    let p = embassy_stm32::init(config);

After a year. So many new changes were merged. I had to look into the rcc part. The crash point is randomly located between LS init and FLASH setting.

After some digging, I found this comment might be related:

embassy/embassy-stm32/src/rcc/bd.rs

Lines 118 to 126 in a4eebdc

	impl Default for LsConfig {
	fn default() -> Self {
	// on L5, just the fact that LSI is enabled makes things crash.
	// TODO: investigate.
	#[cfg(not(stm32l5))]
	return Self::default_lsi();
	#[cfg(stm32l5)]
	return Self::off();

Sadly, STM32WLE5's condition is worse, if I use MSIRange11(48MHz), it crashes no matter what the ls config is.

Then I realized it was caused by the fact that:

• Embassy's RCC init logic requires more clocks compared to C
• After msi_enable(MSIRange::RANGE48M) is called, the system clock is already 48M
• For shorter logic(in C), setting FLASH latency a few MCU cycles later is OK. But you cannot leave this situation too long

This might also happen for other families. I just added a quick fix for the STM32WL family only.

Any other solutions? (simplify rcc init using prebuilt macros / init LS before sysclk / ...?)