Why ST keep implementing RTC as calendar instead of RTC binary counter?

[PSoco.1]

I am not an ST expert nor RTC expert, whatever that means. but I have seen several implementations made by other companies and I have to say RTC as counter (the HW that provide interface to a posix compatible timestamp, usually 32 bit seconds + 15 fractional bits) is faster (at driver level the posix time value is written and read without conversion to expanded form), math friendlier (non trivial time calculation is really hard in expanded form so everyone tends to use posix form converting it) and I suspect since the lower amount of transistor, much simpler, lower power and cheaper. I never liked the RTC calendar HW implementation since it is overcomplicated in both HW and driver and I cannot see any benefit on such implementation. I understand that calendar implementation make sense 30 years ago on 4 bit processors when RTC was mainly used to produce a digital clock; now today cpu are used mostly for IoT and other device that are not just a simple clock printing the date/time over 7 segment LED display, they do calculation so conversion take place often, usually way too often removing any benefit from having HW calendar. can someone name a good readon to stick with calendar HW implementation? why STM32 keep feeding us an RTC calendar in a STM32H7 with CM7 @ >500MHz? thanks, if someone can provide any good reason about this nonsense. by the way, truly love STM32H7, amazing CPU amazing feats, and maybe because I love it, I spend the 10 minutes asking about this odd implementation choice. hope to see in the future a review on ST RTC, a combined calendar + counter so that ST can make happy both users, or maybe better, just ditch the calendar, since with HAL drivers customer won't notice the upgrade, and those do not use HAL will be happier to develop a much simpler and trivial driver.

[PSoco.1]

No I have not, I will verify if this is feasible later. LPTIM sounds a valid option

[PSoco.1]

all timers that can be clocked from LSE/LSI are 16 bits. so no, it is not possible

[waclawek.jan]

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

JW

[MBin]

@PSoco.1​ I have the same frustration !

All this while I thought Calendar is the way forward, given how sophisticated it is as apposed to a simple counter register. I'm so glad I stumbled upon this thread !

I have no use of Calendar at all, I have been converting Calendar to 32-bit Unix timestamp, it was slow. I'm in Stop Mode all the time, so I can't use SysTick as timestamp, I can't use LPTIM either since it is occupied by my encoder.

Finally I had enough and use the Systick interrupt to increment a uint64 counter which I initialized with a real timestamp(calculated from RTC). I also have to re-sync the counter after waking up from Stop Mode. So now rather than always having to calculate timestamp, I just read my uint64 counter.

This solves haha.

[waclawek.jan]

Nice trick, thanks for sharing it.

JW

[PSoco.1]

Yes, I applied similar tricks. but I cannot stress enough how a trick is still a trick. why should we have to use 3 timers to implement something it should be done with just one, how is that our timestamp and our "64bit systick-based timebase" must be synchronized manually with complex conversion funtions in the middle (what about drift, SNTP and other stuff) ? most embedded devices are getting smarter and more connected to internet or other networks. connectivity goes in tandem with security. security uses and abuses RTC for PKI expiry date/time, licensing, tokens for permission/authentication. IoT will be a common thing, security is already common but very far from perfect. currently ST misses 2 important peripherals. the first is key management (which I don't understand why ST does not implement it while other manufacturers do) that is, an extremely "trivial" HW that provide some zeroisable (from TAMP peripheral) registers to hold some master keys lockable from secure bootloader / ROM bootloader / calculated and combined with some more complex implementation with let say OTP and more (server injected Master key?). CRYP HW able to select derived keys with a direct and internal bus, so the CPU cannot read the key, but can only use it. then the second part is generate a sequence of operations like HMAC/AES potentially accessing other currently available HW, like monotonic counters, RTC, RNG and more (OTP values like the PID?). with all this some server may provide "authenticated scripts" that device can only execute to generate some output, for example a RTC SAS token, a licence key to access some data (OTFDEC? which currently is terrible and unusable, that is a whole chapter) you will always have a firmware operating these parts and the flaw will always be that someone can exploit some bug and break everything. currently to make a firmware (truly) secure is a huge task. ST should be smart and provide tools so that it becomes easier to secure their customers products more integrated HSM and less software SM. calendar is in the middle and will be removed on powerful and secure devices, impossible otherwise. you have to connect the dots to see the image

[waclawek.jan]

@PSoco.1​ ,

Maybe you should have a look at the newest STM32U5 https://www.st.com/en/microcontrollers-microprocessors/stm32u5-series.html . They do have implemented the binary mode in RTC, btw.

JW

[PSoco.1]

yes, this is what I am talking about, ultra low power, decent security (now with PKA yea 🙂 ) and good performance

[PSoco.1]

it has Hardware Unique Key (HUK) !!! very cool, finally ST is back on top