Hello, Ti,
I have 2 different markings on the IC UB926QSQ.
How do I decode the code?
83AJT1UG3
73A80RUG3
Greetings
Thorsten
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.
Hello, Ti,
I have 2 different markings on the IC UB926QSQ.
How do I decode the code?
83AJT1UG3
73A80RUG3
Greetings
Thorsten
Hello Thorsten,
These codes contain information on lot assembly, lot date, and assembly site. However usually we do not provide all this detailed information out externally. Is there some particular information you are trying to find from these devices? I can tell you that:
83AJT1UG3 is from March 2018
73A80RUG3 is from March 2017
Best Regards,
Casey
Hello, Casey,
We currently use the combination of the deserializer DS90UB926Q and the serializer DS90UB925Q to transfer data between two boards.
We also use these two chips to transfer control signals via I2C.
When transferring I2C data, the problem occurs that the I2C forwarding between the two chips does not work every once in a while.
The transmission stops for about 300ms and parts of the message are not forwarded/returned (see screenshots).
Normal_operation.png:
If the deserializer receives a message (upper I2C), it waits until the I2C word has been completely sent to it. Then the message is forwarded to the serializer which converts the data back into I2C signals (lower I2C) and transmits them.
Problem.png:
The problem is that sometimes the slave sends the ACK, but the serializer/deserializer does not forward it.
The frequency of this behavior is different on both versions of the chip (83AJT1UG3 more often).
Do you know why this can happen or why both chips behave differently?
Greetings,
Stefan
Hello Stefan,
Every IC will have variance in performance within datasheet limits. For the issue above, the most likely cause is high speed link marginality in the system design between 925 and 926. If there are errors in the FPD-Link then it is possible for a transaction to get lost in-between the SER and DES. I would recommend checking the link quality with our margin analysis program: https://www.ti.com/lit/ug/snlu243/snlu243.pdf
Also it could be the case that there is noise or signal quality issues on the I2C bus on the I2C bus which is not getting seen by this logic analyzer trace. It would be a good idea to check the I2C bus with a high speed scope during these transactions to ensure that the voltage levels for the I2C bus are within the datasheet levels for each device and there are no high frequency glitches showing up which may get recognized by the FPD-Link parts.
Best Regards,
Casey