• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 63 subscribers
  • Views 257 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.

TPS2384: read chip ID, not always the same.

PoChun Chang
Prodigy 10 points
Part Number: TPS2384

Tool/software:

Hi TI,

We put TPS2384 in Intel I350,

and use SDP to send I2C command,

when use I2C commnad 0x00 to read chip ID,

it is 10b in PCIE x4 slot, 

but it is 11b in PCIE x16 slot,

however if we set PCIE x16 slot to gen 1,

the chip ID turns back to 10b,

is any thing causes to read different chip ID?

how to fix?

Attachments:

1. snap the I2C signal from PCIE x4:

Note: In red circle, there is some noise in when clock down.

2. snap the I2C signal from PCIE x16:

Thanks.

  • 0
    TI__Genius 15275 points

    Hi PoChun,

    It seems the register data is reporting back incorrectly...the noise may cause a read error, however the actual data waveform on the SDA is incorrect reporting from the PSE.

    This is the first time I have seen this, can you confirm the device does not chance between different I2C bus connection. Are you using same PSE IC or different IC?

    Regards,

    Brandon

  • 0 in reply to Brandon Beader
    Prodigy 10 points

    Dear Brandon,

    Two cases are from the same device but inserted to different PCIe slots,

    PCIex4 (0x6) and PCIex16 (0x7).

    I2C signal are generated from Intel i350.

    Thanks,

    PoChun

  • 0 in reply to PoChun Chang
    TI__Genius 15275 points

    Hi PoChun,

    Is there any change in the PCB trace paths in terms of trace length, total impedence, cap on the board?

    Anything else hanging on to the SDA/SCL lines?

    Regards,

    Brandon

  • 0 in reply to Brandon Beader
    Prodigy 10 points

    Hi Brandon,

    There is no different in PCB,

    both result use the same hardware,

    although we add another IC on the same SDA/SCL lines,

    but the I2C address is differerent,

    our internal discussion think it should not effect the result.

    Thanks,

    PoChun

  • 0 in reply to PoChun Chang
    TI__Genius 15275 points

    Hi PoChun, 

    I agree, this should not effect the result.

    Are you able to probe the I2C bus on the PCIe slot where the mis information is present and ensure the reading is the same using a prober? Can you check this with a different host to confirm the data from the device is the same?

    Are there any digital isolators, repeaters, or other devices on the PCIe slot? Do you have a schematic for the PCIe slot that we can check the pullup resistors and total cap on the bus?

    Regards,

    Brandon

  • 0 in reply to Brandon Beader
    Prodigy 10 points

    Hi Brandon,

    Are you able to probe the I2C bus on the PCIe slot where the mis information is present and ensure the reading is the same using a prober?

    => we connect I2C bus and read the value as shown in first two pictures.

    Can you check this with a different host to confirm the data from the device is the same?

    => we insert the card into differenct host's PCIe x16 slot, the result is still the same wrong, 0x07.

    Are there any digital isolators, repeaters, or other devices on the PCIe slot?

    => no.

    Do you have a schematic for the PCIe slot that we can check the pullup resistors and total cap on the bus?

    => it is confidential, cannot leak.

    Thanks,
    PoChun

  • 0 in reply to PoChun Chang
    TI__Genius 15275 points

    Hi PoChun,

    My best guess without taking a look at the schematic or layout file:

    There is too much capacitance on the bus which is being caused from parsitic capacitance from long I2C traces. Too much capacitance can be either causing a slower slew rate since the cap is charging, causing the host to not capture the low to high transition resulting in miscommunication.

    It could also be the digital isolated + high capacitance depending on the logic level of the digital translator. Check which side of the digital isolator you are probing, if you have too much cap between isolator and PSE device, the low to high logic may be too slow, which then forces the output of the isolator on the host side to cause an issue.

    Without taking a look at the design specifically, it is hard to say what is the root cause of this. Normally I would recommend an ABA swap but since the device is not changing, there is something between the device and the host causing some miscommunication...

    Regards,

    Brandon