基于DWC2的USB驱动开发-USB复位详解 (qq.com)
上一篇我们详细介绍了USB枚举的第一步,连接检测。那么第二步是干什么呢? 相信做过嵌入式开发尤其做过驱动开发的都会想到-复位,基本上所有的外设模块在开始都需要进行复位操作,以达到一个默认的状态,USB也不例外。一方面初始化时复位以达到默认状态,一方面在异常时复位以恢复。话说复位可以解决99%的问题就是这么来的,如果还不能解决那就断电复位,相信这是很多人解决问题的第一板斧,且不说是不是最优选择,至少这样一般都有效,当然可靠性考虑是否能直接复位一般都需要评估不能这么直接简单粗暴。
这一篇我们就来详细讲讲USB的复位,老规矩理论结合实践,先看规格书的说明再写驱动实测。
首先,复位信号到底是什么样的呢?调试外设时序的时候一般都会关注,复位一般用一组特殊的状态时序来表示,USB也一样。
我们看到USB2.0规格书中对复位信号的描述如下
对于发送端要求D+和D-小于VOL(max)持续10mS以上,VOL(max)的值为0.3V,如下
而对于接收端要求D+和D-小于VIL(max)持续10mS以上,VIL(max)值为0.8V
可以看到VIL(max)比VOL(max)是要大的,这是对发送要求严格一些,因为要考虑信号传输的噪声干扰等因素,预留一些裕度。
上述10ms的参数实际有个名字叫 (TDRST),规格书中要求如下
而一般要求接收端在D+和D-小于VIL(max)持续2.5uS以上就应该检测到复位,这个时间记住,我们可能会遇到临界情况在这个值附近可能出现不稳定的情况,调试时留个心眼,一旦出现这种很可能就是疑难杂症,但是现在留个心眼以后就可能想起来确认这里。
对于根集线器这里还有个要求就是非连续的复位要有3mS以上的间隔(TRHRSI) ,复位持续周期50mS(TDRSTR)以上(因为USB拓扑最大有5个集线器)
参考USB2.0的规格书《7.1.7.5 Reset Signaling》
在低速/全速模式下运行的设备,如果其面向上游的端口上出现SE0超过2.5µs(TDETRST),则可以将该信号视为复位信号。复位须在复位信号结束之前生效。注意这里是复位信号结束之前就生效。(实际这里还可能导致隐蔽的BUG,我这里有一个精彩的案例分析,高速设备总是枚举为全速设备的问题,神奇的是在复位中段服务函数中加个打印就好了,后面会分享)
1.主机(HUB)检测到设备连接,通过DP还是DM拉高区分是低速还是全速/高速。
2.主机(HUB驱动信号SE0以产生复位信号。
3.设备检测到SE0持续2.5uS(TFILTSE0) 以上检测到复位,产生复位中断。
对于低速设备完成复位,对于全速和高速设备后面继续进行高速设备的检测。
速度的检测后面会单独再讲。
如果是从non-suspended 全速状态复位则必须在SE0
开始后的2.5uS(TFILTSE0)~3.0 ms(TWTRSTFS)时间内进行后续的高速速度检测握手。
如果是从suspend 状态复位,则必须在SE0开始后的2.5uS(TFILTSE0)以上时间后进行高速速度检测握手,为什么这里没有最长时间3.0 ms(TWTRSTFS)的限制了呢,因为挂起时时钟是停止的重启时钟需要时间,所以这里不限制上限时间。
如果是从non-suspended 高速状态复位,则设备在恢复到全速之前必须等待不少于3.0ms且不多于3.125ms(TWTREV)。通过移除高速端接电阻并重新连接D+上拉电阻器,可实现全速恢复。该设备对总线状态进行采样,并在开始恢复至全速后检查SE0(复位而非挂起)、不小于100µs且不大于875µs(TWTRSTHS)。如果检测到SE0(复位),则设备开始高速检测握手。
注意
设备必须能够在复位恢复时间10 ms(TRSTRCY)后接受SetAddress()请求,这个时间也是一个调试经验,如果不能枚举可以检查设备的响应时间是否过长。
由于面向下游的端口在复位期间不会处于传输状态,因此高速Chirp信号不会引发断开连接检测。
如下图是DWC2驱动的复位波形,黄色为DP,高速模式。
通过仿真器GDB load程序重新运行,而不是直接上电运行,如果是后者则没有(1)这个状态此时默认是没有拉高的。
DWC2控制器的软件复位不会影响SftDiscon位的状态,所以load程序后SftDiscon保持之前的拉高状态,DWC2控制器复位也不会影响
直到相关UTMI时钟复位,如下代码执行对应到(2)前面的DP拉低,此时UTMI等复位应该是导致了PHY的相关状态复位。
然后是软件设置SftDiscon位为0,拉高DP,如下代码处,对应(2)处的拉高
然后DP拉高100mS之后(3),主机发送复位(4),这里看到复位时间非常短,这是因为设备2.5uS以上,实际是8uS就检测到了复位(如下图所示,图中标尺部分,后面的蓝色的高DM的高是设备发出的Chirp K高速握手信号),进行了后续的高速握手,所以覆盖了主机发送的复位信号,所以看不到复位10mS的持续时间。
复位的信号很简单,但是承接的是连接检测到后续的高速速度握手,时序非常重要,尤其是有个参数2.5uS,检测到复位信号持续2.5uS即检测到复位,而不需要等复位信号移除即不需要等10mS,所以会出现主机在驱动复位,设备已经检测到复位开始后续的高速握手,从波形上看就看不到复位信号持续10mS了,而这也可能导致一些性能不达标的主机,高速握手失败,这个后面单独讲案例分析。
全部0条评论
快来发表一下你的评论吧 !