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.

[Tesla DeLorean]

The L1 series had a latch-up issue as I recall. Also didn't have an independent VBAT pin.

Might need specific procedures to remove power source and then reconfigure and pull current time/date from host system, say via (S)NTP.

Might also need to look at how power loss is handled / managed, and put into STANDBY, and flagging of power-up mode, standby and tamper type events.

[Sourabh]

Hi thanks for the reply, I am using STM32L4 series board and also i am facing issue during the second initialization i.e after main power loss and powering back the board.

 

[MM..1]

Start reading here Solved: RTC Not Working When Using VDD for VBAT on STM32L4 - STMicroelectronics Community

[waclawek.jan]

> 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.

What do you mean by "RTC clock fails to configure"? If there is enough voltage on VBAT pin (i.e. supercap or battery connected to it), you don't need to configure the RTC again - if it retains time, it retains also its configuration.

JW

[Sourabh]

Hi thanks for the reply, the clock doesn't configure the second time, and is there a way to check my LSE state during my clock initialization?

 

[waclawek.jan]

I don't use Cube so can't help with that. However, Cube is open source, so you can debug it as your own code.

You can check state of the clocks in the respective RCC registers, namely, LSE state is given by the LSERDY bit in RCC_BDCR. You can do this in debugger, too.

JW

[Andrew Neil]

You haven't showed your schematic - see: How to write your question to maximize your chances to find a solution

 

Remember that Supercaps are not like batteries: the voltage decays gradually to zero - unlike batteries, which tend to keep a (relatively) steady voltage until they die:

 

#SuperCap #SuperCapVsBattery

[Sourabh]

Hi everyone,

Here are a few additional details that I missed in my original post. The supercapacitor is connected directly to VBAT. Could this configuration cause any issues?

I am also facing a problem when I reconnect the main power for the second time on the STM32L4 series board. At that point, I encounter an LSE timeout issue.

Any insights or suggestions would be greatly appreciated. Thank you.

 

[Andrew Neil]

Still missing hardware details.

Please show the schematic - much more effective than trying to describe electronic circuits in words!

[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

[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?

[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