3 years, 12 months ago.

weird (at least for me) set_time behavior

I've asked some question here, https://developer.mbed.org/users/petereiso/notebook/cc-time-functions/?c=22817 but I have more observations. Clue is, that


starts RTC with value, I believed is UNIX 0. It is not - few seconds later I am reading values (casted to hex) like 12 F4 92 B4. When I tried to read it with PHP date() function, It returned Friday 1st January 2066 01:00:25 AM. However, when I


PHP date() function returns Wednesday 28th October 2009 12:36:01 PM, which is proper string for sent timestamp (few second offset due to callbacks etc). What am I missing?

2 Answers

3 years, 12 months ago.

Seems you have an STM, and quick look in the RTC source code (https://github.com/mbedmicro/mbed/blob/master/hal/targets/hal/TARGET_STM/TARGET_STM32F4/rtc_api.c) shows that they apparantly store years from 2000. So no setting time to before 2000.

Accepted Answer
3 years, 12 months ago.

Is this on the STM platforms? I noticed the RTC behaviour a bit strange when setting to zero, exactly what you indicate, whilst works okay on Freescale(NXP) and SiLabs, zero is zero. However setting the correct time does work fine, that's if you are using the RTC for real time calendar. If you are using the RTC as a general timer then you will need to check the Mbed RTC lib's to see what their idea of 'zero' is, it will be different.

actually I was going to find "fast and easy" way to check, if RTC was initialized, then if no - call NTP or GPS (got both) to update time. I need RTC to provide timestamps for data samples, so it should do the job.

posted by Michal Wisniewski 29 May 2016

What a coincidence, I was doing exactly the same thing the other day. As Erik indicates ST have added offset on the time settings. If you remove the offsets including the month +-1 you will get zero if you set zero. One good thing is the RTC no longer resets on power down or nRST if you have a back cell connected to vBAT.

posted by Paul Staron 29 May 2016