3 no communication via i2c-bus, Nxp semiconductors, 3 no communication via i – NXP Semiconductors UM10301 PCF2123 User Manual

Page 49: C-bus

Advertising
background image

NXP Semiconductors

UM10301

User Manual PCF85x3, PCA8565 and PCF2123, PCA2125

UM10301_1

© NXP B.V. 2008. All rights reserved.

User manual

Rev. 01 — 23 December 2008

49 of 52

19.3 No communication via I

2

C-bus

When no communication with the RTC is possible, it is also not possible to set and read
time. Normally the I

2

C-bus will not get stuck, but especially during the development

phase problems may occur that hang up the bus. One reason may be that spikes on the
bus lines are interpreted as additional pulses which then would convey data not in line
with the I

2

C-protocol. Also timing violations when for example two GPIOs are used to

emulate an I

2

C-bus sometimes lead to unexpected results. On I

2

C-devices a scope may

be used to verify whether the RTC sends an acknowledgement at the end of each byte.
Over the past years oscilloscopes have been introduced that allow trigger and decode for
serial bus protocols, including I

2

C and SPI. Also timing violations can be easily found with

such equipment. These include rise and fall times, setup time, hold times and also
voltage levels.

If the bus gets stuck first it needs to be determined how exactly it is stuck. There are two
“bus stuck scenarios”:

• SCL (clock) stuck low: There is nothing that can be done about this but to hard reset

the device (remove power) because the I

2

C-bus requires clock edges to clock the

data;

• SDA (data) stuck low, but clock ok: A start condition can’t be sent because this

requires a high to low transition of SDA while SCL is high. SDA however is stuck low.
What will work is to send 9 clocks plus a STOP condition. The 9 clock pulses will
clear the I

2

C state machine, thus causing the device to release the bus. This permits

the master to send a STOP condition and now the I

2

C interface of the slave will have

been reset. This works for all I

2

C compatible devices without exception.

According to the I

2

C specification there exists a so-called general call address. This is for

addressing every device connected to the I

2

C-bus at the same time. The general call

address is 00

HEX

. However, if a device does not need any of the data supplied within the

general call structure, it can ignore this address by not issuing an acknowledgement. An
I

2

C device does not have to be designed such that it responds to a general call address.

The real time clocks for which this manual is valid do not respond to the general call
address.

Sending the 9 clock pulses with SDA low may seem like sending a general call address
since data is always zero for every clock pulse. The difference however is that no START
condition could be sent first since SDA was already stuck low. Sending the 9 clock
pulses is not the same as sending a general call address. If a device does require data
from a general call address, it will acknowledge this address and behave as a slave
receiver. The master does not actually know how many devices acknowledged if one or
more devices respond. The second and following bytes will be acknowledged by every
slave-receiver capable of handling this data. A slave which cannot process one of these
bytes must ignore it by not-acknowledging. These RTCs will not respond to a general
call.

In short, when the bus is stuck low due to SDA, the sequence to recover the bus is by
sending 9 clock pulses plus STOP.

Remark

: Only the PCF8593 includes a dedicated RESET input. When reset occurs only

the I

2

C-bus interface is reset. Thus for this device a second option of releasing the I

2

C-

bus is available.

Advertising
This manual is related to the following products: