DS90UB948-Q1: Use serializer-deserializer system with screen glitch and blackout

Hi Blues,

There seems to be a loss of lock which is causing the issue. Could you please check the following:

1. Can you use a logic analyzer to check the lock pin and the 947 LVDS clock input? Is the clock continuous of is there any interruption? please read the 0x0C register when this occurs
2. Does the flickering cause a black screen, or does the video come back? How often is the flickering observed?

3. Are you testing this on a custom board or with the TI EVMs? 
4. Did you have the test pattern generator working before? There is a guide on setting the display timings, which should match what the DLP or display is configured for. Use the internal timing and internal clock mode, so we can rule out whether the external LVDS clock is causing the issue.


Best regards,
Ikram

Thanks for your reply. I'll just reply one by one.

1. We already checked the LVDS input clock of 947. Nothing distortion we detected under any circumstances. 

And I try to read 0x0C register on 947. I cannot guarantee that the register is read durning the flickering, so I have set the program to read 0x0C@947 every 300ms. During this process, flickering occurs, but the register does not read any number other than 0x07.

2. Flickering and black screen are two different phenomena， and they shoud have no causal relationship. The frequency of the flickering is irregular. Sometimes it flikers very frequently. At its fastest, it might flicker once every 10 seconds. In better situations, it might not flicker for several hours in a row (referring to the same segment of the output signal).

Black screen is another phenomema. The DLP will display a black screen when SoC transmit a video. If I don't take any action, the output will remain black and won't recover. At the same time, the screen may flicker even when it is in a black screen state. When a display device experiences a black screen issue, if I keep the device powered on and then connect the FPD-Link to a new device that is working properly, it is able to display the image normally. Reconnecting it back, however, results in a black screen again. This means that the black screen issue is associated with the 948 side. It will recover after a power cycle.

3. The entire link is composed of PCBAs that we have designed ourselves. We have not tested on TI EVMs.

4. Beacuse this system use an unusual resolution(1152*576@60Hz), and DLP is very strict on external signal. Other projects might have successfully output other resolutions, but this project has not successfully generate a workable test pattern. And When I generate test pattern, I poweroff the whole SoC chip which transmit the LVDS signal, and use the internal clock of 947.

In error code 666 case, I have configured the registers mentioned above and enabled the TPG using the internal clock. Precisely because the resolution of 576*288@60Hz requires a PCLK of 25MHz, I set the division coefficient to 8. I can also read that the current rate is 25MHz through 0x4F. In this case, the dlp get the 666 error code. 

I've configured the registers from 0x03 to 0x0E according to the document, where the values have been recalculated based on the actual register. So, are there any registers that I should have configured but I didn't notice?

Looking forward to your reply.

Best regards,

Blues Jiang

Hi Blues,

If you external clock into the device, then you can enable PatGen with external clock to match your resolution even if the DLP has narrow requirements. 
This might be useful to do because flickering might be caused by jitter on the CLK input.

Please use the original display resolution that works with the DLP because the minimum supported PCLK on the 948 is 25 MHz over single or 50 MHz over dual link.

I will check the test pattern script you send and get back to you by Tuesday.

Best regards,
Ikram

Thanks for your reply. Here is another important problem.

Is there any application note to specifically explaining the working mechanism of AEQ?

When flicker happens, we cannot detect any jitter or abnormal signals in the LVDS clock before 947. On the other hand, the 0x3B register of the 948 changes before and after each flicker.

I guess AEQ is a major reason of flickering, but I don't know how it specifically works or how I should optimize it to avoid flickering. So......

We will continue testing, so please reply as soon as possible if there is any useful information. Thank you.

Best regards,

Blues Jiang

Hi Blues,

What does the register 0x3B show as it changes? If it is too high, that could suggest issues with the cabling. 
Please check ADAPTIVE_EQ_BYPASS field, is the AEQ bypassed? If so, enabling adaptive EQ.

Before building the custom boards, was the system tested using TI EVMs? If the system with the same software and configurations was working, then we could have a closer look at what's different on the board.

Also, could you please check if the power-up sequence follows what is required in the datasheet (section 9.2)

If possible, you could read all the registers while running so we can check whether any other error flags are observed.

Best regards,
Ikram

Hi Ikram,

We are still working on this project. Here is our latest test result.

1.We have rechecked the power-on sequence, and it now fully complies with the datasheets of 947 and 948. Accordingly, the issue of screen flickering has significantly reduced but still exists.

2. We still haven't found any obvious issues in the registers. We will continue to investigate this part further.

3.We tested the signal eye diagram on the CMLOUT pin of the 948 chip, as shown in the figure below.

Please let me know if there are any other directions for investigation, thank you.

Best regards,

Blues Jiang

Hi Blues,

Another question, are you seeing this behavior on multiple boards or just one? Also, was this same resolution, modes, and configurations tried with TI EVMs before? If so, it might be possible that we might need to look into the layout/schematic.

I am looking through the eye diagrams you sent. I will compare with our requirements and get back to you.

- Ikram

Hi Ikram,

When we checked the datasheet, we noticed some weird information. In section 8.2.2.1 of the DS90UB947 datasheet, it is noted that differential connectors should be used when operating above 500Mbps line speed. We use this system to transmit a 1152*576@60Hz video stream. Based on our calculations, the amount of data transmitted has already exceeded this metric, and we have chosen to use single-ended coaxial cables. Could you please specify what this standard is exactly? Is our use of single-ended coaxoal cables related to these phenomena?

We have also tried enabling the DS90UB947's internal test pattern, but the screen flickering persists. We are able to detect the DS90UB948's LOCK signal loss. It seems that the video input signal is likely not the main issue then.

Thanks for reply. If possible, please help us verify the first issue. We will continue to work hard on testing.

Regrads,
Blues Jiang

Hi Blues,

What's the resolution you are using here? Is the total 1152*576@60Hz?
In that case, the PCLK comes out to roughly 39.8MHz.

You have the device set to Dual Mode, where the minimum PCLK is 50 MHz. Can you switch to Single-link mode and try this configuration?

Best regards,
Ikram

Hi Ikram,

We use a resolution of 1152*576 at 60Hz, and the PCLK used according to the standard output is 44MHz. The detail of this resolution we used is under below. For each 947, only port0 is connected to port0 of 948 to transmit this resolution.Our current plan uses a coaxial cable, and it should be the so-called single-linked scheme.

However, now that we see the previously mentioned 500Mbps restriction, does this restriction affect our current transmission rate.

Here is another test we tried. We changed the coaxial flywire connection to a twisted pair connection (at the output capacitor of 947 and the input capacitor of 948), without changing any register settings. In this case, we found no flickering. Do you have any troubleshooting suggestions for this phenomenon? (All register settings for 947 and 948 have been provided earlier.)

Finally, please help to check if the eye diagram of the CMLOUT mentioned earlier meets the specification standards. I look forward to your reply.

Best regards,
Blues Jiang

Hi Blues,

If possible could you share the register reads from the device. Then we can compare whether the device is setup for coax/STP modes, check the mode strap settings. The device should work on both STP and coax modes. 

- Ikram

Hi Ikram,

We have found a solution to the screen flickering issue, but we are not clear about the specific principles behind it.

1. We restructured the power-on sequence for both ends, 947 and 948. After confirming that effective signals could be obtained, we reconfigured/reset some registers.

2. Since we did not configure the corresponding SEL01 resistors on either end, we needed to configure them after powering on. For the 948 end, after configuration, we performed a soft reset by writing 0x01 to the 0x01 register to enable its self-adaptation.

3. This is the original power-on configuration register for the 948：

Hi Blues,

Could you please tell me when you read 948 registers 0x1C and 0x28, does it show dual-link mode? This should be auto-detected and an overwrite on 0x34 register in not generally required. Could you tell us why it was decided that needed to be changed?

- Ikram

Dear Ikram,

I tried testing in both scenarios mentioned earlier, and the results were the same, regardless of whether the 0x34 register was configured or not.

Reg[0x1C]@Dev[0x58]:Receive [0x03].
Reg[0x28]@Dev[0x58]:Receive [0x01].

Hi Blues,

Blues Jiang said:

. Since we did not configure the corresponding SEL01 resistors on either end

Are the mode straps correct for the single-link coax operation, and other configurations you are going for? They should have the correct resistor values so they are at the correct rate on start-up.

Could you please share the SER and DES mode straps?

Also, could you please check whether the power-up sequencing are correct for both SER and DES?


Since there is a loss of LOCK issue that was seen earlier, if possible are you able to use a cable to connect the SER to the DES? That might be another way to isolate the issue.

Best regards,
Ikram