手头正好在调一块全志H618的板子DDR和HDMI的问题来回折腾了快两周很多朋友问我这芯片的硬件测试到底怎么下手。这块芯片现在大量用在电视盒子、开源开发板和一些低成本Linux平板方案里四核A53加内置DDR控制器和HDMI 2.0的集成度做消费类硬件确实很省事但也意味着硬件测试的重点非常集中DDR能不能稳HDMI能不能出画面基本决定了这块板子能不能量产。这篇文章就把我实际踩过的坑、用过的仪器、测过的波形和排查思路完整记录下来给正在做H618方案或者类似ARM平台硬件的朋友一个可以直接抄的测试路径。先说清楚这篇文章适合谁看如果你是要做H618核心板、整机主板硬件工程师或者是搞嵌入式Linux但需要配合硬件验证的软件工程师再或者是刚入行想搞清楚DDR和HDMI到底怎么测的测试工程师都可以往下读。内容会从测试环境的搭建讲到DDR训练日志的解读再讲到HDMI信号完整性的抓取方法最后整理一份我遇到过的故障速查表全程用我自己的实操案例说话不写教科书废话。1. 测试开始前先把平台和工具备齐1.1 硬件平台的选择是买核心板还是自己画测试板H618的封装是BGA个人或者小团队想直接在主板上飞线测DDR基本不现实所以我会先把CPU做在一块小的核心板上再通过板对板连接器引出DDR之外的所有信号。市面上现成的H618开发板比如香橙派的Zero2W、Zero3这些其实也是不错的测试载体因为它们自带DDR只要厂家没有把DDR的测试点完全阉割掉你就能透过串口日志和压力工具验证DDR稳定性。不过我个人的建议是如果预算和时间允许最好还是自己画一块只针对DDR和HDMI的测试小卡原因有三个。第一开发板的PCB走线是厂家调好的你测出来的DDR各个参数都正常不代表你自己画的板子也能正常第二开发板通常不会引出DDR数据线或地址线的测试点你没法用示波器真正看到DQS和CLK的相对相位第三H618集成度高很多电源域开发板已经做完了你没法单独测试某个电源域对DDR训练的影响。我自己实测用的是两层方案先拿一块香橙派Zero3做软件调通和基本信号验证确认系统能跑起来以后再画自己的四层测试板把HDMI座、DDR颗粒、电源、串口全部按量产布局走一遍。这样即使后来自研板子出问题也能对比开发板的行为来定位是自己的布线问题还是芯片设置问题。1.2 软件环境串口日志是DDR测试的第一双眼睛硬件测试往往要配合软件才能把问题暴露出来。H618启动时芯片内置的Boot ROM会初始化DDR然后从SD卡、eMMC或者SPI Flash加载引导程序。只要DDR训练失败或者不稳定系统会直接卡死或者反复重启所以串口日志就是你判断DDR是否正常的最直接依据。我的标准做法是这个先用软件工具把Armbian或官方Linux固件写入TF卡TF卡作为一个独立于DDR的启动介质让系统先把DDR调起来再跑到内核里看信息。这里需要注意一个细节TF卡本身是通过SDIO接口访问的和DDR完全独立所以只要TF卡能启动并打印日志基本说明CPU核心和PMU供电没问题如果日志在DDR初始化阶段就断了那问题多半出在DDR颗粒、DDR供电或者PCB走线上了。H618串口默认的波特率很多固件是115200调试串口引脚通常复用在某个UART上具体看原理图。我习惯在固件里打开内核的早期打印这样从Boot ROM到U-Boot再到Linux内核的所有输出都能抓到方便定位是哪个阶段挂掉的。提一句如果TF卡系统制作工具像Rufus或者balenaEtcher在Windows下写卡都比较省心镜像写进去之后直接上电就能看到启动日志。1.3 仪器准备按照测试深度决定要花多少钱硬件测试离不开仪器但不是说每个人都要立刻配一堆高端设备。我给你按测试深度列一个参考表测试深度建议仪器大概能做什么基础功能测试USB转串口模块、万用表、稳压电源看启动日志、量电压、确认通断成本非常低DDR稳定性测试上述加上Memtester/压力软件跑内存压力测试能发现大部分虚焊和供电问题DDR时序测试1GHz以上带宽示波器最好带逻辑分析仪量DQS/DQ的建立保持时间、CLK和DQS相位关系、眼图HDMI信号测试1GHz以上示波器加差分探头看TMDS眼图、差分摆幅、上升沿、时钟抖动HDMI协议测试HDMI协议分析仪或者用逻辑分析仪抓DDC/I2C验证EDID读取、HPD热插拔事件、CEC指令、HDCP握手如果做我自己实际配置是一台500MHz带宽、4GS/s采样率的示波器加一个1.5GHz的有源差分探头。坦白讲500MHz带宽测HDMI 2.0的4K60是有点不够的因为TMDS时钟最高到600MHz测眼图时高频分量会被示波器滤掉一些但用来测1080P、判断信号有没有通、有没有明显反射已经足够量级。真要验证4K60的眼图还是得找实验室或者借一台2GHz以上的示波器这个后面会再展开说。2. DDR部分从原理到一次真实的排查过程2.1 先明白H618内部怎么管理DDRH618的DDR控制器集成在SoC内部对外连接DDR3/DDR3L/DDR4/LPDDR4颗粒具体支持哪几种以官方手册为准。控制器内部有一个PHY模块PHY负责把控制器的逻辑信号转换成符合JEDEC规范的电气信号同时做阻抗校准、ODT片上端接配置、读写训练等一堆事情。DDR的工作频率高信号在PCB上传输时会有延迟和反射H618在启动时会对DDR PHY做“训练”也就是不断调整读写数据的采样延迟、片内端接阻值、驱动强度等参数去找一组让数据读写都稳定的配置。这个训练过程有的厂家叫“DRAM calibration”或“PHY training”H618的日志里通常会有类似“DRAM PHY training”或者初始化DRAM控制器的打印。如果颗粒、走线或者电源有问题训练就可能失败或者得到的参数裕量很小之后系统跑起来就会随机死机、报错。这个训练有点像两个人隔着一条走廊喊话先试几次找到对方能听清你的音量大小和应答延迟。如果你站的位置不对信号反射、走廊里很吵电源噪声、或者对方耳朵不好颗粒质量问题这个调参过程就失败或者每一轮都得试很多次才成功这种“勉强成功”其实是最危险的因为上高低温之后必然翻车。2.2 布线检查等长规则和分组原则在做任何电气测试之前我会先用CAD工具比如AD18很多硬件发烧友都在用把DDR相关走线过一遍对照原理图和PCB报告严格检查。DDR布线有几个硬规则第一个是数据线分区等长。DDR的DQ、DQS、DM信号属于数据组每组内部的走线长度差要尽量小通常控制在几十mil以内具体值取决于DDR频率。第二个是地址线、控制线、时钟线单独一个组它们相对DQS/DQ有固定的等长关系。第三DQS和CLK的差分对内等长要很小因为DQS是数据采样的参考时钟CLK是命令地址的参考时钟两者偏差过大训练时怎么调都找不准。这里有个很常见的误区就是只等长数据线而忽略了DQS到CLK的相位关系。我遇到过一块板子DQ组内的走线长度很齐但DQS整体比其他DQ短了快200mil结果是DDR初始化偶尔能过跑Memtester大概十分钟左右报一次错。后来我把DQS走线加了蛇形绕线调整到与DQ中值长度一致问题才消失。说句实话很多入门开发者不知道DDR走线等长不是“越短越好”而是“相对关系要稳定”这个认知差异在调试时带来的痛苦是巨大的。2.3 用Memtester和日志做第一轮稳定性验证我每次拿到新的H618板子上电后第一件事不是用示波器去抓波形而是先确认系统能稳定启动并能跑内存压力测试。原因很简单示波器只能看到某一个瞬间的信号跑压力工具可能是更宏观的验证方式能把DDR的“长期稳定性”这个指标暴露出来。Memtester是Linux下的一个内存压力工具使用很简单sudo memtester 512M 10第一个参数是要测试的内存大小第二个参数是循环次数。如果DDR初始化有隐患Memtester通常会报出类似“FAILURE: 0xXXXXXXXX”的错误告诉你具体的地址和数据。有时候系统直接死机或者重启连错误都不打印这时候就要靠看门狗和串口日志判断是不是DDR访问冲突导致的内核崩溃。除了Memtester我还会在内核启动后查看dmesg里关于DDR的信息例如dmesg | grep -i dram日志里能看到DDR频率、容量、数据位宽、颗粒类型这些关键信息我见过不少板子因为固件里DDR类型选错导致系统不稳定。比如本来是DDR4颗粒固件却按DDR3的参数去初始化多半会在启动早期就卡死。压力测试的时长怎么定我通常先跑5轮快速验证没问题以后挂机过夜跑至少8小时。如果是为了高低温测试则要在高低温箱里让温度稳定后跑2小时以上因为DDR在临界温度下最容易暴露访问时序问题。2.4 示波器抓DDR信号怎么看核心波形当软件压力测试出现不稳定且能排除颗粒本身的问题后就该请出示波器了。DDR的信号不是像I2C那样一个个孤立的波形而是持续高速切换的总线直接用普通探头去扎数据线的通断意义不大你需要关注几个关键点。首先是DQS和CLK的时序关系。H618的DDR控制器在读操作时DQS是颗粒端输出的数据选通信号处理器要依靠DQS边沿来采样DQ数据所以DQS与DQ之间的时序必须满足建立保持时间。用示波器可以捕捉任意一条DQ和对应DQS的波形观察DQ跳变沿距离DQS边沿的距离是否满足颗粒规格。在低速模式下你甚至可以清楚看到眼图开口比较大如果开口小、边沿抖动大那说明走线等长没控好或者串扰严重。其次是电压和纹波。DDR的VDDQ电压通常由PMU提供若纹波过大会让颗粒内部的比较器误判电平。我用示波器探棒配合弹簧地针测量VDDQ时发现纹波超过50mV后续在DDR供电端并了几个去耦电容并把电源走线加宽后才压下去。这个细节很多人不在意可我测过的DDR不稳定案例里大概有三成是电源纹波惹的祸。看DDR波形时还要注意一点示波器探头必须是短地线最好用探头自带的短弹簧针因为你如果直接用长地线鳄鱼夹接地回路电感会很大测出来的波形抖动会骗你做出错误判断。这个坑我踩得最狠的一次是测出DQS抖动高达300ps后来换短地线再测不到80ps原来那300ps全是测量系统引入的。DDR部分我再分享一个排查案例非常典型。有一块板子在高温老化时频繁重启拆开看日志停在PHY训练失败上常温却一切正常。我先怀疑是DDR颗粒虚焊用X-Ray检查没发现问题然后用热风枪给颗粒局部加热大概到90度左右就复现问题了说明问题在温度相关参数上。再看PMU的DDR供电电压常温26mV纹波高温箱里纹波上升到80mV原来是电源模块的补偿环路在高温下不稳定了加了对地电容后高温下纹波压到45mV老化测试顺利通过。所以遇到DDR和温度有关的问题别急着怀疑CPU或颗粒先去抓住电源纹波。3. HDMI部分接口定义、电路检查和信号抓取3.1 H618的HDMI接口到底有哪些信号HDMI接口看起来是一个扁平的19针座子信号种类其实不少但对于硬件测试来说我们只关心直接影响出图、识别和稳定性的几条通路。项目热词里有人搜“HDMI接口信号定义”这里我就把H618上常见的HDMI相关信号好好拆一下。第一是TMDS数据通道HDMI有3对数据差分线和1对时钟差分线分别叫Data0/-、Data1/-、Data2/-、Clock/-这是高清信号的主干道。H618内置HDMI TX直接输出TMDS差分信号连接到HDMI座子时要求差分阻抗100Ω。第二是DDC通道即I2C总线SCL、SDA用来读取显示器或电视的EDID信息。没有EDID发送端就不会知道对面支持什么分辨率所以DDC不通画面大概率不会正常输出。第三是HPDHot Plug Detect热插拔检测线电视机通过拉高HPD告诉发送端“我准备好了”发送端检测到这个上升沿后会重新读EDID并执行HDMI握手。第四是5V电源线HDMI座子的19脚会输出5V给下游设备供电虽然电流不大但短路风险很高。还有一个经常被忽略的CEC用来消费电子控制比如用一个电视遥控器控制盒子。H618一般有CEC引脚实现的话要串到座子的13脚。CEC不是出图必须的但做量产整机时经常被要求验证。3.2 静态电路检查用万用表先摸一遍上电之前我会习惯性先用万用表测一遍HDMI相关线路的对地阻抗防止焊接短路或者空焊。重点测这几个点5V电源脚对地不能短路TMDS差分对的每一端对地电阻应该一致因为内部有端接阻抗HPD脚对地看有没有上拉电阻。HDMI座子内部有外壳地引脚这些要确保和主板地可靠连接否则ESD防护和电磁兼容都会出问题。很多人做HDMI接口电路设计时只在数据线上放ESD保护阵列却忘了HPD和DDC信号也要做相应的保护。HDMI座子拔插频繁静电打进来的概率很高我见过不止一次因为HPD线上没有保护导致芯片内部被静电打坏的情况。常见做法是用一颗带ESD防护的HDMI保芯片比如TI的TPD12S015这类集成DDC电平转换、HPD缓冲和ESD防护一体对H618这种集成方案来说外围电路能省不少事可靠性也更好。3.3 上电联调从HPD和EDID说起很多HDMI无输出的问题根源不在高速信号上而是在低速的“握手”环节。如果你发现接上电视后H618没有任何显示输出先别急着抓眼图先用示波器探针测量HDMI座子19脚的5V是否正常再测HPD脚有没有从低变高的跳变。这里有一个很关键的顺序HPD的上升沿是在5V电源稳定之后由电视侧拉高的。如果你测到HPD一直是低那可能是电视不识别、HDMI线有问题也可能是你的HPD被下拉电阻拉死了。我测过一块板子HPD设计时漏了串联电阻芯片内部下拉和电视上拉分压之后电视拉高到不了逻辑高电平芯片一直认为没接显示器自然没有输出。加上一颗上拉电阻之后问题马上解决。EDID的验证也很容易操作。如果系统能开机在Linux下用i2c-tools就能读i2cdetect -l i2cdetect -y -r 0x50 i2cdump -y 0x50HDMI的EDID挂在DDC总线上地址一般是0x50如果i2cdetect能扫到0x50地址说明DDC通再用i2cdump把EDID内容dump出来能看清厂商、分辨率支持列表、色彩空间这些关键信息。我之前有一块板子在电视上能正常显示但在某款显示器上只能到1080P一开4K就黑屏最后dum出EDID发现显示器的EDID里面写的最大TMDS时钟被识别有误其实是DDC总线上的上拉电阻阻值太大导致时序畸变把EDID数据读错了。换掉电阻后问题消失。HPD和EDID都正常内核日志里一般会打印类似“hdmi: detected monitor”或者DRM相关的连接状态变化。H618的Linux内核通过DRM/KMS框架管理HDMI输出查看cat /sys/class/drm/card0-HDMI-A-1/status如果返回“connected”说明热插拔检测成功了再强制指定分辨率测试输出xrandr --output HDMI-1 --mode 1920x1080这种方式可以快速判断是握手问题还是信号质量问题。3.4 用示波器抓TMDS眼图和摆幅的判断HDMI的TMDS信号是电流驱动型差分信号规范里单端摆幅一般在400mV到600mV左右差分摆幅在800mV到1200mV左右实际数值会因为驱动设置和线缆损耗有所不同。测TMDS眼图时我会把示波器设成差分模式用差分探头去夹HDMI座子附近的测试点观察信号的眼图是否张开、上升沿是否单调、有没有因为插座或ESD器件引起的严重反射。这里要说一句测眼图要区分测试点位置。如果你在HDMI座子引脚上测看到的是信号经过PCB走线后的波形如果在同一根线接近SoC引脚的位置测波形会更“干净”一些。我们做硬件测试通常以座子附近为准因为这才是下游线材真正会收到的信号质量。示波器带宽至少是信号最高频率的3到5倍测4K60的TMDS信号600MHz的基频意味着你至少需要1.5GHz到3GHz带宽的示波器否则测出来眼图会“假闭眼”看起来信号很差其实是示波器带宽不够。实际情况下如果测1080P信号500MHz示波器配合高带宽差分探头完全够用眼图打开得很明显。如果是4K60我通常退一步测它的时钟通道以及数据通道的抖动再用软件压力测试和实际显示器来验证毕竟消费级实验室里能有2GHz示波器的地方还是少数。CEC验证的话用逻辑分析仪抓CEC引脚上的电平变化确认遥控器按键事件能转换成CEC帧这个相对独立原理像UART单总线波特率约3600bps。如果H618固件把这部分功能屏蔽了你测CEC引脚可能是空的这要根据项目需求决定要不要深挖。4. 整机可靠性测试与常见故障速查4.1 高低温、老化、ESD硬件测试的最后一道关DDR和HDMI单独测完只能说明设计原理上没问题真正决定能否量产的是整机可靠性测试。我的习惯是把DDR压力测试和HDMI视频输出同时放在高低温箱里跑因为H618芯片本身发热量大整机在高温环境里如果散热不够DDR颗粒贴着CPU温度会更高内存稳定性会更严峻。低温则容易暴露晶振起振和电源启动的问题。具体做法是这样的高温60度、低温-20度各跑至少4小时高温阶段跑Memtester加循环播放4K视频低温阶段重点观察冷启动时DDR初始化是否成功、HDMI的HPD检测是否正常。温度循环不要直接满载到关机H618这种BGA封装芯片温度剧变容易造成焊点应力损伤测试完还要重新跑一遍常温全套功能确保没有因为温度变化产生新的不良。ESD测试是HDMI接口的常客因为HDMI座子裸露在机身上。按照消费类电子的普遍测试要求接触放电至少正负8kV空气放电15kV实验过程中不允许出现死机或者HDMI功能永久损坏。我见过一款产品HDMI插座没有做外壳接地隔离打空气放电时静电直接耦合到TMDS线上把SoC的HDMI TX烧了。后来在HDMI座子外壳和主地之间加了一颗高压电容同时增加ESD保护器件才顺利通过测试。这个细节在电路设计阶段就要规划好测试阶段再补救非常痛苦。4.2 常见故障速查表我在H618项目里把遇到过的DDR和HDMI问题整理成了一个速查表直接照着排查可以省很多时间现象可能原因排查步骤上电后串口无任何输出电源/晶振/启动介质先量各路电源电压再看12M晶振是否起振TF卡是否插好串口打印停在DRAM初始化DDR颗粒焊接/供电/参数重新焊接或更换颗粒量DDR电压纹波检查固件DDR配置系统能启动但Memtester随机报错DQS/DQ时序裕量不足示波器抓DQS和DQ相位关系调整走线等长换颗粒批次温度升高后DDR重启DDR电源纹波变大/散热不良高温下量纹波优化电源去耦加强散热接电视无画面且HPD不拉高HDMI线/电视端/HPD电路换线换电视量HPD脚电压检查上拉电阻HPD拉高但读不到EDIDDDC总线连通性/上拉电阻i2cdetect扫0x50量SCL/SDA波形检查焊接能读到EDID但输出花屏TMDS信号完整性示波器看眼图检查差分走线阻抗和ESD器件寄生电容1080P正常但4K60黑屏HDMI2.0握手失败/带宽不足查看内核日志确认显示设备支持测量TMDS时钟频率热插拔偶尔失灵HPD上拉不稳/接触不良多测几次热插拔检查HPD信号质量看是否缺去耦电容播放视频时偶发黑屏信号间歇性劣化/电源瞬态测量播放时TMDS眼图同时抓电源纹波是否有跌落这个表不是万能的但覆盖了我在H618上遇到的大部分问题。硬件测试就是这样现象往往很简单背后的原因却是多层的稳扎稳打一层层排除比瞎猜要高效得多。4.3 延伸一点DDR和HDMI测试思路在其他平台同样通用有人可能觉得H618太小众这门手艺换一颗芯片就没用了。其实不是。DDR的PHY训练、等长布线、压力测试这套方法论放在Zynq这类FPGA平台上一样适用只不过FPGA上你可以用IP自带仿真工具先验证实际硬件测试还是要回到信号和时序的测量上来。HDMI的HPD、DDC、EDID、TMDS这套流程在RK3568、RK3576这些国产SoC上也完全一致我见过很多RK平台HDMI适配问题最后查出来都是硬件信号层面的HPD或者EDID不稳定而不是驱动配置问题。说句大实话很多搞Linux驱动的人觉得HDMI“适配”是软件问题但其实我在调RK3576 Android 14遇到插上HDMI线就没媒体声音的问题时最后定位到是硬件音频路由和HDMI音频数据包的默认设置冲突这种问题如果不回过去验证硬件信号光在软件里调来调去会浪费大量时间。所以在嵌入式硬件这个行当懂一点测试能抓一下信号很多时候比看十篇驱动移植教程更能解决问题。另外像笔记本HDMI无输出这种常见的用户侧故障原理上也逃不开HPD、DDC、电源这几条线排查思路和测H618完全一样掌握了本文这套方法你甚至可以帮朋友修电脑时多一个思路。最后说一点个人体会。硬件测试做久了你会发现真正难的不是会用示波器而是知道该测哪里、测什么参数、什么时候该相信测量结果。H618的DDR和HDMI测试表面上是两条独立的技术线实际都指向同一个核心理解信号在PCB上的传输过程理解芯片内部的握手逻辑然后用尽可能简单的方式验证它们的边际条件。我的经验是测试用例要在设计图阶段就开始规划比如预留DDR的等长测试点把HDMI差分信号在座子附近预留可以下探针的焊盘这些小事能让后面调试省一半力气。还有一个习惯就是每次测试都把示波器截图、串口日志、环境温度和当时的测试固件版本一起存档因为自己调过的板子过几个月再回头看你会发现这些记录比记忆可靠得多。