• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 32 subscribers
  • Views 464 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: TCA6424A

daniele sassaroli
Intellectual 650 points
Part Number: TCA6424A
Other Parts Discussed in Thread: TCA6424

Hi,

I've designed a board with a TCA6424A, but I've problems to read and write in this component.

The I2C bus connects this TCA6424A and also two TCA6416As and I don't have problems to read and write in the registers of the two TCA6416As.

The idea is that the TCA6424A is in reset status because it doesn't move the ACK also if the access cycle is correct.

Reading the TCA6424A's datasheet I've observed that the Exposed pad must be connected to secondary ground
or float. In my design the Exposed pad is connected to ground.  I've noted also that another difference 
between the TCA6424 and the TCA6424A datasheets is that in the datasheet of the TCA6424A there is a clear suggestion
about the exposed pad connection while in the TCA6424 no.

Do you think that access problems depend on the Exposed pad connects to ground?

Could you help me to analyze the problem?

Thank in advance. 

  • 0
    TI__Guru 52075 points

    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

  • 0 in reply to Eric Schott1
    Intellectual 650 points

    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

  • 0 in reply to daniele sassaroli
    TI__Guru 52075 points

    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

  • 0 in reply to daniele sassaroli
    Intellectual 650 points

    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

  • 0 in reply to daniele sassaroli
    TI__Guru 52075 points

    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