cancel
Showing results for 
Search instead for 
Did you mean: 

STM32U5 RTC subseconds count up sometimes

JFisher
Associate II

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:

JFisher_0-1748911187007.png

with this clock configuration:

JFisher_1-1748911209123.png

 

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:

JFisher_2-1748911316050.png

Here's the RTC register contents:

JFisher_3-1748911352897.png

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

1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Super User

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

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

3 REPLIES 3
TDK
Super User

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

If you feel a post has answered your question, please click "Accept as Solution".

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.

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.