STM32N655X0 RTC Stops Counting After Power-Off Depending on the Previous Boot Mode or Firmware Flashing Method

[Gowri_M]

Hi everyone,

We are facing an issue with the RTC on our custom hardware based on the STM32N655X0 MCU and would appreciate any suggestions to help us identify the root cause.

1. Project Overview

We have configured the RTC in our application, and maintaining the correct time across power cycles is an important project requirement.

Our firmware is stored in external flash. During development, we use J-Link for programming, and we have also implemented firmware flashing through USB using an FSBL with DFU support.

Both flashing methods work successfully. However, we have observed unexpected RTC behaviour after flashing and subsequent power cycles.

2. Issue Description

After flashing the firmware, if we remove the main supply (VDD) and power the board back on after a few minutes, the RTC does not account for the elapsed time correctly.

For example, if flashing completes at 12:25 PM and we power off the board immediately, then power it back on at 12:30 PM, the RTC does not reflect the five-minute interval as expected.

We initially suspected the external loader because it is common to both programming methods. To investigate this, we tried enabling the LSE in the external loader and initializing the RTC in the FSBL. However, the issue persisted.

3. Experiments and Observations

Experiment 1: Flashing through J-Link

• We configure the boot pins for development mode.
• We flash the firmware successfully using J-Link.
• After removing VDD and powering the board back on, the RTC does not reflect the elapsed power-off time.

Experiment 2: Flashing through USB

• We configure the boot pins for serial boot mode or use the FSBL with DFU support.
• We flash the firmware to external flash successfully.
• After removing VDD and powering the board back on, the RTC again fails to account for the elapsed time.

Experiment 3: Power cycling without flashing

We also tested the behaviour without performing any firmware flashing:

• We configure the boot pins for development mode, power on the board, and then power it off without performing any programming operation.
• After waiting five minutes, we power the board back on and observe that the RTC has not advanced by the expected five minutes.
• However, when the board's previous boot mode is flash mode, the RTC correctly reflects the elapsed five-minute interval after power-off.

This suggests that the RTC behaviour is related to the board's previous boot mode or the state established during the preceding power cycle, rather than being caused exclusively by the firmware flashing operation.

Experiment 4: Power cycling without removing VDD

When we perform an immediate power cycle after flashing without removing the main VDD supply, we observe an approximately 30-second discrepancy in the RTC time.

4. Backup Domain and VBAT

• VBAT is supplied to the MCU.
• We have verified that the backup registers are not being cleared.
• We use a backup register with a known value to determine whether RTC initialization is required. If the expected value is absent, the application initializes the RTC with a default time.
• During these tests, the RTC does not revert to the default time, and the known backup-register value remains present.

Therefore, the observed issue does not appear to be caused by the backup registers being cleared.

Since RTC timekeeping across power cycles is a critical requirement for our project, any suggestions or pointers would be greatly appreciated.

Thank you!

[JCAIL]

Hi Gowri,

What is the RTC programming at reset strategy ?

“We use a backup register with a known value to determine whether RTC initialization is required. If the expected value is absent, the application initializes the RTC with a default time.”

And what about msp init? 
After a reset the only config to to is :

HAL_PWR_EnableBkUpAccess();
__HAL_RCC_RTCAPB_CLK_ENABLE();

Do not reconfigure the LSE, the RTC.

2°) Are you able to monitor  RTC_OUT1?

Once the RTC is running, its operation mainly depends on the quality of VCC/VBAT and on the rt_ker_ck input signal. An issue with rtc_ker_ck seems more likely.

Anyway, I suggest routing the wake-up timer output to RTC_OUT1. This should let you see exactly when the RTC stops counting as expected.

LL code generated by IA (not tested), Expected freq = (32768 / 2) Hz :

Add this code in the RTC init function :

LL_RTC_DisableWriteProtection();

LL_RTC_WAKEUP_Stop();

while ((RTC->ICSR & LL_RTC_ICSR_WUTWF) == 0U)

{

  /* Add a timeout here in production code. */

}

LL_RTC_ClearFlag_WUT();

LL_RTC_WAKEUP_SetClock(LL_RTC_WAKEUPCLOCK_DIV_2); /* minimum prescaller */

LL_RTC_WAKEUP_Config(reload, 0U);  /* 0 disables automatic WUTF clearing */

 

/* OSEL = wake-up, OUT2EN = 0: route the event to RTC_OUT1. */

LL_RTC_EnableOutput(LL_RTC_ALARMOUT_WAKEUP);

LL_RTC_WAKEUP_Start(LL_RTC_WAKEUP_TIMER_IT_DISABLE);

LL_RTC_EnableWriteProtection();

Please monitor RTC_OUT1 and proceed step by step to identify the issue. Let me know what you find.

Best regards,
Jérôme