PCF8523T unresponsive on I2C after some time

[e8micke]

We have an issue where the I2C interface on PCF8523T gets unresponsive (no ACK after commands) after some time.
To accelerate we have run the unit at ~800kbps (~10x customer speed) for >4 hours, 10 transaction/second and got into this state, so it is not super-trivial to reproduce. 

We are aware that the  PCF8523T cannot handle dual start condition, from datasheet:
"For this device, a repeated START is not allowed. Therefore, a STOP has to be released
before the next START." And we don't do that, its verified, but there could be glitches.

We believe that both VCC and VBAT supplies are stable when this happens.

Are there any known issue on this device where I2C will stop responding, that is not related to VBAT/VCC switching?

By power cycling both VCC and VBAT I2C will work again, but are there any way, like reset the internal state machine by a number of SCL cycles?

[ola_gook]

I am working on the same issue as e8micke (same company).

Just wanted to share a picoscope view of what is going on when the RTC is stuck.

As can be seen, the SDA is NOT stuck. Neither is the SCL.

The meas vertical line shows where the RTC fails to ACK the request for the first write req.

Also, in the second (read) request, there is also no ACK from the RTC slave.

I have prepend the comm sequence with both explicit STOP conditions and 150 clock cycles without any difference in response.

Running out of ideas here. Is there any way of waking the RTC from its dormant state?

/Ola

[ErikaC]

Hello, could you please changed address from 0xD0 to 0xA2 and let me know if the problem persists?

[ola_gook]

I changed the address according to the suggestion (0xA2) but the problem still persists.

Also tried all possible addresses without any change in behaviour. Still no read or write ACK from the RTC slave.

Any further ideas appreciated.

Thanks,

/Ola

[e8micke]

Attached are the schematic.
C407 is not what NXP recommends (1µF instead of 3.3µF), but the slew rate is much lower then 0.7V/ms when voltage is removed
And in this case the voltage is never removed.

Some of the components around the RTC:
ABS07-32.768KHZ-7-T 7pF     X-tal
KW-5R5C334H-R     Supercap
BSS138     N-MOSFET

The two I2C lines are connected directly to a MPC5517EAVLU66
Pin 31: PH1/AN26/EMIOS21/SDA_A 
Pin 32:PH0/AN27/EMIOS20/SCL_A 

[e8micke]

Thanks for that informative document.
Unfortunately we neither have stuck low SDA nor SCL signals. They are both high when this condition happens.
We have tried the "the sequence to recover the bus is by sending 9 clock pulses plus STOP." suggestion
But it did not help.
When looking at the communications it behaves like the I2C on the RTC is completely unresponsive.

[ErikaC]

Could you please share your schematic?

[ErikaC]

Hello,

Please check the User Manual for NXP Real Time Clocks PCF85x3, PCF85x63, PCA8565, PCF2123, and PCA21125.

Section 19. Troubleshooting. 19.3 No communication via I2C-bus.

Hope this helps.

[e8micke]

We have got a bit closer to the problems core.

Reference to an earlier posting of schematics in RTC.PNG file.
The zener diod D404 (DDZ9690) is a 5.6v zener diod.
D405 has a forward voltage at ultra low current at ~0.2V.
Over time voltage to VBAT in many cases will be closer to 5.4V, which is higher than VCC (5V)

We use PM[2:0] to 0x0 in Control_3 register, which gives the "standard mode" of switching between power sources and power modes of the PCF8523T.
But it seems like we sometimes, unintentionally, get a change of mode in the RTC into "direct switching mode", and as VBAT>VCC, I2C communication stops working.

Any idea of what can cause such glitch?

[e8micke]

It seems like it is an software error, exact root cause is under investigation.

DMA is used for the I2C data transfer and somehow (and sometimes) a byte in the beginning of the DMA transfer (and I2C data) are skipped, so "Control_3" got the value of "Seconds", so any writing of seconds between 32 and 59 will turn the RTC "direct switching mode", and as VBAT>VCC that means loss of I2C communication.

If the data loss happens if written seconds are between 0 and 31, it is safe.

Keeping this topic open until we know for sure this was the issue, but we will know for certain within a couple of days.
Really weird error, but thanks for your input!

[e8micke · Accepted solution]

As information, the "by-accident" writing of the register was indeed the issue.

As extra info it seems like  <~0.5V, on both VBAT and VDD (at the same time) are required for the Power-On-Reset to function, to reset the register settings to default