PCF8523T unresponsive on I2C after some time

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

PCF8523T unresponsive on I2C after some time

322 次查看
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 项奖励
回复
7 回复数

153 次查看
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 项奖励
回复

133 次查看
ErikaC
NXP TechSupport
NXP TechSupport

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

0 项奖励
回复

105 次查看
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 项奖励
回复

233 次查看
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 项奖励
回复

279 次查看
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 项奖励
回复

261 次查看
ErikaC
NXP TechSupport
NXP TechSupport

Could you please share your schematic?

0 项奖励
回复

295 次查看
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 项奖励
回复