I2C traffic slows down the time of the PCF85263A rtc chip

------Question for PCF85263AT/AJ Please Put your question below------
Has anyone noticed, that heavier traffic on the i2c bus slows down the time of the PCF85263A, even if that traffic is not addressed to the rtc chip? Or is it just me? :slight_smile:
I had an AD converter on the same bus, with which the microcontroller exchanged about 400 bytes per second. If I remember correctly, the PCF85263A slowed down by almost 1%. If I stopped the AD converter or I moved the PCF85263A to a physically different bus, then the PCF85263A was keeping time to about 5ppm!

Checking one this for you. Will let you know when I have an answer.

Sorry for the delay.

We are still waiting on information on this one.

1 Like

This smells like contention on the i2c bus, can we assume both devices running at their max “compatible” i2c speed? I’d really stick a i2c probe on this and see what on the bus is causing the transmission delays.

Regards,

2 Likes

Thank you very much for you devoting time to this issue.
I don’t believe it’s contention. Here is why:
The RTC side: The PCF85263A interrupts the microcontroller once a minute. In response, the microcontroller exchanges 9 bytes with the RTC.
The AD side: The microcontroller talks to the AD converter 90 times a second, and exchanges 4 bytes each time. This happens in the main thread, not in an interrupt. The interrupts are disabled during the AD transaction – so any RTC interrupt is deferred.
Both the RTC and the AD transactions happen at 320kHz clock rate. A rough calculation would result in 119 microseconds for the AD transaction and 259 microseconds for the RTC transaction.
Assuming I have a bug somewhere in the program that causes the two transactions to mix somehow, that would hold up the RTC for at most 119 microseconds every 60 seconds. That’s only a 2ppm delay…
Here is my theory: The PCF85263A is a very simple device, with only one processing unit inside of it. That handles both counting the time ticks and the i2c transaction. Since the i2c protocol is such, that every device on the bus has to decode at least the address in the message header, it causes the “processor” in my RTC to be busy 90 times a second, possibly missing some of the time ticks. A numerical check: 90 times 119 microseconds per second is exactly 1% duty cycle!
The main intent of my post is to make other engineers aware of this possible issue. I already solved my problem by moving the RTC chip on a bus of its own.

The PCF85263A RTC chip might miss clock pulses or experience delayed updates if the bus is frequently occupied by other devices. This can slightly slow down the timekeeping, especially if the microcontroller has to wait longer to communicate with the RTC.
Some I²C devices, particularly slow ones, can use clock stretching to signal the master to wait before sending more data. If the AD converter or another device on the bus uses clock stretching, it can introduce slight delays that accumulate over time.
However, the PCF85263A might not be directly affected by clock stretching but could still experience timing irregularities if the bus is frequently busy.
By the way, if the problems are not solved you can switch to DS12887:

1 Like

I suspect the problem is EMI on the I2C bus disturbing the very sensitive crystal oscillator circuits.

If you change the I2C bus speed and the timing error changes, that would be a strong indicator this is the problem.

I haven’t designed one of these 32kHz crystal input layouts in decades, but I seem to recall you need to keep the tracks very short, have guard rings on all layers, and route all data lines as far away from the crystal connections as possible.

1 Like

Hi @sarkko ,
Can you test that by doing a heavy DoS type attack, i.e. having a small test code that keeps the I2C bus as busy as possible, thus amplifying the anticipated race condition inside the RTC? Can you see any difference?
Also observe the waveform at the crystal by oscilloscope - does it get disturbed. As Paul suggested, the I2C traffic may disturb the oscillator. Do you have a proper supply coupling cap near the chip supply and near the I2C pull-up resistors?
Cheers, heke

2 Likes

All great feedback! One note @heke, regarding putting an o-scope lead on a crystal lead, this can sometimes affect the waveform itself, so one should keep that in mind when performing such a test.

2 Likes