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

[TDK]

Can you reset the power domain prior to enabling IWDG?

Not sure how you're applying the workaround if POR isn't an option. Workaround seems to require it.

RTC clocked with LSI is going to be horribly inaccurate anyway.

[Attila_Horvath]

The bootloader turn on the IWDG.

The problem is when the LSI frequency around 48 kHz, then the IWDG reset time is about 21 seconds and the firmware restart always because of IWDG. I would like to find a solution to reset the LSI in runtime because the device in field no option for full power reset.

[mrx23]

Why does the LSI have +-50% tolerance?

[TDK]

The LSI here does not have +/- 50% tolerance. Perhaps create a new post if you have additional questions.

To address the general question: Why is the LSI not exact? Because fabrication tolerances, specifically on oscillator circuits like this, contribute to the tolerance.

[mrx23]

Well this one has

How come the tolerance is so much bigger on this one?

[Andrei Chichak]

LSI is intended to run the independent watchdog, not in lockstep with the external crystal, but independent of the external crystals. The frequency is crappy and varies with temperature, but you don't need external components.

Some figure that it is a 32767 Hz source. No, it's 30kHz, or 40kHz, or 17-47kHz, depending on how the die was laid out on a day, the temperature, and phase of the moon. Don't use it where you expect a reliable, predictable frequency. If you use it as a IWDG, don't set your tolerances too tight or you will be sad.

Note: I am not a silicon layout engineer, but I did stay at a Holiday Inn once.

A

[TDK]

edit: deleted response.

Open a new thread if you want to discuss.

[waclawek.jan]

Hi @Attila_Horvath , 

can you please tell us more about your application, so the problem can be reproduced?

- what is the setting of Option Bytes?

- how is your board powered, is that power source permanent?

- do you use Standby or other low-power modes? If yes, how do you exit from them?

- do you use LSI as RTC clock? Do you use it in the LSE CSS?

- how do you observe the LSI frequency?

- do you know, at which moment did LSI switch to higher frequency (i.e. what event lead to the problem)?

Thanks,

JW

[DAlbe.3]

I am having the same problem. I am using the STM32G030K6 powered at 3v3. I use the LSI to drive the RTC and the device spends most of its time in deep sleep (STOP0) mode. I don't need great accuracy, but I expected it to meet the specs in the datasheet. Like others, I initially measured 48.93kHz at MCO. I have implemented the second workaround from errata 2.2.1: reset backup power domain on POR, and it seems to work MOST of the time, but not always.  Once in a while, the LSI is still running far above its 34kHz max and I know the POR flag was set (and so this code ran) because I display the CSR register at startup.

@TDKare you aware of a way to correct the failure condition in software if the workaround fails?  It looks like once the condition has occurred, BOTH a POR and the workaround are required to clear it; a hard reset will not clear the condition.

Code to reset backup power domain follows. I have also tried removing the PWRRSTF conditional and always running the code to reset the backup power domain at startup and can still occasionally reproduce the high (48.9kHz) LSI frequency.

    // 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 clk to power subsystem
        SET_BIT(PWR->CR1, PWR_CR1_DBP);     // enable access to backup power domain
        SET_BIT(RCC->BDCR, RCC_BDCR_BDRST); // reset backup power domain
        CLEAR_BIT(RCC->BDCR, RCC_BDCR_BDRST);
        CLEAR_BIT(PWR->CR1, PWR_CR1_DBP);
    }