【实战经验】USB传输数据时出现卡顿现象

[复制链接]

zero99 发布时间：2017-9-28 15:55

技术帖
文章封面:	-
文章简介:	-

USB传输数据时出现卡顿现象

1 前言
在进行USB开发的过程中，有多个客户反馈，USB传输数据时出现卡顿现象。本文将针对这一问题进行分析。

2 问题分析
这几个客户问题现象基本差不多，采用STM32作为Device设备，在与上位机或者PC端双向通讯一段时间后，从Device端到Host端的数据能够正常，而从Host端到Device端的数据异常，也就是说，STM32在一段时间后不再能正常接收数据，但是，如果只是单向通信，就一直都是正常的。
这几个客户，有用STM32F2的，也有用STM32F4的，有用CDC类的，也有用作HID设备的，但都使用了Cube库。
下面就具体问题以其中一个客户使用STM32F411的USB CDC类的案例来分析问题，现象如下USB通讯数据(CDC类)：

Figure 1 通信一段时间后Data Out数据异常

展开Data Out数据：

Figure 2 Data Out数据异常

分析上图发现，并不是Host端没有向Device端发送Data Out数据，而是确实发送了，但被Device端NAK了。那么为什么会被NAK呢？
通过在调试下查看寄存器，我们发现当出现问题时，Data OUT对应的端点1是处于关闭状态，那么为什么端点1会关闭？查看STM32端的接收代码：

usbd_cdc_if.c:

如上代码，在MCU端接收到赖在Host端的数据后不做任何处理就立即接收下一次数据传输，问题是，这里对接收到的数据啥也没有做，居然还会出现Data Out端点关闭的问题，那么OUT端点到底是怎么关闭的呢？我们接下来看子函数：
CDC_Receive_FS() ->USBD_CDC_ReceivePacket() ->USBD_LL_PrepareReceive() ->HAL_PCD_EP_Receive() ->USB_EPStartXfer()
最后在USB_EPStartXfer函数中有发现再次使能OUT端点的代码：

也就是说，在调用这个函数之前这个OUT端点原本就是关闭的？真的吗？这怎么跟我们理解的不一样？不应该是OUT端点一旦打开就一直开着的吗？带着这些疑问，我们查看STM32F411的参考手册，终于在22.17.6 Operational model一节中找到这么一幅图(由于CDC类数据传输采用的是BULK传输):

Figure 3 MCU对OUT数据传输的处理流程

如上图，MCU对BULK类型的OUT数据处理例程大体如下：
1> Host端试图向一个端点发送OUT token；
2> 当Device端的USB外设接收到这么一个OUT token后，如果RXFIFO空间足够，它将数据包存储到RXFIFO中；
3> 在将数据包内容存储到RXFIFO后，USB外设将产生一个RXFLVL中断(OTG_FS_GINTSTS)；
4> 在接收到USB数据包的个数后(PKTCNT),USB核将内部自动将这个OUT端点的NAK为置1，以阻止接收更多数据包；
5> 应用程序处理RXFLVL中断和从RXFIFO读取数据；
6> 当应用读取完所有数据(等于XFRSIZ)后，USB核将产生一个XFRC中断(OTG_FS_DOEPINTx);
7> 应用处理这个OTG_FS_DOEPINTx中断并通过OTG_FS_DOEPINTx 的中断为XFRC来判断传输完成；

从上面步骤中的第4步中可以看出，当USB核收到来自Host端的数据后会自动将OUT端点关闭，这也就是为什么在接收函数中在接收下一次数据时要再次使能这个OUT端点的原因。因此我们大体可以判断出在OUT数据传输的过程中，USB核会禁止端点->打开端点->禁止端点…如此不断循环中；那么问题到底出现在哪里呢？会不会在USB核自动关闭端点后就没有再次成功打开？带着这样的怀疑心态逐句查看代码，最终在接收函数的子函数中发现这么一段代码：

之所以会怀疑这里，这是客户提供了一个信息，单向通信的时候就不会有问题！这是因为在发送数据时，发送函数的底层函数内也使用到了这个互斥锁:

接收处理数据时，底层是通过接收中断回调上来的，但发送时，我们往往将发送放到main等用户函数中。这两个是不一样的，一个在中断内，一个在中断外，优先级别是不一样的，优先级不一样就有可能导致资源冲突；

我们进一步查看__HAL_LOCK()宏定义:

若__HAL_LOCK(hpcd);失败则直接返回return HAL_BUSY的。为了验证在接收过程中是否__HAL_LOCK失败，我们引进全局变量Lock_Flag,在发送函数中若成功LOCK则设置Lock_Flag=1,UNLOCK后则复位为0：

接下来在接收函数中对全局变量Lock_Flag值进行判断，若为1则锁死程序，因为在Lock_Flag=1时，则表示发送函数中已经获取了锁没有释放，此时若再去获取则会导致失败从而返回HAL_BUSY;这里通过锁死代码以便判断这种情况:

通过调试，当出现问题时，程序果然被锁死在这个while(1)了，这也证明了正是这个互斥锁所致。因此，我们大体可以判断出现问题时流程大致如下:
1> 在mian函数中发送数据CDC_Transmit_FS()
2> USBD_CDC_TransmitPacket()
3> USBD_LL_Transmit()
4> HAL_PCD_EP_Transmit()
5> __HAL_LOCK(hpcd); 此时成功获取互斥锁
6> 恰好此时有一个接收中断，由于USB中断具有优先级，跳转到接收中断内执行；同时，USB核会自动关闭OUT端点；
7> HAL_PCD_DataOutStageCallback()
8> USBD_CDC_DataOut()
9> CDC_Receive_FS()
10> USBD_CDC_ReceivePacket()
11> USBD_LL_PrepareReceive()
12> HAL_PCD_EP_Receive()
13> __HAL_LOCK(hpcd); 此时获取互斥锁失败导致返回，接收函数在OUT端点没有再次打开就已经提前结束，导致接收循环无以为继。

3 解决方案
知道了问题原因所在，接下来解决问题就相对来说比较容易的了。由于此问题是发送与接收处于不同优先等级导致资源冲突所致，那么我们可以将发送也放到与USB接收中断相同的中断等级中去，例如可以利用USB的EOPF中断，在开启EOPF中断后，在此中断内发送数据，这样发送与接收中断就处于相同等级了，EOPF每1ms触发一次，速度完全可以。当然开启一个相同优先级的定时器来做发送数据也是可以，只不过定时器间隔得控制好。

此外，其实此问题是出现在Cube库的低版本中，例如CubeF4 V1.5.0和CubeF2 V1.3.0中都存在，但是在最新本的CubeF4 V1.16.0,CubeF2 V1.6.0版本中此问题得到了解决；此问题虽然后来发现是版本太旧所致，但从多个客户反馈此问题来看，此问题依然不失为一个很好的参考和教训。

文档下载1>> 文档下载2>> 更多实战经验>>