PCF8523T unresponsive on I2C after some time

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PCF8523T unresponsive on I2C after some time

328 Views
e8micke
Contributor I

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?

0 Kudos
Reply
7 Replies

159 Views
ola_gook
Contributor III

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

0 Kudos
Reply

139 Views
ErikaC
NXP TechSupport
NXP TechSupport

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

0 Kudos
Reply

111 Views
ola_gook
Contributor III

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

0 Kudos
Reply

239 Views
e8micke
Contributor I

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 

0 Kudos
Reply

285 Views
e8micke
Contributor I

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.

0 Kudos
Reply

267 Views
ErikaC
NXP TechSupport
NXP TechSupport

Could you please share your schematic?

0 Kudos
Reply

301 Views
ErikaC
NXP TechSupport
NXP TechSupport

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.

 

 

0 Kudos
Reply