做OpenHarmony系统开发这些年我最大的感受是很多问题不是软件逻辑多难而是软硬件交界处的那层“窗户纸”没捅破。就拿HDMI输出来说开发板接显示器点不亮、电视识别不到信号、开机有图无声、热插拔偶尔失灵这些现象背后的根因往往藏在接口定义、电气特性、驱动框架的交叉地带。这篇文章我把HDMI输出这条链路从硬件管脚到系统框架完整拆一遍结合OpenHarmony实战开发中真实踩过的坑把每一项值得注意的细节都摊开讲清楚。无论你是刚接触OpenHarmony的入门开发者还是正在做产品化、过认证的硬件工程师这条链路里的知识点应该都能用得上。1. 摸清硬件底牌HDMI接口定义与PCB设计中的常见误区1.1 19根引脚不是全部都能照抄参考设计标准HDMI Type-A接口一共19根引脚很多初学者拿到原理图第一反应是“照着参考设计抄就行了”。这句话对一半错一半。参考设计能保证基本功能但到了实际产品化阶段引脚细节决定了很多隐蔽问题。先看标准定义。19根引脚大致分四类TMDS数据通道Data0-Data2及各自的屏蔽地、TMDS时钟通道、DDC通道SCL/SDA走I2C协议、以及控制信号CEC、HPD、5V电源、Utility/保留脚。每个TMDS差分对都配了一根独立的屏蔽地线这是HDMI和普通差分信号最大的区别——它要求每个差分对都有完整的地回流路径不能把三对数据线共用一个地。实际PCB设计里最容易犯的错有两个第一把HDMI座子的固定脚外壳地直接和信号地大面积相连。HDMI座子的外壳地应该通过小阻值电阻或磁珠与系统地单点连接目的是隔离外部机壳耦合进来的共模噪声。直接相连的后果是EMI指标变差RE测试时TMDS谐波更容易超标。第二忽略DDC通道的上拉电阻。DDC本质上是I2C总线SCL和SDA需要上拉到5V还是3.3V取决于源端芯片的设计。很多SoC集成的HDMI控制器DDC接口是开漏结构必须外部加上拉电阻才能正常通信。有人抄参考设计时把这个电阻漏了结果电视能识别HDMI但EDID读不到分辨率一直停留在默认的640x480。1.2 TMDS差分对的等长与阻抗直接影响信号质量和认证结果HDMI的TMDS信号速率不低1080P60Hz下数据速率大约1.78Gbps4K60Hz则飙到5.94Gbps。这种速率下差分对的阻抗控制和等长匹配就是硬性要求。差分阻抗要求100Ω±10%等长控制在5mil以内组间等长Data0/Data1/Data2/Clock四对线之间建议控制在10-20mil。这里有个容易忽略的点等长不只是线长的匹配还要把过孔、连接器焊盘的贡献算进去。一个过孔大约等效5-10mil的传输线长度如果某些通道多走了一个过孔线长就得做相应补偿。我见过一个实际案例硬件工程师照着参考设计画板数据线等长做得很好但时钟线因为绕行闪存颗粒多绕了200mil最开始测试1080P完全正常一旦切到4K分辨率就随机花屏。用示波器看时钟通道的眼图张开度明显比数据通道差一截。这个案例说明低速应用可能容忍不等长但到了高速信号领域每一mil的偏差都会被速率放大。1.3 DDC与CEC的上下拉决定了系统识别的下限DDC通道不用多说它负责源端读取Sink端的EDID数据。EDID里包含了显示器/电视支持的分辨率、刷新率、音频格式和声道数。如果DDC通信不稳定系统读不到完整EDID就只能按默认参数输出表现为画面模糊或者比例不对。CEC通道很多人不在意但它也是HDMI的固定功能之一。CEC需要2.7kΩ左右的上拉电阻到3.3V而且这个上拉在源端和Sink端各有一份并联后的等效电阻约为1.25kΩ。如果设计时漏了上拉或者上拉电阻值偏差太大CEC功能会间歇性失灵典型现象是电视遥控器有时能控制开发板、有时不能或者在开机瞬间CEC设备列表不正常。特别提醒CEC信号在HDMI线缆里是低速信号但对上升沿时间有要求300ns-1000ns如果PCB走线寄生电容过大上升沿变缓也会导致CEC通信不稳定。走线尽量短、不要跨分割地是基本要求。1.4 5V电源脚与HPD引脚的相互关系HDMI的18脚是5V电源输出由源端提供用于给Sink端的EDID ROM和HPD检测电路供电。这里有个不少硬件工程师会忽略的逻辑HPD19脚的电平状态其实取决于这个5V是否正常输出。Sink端的HPD电路通常是一个比较器或三极管电路源端5V供电正常、Sink端内部电路就绪后HPD才会被拉高。如果源端5V输出能力不足或者接了负载后电压跌落过多Sink端的检测电路就会判定“信号源不可用”表现为HPD一直在高/低电平之间抖动系统反复识别和断开HDMI连接。所以排查“HDMI偶尔识别不到”的故障时不要急着怀疑软件先用万用表量一下18脚电压在插入线缆后的实际值。如果从5.0V掉到4.5V以下基本可以判定是源端5V供电能力不足或保护电路误触发。2. HPD 19脚背后的软件博弈热插拔检测没那么简单2.1 19脚的电气约定与状态机HPDHot Plug Detect是HDMI热插拔机制的核心信号。Sink端通过HPD电平告知源端当前的连接状态HPD为低电平表示没有连接设备或者设备处于异常状态HPD为高电平表示设备已连接源端可以开始读取EDID并输出信号HPD拉低80ms再拉高表示设备连接虽然还在但EDID内容发生了变化源端需要重新读取EDID比如显示器切换了输入源或分辨率模式这个“拉低80ms再拉高”的时序是HDMI规范里专门定义的一个状态切换机制但很多驱动工程师不知道。结果就是显示器切换输入源之后开发板这边完全没有反应只有重启应用才能恢复画面。原因就是驱动只处理了HPD上升沿/下降沿没有处理“短暂拉低再拉高”这种特殊时序。2.2 OpenHarmony里HPD事件从硬件到应用的完整流转路径在OpenHarmony系统中HPD事件从硬件到应用层大致经过四层物理层HDMI座的19脚电平变化触发SoC内部的HDMI控制器中断。内核层HDMI控制器驱动通常是vendor厂商提供的内核模块响应中断读取HPD状态寄存器上报给Display子系统的HDIHardware Driver Interface实现。HDI层OpenHarmony的Display HDI接口定义了一套标准方法包括热插拔回调注册、EDID读取、分辨率模式获取等。芯片厂商的HDI实现会监听内核上报的热插拔事件通过回调函数通知上层。应用/框架层Surface服务或HDMI服务收到热插拔事件后决定是否重新枚举显示模式、是否把新显示设备加入显示输出列表。这条链路里最容易出问题的环节是内核层到HDI层的事件上报。有些厂商的BSP包把HPD中断触发放到了内核线程里如果内核线程优先级不够高在系统负载高的时候HPD事件会延迟上报几十毫秒甚至几百毫秒。用户体验就是插上HDMI线电视画面要等1-2秒才出来拔掉后电视要多黑屏几秒才恢复正常。2.3 一个典型的HPD抖动问题排查过程之前调试一块第三方OpenHarmony开发板遇到的现象是HDMI连接电视之后画面隔几分钟闪断一次每次大概1秒左右恢复。最开始怀疑是电视兼容性问题换了好几台电视都复现。后来用逻辑分析仪同时监测5V、HPD和TMDS时钟发现HPD在闪断前会出现一个约120ms的低电平脉冲然后重新拉高。正常情况下源端检测到HPD短暂拉低应触发EDID重读但问题是驱动把HPD低电平当成“设备断开”直接把显示链路关了链路重新建立后又要做完整的HDCP握手和模式协商所以整个恢复过程要1秒左右。根因确认后问题就清晰了这是显示器的“待机唤醒”动作电视在待机或信号源切换时会先拉低HPD通知源端然后重新协商。规范建议源端应该识别这种短脉冲并快速重新协商而不是做完整的断开再连接流程。解决方案也简单在内核驱动里增加HPD消抖逻辑。连续检测到HPD低电平超过500ms才判定为真正断开低于该时间视为EDID变更请求触发快速重协商。驱动打上补丁后再也没出现过闪断问题。2.4 三层配合物理层、驱动层、应用层各自该做什么经验之谈HPD处理不能只靠某一层而是三层各司其职。物理层负责保证信号完整性HPD走线要远离TMDS差分对避免高速信号串扰到HPD上形成误触发。很多公板设计HPD走线紧挨着时钟差分对量产机就会出现偶发误断开。驱动层负责消抖和状态管理核心是正确处理HPD的三种情况上升沿连接建立、下降沿连接断开、短脉冲EDID变更。同时要向上层提供查询接口让应用能区分是真正的热插拔还是EDID变更。应用层的职责是响应回调后快速刷新显示参数。OpenHarmony的Display接口提供了GetDisplayCapability和GetDisplaySupportedModes等方法应用在收到热插拔回调后重新获取显示能力切换到优化分辨率。有些应用开发者在回调里做耗时操作导致界面卡顿这种问题属于应用设计不合理不是系统问题。3. HDMI音频输出原理为什么“有图无声”往往不是音频的问题3.1 HDMI音频与传统I2S/PCM的本质差异我相信不少开发者都被“HDMI有图无声”折磨过。要理解这个问题必须先搞清楚HDMI音频和传统音频通路的不同。传统音频I2S/PCM走的是独立音频总线音频时钟由SoC或独立Codec产生音源数据通过I2S接口传给Codec/DAC再驱动扬声器或耳机。这条链路里音频和视频互不干扰。HDMI音频则完全不同音频数据不是单独传输的而是被打包进TMDS视频信号里在视频消隐期Blank Period的数据岛Data Island期间发送。也就是说音频数据必须“插空”塞进视频数据流的缝隙里跟视频共享同一组TMDS通道。这就带来了一个关键推论HDMI是否有音频输出不仅取决于音频驱动是否正确还取决于视频时序是否跑起来了。如果视频输出异常哪怕音频驱动完全正常也不会有声音。我见过太多“有图无声”的排查案例最后发现根本原因是分辨率没协商对视频输出到了副屏或扩展屏音频跟着视频走了。3.2 从AP到HDMI编码器的完整数据通路在典型OpenHarmony设备中HDMI音频通路大致如下第一阶段音频源。应用通过Audio框架OpenHarmony的Audio HDI创建播放流数据源可能是PCM录音文件、流媒体解码后的PCM数据等。第二阶段混音与格式转换。Audio服务对多个音频流做混音并按照HDMI需要把PCM数据调整为目标采样率和位深通常是48kHz/16bit或24bit。第三阶段I2S或TDM传输。转换后的数字音频通过I2S/TDM接口送给HDMI编码器/发送器TX。有些SoC把HDMI控制器和音频控制器集成在同一个封装里走内部总线有些则是外挂独立HDMI TX芯片通过I2S接口互联。第四阶段HDMI编码器打包。TX芯片把I2S音频数据封装成HDMI Audio Sample Packet并在视频消隐期的数据岛间隙发送出去。第五阶段Sink端电视/显示器接收解包恢复出PCM音频通过扬声器或音频输出接口播放。这条链路中任何一个环节断了都会表现为无声。但它们表现出的症状各不相同这为排查提供了线索。3.3 EDID与音频能力协商源端与Sink端的“谈判”HDMI的音频格式不是源端单方面决定的而是源端读取Sink端EDID中的Audio Data Block信息双方协商出一个都支持的格式。EDID的音频块里包含音频格式类型PCM、AC-3、DTS等PCM采样率支持位图32k/44.1k/48k/88.2k/96k/176.4k/192k声道数最大立体声或5.1/7.1位深16bit/20bit/24bit如果Sink端EDID里没有声明某种格式源端就不能输出该格式。典型场景某款老电视只支持48kHz/16bit的双声道PCM但开发板的音频服务根据配置文件强行输出96kHz/24bit电视接收端不认结果就是完全无声。解决思路也清晰音频服务在启动HDMI输出前必须先读取EDID中的音频能力按“Sink支持的格式”和“源端支持的格式”做交集再按优先级选择最合适的格式。OpenHarmony的Audio HDI提供了查询能力的方法但是否在每次热插拔后正确重新协商就要看厂商的BSP实现是否够细致了。3.4 静音时钟与CTS/N值一个容易被忽略的细节HDMI音频传输里有个概念叫Audio Clock Regeneration音频时钟恢复它依赖CTSCycle Time Stamp和NNumber of Bytes两个参数来保持音视频时钟同步。简单说HDMI的TMDS时钟是视频驱动的音频采样率不一定和TMDS时钟成整数倍关系。为了在接收端恢复出稳定的音频时钟发送端需要在数据包里周期性地发送CTS/N值告诉接收端“视频时钟和音频时钟的比例关系”。这两个值是由HDMI发送器根据TMDS时钟和音频采样率自动计算的但前提是发送器芯片需要知道准确的音频采样率。如果音频驱动配置采样率和实际输入到TX芯片的I2S时钟频率不一致CTS/N就算错了接收端恢复出的音频时钟就会漂移表现为声音忽然变调、周期性杂音、乃至完全无声。所以在音频驱动的实现里一定要确认I2S的Master ClockMCLK频率和采样率匹配。比如48kHz采样通常用12.288MHz或24.576MHz的MCLK配置错了HDMI音频就会出问题。3.5 “有图无声”的排查路径清单实际调试中我推荐按下面这个顺序排查效率最高第一步查连接状态。HDMI是否握手成功、分辨率和刷新率是多少。很多“无声”其实是连接没成功电视把开发板当成了不支持的信号源。第二步查EDID音频块。在/dev或sysfs节点下找EDID原始数据用hexdump解析Audio Data Block确认Sink端是否声明了音频支持。第三步查音频播放流状态。用OpenHarmony的音频调试工具查看当前播放流的采样率、位深、声道数确认是不是和EDID协商结果匹配。第四步查I2S时钟配置。用示波器或逻辑分析仪测TX芯片的I2S MCLK/BCLK/LRCK频率确认和配置一致。第五步查TX芯片寄存器。确认Audio Packet是否在发送、CTS/N值是否正常、Audio Infoframe是否携带正确信息。这个流程看起来机械但每一步都能排除一类根因比拿代码瞎猜快得多。4. OpenHarmony侧HDMI驱动开发与调试实录4.1 HDI框架下的Display与Audio两条线OpenHarmony对HDMI的支持分散在Display和Audio两个HDI子系统中这是新手最容易懵的地方。Display HDI负责视频相关的部分枚举HDMI作为Display设备、读取EDID、设置分辨率/刷新率、处理热插拔回调、管理Vsync。开发者主要通过IDisplayDevice接口和IVsyncCallback接口跟HDMI显示通道打交道。Audio HDI负责音频相关的部分枚举HDMI作为输出设备、协商音频格式、实现Audio Stream的播放。开发者通过IAudioAdapter、IAudioStream等接口操作HDMI音频。在OpenHarmony源码里/drivers/peripheral/display/hal/和/drivers/peripheral/audio/hal/下分别有对应接口定义厂商BSP包会在hdi_impl目录下提供具体实现。排查问题时第一件事就是确认厂商是否实现了与你所用SoC对应的HDMI HDI实现以及版本是否匹配系统框架。之前遇到过一件事系统框架升级后HDMI视频正常但HDMI音频设备从Audio框架的设备列表里消失了。后来定位到原因新版Audio HDI改了设备枚举参数厂商BSP还是按旧版结构体上报导致音频服务解析失败。这种问题纯靠应用程序层是解决不了的必须推动BSP同步更新。4.2 dmesg到hdi_client一条实用的排查路径有一次开发板出现“HDMI接上没反应但系统启动时插着能正常显示”的问题。我按以下步骤定位先看dmesg里有没有HDMI控制器相关的报错。果不其然看到一段“hdmi: failed to read EDID: -110”的日志。-110对应ETIMEDOUT说明DDC读取超时。再查EDID读取超时的具体原因。EDID读取走的是DDCI2C超时一般意味着I2C通信异常。检查DDC上拉电阻发现原理图上SCL的上拉电阻贴错成了1kΩ正常应该2.2kΩ到4.7kΩ。1kΩ上拉过强导致信号上升沿变缓在高速读取EDID时出现位错误。换掉电阻后重新测试EDID读取正常了但热插拔仍然时好时坏。继续看dmesg发现每次插入时HPD中断只上报一次第二次插入完全没有中断。再深入看SoC寄存器手册发现HPD中断在第一次触发后没有正确清除pending位导致后续中断被硬件屏蔽。解决方案是修改BSP内核驱动在中断处理函数里增加状态寄存器的读-清-写序列。这是个SoC级的老bug厂商在后续SDK版本里也修复了。整个过程下来最大的体会是OpenHarmony的HDMI问题排查很多时候不是看应用层代码而是要往底层挖。dmesg、/dev/下的节点、hdi_client这些工具比IDE调试器好用得多。4.3 常用调试命令与操作速查OpenHarmony系统下HDMI相关的调试命令和方法值得记录一下抓内核日志hdc shell dmesg | grep -i hdmi 或 hdc shell hilog | grep HDI_Display。区分清楚dmesg负责内核态、hilog负责用户态。查看显示设备列表hdc shell hidumper -s DisplayService 可以列出当前所有显示设备、分辨率模式、连接状态。这是查“HDMI是否被系统识别”的最直接方法。查看音频设备hdc shell hidumper -s AudioService 可以列出音频设备及其状态确认HDMI音频节点是否存在。查看EDID如果BSP在/sys/class/drm/card0-HDMI-A-1/edid下导出了EDID节点用 hdc shell cat /sys/class/drm/card0-HDMI-A-1/edid 然后hexdump解析。有些BSP路径不同可以在/sys下搜索。强制设置分辨率部分BSP支持通过sysfs节点写入mode来强制切换分辨率比如 echo 1920x1080p60 /sys/class/drm/card0-HDMI-A-1/mode。如果系统默认分辨率协商不对这个命令可以快速验证是协商问题还是输出链路问题。4.4 一次“开机黑屏但热插拔正常”的定位全过程这个案例特别有代表性。开发板开机后接HDMI电视黑屏无信号但开机状态下热插拔HDMI线电视却能正常显示。这个现象说明HDMI硬件链路和基本驱动是通的问题出在“开机阶段”和“热插拔阶段”的代码路径差异。我先在dmesg里对比两种场景的日志。热插拔时的日志显示完整的“HPD中断→EDID读取→Mode设置→TX使能”序列开机时的日志却只走到“HPD中断被注册”就停了后续流程没执行。继续追代码发现开机阶段HDMI控制器驱动先于Display HDI初始化而HPD中断注册依赖Display HDI准备好回调接口。时序上没有做同步导致开机时HPD中断提前到来丢失了。热插拔时系统已经完全启动所以一切正常。修法是在驱动初始化流程里增加状态检查如果HPD当前已经是高电平设备已连接初始化完成后主动触发一次热插拔事件而不是等待中断到来。这个补丁本身就是HDMI驱动开发里很常见的“初始化状态同步”处理很多参考设计里也写了但容易在赶进度时漏掉。5. HDMI RE测试整改和一个“看不见的敌人”搏斗5.1 为什么HDMI是RE测试的重灾区电子产品过EMC认证时RE辐射发射测试是最让人头疼的项目之一而HDMI接口几乎是RE测试的重灾区。原因有两方面。一方面HDMI的TMDS信号速率高1080P下时钟频率约148.5MHz4K30Hz时钟约297MHz这些频率恰好落在RE测试的敏感频段30MHz-1GHz甚至更高。更麻烦的是高速信号的谐波非常丰富经常在300MHz、450MHz、600MHz这些频点出现明显超标。另一方面HDMI线缆本身就是一个高效的辐射天线。线缆长度通常在1-3米在超高频段线缆上的共模电流很容易转换成辐射。如果源端的PCB设计和滤波措施不到位哪怕内部信号质量再好线缆也会把噪声“发射”出去。5.2 常见超标点时钟谐波、差分共模、电源噪声根据实际整改经验HDMI的RE超标问题通常集中在三类第一类是TMDS时钟谐波超标。时钟信号的基波和谐波是最主要的辐射源。频谱仪上会看到间隔等于像素时钟频率的尖峰如148.5MHz间隔分布。第二类是差分信号共模转换超标。差分信号如果设计理想两条线互为回流路径对外不产生共模电流。但如果PCB内层参考地不连续、连接器地弹片接地不良差模信号会部分转换成共模在频域上表现为宽带噪声基底抬升。第三类是电源耦合噪声超标。HDMI PHY的供电通常是1.8V或3.3V如果滤波不干净电源纹波会耦合到TMDS输出级产生边带噪声。出现在频谱上就是在时钟谐波两侧出现成对的小峰。5.3 一个实际整改案例从-6dB Margin到-12dB Margin有款产品RE测试时在297MHz附近超标Margin只有-6dB即超标6dB频率正好对应4K HDMI的TMDS时钟。整个整改过程值得复盘。第一步定位是HDMI线缆主导还是PCB主导。做法是分别测“插线”和“不插线”的频谱曲线。不插线时也存在297MHz的小峰但幅度低了10dB说明PCB和连接器本身也有辐射但主要辐射路径还是在线缆上。第二步针对线缆辐射做共模抑制。在HDMI座子附近增加共模电感Common Mode Choke串在TMDS差分对上。共模电感对差模信号阻抗很低对共模信号呈现高阻抗相当于把线缆上的共模电流“顶回去”。第三步检查HDMI PHY的驱动能力设置。很多SoC的HDMI TX驱动能力可以通过寄存器调节。把驱动电流从默认值降低一档之后高频分量明显减小。同时需要验证信号完整性眼图仍然满足要求没有出现误码或闪屏。第四步处理PCB本身的辐射。在HDMI座子下方增加地过孔阵把连接器外壳地和系统地在高频上充分连接同时检查TMDS走线两旁的GND过孔间距确保高频回流路径完整。第一步到第四步做完297MHz频点的Margin从-6dB变成-12dB整机顺利通过测试显示效果没有受到影响。5.4 整改的取舍平衡不到万不得已不要动结构整改经验里最想强调的一点是软件层能控制的其实很有限。展频Spread Spectrum和驱动能力调节是最常用的两个软件手段但都有代价。展频是把时钟频率在小范围内周期性扰动把集中在单一频点的辐射能量分散到整个频段从而降低峰值幅度。代价是展频可能影响HDMI的时序裕量某些对时钟抖动敏感的Sink设备会偶尔花屏且展频不能开太大通常控制在0.5%-1%以内。驱动能力调节是通过降低PHY输出电流来减少高频能量代价是信号幅度下降长线传输时可能触发接收端的均衡器重训练表现为画面偶发闪断。所以整改策略上我的建议是优先保证硬件设计正确阻抗连续、回流完整、滤波充分把软件层的展频和驱动调节当作“最后的筹码”不要开局就用手里的牌。硬件设计差的情况下软件调整最多救急无法根治。6. 从开发到量产HDMI输出的避坑清单6.1 硬件设计阶段的三个确认原理图阶段花十分钟确认下面三件事能省掉后面几周的debug时间第一件事量一下HPD上拉。HPD信号在源端通常需要上拉到5V或3.3V阻值10kΩ-100kΩ不等具体看SoC手册要求。上拉缺失会导致热插拔检测失效但系统启动时因为HPD被外部Sink拉高功能看起来又是正常的——这种“假正常”最坑人。第二件事确认DDC的上拉电阻和电平。DDC电平标准上是5V容忍但一些SoC的I2C控制器只能接受3.3V。如果原理图上DDC直接上拉到5V而SoC不允许5V输入长时间工作可能导致I/O损坏或EDID读取随机失败。建议仔细阅读SoC的HDMI模块电气参数表。第三件事检查TMDS差分对的AC耦合电容。HDMI规范允许源端在TX侧放置AC耦合电容常见值0.1uF。有些SoC内部已经集成了AC耦合电容原理图上再加一组0.1uF反而形成两级AC耦合会导致低频分量丢失画面出现色偏或亮度异常。这个错误很隐蔽因为不是所有产品都会立即表现出来。6.2 软件调试阶段的三个误区误区一只改Display层不改Audio层。HDMI是音视频一起走的改完分辨率后必须确认音频链路是否仍然正常尤其是采样率或通道数是否被重新协商。我的习惯是每次显示参数变更后都跑一次音频播放测试确认音画都在。误区二热插拔测试只在应用层做。很多应用开发者习惯用“监听回调→刷新UI”的方式验证热插拔但应用层回调正常只能说明HDI层已经把事件上报上来了并不能证明显示链路真的正确切换了。要验证驱动层正常需要看dmesg日志里的HPD中断记录和DRM状态切换记录。误区三忽略HDCP。商业视频内容一般要求HDCPHigh-bandwidth Digital Content Protection加密输出。如果板子没有正确的HDCP Key虽然普通桌面画面能正常显示但播放受保护内容时Sink端会拒绝显示表现为黑屏或“HDCP错误”提示。开发阶段就要把HDCP Key的烧录和校验流程纳入测试计划不要等量产时才发现烧录工具缺失或Key没预置。6.3 认证阶段容易被翻旧账的几个问题最后谈认证。EMC和HDMI compliance测试的许多问题追溯到源头都是开发阶段的“小忽略”。我建议在送测前的自测阶段就覆盖以下几个问题HDMI接口处的ESD防护器件对信号的影响。ESD保护管的寄生电容如果过大会严重劣化TMDS信号质量。选型时注意结电容最好控制在0.5pF以下否则高速信号的眼图会闭合。HDMI座子的结构接地处理。外壳弹片与主板地之间如果直接大面积连接RE测试容易出现共模辐射超标。建议用阻容并联网络如1MΩ电阻并联1nF电容连接外壳地到信号地隔离低频地环路同时为高频提供回流路径。HDMI PHY的电源去耦。PHY电源引脚旁至少要有0.1uF和1uF两个去耦电容且尽可能靠近引脚放置。如果PHY电源和SoC核心电源共用一路DC-DC而DC-DC的开关频率又落在HDMI频段的话还要考虑增加LC滤波器隔离噪声。这些细节如果不提前做送测后往往要反复整改既花钱又影响项目进度。认证阶段的每一分Margin都是开发阶段老老实实换来的。