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.

PCA9543A: Part Marking Meaning

Part Number: PCA9543A
Other Parts Discussed in Thread: PCA9536, TCA9543A

Good Day,

I'm using TI part PCA9543A in my design.  My as-designed power-on ramp is 35ms.  From the errata in the data sheet PO rise time must not exceed 10ms. 

I see that PCA9543A has been EOL and replaced with PCA9543APWR with an extended the PO rise time to 100ms.  The new part will/should work in the design.  Unfortunately, the part is still not working.

Due to supply chain issues, I ordered the replacement part from an overseas supplier.  The part markings are shown below.

The markings do not correlate to any of the expected markings contained in any datasheet that I'm aware of.  See images below.

Can anyone tell me what the part markings mean on the part below.  Is it indeed the PCA9543APWR?

Much appreciated,

-Tony

  • Tony,

    The marking is different than what is expected, but the 7-digit lot trace code does show up in our system as verifiable TCA9543APWR devices. So, not the P device, but the T device.

    You say the part still isn't working, can you elaborate on that?

    Regards,

    Eric Hackett 

  • Thank you Eric.  It appears then, I have the updated/correct part installed.  Good news/bad news situation.

    Sure.  I'm not seeing the I2C signals on either of the two outputs on the device.

    A snippet of the design is shown below.  I2C_SCL/SDA signals come directly from the uCntrl.  The SD1/SC1 & SD2/SC2 pairs go to TI part PCA9536 IO Expander IC. 

    I've tried programming the control register to ch1-en (B0=1), ch2-en (B1=1) and also to ch1&ch2 -en (B0/B1=1).  No luck.

    SCL is programmed and verified at 100kHz.  Signals look clean.

    TCA9543 CFG WRITE SEQUENCE (drvbay = 0x01 or 0x02):

    SCHEMATIC:

    TCA9543A  ADDR:

    DATASHEET:

  • Can you read the control register back? If not, please show an oscilloscope trace of the write transaction.

  • Thank you all for your comments and helpful insight. 

    Much appreciated.  This issue can be closed.  I've added 5us delays between register writes and that seems to have fixed the issue (along with the updated part of course which was the original issue).

    -Tony

  • It's possible that the back-to-back writes did not generate a stop condition.