STM32F373 RTC is accurate with VBAT but not when power is on

Forum|Forum|5 years ago
May 27, 2021
11 replies
3983 views

The RTC looses 15 min every 8 hour aprox when the main power is on. I have selected the LSE as the RTC clock, as i show in the images, and i have a 32.768 Khz 10 ppm crystal with a 9 pF load. I thought that maybe it was due to a bad match of the crystal capacitors but the RTC works fine when the main power is off! I really dont know what is going on... Thanks in advance.

This topic has been closed for replies.

Best answer by waclawek.jan

> counts 21,22,23...and suddenly jumps to 31,32...But i dont know if it is normal.

No, this is not normal. I reiterate my above recommendation:

review the area around the crystal - aren't there any high-current track nearby? Are tracks short, especially ground? You can try to output the LSE to a pin (MCO or similar, if there's such facility on the 'F373) and observe using logic analyzer if it's regular, etc.,

You may also want to selectively remove parts of your code which exercise pins/tracks which are in the vicinity of the LSE circuitry, or which control high power/high frequency outputs.

JW

waclawek.jan

Super User

Do you switch off/on or reset in any other way the 'F373 often?

The Hal RTC init sets the INIT bit in RTC, which causesthe subseconds to be cleared. The net effect is, that each reset results in average in half a second to be "lost". Search here on the forum, this is a recurring theme.

JW

DCajigalAuthor

Associate III

I have seen this issue but i dont reset or swith off the F373. It spends 8 hour power on and it looses 15 min aprox, after that it spends 8 hour power off and it does not loose any minute.

waclawek.jan

Super User

As an experiment, remove any code related to the RTC from your program - once enabled, it keeps running and you still can read it in debugger (of BYPSHD is cleared, you may need to read it twice, but that's just a detail). Now run your code for a day - still not good?

If not, review the area around the crystal - aren't there any high-current track nearby? Are tracks short, especially ground? You can try to output the LSE to a pin (MCO or similar, if there's such facility on the 'F373) and observe using logic analyzer if it's regular, etc., but this is a lengthy procedure with unsure results.

JW

DCajigalAuthor

Associate III

In the program i call HAL_RTC_GetTime and HAL_RTC_GetDate several times per second, in order to refresh the date and time of the system. I have tried to user this functions only when i press a button and it seems that doing this the system does not loose time. Could this be the problem? In that case how could i refresh the date and time continuously?

waclawek.jan

Super User

> I have tried to use this functions only when i press a button and it seems that doing this the system does not loose time.

These functions alone shouldn't do anything harmful. You ought to read date always after reading time, though, unless you have BYPSHD set.

Did you block out something else?

JW

DCajigalAuthor

Associate III

I was reading already the date after the time. But now i am trying to read it two times each. I am going to be testing it this week so i will keep you inform. Thank you very much

waclawek.janBest answer

Super User

> counts 21,22,23...and suddenly jumps to 31,32...But i dont know if it is normal.

No, this is not normal. I reiterate my above recommendation:

review the area around the crystal - aren't there any high-current track nearby? Are tracks short, especially ground? You can try to output the LSE to a pin (MCO or similar, if there's such facility on the 'F373) and observe using logic analyzer if it's regular, etc.,

You may also want to selectively remove parts of your code which exercise pins/tracks which are in the vicinity of the LSE circuitry, or which control high power/high frequency outputs.

JW

DCajigalAuthor

Associate III

Okay, i am going to do some tests in the hardware to see if i find the problem. Thank you very much for the answers

DCajigalAuthor

Associate III

In the end it really seems like a hardware problem. The MCO output is not stable when i turn on or off some peripherals...So i will try to be more careful with the RTC in the next design and see if the problem dissapears. Thanks for the help