RTC not configuring after power loss when using Supercapacitor (STM32L-series).

[Sourabh]

We are facing an issue with the RTC on our STM32L-series microcontroller board. Below are the actions we tried and their outcomes:

Main issue:

• When the battery is connected to the supercapacitor for the first time, the RTC initializes correctly.

• But when we simulate a power loss by manually removing the main power and reconnecting it, the RTC clock fails to configure on the second initialization.

Tests performed:

• Removed the supercapacitor and replaced it with a coin cell and an RPS → the clock still fails to configure.

• When the system is configured without any backup power source, the system clock initializes and works normally.

• Referred to this article: https://mischianti.org/stm32-internal-rtc-clock-and-battery-backup-vbat/ and tested the small noise-suppression circuit, but it did not resolve the issue.

• Tried fully resetting the RCC using:__HAL_RCC_BACKUPRESET_FORCE();
  __HAL_RCC_BACKUPRESET_RELEASE();

• This allows the clock to reinitialize, but the stored RTC time/date are lost.
• Please provide any suggestions or guidance to help resolve this issue. I will continue debugging and update this thread with new findings.

[Sourabh]

Hi andrew,

I may be unable to share the entire schematic.

I have followed the same as per the STM32 documentation. Where i have connected my supercapacitor to VBAT directly.

Thanks

[Andrew Neil]

Then post at least the part which shows how you are powering the chip & RTC.

How are you managing the Supercap.

Again, Remember that Supercaps are not like batteries!

[MM..1]

Show LSE schematics part.

[Sourabh]

Hi everyone,

Here is how my LSE and my supercapacitor is connected to VBAT.

[Sourabh]

Hi everyone,

Here is how my LSE and my supercapacitor is connected to VBAT.

  

[Andrew Neil]

So this is your supercap: https://www.yageogroup.com/products/Capacitors/part/FC0V474ZFTBR24

You haven't shown how it gets charged, or how you manage the discharge.

Did I mention that Supercaps are not like batteries?

PS:

SO have you actually checked that Vbat at the STM32 remains within spec throughout the power-cycle ?

Does it work if you just fit a normal, primary battery?

[Sourabh]

Thanks for your input. Yes, the supercapacitor in my design is the FC0V474ZFTBR24, charged using the STM32L4’s internal VBAT charging circuit (PWR->CR4 |= PWR_CR4_VBE).
VBAT was measured during multiple power-cycle tests and remains stable around 3.0–3.2 V, which is well within the STM32L431 specification:

“VBAT = 1.55 V to 3.6 V: power supply for RTC, LSE and backup registers when VDD is not present.”
— STM32L431 Datasheet, Section 3.9.6 (VBAT operation)

To confirm the super capacitor wasn't the cause, I also tested with a 3 V LFP cell and also with RPS(3V), and the behaviour was identical — RTC/LSE fails to re-initialize after the second power cycle.

[waclawek.jan]

> RTC/LSE fails to re-initialize after the second power cycle.

What do you mean by "re-initialize"?

Once initialized, there's no need to "re-initialize" as long as the VBAT power remains within the specified boundaries. In other words, after reset, you are supposed to find out, whether LSE/RTC is already initialized, and if yes, you don't initialize them again.

If you want to explicitly re-initialize RTC/LSE for whatever reason, you should consider performing an explicit backup-domain reset first, see RCC_BDCR.BKPRST.

JW

[Sourabh]

Thanks for the response,

By re-initialize, I simply mean the case where the supercapacitor is newly connected and I start a debug session to observe RTC/LSE running. At this point the LSE starts correctly.

Then I remove the main power so that the MCU switches to VBAT mode (supercap at ~3.0 V).
When I restore main power and start debugging again, the firmware tries to run HAL_RCC_OscConfig() and at this point the LSE no longer starts — it times out.

I am not intentionally reconfiguring LSE every time; I am only restarting the board to verify that RTC continues running. However, because the backup domain never lost VBAT, the LSE remains in a bad state, causing LSERDY to never assert.

So by “re-initialize,” I mean a normal power cycle for validation, not manually reconfiguring RTC. The issue is that after VBAT-only operation, LSE startup fails unless the backup domain is explicitly reset.

[waclawek.jan]

If you reset (by cycling its VDD, or otherwise) the mcu while valid voltage at VBAT is present all the time, LSE and RTC remains running. If not, there's some serious problem with the hardware, but you probably can't tell that just by looking at return value of a Cube/HAL function.

Why does HAL_RCC_OscConfig() perform in a different way than you expect I don't know, I don't use Cube/HAL; however, Cube/HAL is open source, so you can debug HAL_RCC_OscConfig() (single-step, observe variables' and relevant registers' content, etc.)  in the same way as you debug the rest of your code.

JW