DS90UB954-Q1: Proper DIGITAL_RESET1 procedure

Hello,

So DIGITAL_RESET1 is different from DIGITAL_RESET0 in that it resets all the registers to their default values where DIGITAL_RESET0 only resets the digital hardware and not the registers.  If using DIGITAL_RESET1 to do a full reset than all the config registers will need to be set again as well.  It is similar to doing a hard reset by pulling the PDB pin low except it is done in software.  With that being said if no data is being transmitted there may be an underlying issue and making the link more robust may help with that.  Are you able to read any of the status registers when using BIST to troubleshoot?  Also is LOCK being lost when the data stops transmitting?

A few registers to check:

0x04 (DEVICE_STS)

0x4D (RX_PORT_STS1)

0x4E (RX_PORT_STS2)

0x54 (SENSOR_STS_3)

It may also be a good idea to try and read some of the remote status registers to see if there are errors on the serializer.  Are you still able to communicate with the serializer when the data is lost?

Regards,

Nick

My attempted procedure is to issue DIGITAL_RESET1 to the serializer first, wait for about 100 milliseconds, then issue DIGITAL_RESET1 to the deserializer, wait again, and then try initializing from scratch after this point. It might be worth noting that I'm issuing these commands via I2C through an FPGA interface. I'll give you the register status immediately after this to give you some idea:

DESER 0x04: 0xD3 (Everything good, except no PASS and no LOCK)

DESER 0x4D: 0x00 (No errors, no PASS or LOCK)

DESER 0x4E: 0x02 (Cable fault)

DESER 0x54: 0x00 (No errors)

Now, I could see how a cable fault would be an issue, but it doesn't happen outside of this particular sequence of events. We'll look into what could possibly cause a fault, but I also just need to know if our procedure is even correct.

Hi again,

So I don't see any issue with your procedure and if you are reading these registers immediately after a reset then errors may be seen prior to lock. 

However if LOCK never returns then the issue may be causing the link to fail and not return even after a reset.  Are you able to provide any data prior to the reset to see what causes the transmission issues initially? 

If you are never able to get the link working again then perhaps there are issues with the connection itself.

Regards,

Nick