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.

TCA9534A: i2c signal error

Part Number: TCA9534A

Tool/software:

Hi Team,

we using GPIO to simulate I2C to control the TCA9534A.

When I send I2C commands, such as I2C get unit 0 dev 14 reg 0x0, it works fine for the first four command after power on.
However, starting from the fifth command, I receive an error.
Is there a solution to this problem? or what is hte most likely problem? thanks for your help and learn from you.

  • Please show an oscilloscope trace of a failing I²C transaction.

  • Hi Tommy,

    May we see a scope capture of the issue? 

    Are we sure we are not reading a register outside the TCA9534A's reg map? 

    The command table shows 0x00 - 0x03 registers. If you are reading down the map, a fifth read at register 0x04 does not exist and the TCA9534A would NACK the bus. 

    Regards,

    Tyler

  • Hi Tyler,

    attachment 01 show the result of sending the i2c get command woth 0x1

        figure 01

    attachment 02 show the result of sending the i2c get command with 0x4.

       figure 02

    after sending the command in attachment 02, it returns an error.

    what could be the possible of this issue? thanks.

  • 0x04 is not a valid register number. The TCA9534A behaves correctly.

    (And you must use an open-drain driver for SDA.)

  • Hi Tommy,

    In the second scope capture, you are attempting to communicate to register address 0x04 which doesn't exist in the reg map of this device. Please see the reg table in my previous reply. Trying to read/write from 0x04 should NACK. 

    What type of I2C driver are you using? This doesn't look like open-drain since the signal is experiencing overshoots on rising edge. Open-drain drivers are required for I2C. 

    Regards,

    Tyler

  • Hi Tyler & Clemens,

    okay , got it. 

    i think the customer command byte is wrong, right?

    as below:

  • Hi Tyler,

    1. the first ACK in not at rise edge of CLK, does this meet the specification?

    2. this feature> Power-Up With All Channels Configured as Inputs, 

        does the datasheet have information on what need to be configure before starting? 

    3. is there any setting required for register 2 ?  just the GPIO out inverting? or just keep the default setting.

  • 1. The SDA line is sampled at the rising edge of SCL. What happens at other times does not matter; during the hand-over between master and slave, such spikes can happen.

    2. The datasheet specifies the default configuration values. If you need other values, you have to write them.

    3. If you need inverting, you have to configure it.

  • Hi Tommy,

    I agree with what Clemens said. Please see his comments. 

    (1) An ACK = LOW. A NACK = HIGH. At the rising edge of SCL, the SDA = LOW, so this is a successful ACK bit. What happens after is not as important since I2C samples at the rising edge of the SCL. Like Clemens stated, the master and slave (controller and target) device have to hand-off the SDA bus. Sometimes, there is a delay between this hand off in which the PU resistors on SDA begin to pull the bus HIGH which is why the SDA rises for some time before being pulled LOW again. 

    (2) This is the default values of the I/O expander upon powering up the device. 

    (3) Polarity inversion register inverts the state of the incoming data for pins configured as INPUTs, or inverts the logic of a pin configured as an OUTPUT. 

    Regards,

    Tyler