Where is STM32 RTC counter value? (Not F1 family)

[Martijn Jonkers]

Posted on December 08, 2016 at 20:29

Hi,

In the scheduling system we use we need a simple 32kHz low power counter value. 

Exactly like in the stm32F1 family is present.

But in any other family, the RTC registers are replaced by Time and Date registers.

I am able to covert the Time register back to a counter value that overflows every 24 hours and add the number of days.

This way I can get a 32 bit counter value running at 32kHz.

But it is an enourmous hassle and it takes a lot more processing time than needed.

Is there a simple way to get a low power 32kHz counter value, so we can use it for our scheduling?

We aim to disable the HSI/HSE/PLL clocks when no tasks needs to run, but keep de Low power LSE/LSI running to wakeup from stop mode.

We do not need any timestamp values like year month day hour minute second.

Thank you!

[Tesla DeLorean]

Posted on December 08, 2016 at 22:58

The new designs use a calendaring RTC that uses BCD counters, there isn't a free running counter any more. There is usually one TIM connected to the LSI or LSE clock, but is not low power.

[ST Renegade]

Posted on December 08, 2016 at 23:10

Can you explain a bit more in detail what are you actually trying to achieve? Why do you need the counter etc.? Maybe there is another solution, but from your description it's not clear, what is your app doing. Which device are you using etc.

Do I understand that you put your device into sleep and you need a 'timer' running while asleep to wake up the device after some defined time or so?

Otherwise the answer is simply no, the register is not present anymore. I guess because the F1 was the very first device, it was designed this way and the next devices contain the Time/Date registers. Honestly what I would expect from an RTC unit, that it will contain these Date/Time registers instead of an counter register so I don't have to calculate the date/time over and over again, because that's what I expect from such a peripheral and puts an unnecessary load to do it in SW.

Have a nice day,

Renegade

[ST Renegade]

Posted on December 08, 2016 at 23:12

Just to add, some devices include a low power timer... But those are Lx devices if I remember well.

[Martijn Jonkers]

Posted on December 09, 2016 at 08:33

I do not need the RTC features. I just need to able to run a timer, and use wake from stop/sleep, without the HSI/E running. From what I understand, the RTC is the only LOW POWER timer.

I can keep it running using an F0 device with ony 5uA current consumption without loss of application functionality.

Our scheduling system determines the number of ticks it can sleep until the next task is due, it forwards this number to the timer and the timer needs to be able to generate an interrupt on that specific time.

I can use a normal timer for this, but then it is not low power anymore.

Most of our applications do not need the date/time features, just a counter is way easier.

[waclawek.jan]

Posted on December 09, 2016 at 10:06

Martijn,

Several workarounds may be possible:

• use the periodic wakeup rather than alarm, reprogramming the the timeout at every event if needed (up to 36 hours with normal 1s tick)
• consider the prescalers as part of the calculated timeout, i.e. don't run the RTC in seconds (since you don't need the RTC features (running time))
• at every event, reprogram the current time/date to 1.Jan 00:00:00, this simplifies the calculation if timeout is up to 31+28 days

Renegade,

It was a poor design choice to abandon the counter. How hard it might've been to have implemented both counter and calendar, either in parallel or as a user choosable alternative? Granted, more transistors more consumption, but I believe the difference might've been negligible if approached carefully.

I for one, *do* use the clock/calendar in the 'usual' way, but as I need both UTC and local time simultaneously, the only sane approach is to convert running clock (considered as UTC) to linear ('unixtime' or similar), perform the timezone shifts as needed, and then convert back to calendar/clock - so there's no benefit in keeping calendar/clock in this case either.

JW

[Tesla DeLorean]

Posted on December 09, 2016 at 14:37

I too liked the 32-bit counter and the linear progression of time, however I'll observe that very few people can write and test calendar conversions properly, even across a 1901..2099 range where every year divisible by 4 is a leap year.

[George X]

Posted on January 20, 2017 at 09:01

Just to clarify: The year 2000 was not a leap year, even though it is divisible by 4.

I'd rather go with a counter which let's me do my own mistakes than having to fight with a calendar RTC. A calendar RTC makes it almost impossible to implement DST.

[waclawek.jan]

Posted on January 20, 2017 at 10:22

Just to clarify: The year 2000 was not a leap year, even though it is divisible by 4.

Of course it

https://en.wikipedia.org/wiki/Gregorian_calendar

. 1900 wasn't and 2100 won't be.

This mistake may explain why

very few people can write and test calendar conversions properly

JW

[EDIT] Interestingly enough, the year 2000 was

http://www.bluewaterarts.com/calendar/NewInterGravissimas.htm

http://www.bluewaterarts.com/calendar/NewInterGravissimas.htm

:

Anno vero

MM

, more consueto dies bissextus intercaletur, Februario dies

XXIX

continente, idemque ordo intermittendi intercalandique bissextum diem in quadringentis quibusque annis perpetuo conservetur.

[George X]

Posted on January 20, 2017 at 11:13

Got me, you're right. Luckily my calendar implementation knew better than me.

Anyhow, my point about implementing DST on top of calendar RTC remains.