2024-05-30 06:00 AM - edited 2024-05-30 09:44 AM
Erratum 2.2.1 (Unstable LSI when it clocks RTC or CSS on LSE) indicates the following workaround:
If LSI clocks the RTC or when the LSECSSON bit is set, reset the backup domain upon each VDD power up
(when the BORRSTF flag is set). If VBAT is separate from VDD, also restore the RTC configuration, backup
registers and anti-tampering configuration.
Although this works much of the time, sometimes it does not. This seems to be related to exactly what happens on the Vdd rail: if Vdd gets low enough to set the RCC_CSR PORRSTF but not below ~0v6, then the LSI sometimes runs fast (~48.9kHz) on startup, even if the workaround (reset backup power domain) is implemented.
Unfortunately, in the real world, this Vdd scenario happens: when main power glitches, bulk capacitance in most designs will gradually drain and will drain especially slowly once Vdd falls below MOSFET switching thresholds. When power comes back, Vdd may not have gotten all the way to 0V and this issue can manifest despite the workaround.
For reference, the workaround is implemented as follows:
SET_BIT(RCC->APBENR1, RCC_APBENR1_PWREN); // enable clock to pwr control subsystem
// Start LSI oscillator used by RTC and IWDG
SET_BIT(PWR->CR1, PWR_CR1_DBP); // enable access to backup power domain
while(READ_BIT(PWR->CR1, PWR_CR1_DBP) == RESET);
// 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->BDCR, RCC_BDCR_BDRST); // reset backup power domain
while(READ_BIT(RCC->BDCR, RCC_BDCR_BDRST) == RESET);
CLEAR_BIT(RCC->BDCR, RCC_BDCR_BDRST);
}
// Start LSI and wait until ready
SET_BIT(RCC->CSR, RCC_CSR_LSION); // turn on LSI oscillator
while (!(RCC->CSR & RCC_CSR_LSIRDY)); // wait for LSI ready
CLEAR_BIT(PWR->CR1, PWR_CR1_DBP);
Most of the time, the LSI will start and run at 32kHz, but periodically, it will still run at 48.9kHz and then only a POR will clear the condition.
For designs without an LSE, this is a critical condition. The ugly workaround is to measure the LSI with the HSI and then choose prescalers based on the actual frequency.
2024-05-30 06:30 AM
Hi @DAlbe.3 ,
Can you please answer my and @Amel NASRI 's question in https://community.st.com/t5/stm32-mcus-embedded-software/stm32g0-unstable-lsi-frequency/m-p/680761#M48230 ?
JW
2024-05-30 07:58 AM
Thanks @waclawek.jan , I am replying in that thread. I can delete this thread if you think it's better, but I started a separate thread because I think both the thread title and problem scenario are sufficiently different from what @Attila_Horvath described (that thread focused on how to resolve the problem without POR) and forum members would need to read through that thread before finding reference to the erratum workaround maybe not working.
If @Amel NASRI 's suggestion of delaying action after setting DBP turns out to be valid/important, that probably merits both a new thread and a new erratum entry since setting/clearing DBP is such a common activity in nearly all STM32 code bases that use the RTC and there is no hint in the RM that you need to wait for the bit to read back as set before proceeding.
2024-06-05 10:07 AM
Hi @DAlbe.3 ,
Back to the initial question, I believe that you need to check PWRRSTF value: then it is required to reset backup domain and enable LSI each time this flag (PWRRSTF) is set. This is what the errata workaround says:
Are you checking this condition? We need to make sure that you have never such occurrence "periodically, it will still run at 48.9kHz".
-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-06-05 01:26 PM
Hi @Amel NASRI , I provided the exact code (first post in this thread) that I am using; it runs at each system reset.
It took me a while to figure out what was going wrong: the issue manifests despite the workaround *IF* the main power rail falls below the threshold for setting PWRRSTF but does not make it all the way to ground. I found this by accident: I had current leaking from a serial interface used to control the system and enough power was leaking through UART_RXD1 that it would keep the main power rail at around 0v6 even when main power had been removed. In this case, when main power was restored, PWRRSTF would be set, but periodically (maybe one in every 5-10 power cycles), the LSI would still run at ~49kHz despite the workaround running. It's pretty easy to reproduce.
Regards,
David
2024-06-06 08:15 AM
Hello @DAlbe.3 ,
you wrote it's easy to reproduce, but probably only with your HW and settings. We tested this WA extensively when the issue was found new and found it working reliably.
It's not that we don't trust you, but I'd like to know more about the exact application. Maybe I missed that, but what are the VDD and VBAT connections, what capacitors are used and also, what is the BOR setting programmed in the OB?BR,
J
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-06-06 08:59 AM
Hi @Bubbles,
Thank you again; I understand the skepticism and am happy to share whatever details I can. The component is the STM32G030K6T6 (LQFP32); it does not have separate VDD and VBAT pins. Power is 3v3 via an XC6216D332PR LDO with 1uF on the input of the LDO at the LDO and 4.7uF on the output of the LDO at the LDO. The uC has an additional 4.7uF and 100nF across VDD and VSS very close to the uC. All caps are MLCC (very low ESR). The LDO is not taxed (less than 2mA in general, 15mA peak); in this case, testing was done with a bench supply feeding 6v5 to the LDO input (it is normally supplied by a 6V SLA battery) through a Joulescope (dynamic power analyzer) to monitor consumption. There is quite a bit of bulk capacitance on the board on the 6v5 rail so power to the LDO should be *very* stable; testing was done with most of the board de-populated so I could focus on this issue.
The workaround works in most cases. As mentioned earlier, I found this by accident when testing the workaround. The workaround always works if I let the VDD rail drop below ~0v4 (I didn't nail the exact number). However, I found this other issue accidentally in testing because I had a USB-to-serial adapter connected to PA9/USART1_TX, PA10/USART1_RX (the uC has a command interface used for testing) and even when power was removed from VDD, some power was sourced through USART1_RX such that VDD wasn't dropping below 0v6. When power was re-applied to VDD, the PWRSTF is set, but the LSI defect would intermittently recur (maybe once per 5-10 power cycles). Without the serial connection, and allowing VDD to drop below ~0v3, the LSI problem never manifests.
Conveniently, the command interface (which runs at 57.6kbps) includes a command to connect LSI->MCO->USART1_TX and the difference between ~32kHz and ~49kHz is very visible when the clock stream is interpreted as asynch serial data...this made it easy to see even without a scope or counter connected (although I also confirmed the frequencies with a scope).
This isn't a super high priority for me anymore because that serial interface is only used for development/factory. It is still a minor issue because power glitches happen and I'm concerned this could still happen in the field, but it would be very rare. I plan to do two more tests:
2024-06-06 09:09 AM
Maybe a redundant question, but how is NRST connected? Without pullup and with about 100nf to ground? Or only internal reset? How are the NRST option bits set?
2024-06-06 09:12 AM
Hi @Uwe Bonnes, nRST option bits are not touched (they stay at the factory default; I can check what that is if you want, but external reset is functional). nRST has a 100nF to ground but no pull-up; if a pull-up is recommended, then that may be an issue; my understanding was that it is internally pulled high.
2024-06-06 09:45 AM
No pullup is recommended, as per ST recommendation internal pullup and 100 nF is best.