cancel
Showing results for 
Search instead for 
Did you mean: 

RTC second advanced and SSR greater than PREDIVS

A Maq
Senior

Hi,

I​ am using stm32f779 RTC upto subseconds granularity that is using SSR register value for giving upto milliseconds level of time output .

The scenario is such that there is external time source ( network clock) to which I synchronise RTC by updating it's time every hour in order to compensate for time delay or advance ​due to RTC clock drift.

I have managed to get advance and delay of time based on drift into time, date and sub second registers using synchronisation section guidelines of Stm32f7 reference manual. ​

Issue is on using SUBF bits of SHIFTR register when we advance RTC SSR register our second get one plus ahead of intended time i.e if we updated with 6 second it becomes 7 and ​our SSR register is above PREDIVS on each shift operation.

Now I understand that is expected behavior based on Reference manual but there is no mention about how to deal with this situation.

Does only subtracting one from seconds will be enough after each such shift operation or we need to do something about bringing SSR value back to Less than or equal to PREDIVS register value?

3 REPLIES 3

> Does only subtracting one from seconds will be enough after each such shift operation

Yes, for millisecond calculation you then use SSR-PREDIVS.

JW

@Community member​  thanks for your response.

Even if the value of SSR is larger than PREDIVS it is valid?

As soon as I get returned from update and print that value rather than 3 digits output it shows 6 digits for milliseconds (that only happens straight after update to SSR)​.It comes back to normal shortly then always we get milliseconds printed in 3 digits until next update or shift operation for SSR.

Second problem may arise is that if second subtracting sometime it may lead to need for subtracting one from minutes and hours that can require same for day and all other values. Such as if it is 3hr:00:00 or anything similar.

There's no simple solution to this problem.

JW