Have you noticed the Binary mode of RTC v3?

Hello waclawek.jan,

Thank you for your question/observation.

If you look at the table 5 of the AN4759 you will see which STM32s are actually proposing the binary mode.

It is not available for the STM32G0x0 value line, STM32G0x1 line, STM32G4 Series, STM32L4P5 and L41xxx lines, neither for the STM32H7A3 line. But it is for the STM32WL Series.

The best way to check if binary mode is available for your product remains to refer to the RTC section of its reference manual.

Also, I would not describe binary mode as an alternative to calendar. Section 2.2 of the AN4759 can be consulted for more details. Below is a part of it:

"A particularity for the RTC3 is the availability of a binary mode. In this mode the time and date BCD calendar is disable but the sub second register (SSR) of the RTC is extended to 32-bit instead of 16-bit in normal mode and is used as a binary down counter. This feature allows to have a 32-bit counter in low-power mode (the modes' compatibilities are the same than for the other features of the RTC) and to avoid the BCD to binary conversion in case it is required by an application."

Regards,

Adam

Hi Adam,

This news makes me sad (and yes I'm guilty of not reading AN4759 back to back).

And it's a pity.

A simple binary counter in the STM32 RTC is one of the features long needed for many real-world applications of the RTC - in fact probably for all except trivial local timekeeping.

JW

Former Timex engineer of 7 years here... (Yes.. the watch company that specializes in timekeeping).

BCD Mode of RTCs is a relic of the past, and I am glad that ST has decided to upgrade their ancient RTC IP for newer chips. Too little too late for me right now though. I was the one who implemented all the timekeeping stuff in the advanced watches for all those years and we never touched BCD mode of any MCU offering it and opted to just do a unix like timestamp, because everything is infinitely easier. How did we do this on the ST chips with the ancient RTC? We of course had to live with a hack of only using 15 / 16 bits of the sub seconds and accounting for the rollovers ourselves. We hacked the RTC into a BCD counter that could last around 32 seconds without having to service it. The needed resolution was only 1ms, so we used the prescaler so that every tick was 1ms.

With that said:

ST, I am glad you decided to take a step into the modern world and upgrade your ancient RTC IP. Never thought I would see the say where you touched any of your existing old(er) IPs like this. However, you still screwed up. Will you PLEASE, PLEASE, I am begging you, add the darn synchronization interrupt bits for the WUTWF, ALRAWF / ALRBWF flags? Your RTC IP requires you to sit there and poll those bits to be allowed to update the registers. "Only 2 RTC clocks" is NOT acceptable when using a 32kHz clock. As your chips get faster, such as with the U5, do you honestly think I want to waste up to (160 * 60us) ~ 10,000 clock cycles doing nothing? Come on guys, really?

Your LPTIM IP has the synchronization flags for reading and writing the CMP and ARR registers. Unfortunately, the chip I am using right now (L162... long story) does not have an LPTIM, otherwise I would be inclined to just throw away the RTC and use that for my low power binary counter. Just add the synchronization INTERRUPT flags to the RTC IP and any other IP that needs this kind of synchronization. I'll even accept registers added to the end of the block like you did here to keep compatibility. Also, make the LPTIMs 32 bits. You cannot convince me that adding the extra transistors for the extra bits is going to be a huge cost due to the fact the timer does not have a lot of functionality.

https://community.st.com/s/ideazone#0873W000000blYLQAY

[EDIT] https://community.st.com/s/idea/0873W000000blYLQAY/detail courtesy of st+salesforce unable to maintain structure and links.

JW