• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 206 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: I/O Expander I2C signal sequence and expected return values

Per von Knorring
Prodigy 20 points
Part Number: TCA6424A


Tool/software:

Hi There,

We are using your TCA6424A IO Expander. Currently we are trying to do single read of the input register (0 - 2).

The device seems to reply but we can't seem to see any change is the response when different signal levels are applied to the input pins.

We are not doing any configuration commands to starts with since the default state of the pins are 'input' and we are only using inputs to the device.

Included are scope picture of doing single I2C 'read' of input register 0, 1, 2. That is the I2C signal sequence is: <I2C Addr><WriteBit>, <Command Byte> (0,1,2), <I2C Addr><ReadBit>

The values returned are always 0xFF for input register 1, 0xFE for input register 2 and 0xFF for input register 3.

Included are scope pictures of these separate reads. 

1. Does I2C signal sequence look valid in the scope pictures ?

2. Do you need to send a Config command if you are planning to use all pins as Input pins (default config value) ?

Scope Pictures:

1. Read InputReg 0. I2C Addr and Command Byte

2. Read InputReg 0. Read response.

3. Read InputReg 1. Read Response

4. Read InputReg 2. Read Response

Snippet of the TI I/O Expander on our schematic.

  • 0
    TI__Guru 53028 points

    Hi Per Von,

    In the first scope capture, the device address is correctly sent followed by a write bit + command byte address 0x00, then a stop condition. 

    This sets the pointer (command byte) in the TCA6424A. The next time you conduct a read command, you will immediately read from the register 0x00 data which is the input port register. 

    Essentially you are reading from the device correctly, but in two separate start /stop transitions. 

    In the datasheet, we show a read command that has the following sequence: 

    Start --> target address --> write --> ACK --> command byte address (pointer address) --> ACK --> repeated start -->  target address again --> READ --> ACK --> data from command byte address --> ACK --> stop or continued data reads... 

    In TCA6424A, the device will automatically read the next register in line if the auto increment state is enabled via the MSB of the control register --> see table 8-4. 

    Regards,

    Tyler

  • 0 in reply to Tyler Townsend
    Prodigy 20 points

    Thx Tyler.
    If I understand your answer, the IC2 read from our host/controller is correct but could be improved using the auto increment state ?
    I was planning to implement that next.
    The next question is then is the value returned from the device correctly interpreted ? Input Register 0 -> 0xFF, Input Register 1 -> 0xFE and Input Register 2 ->0xFF.

    We can't seem to be able to change those return value when applying different signal levels at the input pins.

  • 0 in reply to Per von Knorring
    TI__Guru 53028 points

    Hi Per Von,

    Per von Knorring said:
    If I understand your answer, the IC2 read from our host/controller is correct but could be improved using the auto increment state ?
    I was planning to implement that next.

    It looks correct, but the complete read transaction is being broken up by a stop and start condition rather than a restart. It will still work this way, but takes more bandwidth. 

    Also, there is a clock stretch event occurring, I assume this is somewhat intentional or yet to be programmed? 

    Per von Knorring said:
    The next question is then is the value returned from the device correctly interpreted ? Input Register 0 -> 0xFF, Input Register 1 -> 0xFE and Input Register 2 ->0xFF.

    I believe it looks like 0xFF, 0xFD, 0xFF

    0xFD = 1111 1101

    Per von Knorring said:
    We can't seem to be able to change those return value when applying different signal levels at the input pins.

    Have you measured the actual voltage at the Pxx pin to confirm that the voltage at the input is below a VIL? 

    Regards,

    Tyler

  • 0 in reply to Tyler Townsend
    Prodigy 20 points

    Thx Tyler,
    Really appreciate the quick response.
    Where is the scope pictures in the 'clock stretch' ? That is not intentional. Does it cause on issue ?
    We will re-check to voltage at the input pins.

    /Per 

  • 0 in reply to Per von Knorring
    TI__Guru 53028 points

    Hi Per,

    I was referring to this scope capture for the clock stretching event. 

    It looks like the clock is being stretched, but I can't see a change in VOL which would indicate that another device is pulling the bus LOW. This might not be a true clock stretching event. 

    Per von Knorring said:
    We will re-check to voltage at the input pins.

    Looking forward to the results. 

    Regards,

    Tyler