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: Device is NACK'ing Config Data via I2C

Other Parts Discussed in Thread: TCA6424A

Using this part for the first time. I'm trying to write to the Config ports to set all I/O pins to outputs. I first send the Start sequence, which the device ACKs. It then also ACKs the command byte (0x8C). But I then follow the write of the command byte with a data byte write (in this case 0x00, to set all I/O on Port 0 to outputs). It NACks this data packet and all subsequent writes. What am I missing?   

  • Hi Joshua,

    Can you provide a scope shot of SDA/SCL when you get the NACK?

    Do you also have a schematic we could review?

    It then also ACKs the command byte (0x8C)

    0x8C isn't a register in the device, I would expect this to NACK. Are you sure you're sending 0x8Ch?

    Thanks,

    -Bobby

  • Hmm, I must be missing something, because if I'm reading the datasheet correctly it says 8Ch is the command byte to access Config Port 0:

  • Hi Joshua,

    You're right, the h'8C command byte accesses the h'0C register with auto-incrementing enabled. This is valid and should result in an ACK from the device. 

    Are you able to share scope shots and a schematic of your setup? We'd like to confirm that the data is being properly received by the device. 

    Regards,
    Eric Schott

  • Hi Eric,

    I've attached a scope capture here of the SCL and SDA lines. Not sure if there's something specific you want me to trigger on. 

    Here is a pic showing the relevant part of my schematic. I'm actually using two TCA6424As. As you can see, one has the ADDR line tied high, the other low. Both show the same behavior: they ACK when a Start sequence is sent with their corresponding addresses, and ACK the command byte 0x8C. But they NACK any data sent after the command byte. 

  • Hi Joshua,

    Thanks for sharing the scope shots. Based on these, it looks like the device is acknowledging every byte that is sent. I've labeled each byte showing its data and the 9th bit in each appears low during the corresponding rising clock edge. The depicted shot looks like a write to U6 (command byte bit 0 clear for write, bit 1 set for ADDR = high) to the CONFIG 2 register (address 0x0E) with some data as shown below. All ack bits in this transaction appear to be 0s as the receiving device drives the SDA line low. 

    Because this doesn't align with your initial report, this issue may only happen occasionally, the controller you're using is interpreting ACKs incorrectly, or there's some other electrical issue occurring between the probed location and either receiving device. Is there a way to identify exactly when the controller reports a NACK? Does this appear to occur in software every transaction, or only occasionally? If occasionally, we may need to do some extra work to capture a bad communication frame. Most scopes have a way to analyse the logic in simple communication protocols such as I2C. Would it be possible to configure your scope to recognize this data and trigger on a perceived NACK? 

    Regards,
    Eric Schott

  • Eric,

    I apologize, this scope capture was made with a Command byte of 0x0E, as you noted, not 0x8C as I mentioned earlier. I thought the auto-increment feature might be the issue so was trying without it. Regardless, the pattern is very consistent: the Start gets ACK'd, the Command gets ACK'd, but the data packets after that do not get ACK'd. Just to confirm: the proper sequence for configuring all lines as outputs should be three writes of data = 0x00 after the Start and Command byes, correct? I'm not seeing varying results, it's the same every time, which leads me to believe the issue isn't noise/electrical, but something I'm doing wrong when sending the data.

    So just to confirm, if I send:

    Start sequence

    Command byte 0x0E

    0x00

    0x00

    0x00

    This should set all pins to outputs, correct?  

  • Hi Joshua,

    To program all three configuration ports for all outputs, the address byte should contain 0x8C to initially write to config port 0 and allow auto incrementing to ports 1 and 2 afterwards. The following 3 data bytes should contain 0x00 for output configuration. 

    Note that auto incrementing may result in an invalid register address, which may be the source of the NACKs being reported. If the non auto-increment address is used, any more than 1 data byte will continue to overwrite the same register. To do this without auto incrementing, three separate sequences can be sent each using address bytes of 0x0C, 0x0D, and 0x0E accordingly. 

    Are you able to capture scope shots of the NACK'd data bytes?

    Regards,
    Eric Schott

  • Eric,

    I got another scope capture. In this instance, I am handling the port address incrementing myself. So I write to 0x0C, then send a 0x00, then 0x0D, 0x00, then 0x0E, 0x00. 

  • Hi Joshua,

    This scope shot also appears to contain ACKs on every 9th clock pulse. However, I'm not sure the sequence here is right. Everytime you manually enter a new address, you will need to start a new I2C transaction with a start condition and the device address. You cannot manually enter a new register address during the same transaction. 

    Manual incrementation writing to these registers should appear as follows:

    (Start) <ADR>(0x44) - <CMD>(0x0C) - <DAT> (0x00) - (Start) <ADR>(0x44) - <CMD>(0x0D) - <DAT> (0x00) - (Start) <ADR>(0x44) - <CMD>(0x0E) - <DAT> (0x00). 

    Regards,
    Eric Schott

  • Hi Eric,

    Thanks for the reply.. You're right, they do look like ACKs. Is it possible they're too short though and are sometimes getting missed? I can't figure out why else my host wouldn't be seeing them sometimes. 

  • Hi Joshua,

    I doubt the timing of the ACK is causing the issue as the voltage on the SDA line doesn't appear to cross the high-level input threshold for most devices. More likely there is an between the probed point on SDA and the controller. Is there possibly a unidirectional buffer or translator between the expander and controller that's preventing data from going in the opposite direction? Please try probing the system as close to the receiving device as possible to make sure the waveform represents what's seen at the input.

    If this is not an electrical issue, it may be related to the configuration of the I2C driver in your controller device. This might be beyond my scope to support, but i can assist with specific questions that may pertain to the I2C standard or elaborate on configuration settings that are available in your device. 

    Regards,
    Eric Schott

  • Eric,

    The only thing between the SDA pin on the multiplexers and the SDA pin on my host is a 10k pullup. The results are identical when probing the SDA side of the pullup. There are no unidirectional buffers or translators at all. Unfortunately, I didn't leave any TPs physically closer to the TCA6424As (I'll fix that next spin). 

    The device I'm using as a host is an Atmel AVR328BP. It's pretty straight forward. I'm using the same code to speak to a different device on another I2C bus. I can post the code if you think that would help.  

  • Sorry, forgot to include the scope capture. 

  • Eric,

    Is the multiplexer waiting for the host to read a message before it can set the config?

  • Joshua,

    We are looking into this and will get back to you after the weekend. Thanks for your patience.

    Regards,

    Eric Hackett

  • Joshua,

    Sorry for the delay here, we are still looking into this.

    Regards,

    Eric Hackett

  • Hi Joshua,

    Thanks for your patience while I was out for a couple of days. 

    It does not seem that this is an electrical issue based on the scope shots. The newest ones still appear to show the device ACKing during every frame.

    I would be happy to review the code to make sure that the program is properly configuring the device. However, the problem I think you're running into is that the MCU is unable to recognize the ACK sent by the device. Are there any software differences between reading/writing to this device versus the working example? Are both devices on the same I2C bus?

    Another avenue to debug would be to connect a logic analyser to the I2C bus and set it to trigger on NACKs. This will help us narrow down where and when these occur if it is periodical or identify why the MCU may not recognize the ACKs electrically. Do you have such equipment available?

    Regards,
    Eric Schott

  • Eric,

    I am stumped. First, (embarrassingly) I forgot I have a I2C protocol analyzer. Hooked it up, and it agrees with what we see on the scope: all packets are being ACK'd by the multiplexer. But my host microcontroller continues to not see the ACK of the data packet. I have posted to some Atmel AVR forums to see if anyone has any ideas. Thanks for youur help; I agree this does not seem like an issue with the TCA6424A, but rather with either my code or the microcontroller itself. 

  • Hi Joshua,

    Thanks for the update. I hope you are able to find a resolution through software. Let me know if you have any other questions about our device or would like to take another look at some electrical characteristics. 

    Regards,
    Eric Schott