RTC current time in milliseconds (display in 6 byte hex)

[kcire L.]

Hello,

I am using an STM32WB55 and am trying to figure out how to get the current time including milliseconds using an RTC and display that time in 6 byte hex format.

I would most likely call the GetTime() based of a millisecond timer if that is the most efficient way to do it.

For example I would like the time to return like this (0x017FB1731312)

Any help or example on this would really be appreciated.

Thanks in advance!

[Peter BENSCH · Accepted solution]

This won't work because you can't get millisecond information from the RTC if you have a 32.768kHz (2^15 Hz) crystal connected, which can't be divided down to 1kHz using an integer value.

There is only the counting down subsecond counter RTC_SSR, which is by default set to 256 at 32.768kHz.

If you want millisecond information, it makes most sense to use a timer and process this information with it. In principle, you can also use the systick timer, which triggers an interrupt every 1ms by default.

However, I am not aware of a ready-made proposal for your requirements for any of the options.

Does it answer your question?

Regards

/Peter

[SAsse.1]

What I am using is one of the 2 RTC Alarm that I configure for 1 sec call back. In the call back function I clear a public variable. That variable gets incremented in the 1 ms SysTick interrupt.

The reason we need to use SyTick is to get milliseconds counter.

The reason we need to use RTC is to synchronize the counting of milllisecond above to the change in seconds.

Note: I use: Counter %= 1000; // to make sure millisec always fall in [0..999] range

[SIGex]

I did some simple research on this issue. When trying to get milliseconds from RTC, the resolution will not be very useful. It's about 4ms. Or more precisely 3.90625ms. 

// execution interval 1ms
INTERVAL_BLOCK(gpTimer0, 1)
{
  HAL_RTC_GetTime(&hrtc,&RTC_Time,RTC_FORMAT_BCD);
  HAL_RTC_GetDate(&hrtc,&RTC_Date,RTC_FORMAT_BCD);

  printf("RTC_Time: %x:%x:%x-%li(%li)| Date:%x.%x.20%x \r\n", 
    RTC_Time.Hours, \
    RTC_Time.Minutes, \
    RTC_Time.Seconds, \
   (RTC_Time.SecondFraction*1000 -RTC_Time.SubSeconds*1000)/(RTC_Time.SecondFraction+1) 
, \
    RTC_Time.SubSeconds, \
    RTC_Date.Date, \
    RTC_Date.Month, \
    RTC_Date.Year);
}

 And the result looks like this:

RTC_Time: 0:0:0-101(229)| Date:21.1.2024 
RTC_Time: 0:0:0-101(229)| Date:21.1.2024 
RTC_Time: 0:0:0-101(229)| Date:21.1.2024 
RTC_Time: 0:0:0-101(229)| Date:21.1.2024 
RTC_Time: 0:0:0-105(228)| Date:21.1.2024 
RTC_Time: 0:0:0-105(228)| Date:21.1.2024 
RTC_Time: 0:0:0-105(228)| Date:21.1.2024 
RTC_Time: 0:0:0-105(228)| Date:21.1.2024 
RTC_Time: 0:0:0-109(227)| Date:21.1.2024 
RTC_Time: 0:0:0-109(227)| Date:21.1.2024 
RTC_Time: 0:0:0-109(227)| Date:21.1.2024 
RTC_Time: 0:0:0-109(227)| Date:21.1.2024 

You can try to set the 7bit asynchronous prescaler (PREDIV_A) to 31 (0x1F) and the 15bit synchronous prescaler (PREDIV_S) to 1023 (0x3FF). In this case, the resolution will be 0.976563ms. This is quite close, but still not exactly 1ms.

That's why sometimes you will encounter such glitches:

RTC_Time: 0:0:0-475(537)| Date:21.1.2024 
RTC_Time: 0:0:0-476(536)| Date:21.1.2024 
RTC_Time: 0:0:0-477(535)| Date:21.1.2024 
RTC_Time: 0:0:0-478(534)| Date:21.1.2024  <<<<< ERROR
RTC_Time: 0:0:0-478(533)| Date:21.1.2024  <<<<< ERROR
RTC_Time: 0:0:0-479(532)| Date:21.1.2024 
RTC_Time: 0:0:0-480(531)| Date:21.1.2024 
RTC_Time: 0:0:0-481(530)| Date:21.1.2024