[参考译文] DS90UB929-Q1：AV 静音解决方案

您好、Ryan、

那么、唯一的问题是在写入之后是否清除了0x4[4]位？ 当前测试是否出现黑屏或此系统的任何其他问题？

此致、
Ikram

Ikram

在实施我们的勘误解决方案后、他们在现场遇到了 UB947的 AV 静音问题。 您可以参阅以下 e2e。

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

我不知道你能不能把它们放在一起。

然后他们检查发现 UB929的寄存器设置不起作用。

对于 UB929、 您可以在您的 EVM 中尝试一下吗？ 解决此问题后,他们将尝试 UB929进行 AV 静音测试,如 UB947。  这两个问题需要尽快解决、因为它们已经进行 大规模生产。  

我可以在明天早上与您通话吗？

谢谢

器件型号：DS90UB947-Q1

工具与软件：

尊敬的专家：

客户系统为 UB947+UB948、它已正常大规模量产。

即使他们已经根据我们的勘误表添加了 AV 静音解决方案,但他们仍然遇到 AV 静音现象。 为了再次重现 AV 静音问题、客户创建了一个1920x1080图片、其 RGB 全部为0x666666。  

使用此测试图片、在 UB947 0x4寄存器位4设置为0的情况下、这可以100%重现 AV 静音问题(黑屏)。

然后、将 UB947 0x4寄存器位4设置为1、然后对 UB947&UB948下电上电。 大约4/5次、AV 静音问题消失了。 但在大约1/5的情况下、 仍然可以看到 AV 静音问题(黑屏)。 所有被测板都存在这种现象。

这是什么原因呢?  

哪个寄存器可以指示 UB947、UB948是否处于 AV 静音模式？

下面是寄存器转储：

e2e.ti.com/.../8206.register-dump.xlsx

下面是它们用于测试的图片、1920x1080 (具有 RGB)均为0x66。 事实上,当他们只是离开最后几个像素在右下角为0x666666, AV 静音问题可以重现。

尊敬的专家：

对此有什么建议吗？

客户已进行大规模生产。 他们要求每天致电以更新进度。

我是否可以建议您在实验室中测试这种现象？ 作为客户生成图片(1920x1080图片、其 RGB 全部为0x666666)？

谢谢

您好、Ryan、

我运行929和948、 寄存器0x4在启动时的默认值是0x80、而在我们写入0x90后、再次读取后仍是0x90。 因此、它不应切换回默认状态。

1.系统是否已关闭并再次打开？
2.在测试的每个装置上是否发生这种情况？ 所有其他 I2C 写入是否按预期工作？
3.是否在任何 AVMUTE 0x666666模式或其他条件下测试该模式？ 还是普通的 PatGen 或端到端视频？

我们收到了一些关于947的后续问题：

1.测试时,视频是如何输入的? 有 PatGen 和 ALP 功能吗？ 或和 SoC 源中？  
2.使用的分辨率是多少？ 我知道您提到的 是1920x1080、但它的分辨率与最终生产显示的分辨率相同吗？

3.到底发送的是什么模式。 我们可以在活动帧中看到0x666666、那么 DE=L 或消隐周期如何呢？

4.您能否验证出现黑屏问题的比率：
   -没有变通办法。 是100%吗？
   -有变通办法(0x4[4]=1 )。 它是否在所有 测试板上占20%？  

我知道您为权变措施而发送了寄存器转储、但没有权变措施、当它在通过和失败情况下都适用权变措施时、您是否也可以向我们发送寄存器转储？ 可能会有差异。  


此致、
Ikram

Ikram

非常感谢您的帮助。 客户已验证 UB929问题是由于其软件错误造成的。

对于 UB947：

1.测试时,视频是如何输入的? 有 PatGen 和 ALP 功能吗？ 或和 SoC 源中？  

它来自 SoC。

2.使用的分辨率是多少？ 我知道您提到的 是1920x1080、但它的分辨率与最终生产显示的分辨率相同吗？

1920x1080、用于生产显示

3.到底发送的是什么模式。 我们可以在活动帧中看到0x666666、那么 DE=L 或消隐周期如何呢？

SoC 不控制 消隐期内的视频数据。   在 消隐期间,可能 SoC 仍会发送0x666666垃圾(在 FIFO 缓冲器中)。 即使在这种情况下、让我确认 UB947是否可以在将0x4寄存器的位4设置为1的情况下消除这些0x666666？ 如果不是、那么  0x4寄存器的第4位究竟是什么功能？

4.您能否验证出现黑屏问题的比率：
   -没有变通办法。 是100%吗？

是的、使用这个特定的0x666666图片

   -有变通办法(0x4[4]=1 )。 它是否在所有 测试板上占20%？  

是、在所有 测试板上均为10%~ 20%

我知道您为权变措施而发送了寄存器转储、但没有权变措施、当它在 通过和失败情况下都适用权变措施时、您是否也可以向我们发送寄存器转储？ 可能会有差异。  

给你。 我添加了寄存器转储以及  通过和失败情况下的权变措施。 差异以红色表示。 我没有看到任何重大差异。

e2e.ti.com/.../register-dump.xlsx

您是否能够设置一个100%重现 AV 静音问题的环境？ 例如、让 soc 在消隐时发送0x666666。 那么您可以测试当前权变措施验证吗？ 这是我们向前迈进的最重要的一步。

BTW、客户 在将0x4寄存器的位4设置为1的情况下测试了帧最后一个像素不是0x666666 (右下角像素不是0x666666)的正常图片。 它们还在1000次上电测试后重现了 AV 静音问题。 这与勘误表中的以下描述不匹配。  "帧的最后一个像素 "是指图片的右下角像素吗？ 为什么仍然会发生 AV 静音？  

"如果帧的最后一个像素为0x666666、并且视频传输延伸到 DE = L 周期、则受影响的配套解串器上的 AVMUTE 模式将被启用。"

谢谢

您好、Ryan、

我使用 PatGen 测试了947-948 (0x666666模式)、但没有遇到 AVMUTE 问题。 根据我们当前的设置、 在消隐周期发送该模式是不可行的。  

Kang cai Mr. Li 说：

BTW、客户测试了 帧最后一个像素不是0x666666 (右下角像素不是0x6666)且0x4寄存器位4设为1的正常图片。 它们还在1000次上电测试后重现了 AV 静音问题。 这与勘误表中的以下描述不匹配。  "帧的最后一个像素 "是指图片的右下角像素吗？ 为什么仍然会发生 AV 静音？  [报价]

在本例中、是否存在寄存器转储？ 很难判断它实际上是不是 AVMUTE、或者是否存在其他 CRC 错误或类似的问题。 系统是否显示黑屏或已恢复？

在您发送的寄存器转储中、工作(有权变措施)和不工作(也有权变措施)之间的唯一区别是0xC7寄存器、它指示来自下游器件的中断。 我正在检查启用任何其他解串器中断是否可以提供指示。




客户测试中是否有关于 SoC 端的更新？ 它们能否控制消隐周期上发送的模式。 如果是、它们可以尝试在该期间发送0x555555来恢复。
0x666666图形会导致 AVMUTE 处于垂直消隐(而不是水平消隐)状态。  

此外、您能否检查 SoC 是否发送 HS/VS 信号、或者这是否仅使用 DE。 一些系统仅使用 DE 来生成同步时序、HS/VS 可能保持静态。


此致、
Ikram

Ikram

客户 SoC 将继续在最右下角将最终像素发送到 Vblanking 周期。 他们不能改变这个逻辑。

其 SoC 将 HS/VS 和 DE 信号发送在一起。

您能问 BU 以前是如何生成、测试和验证 AV 静音问题吗？ 应该有一些方法来重现,对吗?

您好、Ryan、


我们正在实验室中设置949 - 948设置、以检查是否可以在将 PC 作为源代码的情况下重现问题。 此设计将模拟客户的设置、但使用949 SER 和 PC 而不是 SoC。

我们还将尝试设置926作为源来运行925 - 948设置、因此我们可以控制消隐周期并在外部发送0x666666或0x5555。 我将向您介绍我们在这里找到的最新信息。



此外、我在下面附上一份 Excel 表格、以便跟踪测试结果。 我们将检查是否有权变措施/勘误表、然后确定它是在最后一个像素上、每行(全帧)上以0x666666进入 AVMUTE、还是根本没有。 然后、 如果该像素进入 AVMUTE、我们需要检查更改最后一个像素(在有效帧内)是否会退出 AVMUTE。

请与客户合作、添加有关每个案例的备注、发生频率。 对于已经完成的测试、请验证我添加的有关结果的注释是否正确。 与电流测试类似、这可能需要循环和重复以确定发生问题的频率。

e2e.ti.com/.../Test_5F00_Plan_5F00_AVMUTE.xlsx

另外、还有几个问题：

-在929 - 948上,他们是否看到这个问题? 他们是否正在使用权变措施？ 是否有发现？

-在客户的系统上,是否可以更改最后一个像素,永远不会有它0x666666。 如果他们将其永久设置为不同的颜色、可能会怎么样？

此致、
Ikram

Ikram

非常感谢您的反馈。

客户正在做更多实验来填写下表。

e2e.ti.com/.../5751.Test_5F00_Plan_5F00_AVMUTE.xlsx

在929 - 948上、他们是否看到了此问题？ 他们是否正在使用权变措施？ 是否有发现？

它们只是解决了 UB929的寄存器设置的 SW 错误。 稍后将测试相同的测试。 您的帖子。

-在客户的系统上、是否可以更改最后一个像素而不使用0x666666。 如果他们将其永久设置为不同的颜色、可能吗？

感谢这个建议。 他们将与 SoC 端讨论如何实现这一点。   您的帖子。

您好、Ryan、

我需要更多的时间来使用947-948设置(使用另一个 OLDI DES 作为源)对此进行测试。 我的目标是星期一结束一天、看看我们是否可以重现问题。  

根据您发送给我们的信息、最后一个像素0x666666图案似乎是导致该图案的、可能是由于 DE = L 而 RGB 图案仍在传输。 您还可以检查去极性是否正确、或更改去极性。 这是因为我注意到、在无权解决方法和权变措施情况之间、948上的0x22寄存器是不同的。 你知道为什么会这样吗？

另外、小组还询问了最初如何缩小这一问题的范围。 根据我们在电话中讨论的内容、客户发现黑屏问题、然后查看勘误表。 我们是否可以确定0x666666图案是否是在发生原始黑屏问题时首先发送的？ 这是 SoC 当时发送的颜色之一吗？


此致、
Ikram

Ikram

下面是华为实验完成的新更新。  新输入为红色。  

e2e.ti.com/.../Test_5F00_Plan_5F00_AVMUTE_5F00_1.xlsx

您还可以检查去极性是否正确、或更改去极性。 这是因为我注意到、在无权解决方法和权变措施情况之间、948上的0x22寄存器是不同的。 您知道原因吗？

DE 为高电平有效。 是的。 我的理解是、UB948 0x22[6]会自动从 UB947 0x4[4]加载、但顺序相反。 948 0x22[6]= 0匹配947 0x4[4]= 1。

如果您的 EVM 行为不是这样、请告诉我。

这来自数据表："该位自动从远程串行器加载"

小组询问最初如何缩小此问题的范围。 根据我们在电话中讨论的内容、客户发现黑屏问题、然后查看勘误表。 我们是否可以确定0x666666图案是否是在发生原始黑屏问题时首先发送的？ 这是 SoC 当时发送的颜色之一吗？[/QUOT]

 

请参阅 Test_Plan_AVMUTE_1.xls 原始4案例 A、这是其初始案例。 这是一个随机的视频。 最后一个像素不是0x666666。  

请也参考原始9案例 E、对于最后一个像素不是0x666666的图片、将0x4[4]设置为1、它们也在昨天的1000次电源循环后重印一次 AV 静音。  

您好、Ryan、

我在没有变通办法的情况下使用947 - 948进行了测试、但未发现出现此问题。 使用 LVDS 源在活动帧中发送全部0x666666时对此进行了测试。  

为了澄清、如果 活动帧中没有0x666666、则在超过1000次下电上电后、无论是否采用权变措施、都会发生黑屏问题。
如果他们在最后一个像素中发送0x5555555、视频恢复了吗？ 它是否经过测试？ 测试计划注释会显示这一点、但我只是想确认一下。



您能否让客户将 LVDS 流的逻辑分析仪捕获结果输入947。 采集最后一个像素数据。 数据表的"7.3.4 OpenLDI 输入帧和颜色位映射选择"部分将有助于查找 OLDI 映射。 另外、请告诉我使用的是哪个映射方案。

1.请尝试以下操作：

-最后一个像素设置为0x666666  
-没有解决办法
-通过监控 VSYNC 和 HSYNC 捕获 LVDS 信号以沿最后一个像素进行捕获。  

2.重复勘误操作

此致、
Ikram

Ikram

你有没有发现任何人能告诉你他们以前是如何再现 AV 静音的? 或者应该有一些关于之前测试的文档。 过去应该有某种方法、对吧？

为了澄清、 在活动帧中没有0x666666的情况下、在超过1000次下电上电(使用和不使用权变措施)之后、发生了黑屏问题。
如果他们在最后一个像素中发送0x5555555、视频恢复了吗？ 它是否经过测试？ T [/报价]

在本例中、最后一个像素上没有0x666666。 但视频中间会有一些随机的0x666666。

是的、它可以在 最后一个像素中使用0x555555恢复。

请告诉我使用的是哪种映射方案。

您可以检查它们的寄存器转储。 它们的 UB947寄存器0x4F 寄存器为0xC0 (OpenLDI 映射)

客户表示  使用逻辑分析仪采集高速差分 OLDI 信号并不容易。 他们仍需要您在 TI 实验室找到一种重现 AV 静音问题的方法。 否则、我们会被困在这里。

谢谢

[/quote]

Ikram

下面是采集的 UB947上电序列 Huawei。

唯一值得关注的是 VDD11斜升时间为4ms>1.5ms。

这在理论上有什么影响？

注意：它们的 UB929 VDD11斜升时间也是4ms、但没有像 UB947那样显示任何 AV 静音问题。  华为怀疑这不是问题的关键点。

e2e.ti.com/.../UB947-powerup.pptx

您好、Ryan、

对于我们的器件、我们要求遵循上电序列、包括指示上升时间。 我们不会准确指示可能发生哪种类型的错误。 我们只会根据设计和验证数据来共享要求。

我们还要尝试使用 Flink TX 板来检查是否可以在消隐期内进行传输、从而查看我们是否可以重现问题。


此外、我们还有一些问题和可能的测试：

1.在"设置活动帧像素为0x666666以外的图案"的测试中,是否可以分享发送了什么图案? 我们知道它不是0x666666、但它到底是什么？

2.另外,如果他们有测试数据,你能分享测试的周期计数吗? 示例、运行了多少次、有多少个案例显示出问题？

3.出现黑屏问题和"如果黑屏(是前一列)、将活动帧上的最后一个像素更改为0x555555"后、执行以下步骤：

a.任何类型的复位、下电上电/PDB、然后更改 SoC 输出(0x555555)？

b.通过更改 SoC 上的输出在最后一个像素上发送0x5555。 (无 PDB 或复位已完成)<-这是我们需要的测试。 因为我们观察到上电时发生的问题

5.您是否还可以 尝试这两个测试并添加到测试计划 Excel 文件中：  

A.-在 OLDI 上发送黑屏
  -根据需要启动设备
  -运行初始化脚本(尝试使用变通办法,也没有变通办法)
  -然后打开视频(尝试使用0x66666666,而不是0x66666666,并列出使用的模式)
  -重复和  

b.遇到黑屏问题(有或没有权变措施)后、是否会将软复位为 DES 或 SER 恢复视频？
 软件/数字复位将设置寄存器0x1[0]= 1

此外、您能否共享初始化脚本。 使用的 PCLK 和每像素位数是什么？  

我们可以在明天的电话中进一步讨论。

此致、
Ikram

Ikram

我刚刚向您的日历发送了邀请、以便您在6月9：00拨打电话。12. 谢谢

华为将 VDD11上升时间缩短到不到1.5ms、但问题仍然可以重复。

让我们在即将到来的通话中与华为一起解答您的问题。

Ikram

非常感谢您的来电。 以下是会议摘要：

1.希望您可以利用您的新设置再现 AV 静音问题

2.为什么 UB929在 VDD18和 VDD11上都具有1.5ms 的上升限制、而 UB947仅在 VDD11上具有1.5ms 的限制？ 为什么我们有这一上升要求？ PDB 上升、以使芯片以任何方式解除复位。 这对他们来说是一个非常重要的问题、因为他们的 UB929也无法满足此要求。 他们想知道他们的大规模生产是否存在风险？ 他们是否应该进行相应的更改、即使他们还没有看到 UB929有任何问题？

对于您的以下问题：

1.在"设置活动帧像素为0x666666以外的图案"的测试中,是否可以分享发送了什么图案? 我们知道它不是0x666666、但它到底是什么？

这只是一幅正常的画面,太阳升起的画面或游泳的鱼画面。

2.另外,如果他们有测试数据,你能分享测试的周期计数吗? 示例、运行了多少次、有多少个案例显示出问题？

例如、test_plan Excel 文件的 e9为1000次。 这不是每2000次的两次。 仅1000次。

3.出现黑屏问题和"如果黑屏(是前一列)、将活动帧上的最后一个像素更改为0x555555"后、执行以下步骤：

a.任何类型的复位、下电上电/PDB、然后更改 SoC 输出(0x555555)？

b.通过更改 SoC 上的输出在最后一个像素上发送0x5555。 (无 PDB 或复位已完成)<- 这是我们需要的测试。 因为我们观察到上电时发生的问题

这是 B。没有任何下电上电/PDB。

5.您是否还可以 尝试这两个测试并添加到测试计划 Excel 文件中：  

A.-在 OLDI 上发送黑屏
  - 根据需要启动设备
  -运行初始化脚本(尝试使用变通办法,也没有变通办法)
  -然后打开视频(尝试使用0x66666666,而不是0x66666666,并列出使用的模式)
  -重复和  

正如我们在通话中所讨论的,这就是华为目前的程序。 正如您建议的、他们将尝试在 UB947寄存器程序之前禁用 OLDI。 我将为您更新测试结果。

b.遇到黑屏问题(有或没有权变措施)后、是否会将软复位为 DES 或 SER 恢复视频？
 软件/数字复位将设置寄存器0x1[0]= 1

好的。 明天会再试。

此外、您能否共享初始化脚本。 使用的 PCLK 和每像素位数是什么？  

问题与解决方案无关。 其解决方案为1920x1080@60Hz 或 1152x576@60Hz。 都有相同的问题。 明天我会把他们的脚本发给你。

您好、Ryan、

我们能够使用权变措施验证该器件是否在 DE 为低电平时门控 RGB 输出。 我们在 UH947上测试了该特性、并设置 SER 的 PASS RGB 位、以将 SER 用作 UB 器件。



我们将 RGB 硬设置为0x666666、以便其在消隐周期内保持该图形、但我们无法使其进入 AVMUTE 模式。 我们正在与设计团队合作、以确定 DES 是否需要任何其他设置才能进入 AV 静音。 以下是启用了导通 RGB 但没有 RGB GATE 权变措施时的情况：



期望听到 PDB 变为高电平后设置 OLDI 的结果。

此外、能否询问客户是否有任何方法可以将948的 LVDS 输出转换为 RGB？ 例如、我们使用了 FLINK3V8BT-85 RX 板。 如果我们能够获得 RGB 的逻辑分析仪捕捉并检查它如何随 DE 和 SYNC 信号变化、将会非常有用。

此致、
Ikram

Ikram

让我确认 UH947即使没有变通办法设置也无法进入 AV 静音？ 这不是预期行为、对吧？

华为已经尝试过,问题仍然是一样的。

他们有办法将948的 LVDS 输出转换为 RGB？

抱歉、他们没有此信息。

您能帮助回答以下问题吗？ 谢谢

"为什么 UB929在 VDD18和 VDD11上都具有1.5ms 的上升限制、而 UB947仅在 VDD11上具有1.5ms 的限制？ 为什么我们有这一上升要求？ PDB 上升、以使芯片以任何方式解除复位。 这对他们来说是一个非常重要的问题、因为他们的 UB929也无法满足此要求。 他们想知道他们的大规模生产是否存在风险？ 他们是否应该进行相应的更改、即使他们还没有看到 UB929有任何问题？"

Ikram

现在有一个重要的突破！

华为优化 VDD11上升时间小于1.5ms、AV 静音问题消失了、0x4[4]设置为1！ (他们昨天的实验有一些错误。)

非常令人惊讶的是、947和929具有相同的 VDD11 4ms 上升时间、但 UB947存在此 AV 静音问题、而 UB929都不错。 为什么会这样？

它们是否也应该优化 UB929 VDD11和 VDD18上升时间？

非常感谢