I2C I/O Expander PCF8574 hanging?

Has anyone ever experienced problems with a PCF8574 hanging or blocking the I2C bus?

On one of my dataloggers I found that there had no data been logged for a number of days.

Due to the large number of Digital Inputs I have to deal with there is a number of PCF8574S on Board.

When I checked the system the PIC itself was running fine.
No Watchdog or Brownout Reset had occured during the period of time where data shold have been, but wasn't logged.
(There would have been a log entry, the RTC and Log-Memory are on a separate I2C-Bus)

I flipped some Inputs (which should have caused Log entries) but nothing happened.
(apart from the fact that the PIC responded to requests via RS232)

After a Powercyle everything was fine again.

To me it looks like the PCF8574 was hanging and required a Power OFF and ON.

Hi Ralph,

did you use the INT output to read them or do you read them in a loop?

I had similar problem in the past but i used the INT pin to read them only when something change. I fix the problem by reading them in a loop.

Well it can be many things but that's what happened to me.

mmm, i know you do many industrial equipement so i don't know how it could be revelant but, is there's any chance that some 'high voltage noise' came on an input and freez the chip???

I know that there's some diode inside but how efficient they are... i can't tell if they will beat 1N5817, UF1002-T or else like that.

There are opto isolators on every single pin, and the PCFs are being polled

NavMicroSystems, I have had this problem in the past and I found that if before reading the PCF8574's I reset the pins used for inputs to a high state the problem went away. I beleive the output register internal to the PCF8574's is being corrupted.

Dave Purola,
N8NTA

Dave,

many thanks for the hint.

Can you remember in detail how you solved the problem?

The only way I see is to write $FF to the PCF right before reading it.

Yes, I used a scope and looked at the port I/O pins of the PCF's in question and found that pin's used as inputs and programmed for high states were indeed low and after removing the optoisolators from the sockets that were feeding the inputs the port I/O pins were still low. This prompted me to re-write the port I/O pins used for inputs to high states before reading there state's. I have had no problems since....

Dave Purola,
N8NTA

Dave,

many thanks!

That's interesting. Kinda TRIS refresh. Well it make sense, if we RTFM they say clearly

Quote:

---

Originally Posted by TFM

...The I/Os should be high before being used as inputs

---

Something to remeber for all here!

Thanks Dave.

Quote:

---

Originally Posted by mister_e

That's interesting. Kinda TRIS refresh. Well it make sense, if we RTFM they say clearly

Quote:

---

Originally Posted by TFM
...The I/Os should be high before being used as inputs

---

Something to remeber for all here!

Thanks Dave.

---

Steve,
you are right,
that's what the datasheet says,
but it is not really clear.

When initialising the PCFs I do first write $FF to it.
From that point on there are only READs.

So the the I/Os have been set HIGH before being used as inputs.
(The System has been running for about six months without any error, last week was the first time I found a gap in the log.)

The DataSheet doesn't tell that you have to set the I/Os HIGH before every single READ.

However,
if that solves the problem I can live with it.
(I have already changed my READPCF-Routine)

Thanks again to Dave for pointing that out.

EDIT
OK, that takes some extra clock cycles, so I had to recalculate the timing.

I'll put the new FIrmware Live on Monday and let you know wether or not the problem occurs again.

I am trying out the PCF8575 - 16 bit expander in my application. The high byte will be connected to LEDs for output, and the low byte is connected to switches.

For your application using the PCF8574 - did you use the I2CREAD and I2CWRITE commands control the bit expander? Would you mind posting a snippet of your code example on how you control the device?

Thanks.

badrad,

for several reasons I have written my own routines that I can't share.

But
I2CWRITE and I2CREAD should work fine.

(Don't forget the 4k7 PullUps on the Data and Clock Lines)

Quote:

---

Originally Posted by NavMicroSystems

badrad,

for several reasons I have written my own routines that I can't share.

But
I2CWRITE and I2CREAD should work fine.

(Don't forget the 4k7 PullUps on the Data and Clock Lines)

---

Thanks NAV, no probs with the proprietary stuff, understandable. I changed my pullups to 4k7, i had originally put in 10Ks.

The pcf8575s works like a charm. I have 8 panels with a pcf8575 each on one I2C bus, and another 2 on another bus I2C. Highbyte connected to proximity sensors, and Lowbyte connected to LEDs. There is a 3rd I2C bus for serial eeproms, and one serial port for a serial graphic display (Orbital Matrix).

The tricky part of this equation was all the parts are SMD. So I did not prototype the design to do my trials and testing, just straight from paper to circuit board layout. Hand soldering those SOIC and TSSOP, and 604 size parts is NOT a fun task.

Fun only when it works in the end... Now on to the task of coding the darn thing.