Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32U5: RNG hangs when using HSE clock source #3635

Open
mubes opened this issue Dec 10, 2024 · 1 comment
Open

STM32U5: RNG hangs when using HSE clock source #3635

mubes opened this issue Dec 10, 2024 · 1 comment

Comments

@mubes
Copy link
Contributor

mubes commented Dec 10, 2024

A bit confused by this one TBH. I initialise my HSE as follows;

  {
        use embassy_stm32::rcc::*;
        use embassy_stm32::time::Hertz;
        config.rcc.hse = Some(Hse {
            freq: Hertz(16_000_000),
            mode: HseMode::Oscillator,
        });
        config.rcc.pll1 = Some(Pll {
            source: PllSource::HSE,
            prediv: PllPreDiv::DIV2,   // HSE / 2 = 8MHz
            mul: PllMul::MUL60,        // 8MHz * 60 = 480MHz
            divr: Some(PllDiv::DIV3),  // 480MHz / 3 = 160MHz (sys_ck)
            divq: Some(PllDiv::DIV10), // 480MHz / 10 = 48MHz (USB)
            divp: Some(PllDiv::DIV15), // 480MHz / 15 = 32MHz (USBOTG)
        });
        config.rcc.mux.otghssel = mux::Otghssel::PLL1_P;
        config.rcc.hsi = true;
        config.rcc.mux.rngsel = mux::Rngsel::HSI48;
        config.rcc.voltage_range = VoltageScale::RANGE1;
        config.rcc.sys = Sysclk::PLL1_R;
    }

This causes the line let mut rng = Rng::new(p.RNG, Irqs); to hang and eventually time out.

If I comment out the HSE configuration, the above Rng::new works correctly. It looks for all the world like a missing clock, but both HSI and HSI48 are enabled and show up in the trace;

0.000000 INFO  Hello World!
└─ ironage::____embassy_main_task::{async_fn#0} @ src/main.rs:47  
0.000000 TRACE BDCR ok: 0c00c200
└─ embassy_stm32::rcc::bd::{impl#3}::init @ embassy/embassy-stm32/src/rcc/bd.rs:216 
0.000000 DEBUG rcc: Clocks { audioclk: MaybeHertz(0), hclk1: MaybeHertz(160000000), hclk2: MaybeHertz(160000000), hclk3: MaybeHertz(160000000), hse: MaybeHertz(16000000), hse_div_2: MaybeHertz(8000000), hsi: MaybeHertz(16000000), hsi48: MaybeHertz(48000000), hsi48_div_2: MaybeHertz(0), lse: MaybeHertz(0), lsi: MaybeHertz(32000), msik: MaybeHertz(4000000), pclk1: MaybeHertz(160000000), pclk1_tim: MaybeHertz(160000000), pclk2: MaybeHertz(160000000), pclk2_tim: MaybeHertz(160000000), pclk3: MaybeHertz(160000000), pll1_p: MaybeHertz(32000000), pll1_p_div_2: MaybeHertz(16000000), pll1_q: MaybeHertz(48000000), pll2_p: MaybeHertz(0), pll2_q: MaybeHertz(0), pll2_r: MaybeHertz(0), pll3_p: MaybeHertz(0), pll3_q: MaybeHertz(0), rtc: MaybeHertz(32000), shsi: MaybeHertz(0), shsi_div_2: MaybeHertz(0), sys: MaybeHertz(160000000) }
└─ embassy_stm32::rcc::set_freqs @ embassy/embassy-stm32/src/rcc/mod.rs:71  

I did force-enable both hsi and hsi48 in the rcc driver just to be sure it wasn't that, but to no avail. Any advice what to poke next?

Regards

DAVE

@MDr164
Copy link
Contributor

MDr164 commented Jan 2, 2025

I can't reproduce the hang on the STM32U5 I got here. Can you share the rest of the code in a gist maybe or at least the relevant portion where you declare the Irqs struct and such? Neither the Rng::new nor the resulting rng.async_fill_bytes cause any issue and produce random data as expected with the clock configuration you posted on the Nucleo-STM32U5A5.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants