STM32F103C8T6 RTC to get date and time

[soundaryasundaram]

hi, I am using STM32F103C8T6 microcontroller to get current Time and date. I am using Arduino IDE for this project. Since the microcontroller has in-buid RTC, i am using it. I used RTClock.h library. I used the example program "Test_RTClock". In the setup function, i initially set the epoch time by myself using rt.setTime() function. And i did not change anything in the loop function. So, as example, it should print the epoch time for every 1 second.
But, case(1),As i executed the code, i found that the microcontroller prints the correct time at first execution and it takes more than actual 1second to print the next RTCsecond. And again it takes more than actual 1second to Print the next second. and thus IF WE SEE, after few minutes, the MICROCONTROLLER's time is very much delayed when compared to the actual time.
Also if i re-upload (case:2) the code, it prints actual time at first, and then the controller prints delayed time when compared with Actual time.
Also in both the cases, the delay is not same.

First time uploading the code: In first case it takes, 1115 milliseconds to chance a first second and not 1000msec. Then it takes 1405 milliseconds to chance the next second, then it takes 1200 milliseconds to change the next second. here, the millisecond change is random and not 1000ms.
Second time uploading the code: In this case it takes, 1100 milliseconds to chance a first second. Then it takes 1665 milliseconds to chance the next second, then it takes 1455 milliseconds to change the next second. here also, the milli second change is random.
we could see, on every upload, the RTCcounter takes different/random milliseconds and not the actual 1000millisecond.
What causes this random changes ? Does RTC counter doesnot work properly? Somebody kindly help me to fix this issue..

here is my code,

Code: Select all

#include <RTClock.h>

RTClock rt (RTCSEL_LSE); // initialise
uint32 tt;

#define LED_PIN PB1

// This function is called in the attachSecondsInterrpt
void blink ()
{
  digitalWrite(LED_PIN, !digitalRead(LED_PIN));
}

void setup()
{
  pinMode(LED_PIN, OUTPUT);
  rt.setTime(1580410301);
  rt.attachSecondsInterrupt(blink);// Call blink
}

void loop()
{
  if (rt.getTime() != tt)
  {
    tt = rt.getTime();
    Serial.print("time is: ");
    Serial.println(tt);
  }
  }

Regards
Soundarya

[fpiSTM]

Topic moved to proper subforum:

soundaryasundaram uses this library with LibMaple core:
https://github.com/rogerclarkmelbourne/ ... /RTClock.h

Note: I've deleted useless post to not pollute this thread.

[ag123]

if i'm not wrong stm32f103 rtc keeps time to the nearest second. i'd guess between the variations of ms differences it would after all be still the same second or so?
rtc isn't a millisecond timer, it is basically a way to keep the clock time. and in fact setting time isn't always a biggest issue.
the issue is that for some of the pill boards or for that matter crystals. they don't run at 32768 hz. i.e. the crystal is not accurate and it results in timing drifts that can add up to rather big differences say in a month. i've had a crystal that drift 20 minutes per month no less.

the workaround for crystals having large drifts is to use some kind of RTC adjustment.
https://github.com/rogerclarkmelbourne/ ... les/RTCAdj

for issues related to ms drifts, you may like to look at ntp which can compensate for round trip delays statistically
but it still goes back to the same point, stm32f103 rtc keeps time to a second (not ms) and cheap(est) crystals in the wild
don't always keep time at 32768 hz

the rtc is ideal for date/time stamping files e.g. with sd-fat, but isn't quite a high precision timer. for high precision timing,
one may want to calibrate the 8mhz crystal to NTP atomic clocks standards and compensate that 8mhz drifts and probably use that
for high precision timing. i've been wanting to try something that i do not know how to do, how to sync the exact same moment
between devices. if it is possible to achieve sync across devices, it may be possible to say use like 2 - 5 blue pills and do adc sampling
to achieve sampling rates far higher than 2 msps e.g. if you have 5 blue pills perhaps achieve 10 msps interleaved?
the hard part is to achieve that sync and offset which are in the order of nsecs.
(i'm thinking it may be possible to attempt that using the hardware timers, they are elaborate hardware which could make this possible)

[soundaryasundaram]

if i'm not wrong stm32f103 rtc keeps time to the nearest second. i'd guess between the variations of ms differences it would after all be still the same second or so?

No. It changes. Initially i set the time as 1580480000, when i upload the code for first time, i could see the second has changed from 1580480000 to 1580480001 only after 1010ms and not after 1000ms. This means my controller clock is slow by 10ms when compared with the Actual clock time. And this 10ms delay is not same for every upcomming seconds. And if delay remains same, then the next second must comes after 20ms. But for my case, next second(from 1580480001 to 1580480002) appeared after 977ms.

From 1580480000 to 1580480001 = 1010ms (i.e, 10ms slower from actual time)
From 1580480001 to 1580480002 = 0977ms (i.e, 977ms slower from actual time),..

To clearly understand the ms delay,
I again re-uploaded the code by initially setting time as 1580480010. when i run the code, i could see the second has changed from 1580480010 to 1580480011 after 1221ms and not after 1000ms. That means my controller is delayed(slow) by 221ms when compared with the Actual clock time.
Then, from 1580480011 second to reach 1580480012 second, it takes 870ms.

From 1580480010 to 1580480011 = 1221ms (i.e, 221ms slower from actual time)
From 1580480001 to 1580480002 = 0870ms (i.e, 870ms slower from actual time),..

and this delay (ms) increases randomly for the upcomming seconds too , and at some point my controller is nearly slower by minutes and hrs too.
I am so confused about this random delay.

So kindly clarify me, does Crystal inaccuracy is the reason for the random initial delay on both cases? as like: on 1st upload = 10ms and same code on 2nd upload = 221ms.?

[stevestrong]

You have to remove the pins on PC14 and PC15 in order to have correct RTC times.

[ag123]

how did you measure the ms for each rtc second? using systick?
one of those things that is happening when you use a running codes to measure the ms time of another thing is, there are interrupts that happens between 2 separate reads of systick.. if for example an interrupt handler say usb, usb serial or something else takes some time to run, by which time it hands the thread back to your code many ms could have lapsed between the time you first read systick - then interrupt handler hogs the cpu takes ms off that - hands it back to your code/thread many ms later.

in your example, one of the ms interval is 1010 ms (i.e. +10ms) and the other 977ms (i.e. -23ms) it would seemed it is slower in one and faster in the second case. if you are timing the printed output say on the host, that probably isn't too accurate and you may be better off measuring the rtc interrupt between 2 systick intervals. that'd likely have smaller variations between the different rtc seconds.

as for my case, i'm not too bothered with ms drifts than i'm with drifts over an accumulated period of time e.g. say a week to a month, it shouldn't drift too much. initially i've a crystal that drift significantly by about 20 minutes per month. hence i developed that adjustment example to compensate for the rather long drifts. the adjustments are adequate for my purpose and i managed to bring the drifts below a minute per month.

[soundaryasundaram]

You have to remove the pins on PC14 and PC15 in order to have correct RTC times.

Sir,I read STM32F103xxxx datasheet. In that, the RTC clock can be supplied by any of these three HSE or LSI or LSE.. I have used LSE in the code. You can see it in program as
RTClock rt (RTCSEL_LSE);
Also in the schematic diagram of STM32F103C8T6, i had seen PC14 and PC15 are the pins that are connected to 32.768kHzExternal oscillator. So we cannot change anything in this part, because this supplies the clock to RTCblock.

Kindly tell me, is my understanding correct?

My question is why we have to remove the Pins on PC14 and PC15?? Since i am new to this world, kindly bare with my questions and make me to understand the concepts..

[ag123]

you can try to vary your code to measure the ms intervals e.g.

Code: Select all

#include <RTClock.h>
RTClock rt (RTCSEL_LSE); // initialise
uint32 tt;
uint32 last_ms = 0;
uint32 period = 0;
#define LED_PIN PB1

// This function is called in the attachSecondsInterrpt
void blink ()
{
  digitalWrite(LED_PIN, (~ digitalRead(LED_PIN)) & 1);
  uint32_t ms = millis();
  if(last_ms == 0) {
     last_ms = ms;
  } else {
    period = ms - last_ms;
    last_ms = ms;
  }
}

void setup()
{
  pinMode(LED_PIN, OUTPUT);
  rt.setTime(1580410301);
  rt.attachSecondsInterrupt(blink);// Call blink
}

void loop()
{
  if (rt.getTime() != tt)
  {
    tt = rt.getTime();
    Serial.print("time is: ");
    Serial.println(tt);
    Serial.print("period : ");
    Serial.println(period);
  }
}

a sample run on a blue pill stm32f103c8

Code: Select all

time is: 1580410304
period : 1000
time is: 1580410305
period : 1000
time is: 1580410306
period : 1000
time is: 1580410307
period : 1000
time is: 1580410308
period : 1000
time is: 1580410309
period : 1000
time is: 1580410310
period : 1001
time is: 1580410311
period : 1000
time is: 1580410312

errors is less than 1 in 1000

[stevestrong]

Again:

You have to remove the pins on PC14 and PC15 in order to have correct RTC times.

[ag123]

see 2 comments above, i'm getting near perfect rtc clocks on a blue pill, the pins are soldered but left un-connected

among the things you'd need to check, did you solder a 32k crystal at PC14 and PC15?
in particular if you are using a maple mini (clone), your led pin PB1 seem to suggest a maple mini (clone)
maple minis (clone) do not have that 32k crystal soldered
and like steve mentioned, you should not connect any thing else at PC14 and PC15

and it isn't sufficiently clear how you measure the ms intervals for the rtc clocks.
i'm using millis() which is basically the systick interval. that is from the 8mhz crystal - rather 72mhz system clock and
is likely more accurate than 'cheap' 32k crystals

using that alone in the modified sketch 2 comments above i'm getting better than 1 in 1000 ms precision on the RTC clock.

i've been using 'cheap' ebay 32k crystals and they work just well, except for the constant drifts from the exact 32768 hz.
https://www.ebay.com/sch/i.html?_from=R ... 8&_sacat=0
hence i used my adjustments to compensate for large drifts over time
and i didn't use any caps or load capacitors, i simply solder the 32k crystals to the maple mini (clone) PC14, PC15 pins and they just work

there are also those epson 'legendary' 5pf 32k crystals which if you read the specs some of them give a 20ppm specs which is pretty accurate
(that is about like 10 minutes in a whole year)
https://octopart.com/search?q=32768+epson&currency=USD
ST did insist on a 5pf 32k crystal, and based on what i understand, those 5pf 32k crystals are more accurate
https://www.st.com/resource/en/datashee ... f103c8.pdf
e.g. those from epson etc are precision machined parts to exact 32768 hz probably to very high precision. though not necessarily temperature compensated

for the 'cheap' ones, u'd just take your chances with how accurate or precise it is