TCA6424A: TCA6424A

Hi Daniele,

Connecting the thermal pad to ground is the recommended option as the ground plane is typically large and provides good thermal relief to the IC. I don't suspect this would cause an issue with the device recognizing I2C data. 

Can you share which address you are using to initiate communication with TCA6424A? Be sure the address accounts for the state of the ADDR pin. I would recommend checking both options (0x22 and 0x23) in case the electrical connection of this pin is unknown. As the rest of the I2C protocol will be the same for the TCA6416As, it doesn't sound like there's an issue with your formatting. 

Have you been able to verify other functionality of the device? For instance, does the nINT output assert when powered? If not, does modifying any GPIO state cause this interrupt output to assert? If not, it's possible that the device is not at all functional due to being underpowered or damaged. 

If neither of these resolve the issue, please share a schematic of the I2C bus (primarily if there are devices between the controller and TCA6424A) and any waveforms of the I2C signals you have captured. I would be particularly interested in seeing the address byte sent to TCA6424A and the resulting NACK. Please probe as close to the TCA6424A IC as possible to best represent the signals as seen by the device. 

Regards,
Eric Schott

Hi Eric,

thank for you suggestions.

Meanwhile I've bought the Eval board of the TCA6424 and I've connected the Eval board to the board.

I have read and written with out problem using the ADDRESS 22 Hex or 23 Hex.

In the attached file you can see the section of the schematic with the TCA6424.

Regards,
Daniele Sassaroli

Hi Daniele, 

It's good to hear that the software works well on the development board. Are you using this IO expander EVM? 

It seems that the issue likely exists in hardware. Therefore, I think capturing the scope shots of the I2C signals is likely the best course from here. I would also recommend verifying the connection of all supplies and signal pins. You may also try replacing the problem device with a new one if you suspect that it may be damaged. 

Regards,
Eric Schott

Hi Eric,

Hi Eric,

Hi Eric,

Hi Eric,

Hi Eric,

Hi Eric,  sorry for the messages. I've used the IO Expander EVM to evalute my SW and HW. I've observed that in my design the INT input is not pulled. Do you think that this is a problem? Regards, Daniele Sassaroli

Hi Daniele, 

It sounds like the device is not functioning properly at all. I would expect the nINT line to assert during powerup as the inputs tot eh GPIOs (configured as inputs by default) likely change during startup. You can check this by toggling any GPIO pin state to see if nINT ever asserts. 

This would be indicative of an underpowered or damaged device. If you can verify that the device is properly powered, I would recommend removing and replacing it with a new one to see if this resolves the issue. 

I'll remove some of your previous messages to clean things up a bit :)

Regards,
Eric Schott