HDMI 2.0黑屏排查：SCDC寄存器与TMDS配置全解析

做HDMI 2.0的工程师应该都有过这种经历眼图测试过了、PCB走线也按阻抗控制做了、FPGA/SoC的TMDS编码逻辑仿真时一切正常结果一接4K60显示器就是黑屏示波器探头搭上去又分明能看到像素时钟和串行数据在跳。这种问题往往和信号质量没有半点关系真正拦路的是HDMI 2.0协议里一个很容易被忽视的环节——SCDC状态与控制数据通道。它不是传视频数据的通路却直接决定了源端和显示端能不能协商出正确的TMDS时钟比率。很多方案做到最后卡住就是没有通过I2C对SCDC寄存器做正确的读写配置。这篇文章我想把SCDC这块从头到尾捋一遍。从寄存器地图、I2C地址规划到0x15这个核心TMDS配置寄存器的读写细节再到实际项目中踩过的TMDS配置坑一次性讲透。内容适合正在做HDMI 2.0源端或Sink端硬件/固件开发的同行也适合用FPGA做视频接口方案、被I2C时序折腾得睡不着的新手。看完之后至少能照着写一份能用的SCDC配置代码并且知道黑屏时该去哪里排查。1. SCDC这个“隐藏关卡”到底是什么1.1 为什么HDMI 2.0一定要多一个SCDCHDMI 1.4时代源端和Sink端之间通过DDC通道交换EDID就已经能满足绝大部分需求。EDID告诉源端显示器支持什么分辨率、什么色彩格式源端照着EDID里列的时序去输出就行。但到了HDMI 2.0TMDS链路速率被拉高到单通道5.94Gbps这时候出现了一个新问题同一台显示器可能既支持老一代的HDMI 1.4兼容模式也支持HDMI 2.0的10:1高速模式。EDID里只有静态能力描述没有办法在运行中动态协商“这一帧用哪种TMDS时钟比率”。SCDC就是为了解决这个动态协商问题而生的。HDMI 2.0规范在DDC通道里定义了一组新的I2C从设备寄存器放在7位地址0x54上。显示器端通过这组寄存器把自己的SCDC版本、能力、状态标志暴露给源端源端则通过写TMDS Configuration寄存器告诉显示器“我要用10:1模式跑4K60」还是“我只打算用4:1兼容模式”。如果源端不写、写错、或者写了但校验失败Sink端就不知道该怎么解串结果就是黑屏、闪屏、或者画面撕裂。SCDC里最出名也最关键的一个寄存器就是地址0x15的TMDS Configuration。它里面最低两个bit就是TMDS_Bit_Clock_Ratio字段。写00表示10:1这是HDMI 2.0高速模式TMDS比特率等于像素时钟的10倍跑4K60 RGB时像素时钟594MHz对应的串行比特率就是5.94Gbps写01表示4:1属于降速兼容模式用于带宽要求不高的时序。很多项目在黑屏排查时绞尽脑汁查TMDS输出信号结果最后发现是0x15寄存器的值压根没写对。1.2 SCDC在DDC总线上的位置与I2C地址规划HDMI的DDC通道本质上就是一条I2C总线上面按不同从地址挂了多类设备。第一个是EDID挂在8位地址0xA0/0xA1上第二个是HDCP的Sink设备挂在0x60/0x62这一带第三个就是SCDC挂在7位地址0x54上。换算成8位读写地址写地址是0xA8读地址是0xA9。这个地址区分是整个SCDC配置里最容易出错的地方因为0xA8离EDID的0xA0实在太近肉眼扫过去很容易看错有时候代码里从別处抄了EDID读函数只改了个寄存器偏移量没改从地址结果所有SCDC操作全部落在了EDID的I2C地址上读回来的数据当然全是错的。还要注意一点SCDC寄存器不是所有显示器都支持。HDMI 1.4的显示器没有SCDC设备源端去读0x54时I2C会NACK。因此在正式流程里源端读SCDC之前要判断显示器是否支持HDMI 2.0判断依据可以从EDID的HF-VSDB块里找也可以直接尝试读SCDC的版本寄存器读NACK就直接降级走HDMI 1.4模式。稳健的驱动都会把这一步做成动态探测而不是硬编码。2. 动手前先搞懂SCDC寄存器地图2.1 核心寄存器0x15 TMDS Configuration0x15这个寄存器是源端写给Sink端的主要作用就是声明TMDS时钟比率。它的位定义大致是这样的Bit位字段名值说明7:2Reserved000000保留位写01:0TMDS_Bit_Clock_Ratio0010:1模式HDMI 2.0高速模式1:0TMDS_Bit_Clock_Ratio014:1模式HDMI 1.4兼容降速模式1:0TMDS_Bit_Clock_Ratio10 / 11保留值不应写入这里的10:1和4:1别理解成“显示器的缩放比例”它描述的是串行比特率与像素时钟之间的关系。以4K60 RGB 8bit为例像素时钟是594MHz10:1模式下每条TMDS通道的串行比特率就是5.94Gbps而如果源端只写014:1串行速率只有2.376Gbps数据显示带宽完全不够Sink端解出来的画面必然是花的或者直接黑屏。反过来如果跑1080p这种低带宽时序某些Sink会建议源端使用4:1降速降低信号的EMI辐射这时候源端也要按Sink的update flag把0x15改成01。2.2 能力寄存器与更新标志怎么配合SCDC不只是0x15一个寄存器。在0x00这个地址上Sink端会报告自己的SCDC版本HDMI 2.0的Sink通常回0x10这个值表示它支持SCDC的1.0版本。0x00到0x0F这一段是Sink端的能力区源端上电后应该读一遍确认Sink支持哪些功能。0x10到0x17这一段是状态与控制区0x15就在这里面。0x11是SCDC Update Flags寄存器它的bit0是SCDC_Update_Flag由Sink置位。整个协商流程是这样的Sink端在需要源端重新配置TMDS模式时先把0x11的bit0置1再通过HPD脉冲之类的机制提醒源端重新读SCDC。源端检测到后读0x11发现update flag为1就会去读0x15按自己的输出模式把TMDS_Bit_Clock_Ratio字段写进去。写完源端要回读0x15做校验确认写入成功后再把0x11写0清除标志位。这有点像一个带“更新请求”的双向握手协议Sink提出需求源端响应并执行最后确认完成。2.3 7位地址还是8位地址别再搞混了I2C从设备地址这个东西不同MCU适配库的表示方法能把人绕晕。规则是这样的7位地址0x54左移一位变成8位最低bit是读写方向。所以8位写地址是0xA88位读地址是0xA9。大部分Linux I2C用户空间的写法直接填7位地址0x54就行内核会自己拼读写位但STM32的HAL库、某些FPGA的I2C IP和单片机控制器的API往往需要你手动填8位地址。我之前就见过一个项目固件代码里用了0xA8作为I2C地址传给一个自动补读写位的函数结果总线上的地址变成了0x5010xA0的偏移直接和EDID冲突调试了很久才反应过来。建议做法是无论什么平台都在代码里写清楚“SCDC_7BIT_ADDR 0x54”然后统一管理读写方向的转换不要到处硬编码0xA8这种魔数这样才能减少低级错误。3. 手把手I2C读写SCDC寄存器3.1 I2C基础时序回顾以及为什么开漏加上拉是必要的SCDC的物理层就是标准I2C速率协议上允许到400kHz但实测下来100kHz最稳妥。为什么I2C要开漏输出外加外部上拉电阻因为I2C总线是多主多从共享机制如果每个设备都用推挽输出两个设备同时一个拉高一个拉低直接就把管子烧了。开漏输出意味着每个设备只能主动把总线拉低释放时靠外部上拉电阻把电平带回高。这个机制决定了上拉电阻的取值很关键电阻太大上升沿太慢高速传输时电平建立不起来电阻太小低电平驱动电流过大从设备可能拉不下去。HDMI DDC通道上一般挂多个设备上拉电阻的并联效应也要算进去常见取值是1.5k到4.7k之间具体要看总线上挂了多少个从设备。如果你发现逻辑分析仪上SDA释放后的上升沿明显变化很慢或者时序波形圆头圆脑的那就是上拉电阻大了降阻值试试。完整的一次I2C写事务流程是主机先发Start信号SCL高电平时SDA从高拉低然后发从设备写地址0xA8等从设备ACK接着发寄存器偏移地址0x15等ACK再发要写入的配置数据等ACK最后发Stop信号SCL高电平时SDA从低拉高。读事务稍微复杂一点需要先做一次“伪写”发Start、0xA8、寄存器地址0x15然后重新发Start、0xA9从设备会从当前寄存器地址开始回数据。不支持重复Start的老设备也可以用StopStart替代但效率低一些。3.2 读SCDC能力区和状态区的完整过程在实际驱动里读SCDC能力区通常在HPD上升沿之后做。HPD从低变高说明显示器已经准备好源端要等一小段时间让显示器内部的I2C控制器稳定下来一般等20到50ms。稳定后源端发一次I2C读从寄存器0x00开始连续读16字节把能力区和状态区一次拿回来。这里有个技巧读回来的数据不要只盯着0x15先看0x00版本号再看0x11的update flag最后才判断0x15当前值这样能更准确判断当前链路协商到哪一步。用逻辑分析仪抓这个流程时你会看到一串读事务开始是0xA8伪写0x00然后重复Start发0xA9接着从设备每ACK一个字节就吐一个数据共16个字节最后主机NACK第17个时钟并发送Stop。NACK的目的就是告诉从设备“我要结束了不需要再往下读了”。很多新手看到这里以为I2C出错了其实这是标准的“主收尾”动作。3.3 写TMDS配置寄存器并回读校验的代码示范下面这段代码是一个通用MCU平台上的参考实现用寄存器操作而不是HAL库方便移植到任意平台#define SCDC_7BIT_ADDR 0x54 #define SCDC_WRITE_ADDR ((SCDC_7BIT_ADDR 1) | 0) // 0xA8 #define SCDC_READ_ADDR ((SCDC_7BIT_ADDR 1) | 1) // 0xA9 #define SCDC_TMDS_CFG 0x15 #define TMDS_RATIO_10_1 0x00 #define TMDS_RATIO_4_1 0x01 int i2c_write_byte(uint8_t addr, uint8_t reg, uint8_t data); int i2c_read_byte(uint8_t addr, uint8_t reg, uint8_t *data); int scdc_set_tmds_ratio(uint8_t ratio) { uint8_t val; int retry; for (retry 0; retry 5; retry) { // 写 TMDS Configuration 寄存器 if (i2c_write_byte(SCDC_WRITE_ADDR, SCDC_TMDS_CFG, ratio) ! 0) continue; // 回读校验确认写入生效 if (i2c_read_byte(SCDC_READ_ADDR, SCDC_TMDS_CFG, val) ! 0) continue; // 只比较低两位保留位不参与判断 if ((val 0x03) ratio) return 0; } return -1; }上面这个函数看起来简单但实际项目里要注意几点一是写入后必须回读校验有些I2C主控制器写操作返回成功但Sink端因为内部总线忙没有真正更新寄存器二是重试机制必须有HDMI链路协商过程中Sink端可能处于忙状态第一次写NACK不代表设备坏了多试几次就成功了。我自己一般在重试之间加一个1ms到5ms的延时避免总线风暴。3.4 完整配置流程源端视角接下来把源端初始化SCDC的完整流程串一遍检测HPD上升沿驱动延时20到50ms等待DDC通道稳定。读EDID确认显示器支持HDMI 2.0和期望分辨率。尝试读SCDC从地址0x54。如果NACK判断为HDMI 1.4设备走旧流程。读0x00版本号确认SCDC版本读0x11 update flag记录当前状态。判断目标输出模式需要的TMDS时钟比率。4K60 RGB 8bit这类高带宽模式写0x150x0010:1低带宽时序且希望兼容HDMI 1.4链路时写0x150x01。回读0x15校验低两位。写0x110x00清除update flag。开始输出TMDS数据。如果源端能力不足比如芯片只支持HDMI 1.4的TMDS速率而Sink端在EDID里声明必须10:1模式那么源端应当在EDID分析阶段就降级到低分辨率而不是硬上4K60然后黑屏。这个降级策略属于系统设计层面但和SCDC的写值强相关建议在驱动里做成一个联动逻辑分辨率、像素时钟、SCDC配置值三者在同一个决策函数里一起算出来不要散落在不同模块。4. TMDS配置避坑指南重点4.1 坑1只写不读寄存器没写进去这是我见过最多的问题。固件代码里确实调用了i2c_write驱动也返回了成功但Sink端实际收到的还是默认值。为什么一种可能是I2C主控制器的写事务少了Stop信号事务没真正提交另一种可能是Sink端内部MCU在上电后还没有完成SCDC寄存器区域的初始化早于20ms的写操作被丢弃了。解决方式就是严格执行回读校验回读结果和预期不一致就视为失败并重试。你可以把回读失败次数打印出来调试阶段能省很多无谓的排查。4.2 坑2地址写错成0xA0数据发到了EDIDSCDC的8位写地址0xA8和EDID的0xA0太像了代码里一旦用了0xA0或者0xA8但被某个适配层错误地左移/右移了一次事务就会发到EDID的地址上。EDID从设备对“往不存在的寄存器写数据”这件事通常不响应I2C会出现NACK但有的MCU驱动会把NACK当成功处理导致问题闷在下面。排查手段很简单抓DDC总线的波形确认第一帧的从地址到底是0xA8还是0xA0。4.3 坑3上拉电阻和I2C速率不匹配HDMI的DDC总线上同时挂着EDID、HDCP、SCDC电容负载本身就不小。如果你把上拉电阻从4.7k换成10kI2C上升沿可能从几百纳秒涨到几微秒在400kHz速率下直接违反建立时间。反过来上拉电阻太小比如小于1k总线低电平可能被抬高到超过VIL阈值设备根本拉不低。做量产设计的时候不要只按理论值选电阻要在真实显示器上扫一遍100kHz和400kHz两种速率用逻辑分析仪看时序余量。4.4 坑4忽略更新标志和HPD时序SCDC协商不是一次性的显示器端在热插拔、HDCP重握手、EDID变化时都可能重新置位update flag。如果源端驱动只在开机时处理一次SCDC后续就再也没有读0x11那么当显示器要求切换TMDS模式时源端不会响应自然就会黑屏。处理HPD中断时要小心别和I2C事务打架不要在HPD电平抖动还没稳定的时候就去读SCDC先做软件延时去抖再触发一次完整的SCDC能力区读取。4.5 坑5只配SCDC忽略了HDCP的联动4K60内容通常要求HDCP 2.2HDCP 2.2的握手发生在TMDS链路建立之后。如果你的SCDC写值已经对了但HDCP因为密钥交换失败或者认证状态机卡住同样会黑屏。更隐蔽的是某些Sink在HDCP认证完成后还会再次刷新SCDC的update flag要求源端重新确认TMDS配置。所以产品化代码里SCDC状态管理和HDCP状态机要有统一的调度不能是两条互相不通讯的独立代码路径。稍微不严谨一点就会在兼容性测试时翻车。5. 实测问题排查实录与速查表5.1 我用逻辑分析仪抓到的三类异常波形第一类是SDA一直低电平这通常是某个设备拉死了总线常见原因是I2C从设备地址配置错误导致不该响应的设备参与了事务或者时序复位异常。第二类是SCL有连续脉冲但SDA完全没有数据变化这种多半是主机在等待从设备ACK但从设备一直没起来主机卡在某个循环里反复发Start。第三类是最难发现的总线看着一切正常地址0xA8也能收到ACK但写0x15以后回读的值恒为0x00怎么都写不进去。这类问题就要回过去看Sink端的固件是不是SCDC的寄存器写保护位被置了或者0x15被Sink端定期刷新覆盖。排查I2C问题有个很实用的顺序先看波形、再看数据内容、最后查代码逻辑。波形能确认物理层和时序数据内容能确认地址与帧格式代码逻辑能确认是不是策略层面的问题。跳步排查是大忌很多工程师一上来就改代码结果发现是逻辑分析仪的采样率不够导致波形根本没抓全。5.2 常见问题排查速查表现象可能原因处理方式4K60黑屏TMDS信号正常0x15寄存器未写入10:1模式写0x150x00并回读校验SCDCBus上读地址NACKSink不支持SCDC或地址错误确认EDID是否声明HDMI 2.0检查7位/8位地址转换写0x15后回读恒为0写保护、更新标志竞争、写事务未提交清0x11后再写加入重试机制I2C波形上升沿过缓上拉电阻太大或总线电容过重上拉电阻改为2.2k或1.5k速率降到100kHzHPD中断后黑屏update flag处理不完整HPD去抖后完整读SCDC能力区再走配置流程花屏且有规律性条纹4:1与10:1速率不匹配确认分辨率和TMDS比率联动逻辑5.3 一个4K60黑屏的完整排查过程复盘去年有个项目FPGA做HDMI 2.0源端外接三台不同品牌的4K显示器其中两台正常一台始终黑屏。拿到样机后我先用逻辑分析仪挂在DDC上发现黑屏这台显示器在HPD上升沿后SCDC读流程完全正常0x15也能读到默认值但源端写0x150x00之后回读的值却变成了0x03。0x03是保留值正常情况不可能出现。仔细查下去才发现这台显示器的Sink固件会在SCDC写事务完成后的一小段窗口内自己刷新0x15寄存器把保留位也一并覆盖了我们的回读代码比较了整个字节等于老是在和Sink端“抢写”。最后改成只比较低两位并且把回读时机放在Sink刷新完成之后问题就解决了。这也是为什么我强烈建议回读校验只对0x03这个掩码做比较而不是全字节相等判断。这个案例里值得记住的一点是HDMI链路上每个设备的固件实现都不完全一样协议规范只是底线实际的寄存器行为可能各有各的脾气。调试的时候不要假设“我写对了设备就应该回什么”一切以逻辑分析仪实测数据和回读状态为准。6. 写在最后的一点体会SCDC这套机制说到底是HDMI 2.0在物理层之上加了一层“链路状态协商”的保险。它不传输视频流却决定了视频流能不能以正确的速率跑起来。这几年做HDMI相关的项目我越来越觉得协议里这些不起眼的小角落才是真正的分水岭把TMDS信号调得很漂亮的人很多能在一堆寄存器标志位之间把链路协商理顺的才算是真的把HDMI 2.0吃透了。如果你正在做HDMI源端或者Sink端我建议把SCDC的读写封装成独立模块配上完整的回读校验和重试机制然后把逻辑分析仪的I2CDecoder直接用起来。真到了兼容性测试那一步你会发现这两件事帮你省下的时间足够把整个项目的心跳调试再打磨一遍。