rogerclarkmelbourne / Arduino_STM32

Arduino STM32. Hardware files to support STM32 boards, on Arduino IDE 1.8.x including LeafLabs Maple and other generic STM32F103 boards
Other
2.52k stars 1.26k forks source link

RTClock running very very slow #572

Closed BNNorman closed 5 years ago

BNNorman commented 5 years ago

I've got some STM32F103C8's from Alieexpress. I have a project to monitor air quality and originally used a DS3232 to provide a timestamp. Then I thought I'd try to use the STM32's built in rtc to free up the DS3232 for other things but I noticed some strange behaviour - the rtc in the stm32s I have appear to be running very very slowly.

To check this out I have a simple stripboard with a socket for the Blue Pill, a 3v battery connected to vbat and a DS3232 connected using I2C.

My Sketch sets the STM32 rtc and the system time from the DS3232 during setup. So far so good.

The sketch then outputs the times every 5 seconds using the DS3232 as the loop time control. The System clock keeps step with the DS3232 but the STM32 rtc seems to have a mind of it's own. I have attached a screen shot - in column H you can see that the difference between each 'error' in column G is, on average, an accumulating 3 second lag. I don't know why the System,RTC and DS3232 aren't exactly the same at the very beginning but the STM32 rtc is clearly running slow.

image

I read, on the net, that the soldering of the 32.768kHz crystal might need rework on these boards so I've done that - and the two capacitors (C9/C12 under the board). But it made no difference.

I've been side tracked by this for two weeks - no-one else (on the web) appears to have a problem but I can't see any fault with my sketch (below). I have 'played' with the prescaler value and can improve the situation using a value of 12781 instead of 32768. I calculated the pre-scaler based on the time error as a fraction of 32768.

It's difficult to scope the XTAL output without upsetting the frequency so I'm not able to accurately assess if the crystal is running at the correct frequency - but it's way way off if not. I mean losing tens of seconds in as many minutes.

My sketch is below. If anyone can help me resolve this I'd be eternally grateful as will my maker buddies looking to use the BluePills for LoRa/LoRaWan applications.

Regards Brian

`/* STM32_RTC_VS_DS1307

include

include

define LED PC13 // blink during loop

// Using the DS1307 library - works fine reading DS3232 // original DS1307RTC clashes with RTClock - renamed RTC to RTC2

include

// STM32 built in clock

include

RTClock stm32rtc(RTCSEL_LSE); // initialise the RTClock using the 32kHz xtal source

char logMsg[100]; // message buffer tmElements_t tm; // used by

uint8_t LED_STATE=LOW; time_t startTime=0;

/***

}

/***

void loop() { LED_STATE=!LED_STATE; // LED flasher digitalWrite(LED,LED_STATE);

time_t t0=RTC2.get();

while((RTC2.get()-t0)<5) yield();

RTC2.read(tm);

// output a status message snprintf(logMsg,sizeof logMsg,"SYS Time is %0.2d:%0.2d:%0.2d, RTC time is %0.2d:%0.2d:%0.2d, DS3232 time is %0.2d:%0.2d:%0.2d", hour(),minute(),second(), stm32rtc.hour(),stm32rtc.minute(),stm32rtc.second(), tm.Hour,tm.Minute,tm.Second);

Serial.println(logMsg); }

`

BNNorman commented 5 years ago

Further info, in case anyone has suggestions. I have 6 STM32F103C8 units and have tested them all with the same sketch. 3 run slow, two run fast and one seems to be keeping step with the DS3232 RTC. Strikes me it's a variation in crystal frequency and not the RTClock library. Room temp is stable at a comfortable 24 deg C. I have reworked the solder joints on ALL the units 32Khz crystal and C9/C12. Unfortunately I don't have a really good scope (just a software scope - DS120) to monitor the XTAL OUPUT on PC15 - even tried making up a buffer amp using a LM358 but the extra Dupont breadboard wires cause mains pickup - though I can see the XTAL signal but it's too hard to estimate the exact frequency (looked nearer to 25kHz to me).

stevstrong commented 5 years ago

http://stm32duino.com/viewtopic.php?f=3&t=4151 http://stm32duino.com/viewtopic.php?f=2&t=4050&p=48682&hilit=rtc+xtal#p48682

BNNorman commented 5 years ago

Thank you, I have also found the STI document detailing rtc calibration. Since this is clearly a hardware issue and appears to vary from unit to unit based on XTAL frequency and not software I'll close the issue.

BNNorman commented 5 years ago

Final word - it was the header pins on PC15/14 of the blue pill - removed them from all my blue pills and now they keep time.

rogerclarkmelbourne commented 5 years ago

Thanks for the "final word". Thats well worth knowing.

nandoperu100 commented 5 years ago

Final word - it was the header pins on PC15/14 of the blue pill - removed them from all my blue pills and now they keep time.

hi.. how you removed (hardware of Software ) could you explain , because I have the same problem..Thanks

BNNorman commented 5 years ago

Hardware. If the pins connect to strip board tracks it adds capacitance which messes up the clock frequency. If using headers just remove the pins so that can't happen.

nandoperu100 commented 5 years ago

Thanks so much !! . I solved the problem according your instructions

delpitec commented 3 years ago

Final word - it was the header pins on PC15/14 of the blue pill - removed them from all my blue pills and now they keep time.

Very good. That worked for me. Tks

patenkoanton commented 2 years ago

Hi Brian, your solution has worked for me (Bluepill board). I didn't even completely remove the header pins, just cut them with pliers. I guess for better results I have to completely unsolder the header pins and remove the remaining solder from the board.

I'm wondering though if there's any better solution for this, i.e. how do we remove the parasite capacity of those header pins without removing the pins themselves? Like grounding those pins (random idea) or anything like it?

BNNorman commented 2 years ago

If you look at the pcb schematic you'll see you have no choice but to not solder those pins. They are the clock signals so grounding those pins will result in no clock at all.

reiyawea commented 2 years ago

Final word - it was the header pins on PC15/14 of the blue pill - removed them from all my blue pills and now they keep time.

I ran into the same problem on STM32F401 breakout board (aka Black Pill) -- RTC becomes slow when powered by VBAT. I removed the header pins of PC14&15 and it worked! Thank you very much for your precious experience.

sup3rtemaki commented 1 year ago

Thank you very much Brian, trimming the pins PC14/PC15 of my Bluepill solved the problem!

mshafeeqkn commented 3 days ago

I have the sam problem. Can anyone share where the header pin actually located is? I've seen the header pin for BOOT0 and BOOT1. But where is for PC14 and PC15

mshafeeqkn commented 3 days ago

OMG, it's not a jumper. I removed the bluepill from my breadboard and now works like a charm

BNNorman commented 3 days ago

Clearly labelled here, bottom right

https://miro.medium.com/v2/resize:fit:1400/0*r7Y5Z7LXcx2Bmy3f.gif