Read of RTC only after write

[SoftwareArchitekt]

Describe the bug
I am using a blackpill_f401cc board. It comes with an STM32F401 CPU. This includes an RTC.
SW Zephyr 4.1.0-1530
Stwps what I have done:

1. Set RTC with rtc_set_time(rtc, &tm) with an date and time
2. Read the date and time with rtc_get_time(rtc, &tm) -> it works
3. Buffer the RTC with Batterie on VBAT-Connector and GND.
4. Remove rtc_set_time from code
5. flash
6. run program -> read the correct time
7. disconnect from power
8. reconnect power -> rtc_get_time -> error -61 / -ENODATA
9. after debugging, I figure out that in file zephyr/drivers/rtc
   /rtc_ll_stm32.c line 531 throw this error

At this point I just want to remove the code from line 525 to 532 for proper working.
How else could it be fixed?

This is my first issue here, so I hope I wrote everything clear - if not, just support me to fill the needed informations

[github-actions]

Hi @SoftwareArchitekt! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[leonardo-munoz-pragmafw]

Hi @SoftwareArchitekt , I would like to help with this issue. Do you have any update on it?

[SoftwareArchitekt]

Thanks for your interest. It is still the same. I just make the changes lokal. Maybe it would helpful, when the author of the file will join discusion

[etienne-lms]

The issue likely comes from power supply being disconnected:

7. disconnect from power
8. reconnect power -> rtc_get_time -> error -61 / -ENODATA

Power supply voltage needs to be maintained on your device for persistent RTC to be functionnal. Note in the SoC refman:

As long as the supply voltage remains in the operating range, the RTC never stops,
regardless of the device status (Run mode, low-power mode or under reset).

[SoftwareArchitekt]

The issue likely comes from power supply being disconnected:

7. disconnect from power
8. reconnect power -> rtc_get_time -> error -61 / -ENODATA

Power supply voltage needs to be maintained on your device for persistent RTC to be functionnal. Note in the SoC refman:

As long as the supply voltage remains in the operating range, the RTC never stops,
regardless of the device status (Run mode, low-power mode or under reset).

I checked this. The power stay with a battery on vbat. And the rtc is running. So it has not a dependency to this issue

[etienne-lms]

At this point I just want to remove the code from line 525 to 532 for proper working.

Do you mean the time read is the expected one: it considers the time initially set and the time spent until you power on back the device back and read the RTC?

[SoftwareArchitekt]

yes, the time read is exactly what was set before plus time just running on vbat. As I wrote, everything run fine when i comment the part out. But I am not sure, why it is inside.
One point from your quote "Run mode, low-power mode or under reset", there is a reset to the cpu done, but not to RTC, but time is still running in this time from RTC.

[etienne-lms]

RTC on backup power domain is expected to run whatever reset/power off/...
That's strange RTC_ISR bit INITS gets cleared while your RTC seems to run.
The RefMan says about RTC_ISR[INITS] value:

This bit is set by hardware when the calendar year field is different from 0 (backup domain
reset value state).
0: Calendar has not been initialized
1: Calendar has been initialized

Maybe the issue comes from RTC calendar registers shadowing being in progress. The RefMan says that RTC_ISR[RST] (bit 5) needs to be set before one reads the RTC calendar registers.
Try this fix in Zephyr STM32 RTC driver:

+ 	uint32_t time_ref = k_uptime_seconds();
+
+	while (LL_RTC_IsActiveFlag_RS(RTC) == 0U) {
+	 	if (k_uptime_seconds() - time_ref > 2) {
+			LOG_ERR("Timeout on RTC initialization");
+			return -EIO;
+	 	}
+	}
+
 	if (!LL_RTC_IsActiveFlag_INITS(RTC)) {
 		/* INITS flag is set when the calendar has been initialiazed. This flag is
 		 * reset only on backup domain reset, so it can be read after a system
 		 * reset to check if the calendar has been initialized.
 		 */
 		k_spin_unlock(&data->lock, key);
 		return -ENODATA;
 	}

[SoftwareArchitekt]

it looks better, I will test it, but pls give me a few days for it

[etienne-lms]

No problem. Note that I haven't tested this change.
If you manage to fixes your issue, would you be okay to create a pull request?