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.

DS90UB949-Q1: Ser/Des DS90UB949-Q1 and DS90UB948-Q1 BIST and PASS pin

Part Number:

We are using the DS90UB949-Q1 and DS90UB948-Q1 ser/des pair to drive some displays in our IVI device. We are using BIST function on the DS90UB948-Q1 deserializer to check the FPD-Link quality and status during the device operation. 

Result of BIST is on PASS pin so I want to read BIST PASS signal on deserializer pin 7 with oscilloscope.

PASS pin is shared with GPIO0 and SDOUT so I'm not completely sure that I read exactly PASS signal, and not GPIO0 value or SDOUT value.

What I did?

  1. First I set BIST_CONTROL(0x24) register on deserializer with value :

BIST_EN : 0
BIST_CLOCK_SOURCE : 01
BIST_PIN_CONFIG : 1 (I want to start BIST with BISTEN pin )
AUTO_OSC_FREQ : 1
BIST_OUT_MODE : 01

2. Then switch to port 0 and set GPIO0_CONFIG register to value:

GPIO0_DIR _D_GPIO0_DIR : 00 (Functional mode) - I expect to get PASS signal on pin 7
Rest of values in register are 0.

3. Then set D_GPIO0 (pin 19) to HIGH and D_GPIO[3:1] (pins 16, 17,

and 18) to LOW.

4. Set BISTEN pin to HIGH

5. Toggle 0x04[5] on the serializer. (MCU is on serializer side)

6. After 1 sec BISTEN pin is set to LOW

On the image below is what I captured.

Yellow signal is BISTEN pin and the purple one is signal on pin 7 on Deserializer.

I expect PASS signal on purple signal, but it's going LOW right after BISTEN is set to LOW and that is not what I expected.

Questions: Is the whole procedure right and how can I be sure that I read PASS signal?

If purple signal is PASS signal, why it's going LOW although there is no any LOW level in half-pixel clock period that means there is no error in BIST?

Also, after BISTEN is set to low, I’m trying to read some registers on Serializer and Deserializer via I2C. I managed to read serializer registers after that, but Deserializer and everything on I2C bus on DESER side Is not available. I don’t get ACK on I2C communication.

Thank you!

Best regards,

Tomislav

  • Hi,

    I'm sending this summary again because this topic has so many posts.

    5148.BIST_issue.pdf

    Do you have any idea how to continue debugging this issue?

    Thank you very much for support!

    Best regards,

    Tomislav

  • Hi Tomislav,

    Thank you for the summary, Can we try to reset the TCA6408 after BIST to see if that is somehow disabling the I2C bus?

    Regards,

    Michael W.

  • Hi Michael,

    Portexpander TCA6408 reset pin is connected to GPIO 6 of 948 so I need to have I2C access to 948 but I don't have it.  

    I am not able to communicate with 948 after BIST is disabled.

    Best ragards,

    Tomislav

  • Tomislav,

    Backing up here - what is the reason that you can not simply enable BIST through registers via the 949 side using register 0x14? There is no need to implement this overly complicated method which seems to have some issues anyways. 

    Best Regards,

    Casey 

  • Sorry disregard my previous comment - I see that the issue with that was the deserializer needs to be the side to initiate the BIST or it will not properly go into BIST RX mode while the 949 is in BIST TX mode. 

    I found how to resolve your issue but I'm not sure why it is happening. We will need to check that offline and see what the cause is. It looks like sometimes (it doesn't happen every time) when BIST is disabled via pin, the BC watchdog timer is getting turned off at the serializer side. Notice the default for 949 register 0x16 is 0xFE and when the comms stop working it gets reset to 0x01. It seems like during the BIST enable/disable process there is a BC CRC error and because the watchdog it turned off, it will lock up the channel. You can clear the issue by setting 0x16 = 0xFE, or by issuing a digital reset at the serializer with 0x01 = 0x02

    Best Regards,

    Casey 

  • Hi Casey,

    Thank you! It seems that resetting 949 including registers after BIST resolves some problems. In fact that's what I did after BIST is disabled but I used DIGITAL_RESET1.

    Now I can communicate with 948 after BIST. But...

    I still have problems with CRC errors during BIST and PASS pin on 948 is LOW after BIST.

    I send you new registers dump and waveforms during BIST.

    Please take a look. Maybe you can find what is wrong.

    regs_dump.zip

    waveforms.zip

    Thank you very much for support.

    Best regards,

    Tomislav

  • Hello Tomislav,

    Your sequence for clearing CRC errors is not matching the datasheet:

    You need to clear CRC error count after BIST is enabled (in the beginning of the test). Your sequence is toggling the CRC error count clear before enabling the test. 

    Best Regards,

    Casey 

  • Hi Casey,

    I moved toggling the CRC error count clear after BIST is enabled on 948 on BISTEN pin and the same is happening.

    Waveforms (also LOCK pin captured):

    including_lock.zip

    About 3 sec after BIST is disabled registers have this value: ( they are not the same value every time.)

    948  BIST_ERROR_COUNT - port 0: 0x06

    948  BIST_ERROR_COUNT - port 1: 0x06

    949  CRC Errors 0x0A - port 0: 0x07

    949  CRC Errors 0x0B - port 0: 0x00

    949  BIST BC Error Count - port 0 :0x00

    949  CRC Errors 0x0A - port 1: 0x05

    949  CRC Errors 0x0B - port 1: 0x00

    949  BIST BC Error Count - port 1 :0x00

    Best regards,

    Tomislav

  • Hello Tomislav,

    We need a few days to look into this further. We will plan to respond back in 2-3 days. Thank you for your patience

    Best Regards,

    Casey 

  • Hello Tomislav,

    Thank you very much for your patience here. After some discussion on this internally, I believe the errors you are seeing are most likely a result of the sequence which is happening going into and out of BIST, not necessarily capturing real errors during the test. The reason is that going into or out of BIST triggers a loss of LOCK which subsequently may cause a few transient errors as the DES unlocks. You can see the effect here on a setup which I have for example:

      

    So when the test concludes, you are essentially seeing errors which are related to the normal relocking process and not actual errors from the test. The most accurate way to actually check errors during the test is to monitor the PASS pin while BISTEN is high to see if there are any drops. I'm looking internally to see if there is any other possible method, but it appears that this may be the only solution. Of course, the documentation should likely get updated to clarify this as well in the datasheet 

    Best Regards,

    Casey 

  • Hi Casey,

    Thanks for your effort.

    We have the requirement to perform BIST of the FPD-link III between the serializer and the deserializer at startup to ensure the correct functionality of the communication link. To be sure link is established well we shall check the result of the BIST by checking the value of the PASS PIN after BIST is disabled. If high then no error has occurred, if low then an error has occurred and the FPD-Link III shall return to normal operation mode. The requirement is written according to 984 and 948 manual.

    Obviously we can't do that because PASS pin is LOW after BIST is disabled due to CRC errors and loss of LOCK in BIST sequence. Also we can't see BIST result checking registers on 948 and 949 side cause there will be errors as result of relocking process and values are not relevant (not the real errors).

    We are not able to monitor PASS pin while BISTEN is high, looking for drops with hardware and configuration we have. 

    Please let us know (when you check internally) if there is some other way to check BIST result?

    Thank you!

    Best regards,

    Tomislav

  • Hello Tomislav,

    I will check if there is any other workaround available and let you know here but at the moment it does not seem likely 

    Best Regards,

    Casey 

  • Hello Tomislav,

    Here is a validated script we have used before to perform the BIST test using only reg writes but it requires connection of I2C directly to the 948 side. We don't have any known way to implement the test using remote connection like you have implemented here due to the issues discussed previously. 

    949-948_Link_190MHz_FLAT.zip

    Best Regards,

    Casey