MCP23016 missing D7 on I2CRead

[TWSK]

I have a PIC 16F876A running at 4 Mhz, interfaced via I2C, to a PIC MCP23016 ( TP @ 1 Mhz )

The SCL (portc.3) & SDA(portc.4) lines are pulled to Vcc via 4.7K

Variables were used for the control, address, and data portions of the I2CRead statement.

I was successful at setting up and using the MCP as an 8/16 bit output device as well as an 8/16 bit input device.

I did run into an anomaly when using it as an input device.

The bits for the two registers GP0 and GP1 were read back from the MCP but bit D7 was missing from the first register that was read. A scope reading revealed that the first SCL clock pulse #1 after the internal read was missing or shortened to a glitch. ( see PIC data sheet DS20090B, FIG 1.7 ).

By reducing the Cext to 15 pf from the recommended 33 pf ( ie. increasing the internal MCP clock to 2 Mhz) the # 1 clock pulse was restored. Even better results occured when I used only the stray capacitance of the bread board to increase TP to 4 Mhz.

It would appear that the MCP is holding the SCL line down long enough to distort or eliminate SCL pulse #1. By increasing the internal MCP clock speed, the MCP processes the data faster reducing the hold down time for SCL?

This would seem to be a dubious fix for this problem.

I'm hoping one of the forum members has run into this problem and can suggest a few more things for me to try or check.

thank you in advance,

TWSK

[TWSK]

I have a PIC 16F876A running at 4 Mhz, interfaced via I2C, to a PIC MCP23016 ( TP @ 1 Mhz )

The SCL (portc.3) & SDA(portc.4) lines are pulled to Vcc via 4.7K

Variables were used for the control, address, and data portions of the I2CRead statement.

I was successful at setting up and using the MCP as an 8/16 bit output device as well as an 8/16 bit input device.

I did run into an anomaly when using it as an input device.

The bits for the two registers GP0 and GP1 were read back from the MCP but bit D7 was missing from the first register that was read. A scope reading revealed that the first SCL clock pulse #1 after the internal read was missing or shortened to a glitch. ( see PIC data sheet DS20090B, FIG 1.7 ).

By reducing the Cext to 15 pf from the recommended 33 pf ( ie. increasing the internal MCP clock to 2 Mhz) the # 1 clock pulse was restored. Even better results occured when I used only the stray capacitance of the bread board to increase TP to 4 Mhz.

It would appear that the MCP is holding the SCL line down long enough to distort or eliminate SCL pulse #1. By increasing the internal MCP clock speed, the MCP processes the data faster reducing the hold down time for SCL?

This would seem to be a dubious fix for this problem.

I'm hoping one of the forum members has run into this problem and can suggest a few more things for me to try or check.

thank you in advance,

TWSK

The I2C specification states:

The I2C-bus specification
7 TRANSFERRING DATA
7.1 Byte format
.................................................. ......If a slave can’t
receive or transmit another complete byte of data until it
has performed some other function, for example servicing
an internal interrupt, it can hold the clock line SCL LOW to
force the master into a wait state. Data transfer then
continues when the slave is ready for another byte of data
and releases clock line SCL.

Questions: ( to any I2c GURU s )

Does the Pic BASIC Pro I2cread command respond to the SCL line being held low by the slave?

Is there a time limit on how long the Pic Basic Pro master waits for the SCL line to be released by the slave?

It looks like the read of D7 was only successful when the slave's processing time was reduced so the wait time ( SCL held low ) was reduced and the master clock pulse 1 became viable as the slave was no longer "stepping" on it.