This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TCA6424A: Can I add error checking to I2C packets and how?

Part Number: TCA6424A

Hi team,

Asking this question on behalf of my customer.

"

We’ve got some issues with our IO Expander that we’re hoping to resolve with some enhanced error checking.  To date, we’ve had the part hanging on our I2C bus talking as a slave to our PIC16 master at 100 kHz.  It’s mostly good, but there are some scenarios where the ports configured as outputs seem to get out of sync with their commanded state.  This sometimes requires us to reset the part to restore normal operation.  To help combat this, we’re planning on adding 2 measures.  The first is to read the latch state of the output pins.  If these come back in a different state than what’s expected, we’ll reset/re-initialize the part.  Second, and this is where we need TI help, is we’d like to add some type of error checking to the I2C packets.  We noticed that the TCA6424A mentions support for SMBus and wondered if that meant the part supports a form of Packet Error Checking as described in this TI app note. We didn’t see any explicit mention of it in the IO expander datasheet – can you confirm whether this part has this capability?

"

Essentially, can they add error checking to the I2C packets and if so, how?

Thanks,
Lauren

  • Hi Lauren,

    Our device was designed as an I2C IO expander though it does have some compatibility to SMbus controllers, it does not include the Packet Error Checking that you pointed out in the app note.

    "To date, we’ve had the part hanging on our I2C bus talking as a slave to our PIC16 master at 100 kHz. "

    You mean SDA get latched low? Or are you seeing something else like the output pins on the p-port don't respond?

    "but there are some scenarios where the ports configured as outputs seem to get out of sync with their commanded state."

    Have you captured any scopeshots of the I2C signals to see if any noise may be coupling onto the lines causing false clocks or data to appear high when its supposed to be low (or vice versa)?

    Thanks,

    -Bobby