基于DWC2的USB驱动开发-高速设备枚举为全速设备问题案例分析

本文转自公众号，欢迎关注

基于DWC2的USB驱动开发-高速设备枚举为全速设备问题案例分析 (qq.com)

一.前言

 

本文分享一个高速设备被枚举为全速的问题。

 

 

高速设备速度握手参见本系列的文章。

二.问题

 

我们设计的UVC摄像头工作在高速模式，接一个第三方的主机用于显示和无线上传，主机也支持高速模式。

 

 

我们的UVC摄像头接PC测试都能正常枚举为高速，从来没有失败过。接第三方的主机时总是被枚举为全速，偶尔能成功一两次枚举为高速，几乎都是枚举为全速。

 

 

三.分析过程

 

既然接电脑没问题，接第三方主机有问题，那么就怀疑第三方主机的兼容性问题。先前软件做了一些分析，调试没法确认问题，进行了一些打印信息的调试，在中断中关键事件进行打印，发现接入第三方设备时进行了两次复位和速度握手。这是一个异常信号，正常一次复位和速度握手就能完成。于是使用示波器监控，对比接PC正常的和接第三方设备不正常的复位，速度握手过程。

 

 

接PC正常的波形，由于要抓长时间所以图中高速握手的细节显示不了了，但是整体依旧可以知道各个阶段

 

 

 

接第三方主机不正常的

 

 

 

对比可以看到接PC一次完成高速握手

 

 

 

而接第三方复位了两次第一次尝试高速握手主机无响应，第二次没有尝试高速握手了，注意这里没有抓前面初始化过程了。

 

 

 

这里主机第一次没有响应设备的Chirp K是不对的，这里因为主机是按键唤醒的，怀疑是刚上电未就绪，但是主机为什么未就绪就要发送复位呢，应该是USB初始化完后就绪才发复位的，所以这里主机肯定是不对的，而且为什么主机要发两次复位也不得而知，但是肯定是不正常的，有些第三方的东西做的不健壮也没办法，我们现在也没办法知道主机的处理逻辑。

 

 

既然主机不对，这个先不管，但是为什么设备在第2次复位时没有发Chirp K进行高速握手了呢。

 

 

这要从上一篇说的设备驱动说起。

 

 

设备驱动的流程如下

 

 

1.初始化配置DevSpd设置期望的工作速度，按照该速度去握手

 

 

2.配置EnumDoneMsk使能中断，清除中断标志EnumDone

 

 

3.等待中断，中断中查询实际握手的速度EnumSpd，根据该速度再次重新配置DevSpd设置实际工作速度。并清除中断标志EnumDone。

 

 

上述的逻辑是用户可以设置最高期望的工作速度，但是实际主机支持多少就工作在多少，这样不管主机是什么速度，代码都不需要修改，初始化指定为高速即可，最终按照实际握手结果而定。

 

 

原因就在于上述红色字体部分，第一次由于主机没有响应Chirp K所以设备握手结果是全速，所以中断服务函数中设置为了工作模式为全速，下一次复位时依然会按照全速握手此时就不会发Chirp K了。

 

 

即如图所示

 

 

 

那么是不是可以在复位中断中重新再配置为高速来达到下一次复位进行高速握手呢，因为复位中断是在握手完成中断之前的，这样是不行的，因为设备检测到复位进入复位中断时硬件已经开始进行后续的握手处理了，软件的修改已经来不及了。此时设备已经是正常的全速工作了，并不知道在何时需要重新设置为高速以等待下一次的复位握手，毕竟这个两次复位握手不是标准流程，是主机的异常导致的。以上导致了第一次握手为全速之后后面就只能是全速了。

 

 

既然如此我们还可以修改中断服务函数中的处理，不在中断服务函数中根据前一次握手速度设置实际工作速度，这样第二次就可以握手为高速了，如下所示

 

 

这样看似解决了问题，但是实际导致了用户API逻辑问题，原来用户API初始化设置期望的速度为高速，如果主机不支持高速则握手为全速工作，没有问题，

 

 

现在这种情况如果主机不支持高速，则设备一直工作在高速将没办法工作，所以这个修改会导致和其他主机通讯异常，不可取。即改变了原来API的逻辑。

 

 

 

四.解决方法

 

虽然问题在于主机，但是出于兼容性考虑还是要想解决办法的，毕竟第三方设备健壮性没法保证，写驱动考虑兼容性，甚至兼容非标，非健壮设备也是要考虑的。

 

所以这里对API接口再增加参数区分，原来的参数还是表示期望速度，但是实际工作速度按照握手结果决定，原来的逻辑不变。再增加一个参数即强制固定速度，也就是如果设置为固定速度则握手完成中断中不根据握手结果更新速度，设置多少就多少不再改。这样通过参数来应对原来的用户逻辑和兼容这个有问题的主机。需要修改的地方是API增加一组强制固定速度和原来的期望速度对应，中断服务函数中根据是强制速度还是期望速度处理，期望速度就根据握手值更新速度，固定值则不更改。

 

五.总结

 

本篇以一个实际的案例进行分析，体现了对USB高速握手过程理解的重要性，所以前一篇高速握手详解的文章非常重要，在此基础上才能很快的定位问题。之前一直强调知其然知其所以然很重要，只有深入理解才能快速解决问题。同时也体现了驱动开发比一般嵌入式开发更深入的要求，不仅要考虑正常设备能工作，还要兼容不正常的，不标准的，不健壮的设备，这也需要更深的理解和功力。