STM32G0 Unstable LSI frequency

[Attila_Horvath]

Dear Everyone,

We use STM32G0B0 MCU and in errata there's a section from the unstable LSI frequency. In some case the LSI frequency about 48 kHz. The workaround not work, after backup domain reset, the LSI frequency still about 48 kHz.

My theory is that, the IWDG is running, so the backup domain reset cannot turn off LSI. Someone has a valid workaround or some ideas how I can force the backup domain reset if the IWDG running? Unfortunately POR not an option...

Br,

Attila

[waclawek.jan]

@DAlbe.3,

Do you also use IWDG, as @Attila_Horvath does?

JW

[Amel NASRI]

Hi @DAlbe.3 ,

Could you please insert the following wait loops to ensure that required bits are set properly:

• just after line 5 of your code to ensure that access to backup power domain is enabled:

 while(READ_BIT(PWR->CR1, PWR_CR1_DBP) == RESET);

• just after "SET_BIT(RCC->BDCR, RCC_BDCR_BDRST);"

while(READ_BIT(RCC->BDCR, RCC_BDCR_BDRST) == RESET);

 Does this make a difference?

-Amel

[DAlbe.3]

Yes, I am also using IWDG

[DAlbe.3]

Hi @Amel NASRI ,

First, many thanks for responding so quickly!

I added the checks for DBP and BDRST and it seemed better at first, but unfortunately I was still able to reproduce the bug (LSI > 48kHz).  It requires 1-25 POR to see it, but it did happen and as always, persists until the next POR. I have been able to reproduce it numerous times.

Separately, I'm interested in your suggestion regarding PWR_CR1_DBP because I enable/disable DBP in several places in my codebase and need to know if I should add this check (to wait for DBP set) before accessing registers in the backup power domain. There's no mention of it in the RM; is this a known issue with setting DBP?

The code run at startup is:

    // See Errata 2.2.1: Unstable LSI after main power domain reset
    // if reset was due to POR or BOR, reset the backup power domain
    if (RCC->CSR & RCC_CSR_PWRRSTF) {
        SET_BIT(RCC->APBENR1, RCC_APBENR1_PWREN); // enable clock to pwr control subsystem
        SET_BIT(PWR->CR1, PWR_CR1_DBP);     // enable access to backup power domain
        while(READ_BIT(PWR->CR1, PWR_CR1_DBP) == RESET);
        SET_BIT(RCC->BDCR, RCC_BDCR_BDRST); // reset backup power domain
        while(READ_BIT(RCC->BDCR, RCC_BDCR_BDRST) == RESET);
        CLEAR_BIT(RCC->BDCR, RCC_BDCR_BDRST);
        CLEAR_BIT(PWR->CR1, PWR_CR1_DBP);
    }

Regards,
David

[DAlbe.3]

Because this is an intermittent problem, I'll mention a possible issue:

In my test setup, I'm running software on the uC that has a command line interface. I have a serial terminal connected to USART1 at 57.6kbps.  When I issue a test command, PA9 is reconfigured from USART1_TX to MCO and MCO is configured as LSI.  When the LSI is running at 32kHz, the MCO output is interpreted by the terminal as a stream of 'U' characters, but 48kHz is interpreted as a stream of ASCII garbage. This makes it easy to "see" the problem without having to hook up a frequency counter (although I have confirmed this numerous times with a frequency counter).

A side effect of having the serial terminal hooked up is that USART1_RX is driven high and so when I remove Vdd, there is leakage through USART1_RX that keeps Vdd around 0v66.  When I re-apply 3v3 to Vdd, the RCC_CSR register has the PWRRSTF bit set, but LSI problem manifests more readily.

When I disconnect both 3v3 and the USART1_RX connection (allowing Vdd to drop below 0v6), I have not yet reproduced the problem (although because it's intermittent it's hard to be sure).  Nevertheless, the problem does seem to relate to how Vdd ramps down or up or how low Vdd drops. I mention this in case it provides any useful clues about the underlying failure mechanism.  Obviously power glitches happen in the real world that will allow Vdd to cycle down but not all the way down (due to bulk capacitance) and then back up, so this would still be a serious issue.

[waclawek.jan]

> Yes, I am also using IWDG

And do you use software or hardware IWDG, i.e. do you start IWDG in software, or do you have the respective Option bit set (cleared) so that IWDG is started automaticallty by hardware upon reset?

In any case, can you please try to reproduce the problem without IWDG? I mean, does the backup-domain reset fix the problem if IWDG is not used?

JW

[waclawek.jan]

Just to keep all data points at one place, I'm cross-referencing this thread.

JW

[Uwe Bonnes]

Are you running at the extremes of supply voltage or temperature? Is you supply fluctuating noticable?

[waclawek.jan]

@Uwe Bonnes,

@DAlbe.3  described the exact mechanism he "uses" to trigger the problem, in this thread (another data point).

JW

[DAlbe.3]

I start the IWDG in software