Unexpected error messages from probe-rs and boot failure when using default rcc config with SMPS on STM32H735.

[hydra]

I ran the blinky.rs example on an H735IG, by first copying it from the stm32h7 to the stm32h735 examples folder, made no changes, ran it and was greeted by unexpected messages from probe-rs and the inability to connect any debugger until the MCU was powered off and on again into STM32 DFU mode using the boot button.

After much head-scratching, trying known-good boards to ensure my development environment and debugger were indeed working correctly, and finally using Segger's o-zone + a J-Link debugger I was able to step through the code and find that when ldoen was called in rcc_init() my target would die.

My target is using an SMPS MCU power supply configuration, enabling the LDO causes the MCU to die which then results in debugger errors.

The exact error from probe-rs, so that others can find this via their favorite search engine, was:

WARN probe_rs::probe::stlink: send_jtag_command 242 failed: SwdDpError

This occured a couple of times, then fails with 'ARM specific error occured'.

The specific configuration I'm using in my schematic is as per these diagrams:

AN5419
Figure 2. Sytem supply configuration (top right image of the six)
Figure 5. Direct SMPS Supply.

https://www.st.com/resource/en/application_note/an5419-getting-started-with-stm32h723733-stm32h725735-and-stm32h730-mcu-hardware-development-stmicroelectronics.pdf

I was not expecting to have to create my own rcc config to run blinky, I assumed the default RCC config would work and that later in my own code I would have to add my own rcc config and do PSU mode selection, but the blinky.rs example does not work on an H735 when using an SMPS PSU configuration.

My preference would be that the default RCC config does not adjust power supply settings at all, if possible, to prevent this crash and failure from occuring.

[hydra]

I note that the default configuation is detailed in RM0468 Rev 3 as follows:

It seems this snippet of code is the culprit:

    #[cfg(any(pwr_h7rm0399, pwr_h7rm0455, pwr_h7rm0468, pwr_h7rs))]
    {
        use pac::pwr::vals::Sdlevel;
        match config.supply_config {
            SupplyConfig::Default => {
                pwr_reg.modify(|w| {
                    w.set_sdlevel(Sdlevel::Reset);
                    w.set_sdexthp(false);
                    w.set_sden(true);
                    w.set_ldoen(true);     <--- CRASH OCCURS IN HERE.
                    w.set_bypass(false);
                });
            }

So maybe the PWR_CR3 register shouldn't be touched?

[hydra]

ok it turns out this is the culprit:

            #[cfg(any(pwr_h7rm0399, pwr_h7rm0455, pwr_h7rm0468, pwr_h7rs))]
            supply_config: SupplyConfig::LDO,

...

            SupplyConfig::LDO => {
                pwr_reg.modify(|w| {
                    w.set_sden(false);
                    w.set_ldoen(true);     <--- CRASH OCCURS IN HERE.
                    w.set_bypass(false);
                });
            }

So yeah, not sure of the reasoning behind that @Dirbaio - maybe you could shed some light on that?

[hydra]

it seems that if you leave SupplyConfig set to Default the system doesn't boot as it get stuck in this loop:

    #[cfg(any(stm32h7))]
    while !PWR.csr1().read().actvosrdy() {}

so, as-is, using SupplyConfig::Default is currently broken on H7, unless I'm missing something? And indeed, I cannot find any examples that use SupplyConfig::Default either.

IMHO the default RCC config should probably 'just work', so perhaps the check is only needed if the voltage scaling needs to be changed? Currently the default for the H7 (except H7RS) is VoltageScale::Scale0, but perhaps that should be VoltageScale::Scale3 so that the VOSRDY check isn't required?