Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

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.

TCA9555: Outputs not always toggling even writing to output registers after a reset event

Part Number: TCA9555

I have come across a weird issue with the TCA9555 IO expander: occasionally, it stops toggling its outputs even though our microcontroller is writing to the expander's output registers. Furthermore, after writing, we are checking not only that the I2C transfer has succeeded but we're also reading the state of the output registers to ensure they hold the desired value and they always do. We are also always checking the Configuration Register before writing to each output to ensure it is properly configured.

Our setup is made of two boards, one with our microcontroller and another with the IO expander. This problem occurs when we disconnect the cable that connects our two boards, which carries both power and the I2C bus to the TCA9555. We disconnect the cable to simulate intermittent I2C faults and random power events from which we are required to recover from. Sometimes, the IO expander works as expected as soon as the cable is re-attached, other times it won't change any of its outputs even though we have the confirmation that its internal registers are properly configured.

We would like to know if this is a known problem with the TCA9555 and/or if there are any recommendations in other to mitigate this issue and always accomplish a full recover of the IO expander.

  • Hey Tiago,

    Is it possible for you to provide us with a schematic of the TCA9555?

    -I'd like to review it to make sure it looks okay.

    "We would like to know if this is a known problem with the TCA9555 and/or if there are any recommendations in other to mitigate this issue and always accomplish a full recover of the IO expander."

    This is not a known problem with the TCA9555 but I usually do not hear of customers disconnecting the device and reconnecting it in this manner.

    From my understanding, you are quickly disconnecting the Vcc and then reconnecting it through this cable. This could violate the Power Supply Recommendations of this device in section 11 of the datasheet. You may want to place a scope probe on Vcc of the device and monitor what it sees during these two events.

    The other possibility I can think of is you are causing a glitch in the state machine during this event. What we can try is to pulse the SCL pin with 9~18 clock pulses and then trying to communicate with the device.

    If you can post pictures of the waveforms when you run into this issue (I2C bus), that may help us see the issue. Sometimes what we see is the stop condition on the I2C bus is not implemented and the device has the values stored in the register but does not execute it until the stop condition is sent.

    Thanks,

    -Bobby

  • Hi Bobby, thanks for following up with this. 

    Bobby Nguyen said:

    Hey Tiago,

    Is it possible for you to provide us with a schematic of the TCA9555?

    -I'd like to review it to make sure it looks okay.

    >> This is how we have the TCA9555 connected in our board. The outputs are controlling NPN BJTs.

     

    "From my understanding, you are quickly disconnecting the Vcc and then reconnecting it through this cable. This could violate the Power Supply Recommendations of this device in section 11 of the datasheet. You may want to place a scope probe on Vcc of the device and monitor what it sees during these two events."

    >> I'm not actually reconnecting that quickly, I'm allowing a few seconds to pass before reconnecting the cable, but I still need to check the supply's output when reconnecting the cable (the cable provides the enable signal for the TCA's power supply, to that can be the issue). In the event the supply is the problem, is there any way to force a reset of the TCA9555 with I2C? Our main concern is that the TCA9555 appears to be fully working although it is not changing its outputs.

    "The other possibility I can think of is you are causing a glitch in the state machine during this event. What we can try is to pulse the SCL pin with 9~18 clock pulses and then trying to communicate with the device."

    >> Yes, we sometimes do that pulsing to recover the bus if the TCA9555 does not respond (occasionally, it can miss a clock but it is quite rare though). However, we can't seem to understand why it sometimes is not toggling its outputs although it is responding to I2C read and write requests. We are forcing a write to the configuration registers before each toggle, and also reading and printing the contents of the output register before each write to check if the previous write operation was successful.

    "If you can post pictures of the waveforms when you run into this issue (I2C bus), that may help us see the issue. Sometimes what we see is the stop condition on the I2C bus is not implemented and the device has the values stored in the register but does not execute it until the stop condition is sent."

    >> I have checked this and it seems we are performing a stop condition after each write. I've included a file with a capture from a Salae logic analyser, hoping that you can use their software and visualize the I2C bus waveforms. Please let me know if you prefer an oscilloscope waveform of the messages instead.

    Thank you once more, 

    Tiago

    nok_tca9555.logicdata.zip

  • PS: I have noticed in the file that I've sent you that we're apparently misconfiguring the IO configuration registers of the TCA9555, which seems a bit odd. I'm going to double check that logic analyser capture...
  • Hey Taigo,

    I can't seem to be able to open the file you sent in the zip folder (it's an unknown file type). Are you able to attach a picture?

    Thanks,
    -Bobby
  • Hey Bobby,

    The file can be opened with the software available on this website: www.saleae.com/downloads.

    I've finally figured it out. We had a bug in our code that would, occasionally, send a wrong configuration to the outputs' configuration register of the TCA9555.
    This would randomly configure all of the expander's IO pins to inputs when the firmware detected that the cable was disconnected, hence the intermittent behavior.
    So, our code was to blame and not the TCA9555.

    Sorry for this oversight on our part. Thank you for your assistance on this, it was your suggestion of digging into the I2C bus that made me notice what was going on. (We have validated the I2C code before so we assumed it was fine, this was a bug caused by recent changes.)

  • Hey Tiago,

    Thanks for getting back with us about this, it's always helpful for others who may search our e2e database looking for similar problems and finding threads with verified solutions.

    Thanks again,

    -Bobby