• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 33 subscribers
  • Views 1374 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.

PCA9555: I2C not working

Sahil
Expert 1585 points
Part Number: PCA9555
Other Parts Discussed in Thread: TCA9555

Hi,

I am trying to establish communication with PCA9555 io-expander chip via I2C, I am receiving NAK  and my controller stops communication as expected. I even changed the chip with assumption the chip might be bad but still no luck. The PCA9555 address is set to A0:A1:A2 = 0 which corresponds to 0x20 address according to the datasheet. 

One can see the controller is initiating a communication by sending 0x20 (0b0100 0000) and WriteBit set to 0 and the chip is replying NAK as the night bit. Here is the scope signals.

I tried different addresses as well. I have 10k pullups on both lines and the communication is at 100kHz.

I have already checked my code with e2e on another forum and according to TI employee on the forum, my code has no issue. Here is the link to the thread. 

Here is the snapshot of the scope. The first burst is a Write attempt to select the chip internal address 0x00 and the second is a Read attempt.

Any help will be appreciated.

Thanks

Regards,

Sahil

  • 0
    TI__Guru 62920 points
    Hi Sahil,

    Does the I2C bus just consist of a master device, PCA9555, and pull-up resistors, or is it more complicated?

    Can you please confirm that you follow the power ramp guidelines documented in Section 10 of the datasheet? If not, the device may not properly initialize. This could be addressed either by modifying the power ramp or by using the TCA9555 device instead.

    If that isn't the issue, then could you please observe the SCL/SDA lines on an oscilloscope? (It looks like you may be using a logic analyzer at the moment.) This will allow us to better observe both the signal timing as well as the voltage levels to see if there are any potential compatibility issues.

    Regards,
    Max
  • 0 in reply to Miguel Robertson
    TI__Guru 60850 points
    Hey Sahil,

    Can you also provide us with a schematic to review?

    Thanks,
    -Bobby
  • 0 in reply to Miguel Robertson
    Expert 1585 points

    Hi,

    I have gone through the section 10 and that is taken care of.

    I have collected scope images and highlighting an region that could have potential cause of the problem ? 

    There are two Zoom windows Zoom 1 and Zoom 2 regions.

    Zoom 1 is highlighting the NAK received during a write request

    Zoom 2 highlighting the NAK received during Read request

    We have many devices that have incorporated PCA9555 already and there is no option to change the chip to another alternative.

  • 0 in reply to BOBBY
    Expert 1585 points

    Hi Bobby,

    We are using an evaluation board for PCA available on Digikey Link Digikey Part # 1738-1163-ND. They have schematic in pdf form on the same page. 

    Here is the snapshot of the schematic of their board.

  • 0 in reply to Sahil
    Expert 1585 points

    Hi

    I have found the problem. The evaluation board I am using says 5V for PCA9555 and my controller is running 3.3V TTL signals which according to the datasheet of PCA9555 will not get recognized i.e. Vinput High 0.7x5V. I feeded the 5V pin with 3.3V and it fixed the problem.

    Thank you all

  • 0 in reply to Sahil
    TI__Guru 60850 points
    Hello Sahil,

    Just wanted to tie up some loose ends since you solved the issue.

    "I have collected scope images and highlighting an region that could have potential cause of the problem ? "
    What you are seeing in the scopeshots is likely crosstalk. A fast di/dt (change in current over time) mixed in with mutual capacitance (parasitic) between SDA and SCL on the PCB will cause what you are seeing. The affect on the signal integrity is very marginal because I2C samples data on in the middle of the clock high period. From what I can see in the scopeshots, this is likely not going to be an issue.

    You may want to check the undershooting though as the undershoot could be violating absolute minimum value.

    -Bobby
  • 0 in reply to BOBBY
    Expert 1585 points

    Thanks Bobby