DS90UB929-Q1: AV mute solution

Hi Ryan,

So, the only issue is that the 0x4[4] bit is being cleared after the write? Is the black screen or any other issue occurring with this system with the current tests?

Best regards,
Ikram

Ikram,

They met AV mute issue for UB947 in the field after they already implemented our errata solution. You can refer to below e2e.

https://e2e.ti.com/support/interface-group/interface---internal/f/interface---internal-forum/1369332/ds90ub947-q1-av-mute-workaround

I don't know whether you can take care of both of them together.

And then they check and find register setting for UB929 doesn't take effect.

For UB929, could you try this in your EVM? After this issue solved , they will try UB929 for AV mute test like UB947 as well. Both issue need to be closed shortly because they are already in  mass production. 

Can I make a call with you at your tomorrow morning?

Thanks

Part Number: DS90UB947-Q1

Tool/software:

Dear expert,

Customer system is UB947+UB948 which is already in mass production normally.

Even they already added solution for AV mute based on our errata, but they still met an AV mute phenomenon. To reproduce the AV mute issue again, customer created a 1920x1080 picture whose RGB are all 0x666666. 

This can 100% reproduce AV mute issue (black screen) with this test picture with UB947 0x4 register bit 4 set to 0.

Then they set UB947 0x4 register bit 4 to 1 and then power cycle UB947&UB948. For around 4/5 chance, the AV mute problem is gone. But by around 1/5 chance, AV mute issue (black screen) still can be seen. This phenomenon can be seen with all boards under test.

What is the reason for this? 

And which register can indicate UB947,UB948 is in AV mute mode or not?

Below is register dump:

8206.register dump.xlsx

Below is picture they used to test, 1920x1080 with RGB are all 0x66. In fact, when they just leave the final several pixels at lower right corner as 0x666666 , AV mute issue can be reproduce.

Dear expert,

Is there any suggestion on this?

Customer is already in mass production. They are asking for daily call to update progress.

Can I suggest you test this phenomenon in your lab? Generate a picture as customer (1920x1080 picture whose RGB are all 0x666666)?

Thanks

Hi Ryan,

I ran the 929 and 948, and register 0x4 is 0x80 default upon startup, and after we write 0x90, it's still 0x90 after reading again. So, it should not switch back to default condition.

1. Is the system powered off and on again?
2. Is this occurring on every unit tested? Are all other I2C writes working as expected?
3. Is this being tested with any AVMUTE 0x666666 pattern, or other conditions? Or is it with usual PatGen or end-to-end video?

We had a few follow up questions about the 947:

1. For the tests, how is the video being input? Is it with PatGen and ALP? Or and SoC source? 
2. What is the resolution used? I know you mentioned 1920x1080 but is it the same resolution as the final production display?

3. What pattern exactly is being sent. We can see the 0x666666 in the active frame, what about the DE=L or blanking period?

4. Could you verify the rate the black screen issue occurs:
      - without the workaround. Is it 100%?
      - with workaround (0x4[4] = 1). Is it 20% on all boards tested? 

I know you sent register dumps for workaround and no-workaround, could you also send us the register dumps while it is working with the workaround in both passing and failing cases? Maybe there could a difference. 


Best regards,
Ikram

Ikram,

Great thanks for your help. Customer already verified UB929 issue is due to their SW bugs.

For UB947:

1. For the tests, how is the video being input? Is it with PatGen and ALP? Or and SoC source? 

It is from SoC.

2. What is the resolution used? I know you mentioned 1920x1080 but is it the same resolution as the final production display?

1920x1080 for production display

3. What pattern exactly is being sent. We can see the 0x666666 in the active frame, what about the DE=L or blanking period?

SoC doesn't control video data for blanking period. It is possible SoC still send 0x666666 garbage (in FIFO buffer )during blanking period. Even at this case, let me confirm whether UB947 can eliminate these 0x666666 with bit 4 of 0x4 register set to 1? If not, what  bit 4 of 0x4 register exactly do?

4. Could you verify the rate the black screen issue occurs:
      - without the workaround. Is it 100%?

yes, with this specific 0x666666 picture

      - with workaround (0x4[4] = 1). Is it 20% on all boards tested? 

Yes, 10% ~ 20% on all boards tested

I know you sent register dumps for workaround and no-workaround, could you also send us the register dumps while it is working with the workaround in both passing and failing cases? Maybe there could a difference. 

Here you are. I added register dump with the workaround in both passing and failing cases. The difference is in red. I didn't see any essential difference.

register dump.xlsx

Could you setup an environment to 100% reproduce AV mute issue ? For example, let soc send 0x666666 at blanking on purpose. Then you can test current workaround validation? This is the most important step for us to move forward.

BTW, customer tested a normal picture whose last pixel of the frame is NOT 0x666666 (lower right corner pixel is NOT 0x666666) without bit 4 of 0x4 register setting to 1. They also reproduced AV mute issue after 1000 times power up test. This doesn't match below description from errata.  Does "the last pixel of the frame " mean the lower right corner pixel of the picture? Why AV mute still happen? 

"If the last pixel of the frame is 0x666666, and the video transmission extends into the DE = L period, then AVMUTE mode on the affected companion Deserializer will be enabled."

Thanks

Hi Ryan,

I tested the 947-948 with the 0x666666 pattern, with PatGen and we didn't run into an AVMUTE issue. From our current setup, it isn't feasible to send that pattern on the blanking period. 

Ryan Wang said:

BTW, customer tested a normal picture whose last pixel of the frame is NOT 0x666666 (lower right corner pixel is NOT 0x666666) without bit 4 of 0x4 register setting to 1. They also reproduced AV mute issue after 1000 times power up test. This doesn't match below description from errata.  Does "the last pixel of the frame " mean the lower right corner pixel of the picture? Why AV mute still happen? 

From this case, is there a register dump? It's difficult to say whether it was in fact an AVMUTE, or if there are other CRC errors, or similar issue. Did the system stay black screen or recovered?

In the register dump you sent, the only difference between the working (with workaround) and not-working )also with workaround), is the 0xC7 register, and it indicated interrupt from downstream device. I'm checking whether enabling any other deserializer interrupts could provide indication.




Any update on the customer tests about SoC side? Can they control patterns sent on the blanking period. If so, they could try sending 0x555555 in that period to recover.
The 0x666666 pattern causes AVMUTE in the vertical blanking, not horizontal. 

Also, could you check whether the SoC sends HS/VS signals or if that is only using DE. Some systems only use the DE for generating the sync timing, and HS/VS might stay static.


Best regards,
Ikram

Ikram,

Customer SoC will keep sending the final pixel at the most lower right corner to Vblanking period. And they cannot change this logic.

Their SoC send both HS/VS and DE signal together.

Could you ask how BU produce , test and verify AV mute issue previously? There should be some way to reproduce , right?

Hi Ryan,


We are setting up a 949 - 948 setup in the lab to check if we can reproduce the issue with the PC as a source. This will emulate the customer's setup, but with the 949 SER and PC instead of SoC.

And we will also try setting up a 926 as a source to run a 925 - 948 setup, so that we can control the blanking period and send 0x666666 or 0x555555 externally. I will update you on what we find from here.



Also, I'm attaching an excel sheet below to keep track of the tests. We will check with and without the workaround/errata, and then whether it enters AVMUTE with 0x666666 on last pixel, on every line (full frame), or not at all. And then if it enters AVMUTE, we need to check whether changing the last pixel (within the active frame) exits AVMUTE.

Please work with the customer to add comments about each case, the frequency of occurrence. And for the tests already done, verify whether the comments I added about the result are correct. Similar to the current tests, this may require to loop and repeat to find how often issue occurs.

Test_Plan_AVMUTE.xlsx

Also, a couple of further questions:

- on the 929 - 948, are they seeing this issue? Are they using the workaround? Any findings?

- On the customer's system, is it possible to change the last pixel and never have it 0x666666. Maybe if they set it to a different color permanently?

Best regards,
Ikram

Ikram,

Great thanks for your feedback.

Customer is doing more experiment to fill below table.

5751.Test_Plan_AVMUTE.xlsx

Ikram Haque said:

on the 929 - 948, are they seeing this issue? Are they using the workaround? Any findings?

They just solved SW bugs for register setting for UB929. Will test the same test later. Will keep you posted.

Ikram Haque said:

- On the customer's system, is it possible to change the last pixel and never have it 0x666666. Maybe if they set it to a different color permanently?

Thanks for this suggestion. They are discussing with SoC side to see whether they can implement this.  Will keep you posted.

Hi Ryan,

I will need a little more time to test this with the 947-948 setup using another OLDI DES as a source. I'm targeting end of day on Monday to see if we can recreate the issue. 

Based on the information you sent us, it seems that the last pixel 0x666666 pattern is causing it and it might be due to DE = L while the RGB pattern is still transmitted. Could you also check if the DE polarity is correct, or changing the DE polarity. This is because I noticed that between the no-workaround and workaround cases, the 0x22 register on 948 are different. Do you know why that is?

Also, the team asked about how this issue was narrowed down initially. From what we discussed on call, the customer found black screen issue, and then looked into the errata. Do we know for sure whether the 0x666666 pattern was sent in the first place when the original black screen issue occurred? Is that one of the colors the SoC sent at the time?


Best regards,
Ikram

Ikram,

Below is new update for experiments huawei done. The new input is in red. 

Test_Plan_AVMUTE_1.xlsx

Ikram Haque said:

Could you also check if the DE polarity is correct, or changing the DE polarity. This is because I noticed that between the no-workaround and workaround cases, the 0x22 register on 948 are different. Do you know why that is?

DE is high active. This is correct. My understanding is UB948 0x22[6] is automatically loaded from UB947 0x4[4] but reversed. 948 0x22[6]=0 match 947 0x4[4]=1.

If your EVM doesn't behave like this, pls let me know.

This is from datasheet: "this bit is automatically loaded from the remote serializer"

Ikram Haque said:

the team asked about how this issue was narrowed down initially. From what we discussed on call, the customer found black screen issue, and then looked into the errata. Do we know for sure whether the 0x666666 pattern was sent in the first place when the original black screen issue occurred? Is that one of the colors the SoC sent at the time?

Pls refer to Test_Plan_AVMUTE_1.xls raw 4 case A, this is their initial case. It's a random video. Last pixel is not 0x666666. 

Pls also refer to raw 9 case E as well, for picture whose last pixel is not 0x666666, with 0x4[4] set to 1, they also reproduced once AV mute after 1000 times power cycle yesterday. 

Hi Ryan,

I tested with the 947 - 948, without the workaround, and did not see this issue occur. This was tested with LVDS source sending all 0x666666 in the active frame. 

To clarify, in the cases where there is NO 0x666666 in the active frame, after 1000+ power cycles, with and without workaround, the black screen issue occurred.
And if they send 0x5555555 in the last pixel, the video recovered? Was this tested? The test plan comment says so, but I just want to confirm.



Could you please ask the customer to get logic analyzer captures of the LVDS stream into the 947. Capture the last pixel data. The "7.3.4 OpenLDI Input Frame and Color Bit Mapping Select" section of the datasheet would help to find the OLDI mapping. Also, please let me know which mapping scheme is used.

1. Please try this:

- last pixel set to 0x666666 
- no workaround
- capture LVDS signals to capture along last pixel by monitoring VSYNC and HSYNC. 

2. Repeat with the errata workaround

Best regards,
Ikram

Ikram,

Have you found anybody who can tell you how they reproduced AV mute previously? Or there should be some documents about previous test. There should be some way in the past, right?

Ikram Haque said:

To clarify, in the cases where there is NO 0x666666 in the active frame, after 1000+ power cycles, with and without workaround, the black screen issue occurred.
And if they send 0x5555555 in the last pixel, the video recovered? Was this tested? T

For this case, there is no 0x666666 at the last pixel. But there is some random 0x666666 in the middle of video.

Yes, it can be recovered with  0x555555 in the last pixel.

Ikram Haque said:

please let me know which mapping scheme is used.

You can check their register dump. Their UB947 register 0x4F register is 0xC0 (OpenLDI mapping)

Customer said it is not easy to capture high speed differential OLDI signal with logic analyzer. They still need you find a way to reproduce AV mute issue at TI lab. Otherwise, we are stuck here.

Thanks

Ikram,

Below is UB947 power up sequence huawei captured.

The only concern is VDD11 ramp up time is 4ms>1.5ms.

What impaction for this in theory?

NOTE: Their UB929 VDD11 ramp up time is also 4ms but didn’t show any AV mute issue like UB947.  Huawei doubt this is not the key point of the problem.

UB947 powerup.pptx

Hi Ryan,

For our devices, we require that the power-up sequence, including indication of rise-time, is followed. We don't indicate exactly which type of errors might occur. We only share the requirement based on the design and validation data.

We are also trying to check whether we can transmit in the blanking period by using the FLINK TX board, to see if we can recreate the issue.


Also, we have a few questions and possible tests:

1. In the test with "Set active frame pixels to pattern other than 0x666666", with and without workaround, could you share what pattern was sent? We understand it was not 0x666666, but what was it exactly?

2. Also, if they have the test data, could you share the cycle counts of the tests? Example, how many times it was ran, and how many cases showed issue?

3. After black screen issue occurs, and "If screen is black (is previous column), change last pixel on active frame to 0x555555" steps are taken, do they:

a. Any type of reset, or power cycle/PDB, and then change the SoC output (0x555555)?

b. Send 0x555555 on last pixel by changing output on SoC. (No PDB or reset done) <- this is the test we need. Because we observed issue happening on power-up

5. Could you also please try these two tests and add to the Test Plan excel file: 

A. - Send black screen on OLDI
    - Power-up devices as required
    - run initialization script (try with workaround and also without workaround)
    - then turn on video ( try with 0x666666, and also NOT 0x666666, and list what pattern was used)
    - repeat and 

B. After getting black screen issue (with or without workaround), does soft reset to DES, or SER recover the video?
 A software/digital reset would be setting register 0x1[0] = 1

Also, could you please share the initialization script. What is the PCLK and bits per pixel used? 

We can discuss further in the call tomorrow.

Best regards,
Ikram

Ikram,

I just sent invitation to your calendar for a call on your 9:00AM Jun. 12. Thanks

Huawei reduced their VDD11 rise time to less than 1.5 ms but the problem still can be reduplicated.

Let's go through your question with huawei together on the coming call.

Ikram,

Great thanks for your call. Here is meeting summary:

1. Hope you can reproduce AV mute issue with your new setup today

2. Why UB929 has rising up 1.5ms limitation for both VDD18 and VDD11 while UB947 only has 1.5ms limitation only for VDD11? Why do we have this rising up requirement ? There is a PDB rising to release chip from reset any way. This is very important question for them because their UB929 also cannot meet this requirement. They want to know whether there is any risk for their mass production? Should they make change accordingly even they didn't see any issue for UB929 yet?

For your below questions:

1. In the test with "Set active frame pixels to pattern other than 0x666666", with and without workaround, could you share what pattern was sent? We understand it was not 0x666666, but what was it exactly?

It is just a normal picture, a sun rising picture or a swimming fish picture.

2. Also, if they have the test data, could you share the cycle counts of the tests? Example, how many times it was ran, and how many cases showed issue?

For example, E9 of test_plan excel file, 1000 times. It's not twice per 2000 times. Just 1000 times.

3. After black screen issue occurs, and "If screen is black (is previous column), change last pixel on active frame to 0x555555" steps are taken, do they:

a. Any type of reset, or power cycle/PDB, and then change the SoC output (0x555555)?

b. Send 0x555555 on last pixel by changing output on SoC. (No PDB or reset done) <- this is the test we need. Because we observed issue happening on power-up

It is B. There is no any power cycle/ PDB.

5. Could you also please try these two tests and add to the Test Plan excel file: 

A. - Send black screen on OLDI
    - Power-up devices as required
    - run initialization script (try with workaround and also without workaround)
    - then turn on video ( try with 0x666666, and also NOT 0x666666, and list what pattern was used)
    - repeat and 

As we discussed in the call, this is what huawei current procedure. As you suggested, they will try disable OLDI before UB947 register program. I will update you the test result.

B. After getting black screen issue (with or without workaround), does soft reset to DES, or SER recover the video?
 A software/digital reset would be setting register 0x1[0] = 1

OK. Will try tomorrow.

Also, could you please share the initialization script. What is the PCLK and bits per pixel used? 

The issue is not resolution related. Their solution is 1920x1080@60Hz or 1152x576@60Hz. All have the same issue. I will send you their script tomorrow.

Hi Ryan,

We were able to verify that the device gates the RGB output while DE is low with the workaround. We tested this on the UH947 and set the PASS RGB bit for the SER to behave as the UB device.



We hard set the RGB to be 0x666666, so it stays that pattern during the blanking period, but we were not able to get it to AVMUTE mode. We are working with the design team to find if there is any other setting required for the DES to enter AV MUTE. This below is how it was with PASS RGB enabled, without the RGB gate workaround:



Looking forward to hearing about the result from setting OLDI after PDB is high.

Also, could please ask the customer if they have any means to convert the LVDS output of the 948 to RGB? We used the FLINK3V8BT-85 RX board for example. It would be very helpful if we were able to get a logic analyzer capture of the RGB and check how it changes with DE and sync signals.

Best regards,
Ikram

Ikram,

Let me confirm UH947 cannot enter AV mute even without workaround setting? This isn't expected, right?

Ikram Haque said:

Looking forward to hearing about the result from setting OLDI after PDB is high.

Huawei already tried this and the problem is still the same.

Ikram Haque said:

they have any means to convert the LVDS output of the 948 to RGB?

Sorry, they don't have this.

Could you help to answer below questions? Thanks

"Why UB929 has rising up 1.5ms limitation for both VDD18 and VDD11 while UB947 only has 1.5ms limitation only for VDD11? Why do we have this rising up requirement ? There is a PDB rising to release chip from reset any way. This is very important question for them because their UB929 also cannot meet this requirement. They want to know whether there is any risk for their mass production? Should they make change accordingly even they didn't see any issue for UB929 yet?"

Ikram,

There is an important breakthrough just now!

Huawei optimized VDD11 rising time less than 1.5ms and AV mute problem is gone with 0x4[4] set to 1! (Their yesterday's experiment has some mistake.)

It is very surprise both 947 and 929 has the same VDD11 4ms rising up time, but UB947 has this AV mute issue while UB929 is all good. Why is that?

Should they optimize UB929 VDD11& VDD18 rising up time as well?

Great thanks