STM32G030 RTC LSE clock instability

[NiTr0man]

I tried to use internal RTC with LSE clocking in device which has GSM/GPRS module (GSM part decoupled from MCU part by ferrite beads in power lines and resistors in data lines). In first PCB revision (no separate ground region under crystal) I noticed significant RTC slowdown at GPRS transactions (0.2-0.4 seconds at each GPRS data transaction, when I soldered wires to GSM part ground and VCC pads - clock slowdown is increased). I've fixed board layout according to design recommendations (separate ground regions, ground traces around quarts lines, extra ferrite bead in CPU power line) but it doesn't affect clock instability at all.

Vcc is decoupled to ground after ferrite bead by 22pF and 100nF capacitors, before ferrite bead there's a 100uF tantalum capacitor after LDO. Vbat is decoupled by 100nF capacitor and 2x22pF capacitors (there are places for different external RTC modules). Quartz is one with 12.5pF load, load capacitors are 22pF each (I experimented with smaller values - nothing was changed). Driving strength is set to high. PC13 is set as output, low level.

Here's piece of board with quartz, power and Vbat lines. X10 is place for ground shield (shielding doesn't change anything on earlier board prototype).

What's wrong with it? Is there any option to make it stable in high-EMI environment? when I've tested older board revision, there was clock slowdown even when device's GSM module was switched off but there was a second such device with GSM placed in 10-20cm near it.

External RTC MEMS module will be a good solution, but I expected to use internal one...

[waclawek.jan]

From that picture I don't quite understand what exactly is the return path from capacitors to mcu ground pin.

Is there any other ground layer around to which those vias are connected?

Also, have you tried different RCC_BDCR.LSEDRV settings?

JW

[NiTr0man]

there's a bottom (green) layer with separate ground region connected to main ground at via near ground pin.

I started project with low drive strength, when I noticed clocks slowdown - I've increased drive strength to high, but clock slowdown remains present (but AFAIR it starts to work better)

[TDK]

Are you going to sleep between transactions? Are you perhaps re-initializing or otherwise touching the RTC after a wakeup?

[NiTr0man]

No, I didn't use powersaving in code. Also I didn't reinitialize RTC - just fetch time from it (and once per hour synchronize time with NTP). also, when GSM part is off - clock runs stable till I place same device with active GSM module near this one (10-20cm).

[waclawek.jan]

Well, radiated EMI may be hard to shield off, it may be picked up by a surprising variety of the circuitry, not only in the immediate vicinity of the oscillator/crystal...

JW

[AScha.3]

>Is there any option to make it stable in high-EMI environment? 

Maybe do it  "my way" : dont use a crystal, use a oscillator;

today about same price as a good crystal + caps.

something like this:

 

...then check, if there still any influence from ext. radiation .

+

other "problem" with LSE internal osc. : if switching action on adjacent pins...

- so check, if you have any switching on pins next to LSE - pins .

[NiTr0man]

>Maybe do it "my way" : dont use a crystal, use a oscillator;

oscillator costs same price as cheap RTCs with oscillator like RX8130CE, and consumes more power than RTC (there is backup 0.22uF supercapacitor for RTC, and oscillator may consume too much extra power).

[TDK]

I'm a little surprised by the reported behavior. It would be odd for LSE to be intermittent. Consider enabling CSS and monitoring the LSECSSD flag.

> I noticed clocks slowdown

How exactly are you noticing this? Expected vs observed behavior. A log with timestamps, or a clock scope trace with slowdown present, or something else concrete may help explain this.

[NiTr0man]

>How exactly are you noticing this? Expected vs observed behavior. A log with timestamps, or a clock scope trace with slowdown present, or something else concrete may help explain this.

 

I noticed it in status packets with minute of day reported - clock losts ~5 minutes per 8 hours. Then I've added time logging each 10 seconds to UART, and draw chart with clock deviation on host - and it's flat till next GSM transaction.

Also I placed precise frequency meter at PC13 and enabled test clock output (512Hz) - at normal state it shows 512.034Hz, but during GSM transaction it shows lower floating frequency (4xx Hz).

[NiTr0man]

Here's example chart. dots - clock deviation compared to PC system clock; green lines - interaction with GSM module (AT commands and GPRS data transmission), red line (among bunch of green lines) - initial clock sync.

 

[NiTr0man]

As I expected RX8130CE and MAX31343ETAY external RTCs work perfectly with near-zero time drift (less than 1 second per hour; they have no centiseconds so I can't tell real clock drift). It's an enough cheap solution - but I confused that internal RTC/LSE is so sensitive for EMI...

So I have a question: is LSE from other STM32 MCU series have same high sensitivity for EMI, or it's bug of STM32G0 series (and possibly some others with similar LSE schematic)?

[AScha.3]

I can't tell about LSE sensitivity to GSM signal, but also the ADC is disturbed by nearby RF, we had problems with Wi-Fi transmission on same board, so we removed it, to get good ADC values.

Maybe same with RTC, as there is no level or sensitivity given in ds.

I just assume, drive level of most separate RTC chips is higher and so less sensitive to any RF.

I decided just to use crystal oscillators for HSE and LSE, to get rid of the problems with crystal drive level etc.

Or a separate RTC chip, as you have now.