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?
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
Hello, could you please changed address from 0xD0 to 0xA2 and let me know if the problem persists?
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
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
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.
Could you please share your schematic?
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.