工程师笔记 |USB发送数据时出现迟滞现象

[复制链接]

STMCU-管管发布时间：2021-11-9 10:16

文章
文章封面:
文章简介:	客户反馈，使用STM32F446的高速USB外设，即USB_OTG_HS外设，且使用内置全速PHY。客户的产品USB用做device，自定义HID类

问题描述

客户反馈，使用STM32F446的高速USB外设，即USB_OTG_HS外设，且使用内置全速PHY。客户的产品USB用做device，自定义HID类，当连接带UOS操作系统的HOST时，会发现当前数据并没有成功发送，但是会发送上一次的数据，即发送数据出现”迟滞”现象。但在Windows下却没有出现此类问题。另外，客户同时还使用了STM32F446上的USB_OTG_FS外设，且此外设做同样的事一切正常，目前此问题只出现在USB_OTG_HS外设上。

问题查找

刚开始猜测是长度问题，即发送最大包长需要再发送一次空包。但客户反馈他们的发送长度为62个字节。于是去客户现场使用USB协议分析仪采数分析，发现一切通信正常。

通过查看客户演示重现问题的过程，发现在正常时是一切OK的，只在进行USB拔插时才发送问题。应用程序不断发送数据的过程中拔掉USB线，然后再次插上，在此过程中应用程序一直尝试发送数据。当USB线重新连接上且重新枚举成功后，“迟滞”现象则重现了，即每次应用程序调用发送接口实现发送的是上一次尝试发送的内容。

调试客户的程序，发现当USB线拔掉后，应用程序还会往USB IP对应的发送FIFO内写入数据，这其实是不对的。按理USB线拔掉后USB的状态应该恢复到默认状态，

即pdev->dev_state=USBD_STATE_DEFAULT. 但实际上，通过调试发现此状态在USB线拔掉后是suspend状态。

那么为什么会是这样的呢？

于是立即想到Vbus sensing功能。马上与客户硬件工程师核对，原来客户产品的USB_OTG_HS的Vbus_sensing脚是悬空的，并没有连接Vbus，但是客户的USB_OTG_FS外设却又是连接了。于是客户的产品两个USB口，同样的工作，一个USB口正常，另一个USB口却会出现问题。

问题分析

差异找到了，接下来就是分析由此如何造成问题的。

由于USB_OTG_HS并没有真正实现Vbus sensing功能（因为没有硬件连接），于是当USB线断开时，应用程序并不能准确地检测到断开事件（Disconnected），只会出现suspend，应用程序是无法直接的区分真正的suspend和USB线断开连接的。当应用程序有数据需要通过USB口发送时，如果当前是suspend状态，那么它会首先唤醒USB总线然后再发送数据：

Figure1

而这样发送远程唤醒信号时，device本身会产生一个resume中断，于是在resume中断回调函数内:

Figure 2

如上所示，程序会将dev_state错误地恢复到上一次状态，即正常状态USBD_STATE_CONFIGURED, 如此一来，程序就错误地往USB IP的内的发送FIFO写入数据了，即使此时由于USB线已经断开而导致无法真正发送成功，但USB IP的内置发送FIFO此时是有了数据的。

通过调试，查看OTG_DTXFSTS1寄存器相应端点1对应的发送FIFO的剩余空间可知，这个时候的发送FIFO的确实有数据的。接下来是USB线插上重新枚举，那么为什么USB重新枚举后还会再现问题呢？通过设置断点发现，在USB成功重新枚举过后，通过OTG_DTXFSTS1寄存器指示，发送FIFO内容并没有清空，于是在接下来发送数据时，永远都是实际上发送的是上一次写入到FIFO中的数据。

问题已经找到

问题解决

▼于是解决方法就很容易找到了▼

在USB重新枚举过后在合适的地方将端点1对应的发送FIFO清空一下即可。

Figure 3

问题总结

在客户的这个案子中，由于USB_OTG_FS连接了VBUS SENSING脚，当USB线拔掉后，会产生正确的disconnect中断，USB device的状态也会正确地切换到default状态，从而过滤掉应用程序想要发送的数据，因此并不会出现类似问题，因此，在客户的产品设计中，建议硬件千万不要忘了连接vbus引脚，即使在想省IO引脚的情况下，这样容易造成对软件的开发诸多不便.

在USB的状态处于非configured状态时，最好不要往发送FIFO写入数据，应用程序应该想办法将这些数据过滤掉。