一 前言

　　在高速串行技术如此广泛应用的今天，简单易用的 USB 堪称是PC平台上最成功的I/O技术，普及率几乎100％。而且随着终端用户对于高速USB设备应用需求的不断增加，越来越多的 嵌入式 通信类终端产品开始增加了USB2.0主机接口的设计以满足客户的应用需求。成熟的应用技术由PC平台转向嵌入式平台的已经成为一种趋势。为了满足USB2.0一致性应用的需求，所有的USB2.0设计都必须满足USB IF发布的USB2.0物理层一致性测试要求。相对于比较成熟的PC平台USB2.0 主机测试技术而言，基于通信类终端的嵌入式USB2.0 主机的测试面临更多的挑战。特别是进行二次开发的应用厂商而言，如何满足USB2.0物理层一致性测试要求很大程度上需要原厂在测试模式以及测试封包方面提供更多的支持。但应用需求的多样化导致了许多设计架构脱离了原厂的测试状态机控制范畴，问题接踵而来。

　　二 嵌入式USB2.0主机测试

　　1 产品USB部分原理及测试环境

　　产品USB控制原理

　　USB控制主机采用某大型通讯类方案提供商的IAD解决方案，片内集成一个USB2.0控制器，然后通过一个USB HUB中继对外提供２个高速主机接口。

　　测试设备：

DUT_USB2.0功能框图

　　2 测试中出现的问题

　　本次测试将主要验证产品上两个USB高速主机接口的眼图。对于USB2.0物理层的 眼图测试 ，USB IF在USB2.0 SPEC中有着明确的眼图模板定义如下：

Transmit Waveform. Template

　　关于USB高速主机眼图测试的测试方法，USB IF在USB2.0 SPEC中也有清晰的定义，USB2.0主机控制器必须支持规定的测试模式。对于眼图的测试则必须支持TEST PACket测试模式，连续发送规范的测试码流以测定眼图模板，上升下降时间，传输抖动以及其他的一些AC指标。也就是说测试是基于原厂对于测试模式的支持并提供相应的Firmware。准备测试前工程师和原厂沟通后顺利拿到了测试Firmware和测试命令。原厂提供的测试方法是在上电启动之后进入 CFE模式然后下载和运行测试专用Image,这样就可以使用TEST_Packet命令进行眼图的测试了。测试连接图示如下：

测试连接图

　　一切看起来都是那么的顺利，但是当我们通过串口进行TEST Packet命令下发之后在两个主机接口却看不到信号波形出现。因为是第一次进行嵌入式USB的测试，所以对于出现的问题是没有任何经验可以参考和借鉴的。从串口信息来看是显示命令下发成功的，那问题到底出在哪里呢？只有从信号流向一步一步地查找了。工程师首先测试了USB HUB与CPU之间的UpSTream接口，发现有相应的信号波形出现。也就是说USB主机控制器已经执行了TEST Packet命令并发送了测试码流,问题出现在了USB Hub这里，它并没有向两个Down Stream Facing Port转发码流。而且原厂提供的命令也很奇怪，根据有PC主板测试经验的工程师的意见，对于HUB的测试应该需要指定测试端口才对。而在测试命令中我们并没有看到相应的指令而只有简单的TEST Packet命令。在询问了原厂技术人员后问题有了答案：

　　（1）原来我们采用的方案只支持一个USB 主机接口，所以在片上只集成一个USB 主机 CONtroller，测试命令也是基于主机控制器类型的。而我们的板级应用是采用了一个USB Hub与主机 Controller中继来实现多端口应用的扩展，根本无法进行Hub Down Stream Facing Port的测试。

　　（2）并且原厂的测试是在CFE模式下通过下载运行特定的测试程式来进行测试，在这个阶段，并没有实现USB Hub的初始化以及配置字的操作，也就是说USB Hub是不可控的无法进入测试模式的设定。我们的多USB主机端口的应用设计使得系统架构中加入了USB Hub进行中继，已经超出了原厂设计的USB测试状态机控制范畴，导致了无法通过原厂提供的测试命令进行测试。再次和原厂技术支持讨论新的测试程式的开发从时间说来看已经不实际了，客户非常关注并要求我们必须尽快给到USB 主机的测试报告。第一次进行嵌入式USB 主机测试就遇到如此棘手的问题，工程师们一时间束手无策。有没有另外的方法呢？