STM32U5 RTC subseconds count up sometimes

[JFisher]

Hello,

I've noticed an issue when using the RTC to try to calculate subseconds. I am using the NUCLEO-U575ZI-Q board, with a new project with these settings:

with this clock configuration:

 

I've added this code to the while loop:

 /* Infinite loop */
 /* USER CODE BEGIN WHILE */
 RTC_TimeTypeDef last_time = {0};
 int first = 1;
 while (1)
 {
	 RTC_TimeTypeDef sTime = {0};
	 RTC_DateTypeDef sDate = {0};

	 do {
		 HAL_RTC_GetTime(&hrtc, &sTime, RTC_FORMAT_BIN);
		 HAL_RTC_GetDate(&hrtc, &sDate, RTC_FORMAT_BIN);
	 } while (sTime.SubSeconds != hrtc.Instance->SSR);

	 if (!first) {
		 if (sTime.Seconds < last_time.Seconds) {
			 HAL_Delay(1000); // Breakpoint 1
		 } else if (sTime.Seconds == last_time.Seconds && sTime.SubSeconds > last_time.SubSeconds) {
			 HAL_Delay(1000); // Breakpoint 2
		 }
	 }

	 first = 0;
	 last_time = sTime;
	 HAL_Delay(100);
 /* USER CODE END WHILE */

 /* USER CODE BEGIN 3 */
 }
 /* USER CODE END 3 */

The issue I am seeing is that when I set breakpoints at line 17 and 19 above, I regularly hit them. Here's an example of hitting line 19:

Here's the RTC register contents:

The problem is that it seems that there's an issue where the SSR register ticks up sometimes? The Seconds hasn't updated, but the SSR register has somehow gotten a larger value in it. I checked the Errata for this part and I don't see anything relevant there?

Thank you,

Jonathan

[TDK]

> while (sTime.SubSeconds != hrtc.Instance->SSR)

This check shouldn't be necessary and is causing DR to be locked until the next loop. If you take it out, do you still get the bad behavior?

 

You are certainly running afoul of this:

In case the software makes read accesses to the calendar in a time interval smaller than 1 RTCCLK periods: RSF must be cleared by software after the first calendar read, and then the software must wait until RSF is set before reading again the RTC_SSR, RTC_TR and RTC_DR registers.

[JFisher]

No, there is no difference with that do/while loop removed. I only added that because I saw some other STM32 MCUs had that recommendation (I think the F series), and wanted to at least try to see if maybe it affected this chip.

Thank you for pointing out the RSF functionality -- I had missed that. I will take a look at that and see if this resolves the issue.

[waclawek.jan]

The loop is needed for BYPSHAD=1 which is not your case. It may also be part of the mechanism to cope with the lock-sometimes-does-not-work erratum in RTCv2 (you use RTCv3 so that issue does not pertain to your case).

After the loop is removed, RSF check should not be needed, if you don't read time elsewhere, as the 100ms delay should be enough to achieve the next shadow copy. So, I'm not sure what's the source of your observation; but then I am also not interested in debugging Cube/HAL code.

JW

PS. Note, that observing RTC register in debugger may mess with the shadow/locking mechanism, too.