A linear RTC seconds counter on STM32F4

[bad client]

Posted on June 27, 2018 at 16:02

Hi folks,

I have been RTC on STM32F1 for a very long time. I have been using the RTC seconds counter (and subsecond counter)  to calibrate RTC continuously (i.e. every day) on-the fly against a reference time (derived from 50-Hz mains).

Now I want to move on to newer MCUs like F3 or F4, which come with a different RTC module that no longer support RTC counter register.

The question is, what would be a proper/best way to emulate/simulate or replace RTC counter function on those newer chips?

Sincerly,

Rob

PS: 1) Have LSE with nominal freq 32768hz. 2) And I want to avoid a counter derivation from calendar module if possible.

#counter #rtc

[Tesla DeLorean]

Posted on June 27, 2018 at 18:33

You can connect LSI/LSE internally to TIM5 (see RM0090), don't think you can use it in external clock mode and prescale it, but might be able to feed the TIM5_CH4 as an internal TRGO/ITRx node.

I use the SysTick to drive a millisecond, and UNIX style second counter, and do my timing and calendaring from that.

[waclawek.jan]

Posted on June 27, 2018 at 20:49

I want to avoid a counter derivation from calendar module if possible.

What does it mean? You don't want to perform a reverse-calculation from the time/date to a running counter? And you don't need the battery-backup feature, but still want to use LSE for some reason (don't have HSE)?

As Clive said, LSE is usually brought to one of the input channels of one of the timers, usually to a relatively useless one and multiplexed with other signals that get into way if you want to use them too. In the 'classic' 'F4 mentioned by Clive, LSE on CH4 of TIM5 can't be used in any other way than the intended one, to calibrate HSI against LSE (it can't be brought out as TRGO, again, by an inexplicable design choice, only *compare* can act as TRGO on CH2-CH4). This IMO is a dead-end.

Another option would be to bring out LSE to a pin through MCO and bring it back to a timer as external clock. Wasting 2 pins is IMO rarely justifiable.

I personally would maintain as much RTC functionality as possible. Perhaps a good tradeoff would be to run the RTC normally, benefiting from LSE, battery backup, fine adjusting, and even perhaps the 50/60Hz sync facility (but that's a two-edged sword); while counting seconds in software in a Wakeup interrupt. The subseconds-seconds relationship is not atomic anymore (is it on the 'F1 at all?), but that can be pulled out in software, if needed, even if it's not that trivial.

my 2 eurocents

JW

[bad client]

Posted on June 28, 2018 at 10:32

Thank you both Clive and Jan,

Let me narrow the domain of my question: It is not about the whole RTC function, which already works fine. It is just about a long time calibration, where I have already one reference second counter (with its help I start a measurement interval of let me say 24hours), and then I measure the RTC seconds elapsed in the same same interval, and then calculate the deviation of RTC from my reference time. (I already know how to do all the measurement calculations and how to do RTC smooth calibration, etc.) My question is only this: how can I obtain the number of seconds RTC has counted, in a certain time interval that is defined by my reference second counter.

What about Alarm function of the RTC?

I thought I could configure an periodic alarm interrupt with a second duration and let the isr  to increment a free second counter variable, that would give number of seconds since system start; pretty much like the SysTick function.

Thanks again

Rob

PS: I intend to avoid using calendar conversion due to calculations and ugly conversions involved because of STUPID summer time changes.

[waclawek.jan]

Posted on June 28, 2018 at 14:22

I thought I could configure an periodic alarm interrupt with a second duration and let the isr  to increment a free second counter variable, that would give number of seconds since system start;

Should work (I suggested wakeup above but alarm should be fine too).

PS: I intend to avoid using calendar conversion due to calculations and ugly conversions involved because of STUPID summer time changes.

I recommend *not* to do these changes by actually changing the RTC's time. Rather, keep RTC maintaining UTC time, and do every correction - summer/LST, time zones - in software.

JW

[henry.dick]

Posted on June 28, 2018 at 13:13

'

what would be a proper/best way to

emulate/simulate or replace RTC

counter function on those newer chips?'

what's best is relative.

If the board is continuously powered, I often use a (high speed) timer interrupt to increment a counter and use the time.h functions to convert it to time/date. in some applications, I have actually used the rtc interrupt to do the same, forgo the built-in rtc counter module.