stm32f4xx RTC peripheral subseconds for precise timestamp

[harinath]

Posted on May 28, 2014 at 08:48

Hello everyone,

I have ported the following RTC_Calender example to STM32F4-Discovery board.

STM32Cube_FW_F4_V1.1.0\Projects\STM324xG_EVAL\Examples\RTC

I was logging the date & time along with subseconds feature ( as mentioned in stm32f4xx_hal_rtc.h file, its range is 0 to 59). But this value range depends on AsynchPrediv & SynchPrediv of RTC_InitTypeDef structure. I'm using LSI as RTC clock. Page 782 of stm32f4Reference manualRM0090 says: where AsynchPredivis PREDIV_A and SynchPrediv is PREDIV_S. currently I configured AsynchPrediv=0x7F and SynchPrediv= 0xFF I log the date, time in a while(1) loop :

/* Time Format : hh:mm:ss:ss */
buffsize = sprintf((
char
*)aShowTime,
''%0.2d:%0.2d:%0.2d:%0.2d\r\n''
,
stimestruct.Hours, stimestruct.Minutes, stimestruct.Seconds, stimestruct.SubSeconds);

The output is as follows(mm-dd-yy hr:mm:ss:ss):

05-28-2014 01:42:11:255

05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:255 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:254 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:253 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:252 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:251 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 05-28-2014 01:42:11:250 After subseconds reaches to 0, then starts from I'm looking for a precise timestamp for logging data, could anyone here suggest please. Thanks in advance. #rtc #stm32cube #stm32f4

[gk_it]

Posted on May 28, 2014 at 10:08

Setup 32bit timer (TIM5) with 1us tick and reload after 3599999999 (one hour).

Optional on timer reload : counting hours + calendar.

Reading one hour time is fast, just read timer CNT, but with hours + calendar CNT need to be read double time: before read hours + calendar structure and after to avoid hour tick mistake.

[harinath]

Posted on July 17, 2014 at 04:02

Thanks for the explanation.

I couldn't understand 

Reading one hour time is fast, just read timer CNT, but with hours + calendar CNT need to be read double time: before read hours + calendar structure and after to avoid hour tick mistake.

would you explain it please.

[Tesla DeLorean]

Posted on July 17, 2014 at 18:08

When reading a time/date across multiple variables one trick to ensure you aren't at a roll-over event is to read the values twice until they remain the same.