1 前言
在向客户推 STM32F4 芯片的时候，客户反馈使用 CDC 类无法发送 64 个字节，于是通过深入研究问题，发现问题之所在，到解决问题。本文将基于 STM32F4DISCOVERY 板，一步步重现问题，一方面介绍如何使用 USB 的 CDC 类进行开发，另一
  z& E% ?9 X+ f1 x- P方面，对在开发过程中碰到发送 64 整数倍数据时会失败的问题分析及解决方案。
2 硬件介绍
3 P$ }8 k; Z# i2 \' y在创建工程之前，我们首先即将使用的硬件进行必要的介绍。
) k: I' Q. d1 {. p! m' m


/ a+ y; ^6 |" q( n. G% _5 a0 Q如上图所示，USB 电路使用 PA11，PA12，全速 USB OTG，当然，这里只做 device，英雌只需要看上图的下面部分。

$ `8 R. L' X$ K, x0 r

如上图，本例中将使用到 1 个用户按键，PA0，按下时为 1 电平。
9 k: P: c, h+ K- a另外，晶振使用的是外部 HSE 8M 晶振。
+ w5 l( o  s% D1 ?1 u4 L
3 创建 CubeMx 工程
8 `/ [$ \5 o9 E' m- y( V" l打开 CubeMX(V4.17.0)，创建一个以 STM32F407VGTx 的工程，使用 FS-USB，并使用 PA0 外部输入 EXIT，如下图所示：
" f5 m( _5 w6 E& D# d" e1 _; q& P
" z/ E3 C4 C4 m, E# @2 x
8 {# R3 c- U7 u
使能外部 HSE，使用外部 8M HSE,其时钟树如下设置：

- h/ N- I* T* d3 z

) I" W5 V1 m/ r# n  H( k接下来是配置参数，这里只修改 USB 中断优先级为 1，而 PA0 的外部中断优先级设置为 4，如下：

, _# t  g+ t& k1 k6 p( X

然后再中间件将 USB class 设置为 Communicaiton Device Class,如下：

1 J) v% z9 _8 `3 @4 R
# `8 s4 C  p5 [) o7 g  c
( T0 n. @& X) \最后将工程的堆设为 0.5K，栈设为 1.5K :


8 f2 x* F7 K0 U

最后生成一个 F407_CDC_Test 的工程。

3 o: n% r: l& E4 修改工程代码
我们对生成的工程不做任何修改，直接编译后烧进开发板后是可以被 PC 识别为虚拟串口的，如下图所示：

* r' V! a+ ~0 S
& h/ b# H1 X% N) b
8 v* J; M6 D9 D3 n& n) U7 P
. |# ~; o9 c" g) E; X(注意：这里所说的虚拟串口主要是指其可以被当做串口来用，但其速度跟串口所设置的波特率完全没有关系，用户不要被名字所迷惑，虽然使用起来跟串口没有区别，但其本质还是 USB，在初始化设置波特率不会对 USB 的通讯速率产生任何影响，本文档所描述的是全速 USB，因此，其最大速率就固定为 12M/S，这个是由全速 USB 外设标准 48M 输入时钟所决定的)此时是没有任何具体功能的，为了更好的看到通讯的数据，我们将使用串口通讯工具来进行测试，这里我们使用的串口工具是: sscom32.
( m! s& ?$ v' |3 `0 S: V+ r& X
1 s0 ^/ ?* u. H* \4.1 验证接收功能
我们将使用 PC 串口工具 SSCOM32 通过 USB 向 MCU 发送数据，为了能在 PC 端能看到 MCU 是否能接收到数据，我们在MCU 端修改代码，让 MCU 一旦接收到来自 PC 端的数据后，立马返回一模一样的数据，因此需要在生成的源码文件usbd_cdc_if.c 文件中找到到函数：CDC_Receive_FS()，添加处理函数，如下：

1. static int8_t CDC_Receive_FS (uint8_t* Buf, uint32_t *Len)
   
2. {
   
3. /* USER CODE BEGIN 6 */
   
4. HanldeReceiveData(Buf,*Len);
   
5. USBD_CDC_SetRxBuffer(&hUsbDeviceFS, &Buf[0]);
   
6. USBD_CDC_ReceivePacket(&hUsbDeviceFS);
   
7. return (USBD_OK);
   
8. /* USER CODE END 6 */
   5 f) J6 _  R- t+ v
9. }
   
10. /* USER CODE BEGIN PRIVATE_FUNCTIONS_IMPLEMENTATION */
    
11. static void HanldeReceiveData(uint8_t* Buf, uint32_t Len)
    
12. {
    
13. CDC_Transmit_FS(Buf,Len);
    " t3 z, E! `2 S  J$ C& A3 U7 p
14. }
    6 I; {9 p6 n8 U& R" t
15. /* USER CODE END PRIVATE_FUNCTIONS_IMPLEMENTATION */

复制代码

编译后烧进板子进行验证：
; H2 x4 C, b  w& Q! f6 q


: x5 v; d2 b/ n! b$ ~# K4 @1 C
* g" b% L3 e2 G: K如上如所示，串口工具能够收到来自 MCU 的返回数据，与发送数据完全一样，这说明，MCU 已经接收到了 PC 端发送的数据，另外，PC 端也能接收到 MCU 端发送的数据。

4.2 验证发送功能
接下来我们来通过按键响应来主动向 PC 端发送数据，我们在按键回调函数内添加代码如下：
2 v7 }* n3 G% @2 P7 T% j# d

1. /* USER CODE BEGIN 0 */
   
2. static uint8_t SendData[256] ={0};
   6 O' S7 q7 O: f/ `2 q# t
3. void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
   
4. {
   7 B# f% I! C2 N  m" V# N" T, e! a
5. uint16_t i;
   : A- Z! ^3 R" l4 \% p4 ?
6. for(i =0; i<sizeof(SendData); i++)
   
7. {
   
8. SendData[i] =i;
   % B5 D6 ^$ T% F" G% u
9. }
   
10. CDC_Transmit_FS(SendData,63);
    
11. }
    1 b6 v' L3 a$ I9 o; l4 W
12. /* USER CODE END 0 */

复制代码

8 @7 {+ ]! U7 y
) ]+ o* W( ^9 N( o即用户按下按键，MCU 则向 PC 端发送一次数据，这里发送的是 63 个字节，内容为 0~62，测试后 PC 端的串口工具完全能收到 MCU 端发送的 63 个字节，如下图所示：
/ m8 Z0 T# R& t
5 T# X. m( b; ~( f0 D' U+ p
5 C9 A( I5 b' I! Y
; P; t3 e& B) A$ k1 V# c  j( A/ V
但是当我们将代码修改为发送 64 个字节后 :
' b$ q* [! h6 k$ Z: x

1. /* USER CODE BEGIN 0 */
   
2. static uint8_t SendData[256] ={0};
   
3. void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
   ! K( c- p/ N" o8 q
4. {
   
5. uint16_t i;
   
6. for(i =0; i<sizeof(SendData); i++)
   
7. {
   
8. SendData[i] =i;
   3 u4 |7 z& O! Y1 D# I
9. }
   4 o# h+ V5 q+ I# L; g- b; ^( y% I
10. CDC_Transmit_FS(SendData,64);
    
11. }
    ! H$ m2 G- z/ e2 N' S
12. /* USER CODE END 0 */

复制代码

) r: Z. r1 Z% `0 p修改后进行验证，发现 PC 端串口工具不能接收到数据，，这里代码基本完全没有变化，只是发送长度之前为 63，这里为 64，结果却不相同，很明显，USB CDC 协议栈哪里出了问题。


我们先使用 USB 分析仪对发送 64 个字节时进行 USB 总线监控：

2 |9 l" v; g6 q& X6 @

如上图，我们发现，当发送 64 个字节时，由于正好是最大包长(64)，按 USB 标准来看，应该多发一次空的 transaction,但是这里，仅仅只发了一次 transaction，这也就是为什么串口没有接收到数据的原因(MCU 端的 USB 实际上是已经发送了 64 个字节，但由于缺少一个 transaction，因此 PC 端的驱动会认为数据格式不完整，而放弃所有已经接收到的数据，从而使上层看起来没有接收到任何内容)。
$ M# e2 y6 Y* Y
% Q; i" m6 o% q

$ e* n. G. k; [3 ~3 ^, W# \& Y因此，接下来的工作就是找到 USB 协议栈中的相应处理环节，然后将缺少的那个空的 transaction 补上即可。

2 b6 Y/ w& ~9 v2 ^- ?# Y2 A

4.3 USB CDC 协议栈修改
% U* |. _+ Y+ S8 n+ E3 G4.3.1 USB 数据发送流程分析
在对 USB CDC 协议栈进行修改之前，我们先来梳理下 USB 发送的流程。
. U5 ^4 k% L7 ?! ?1 M! z发送 USB 数据大概过程如下：
! G$ g! q' G, S2 C+ v' i1> 填写 DIEPTSIZ 寄存器的发送包数(pakage count)和传输大小(transfer size)。
2 I& e% C$ A  n1 t1 ]2> 使能发送断点的发送空中断(DIEPEMPMSK,利用发送空中断 TXFE 来将发送数据填充到 DFIFO)。
3> 使能断点。
4> 后续就是中断的事了。
. K5 L& r0 w2 |后续将会有 3 次中断：
1> USB_OTG_DIEPINT_TXFE 中断:在此中断处理中，程序将发送缓冲的数据分包填充到 DFIFO（不能超过最大包长，只
有最后一包数据才有可能小于最大包长）。
2> USB_OTG_DIEPINT_TXFE 中断: 还是 TXFE 中断，上次 TXFE 填充的发送数据全部发送完了后，最终还是会继续触发
TXFE 中断，也就是这次中断，在这次 FXFE 中断中禁止 FXFE。也就是说，后续不会再有 TXFE 中断，除非再次使能。
3> USB_OTG_DIEPINT_XFRC 中断：传输完成中断，表示到这次中断为止，传输完成。在这个中断中将回调HAL_PCD_DataInStageCallback()函数，就相当于发送中断一样。
这就是 USB 数据发送的流程，这里需要注意地是，对于端点 0 和非端点 0 来说，在具体流程实现上还是稍微有所差异的。究其原因，主要是端点 0 和非端点 0 的 DIEPTSIZ 寄存器的包大小和传输大小位宽是不一样的。如下图：

0 s' g# L2 \( r. O( x1 s% f
$ P  u  ^( P4 Z% a& ?' j, s

9 f! a+ a9 l: `* P) l8 W6 d' P

/ L3 [4 C/ N( c3 ~; Q0 j5 A对比上图，端点 0 的 DIEPTSIZ 寄存器的 XFRSIZ 位宽为 7，最大值为 127，也就是说最多一次只能传输 127 个字节，按最大包长 64 字节来算，就是是最多两包数据。如果需要发送超过 127 个字节时，又该如何做呢？查看 USB 协议栈内核代码，发现每次端点 0 发送数据时，在发送代码中固定每次最多可以传输 64 字节，然后在传输完成中断处理时，再将剩下的数据接着传输(usb core)，当然，每次传输最多也是 64 个字节，就这样，直到发送完所有数据为止。为什么每次传输最大设置为 64？
6 C# U" f+ s& H! M不是 XFRSIZ 位宽为 7,理论上可以为 127 吗？我的理解是，这样也是可以的，只要包长控制在 64 个字节内就可以了，至于每次传输多少字节，只要 XFRSIZ 位宽够用，你可以设置 127 个字节范围内任何数据均可。代码中设置为 64，主要为了图方便。
; S0 D* U) g6 \  x- A  x但是，对于非端点 0，XFRSIZ 位宽为 19 位，524288 个字节，足够传输所有实际数据了，因此，在发送代码中，并没有限定传输数据的长度，在 TXFE 中断中也能将所有待发送的字节填入 DFIFO。但是，当发送的数据刚好是 64 的整数倍时，按USB 标准，应该继续发送一次空字节，以表示数据全部发送完毕。如下：


4.3.2 代码修改
对比端点 0 的处理，发现端点 0 在传输完成中断(XFRC)中，有对这种情况的判断，一旦检测到这种情况，则会发送一次空传输。如下：
; F8 m7 f' j8 ?* c+ B% D4 A6 W+ ^* ]; }usb_core.c 文件中的 USBD_LL_DataInStage()函数 :

1. USBD_StatusTypeDef USBD_LL_DataInStage(USBD_HandleTypeDef *pdev ,uint8_t epnum, uint8_t
   
2. *pdata)
   
3. {
   " c5 k$ h) {/ ?& b
4. USBD_EndpointTypeDef *pep;
   3 _; H) U5 L+ d. \
5. 
   4 Y9 P  \& x+ g/ B: i. Q
6. if(epnum == 0)
   0 g3 S( ]( X4 U# F
7. {
   
8. pep = &pdev->ep_in[0];
   
9. 
   : ]8 G0 r9 G3 ?5 _8 j* J5 d
10. if ( pdev->ep0_state == USBD_EP0_DATA_IN)
    * l8 U1 Q6 H1 L2 _! {- @" z
11. {
    
12. if(pep->rem_length > pep->maxpacket)
    - J: B! v% x/ V  t
13. {
    : ^6 C7 z) m& `0 X$ P# L$ ]5 r
14. pep->rem_length -= pep->maxpacket;
    5 _( o- n; S1 @7 w
15. //继续发送剩余数据
    . O7 a6 ~& h6 a& \) q+ g
16. USBD_CtlContinueSendData (pdev,
    
17. pdata,
    
18. pep->rem_length);
    0 g& L& V4 C4 }; n+ y
19. 
    / C( I% O- U" x$ K8 x( m
20. /* Prepare endpoint for premature end of transfer */
    
21. USBD_LL_PrepareReceive (pdev,
    ! S- u* q0 ~. }* W7 \$ d% u) w
22. 0,
    . u; K& i2 J/ y. ?. d& W  ^- F) Q
23. NULL,
    3 d7 g' y+ p" d3 S# l! O* J
24. 0);
    + T) s% }8 x8 p  T0 o) S
25. }
    % w! J; D$ R5 U, |
26. else
    * [( V3 _! W/ B; ?3 A* L
27. { /* last packet is MPS multiple, so send ZLP packet */
    ' a. m0 _& o5 [' [2 Q2 A$ l- ?
28. if((pep->total_length % pep->maxpacket == 0) &&
    & ]7 |, v, A3 F$ S$ g( `
29. (pep->total_length >= pep->maxpacket) &&
    . Q0 P" w+ j3 N. O5 ?% |1 W  t
30. (pep->total_length ep0_data_len ))
    
31. {
    ) x; S4 [' L- t& y
32. //再多发送一次空数据
    
33. USBD_CtlContinueSendData(pdev , NULL, 0);
    
34. pdev->ep0_data_len = 0;
    
35. 
    " U/ i3 y2 M+ D- {
36. /* Prepare endpoint for premature end of transfer */
    1 k2 B7 o: c5 y) P9 Y
37. USBD_LL_PrepareReceive (pdev,
    1 ^8 R6 q2 Q( N2 A7 ?" `7 A
38. 0,
    
39. NULL,
    & O4 X7 [& Z- o% ?, X0 m% s
40. 0);
    
41. }
    ) L- K" C% E; ^. P2 \+ ~5 I1 Z, o
42. else
    & f; {" D7 {' b/ {) `5 Z
43. {
    " w2 _% t9 Q/ G2 ~' r
44. if((pdev->pClass->EP0_TxSent != NULL)&&
    ! J1 B6 L+ S1 v) j( [8 D
45. (pdev->dev_state == USBD_STATE_CONFIGURED))
    $ M! p* F7 W) M
46. {
    
47. pdev->pClass->EP0_TxSent(pdev);
    
48. }
    
49. USBD_CtlReceiveStatus(pdev);
    4 D9 F, V9 y0 b& z7 d% j: _$ _
50. }
    
51. }
    
52. }
    % m) }+ A. X: C0 l* u& O1 k  f/ L
53. if (pdev->dev_test_mode == 1)
    
54. {
    1 O% y* U& M* K
55. USBD_RunTestMode(pdev);
    
56. pdev->dev_test_mode = 0;
    
57. }
    
58. }
    % u. H$ [0 X1 T$ W1 w
59. else if((pdev->pClass->DataIn != NULL)&&
    
60. (pdev->dev_state == USBD_STATE_CONFIGURED))
    
61. {
    / o& U8 Q. e6 h
62. pdev->pClass->DataIn(pdev, epnum); //非 0 端点回调 CDC 类的 DataIn()函数处理
    ' }' I# N( s/ u3 C; t
63. }
    
64. return USBD_OK;
    . |- D) ~1 g) u% m8 u) A! x
65. }

复制代码

从上述代码，我们明显可以可以看出，USB 协议栈在对于端点 0 的数据明确做了一系列处理，以使其可以续发数据以及发送空数据传输，向主机端表示所有数据发送完毕。而对于非端点 0 的数据，则直接向上回调相应 USB 类的 DataIn 处理函数，
把责任完全撇给 USB 类去处理。
接下来查看 CDC 类的 DataIn()函数 :
; P+ a7 S  f- I4 d9 d! j5 d

1. static uint8_t USBD_CDC_DataIn (USBD_HandleTypeDef *pdev, uint8_t epnum)
   3 P/ ?6 P0 v3 j, t5 ?- O) ]- S$ e
2. {
   
3. USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*) pdev->pClassData;
   
4. 
   
5. if(pdev->pClassData != NULL)
   
6. {
   ' f6 y6 ]% r. w" H" k" t( P" R
7. 
   9 i1 i* P5 e# R5 o0 ^5 ]
8. hcdc->TxState = 0;
   9 ?% e5 q. B. e' Y# Y7 p; Y( V
9. return USBD_OK;
   * b5 r6 z8 b4 E8 Q" d  }( [
10. }
    2 v5 C4 y3 I% l5 r/ \
11. else
    
12. {
    
13. return USBD_FAIL;
    / k8 ?2 J( K! M7 S+ K
14. }
    
15. }

复制代码

' j. m8 w" L+ n. e% k& h虽然 USB 类的 DataIn()回调函数是不需要处理做续发数据处理（19 位的 XFRSIZ 位宽已足够表示数据长度），但是对于最大包长的整数倍长度数据的最后一个空包并没有做相应处理，因此，我们需要对其进行改造：

1. static uint8_t USBD_CDC_DataIn (USBD_HandleTypeDef *pdev, uint8_t epnum)
   
2. {
   
3. USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*) pdev->pClassData;
   
4. PCD_HandleTypeDef *hpcd =pdev->pData;
   & n$ n7 K: g1 T+ D1 [) T
5. USB_OTG_EPTypeDef *ep;
   * g) n! [, x  E& P
6. ep = &hpcd->IN_ep[epnum];
   
7. if(ep->xfer_len >0 &&ep->xfer_len%ep->maxpacket ==0)
   
8. {
   
9. USBD_LL_Transmit (pdev,epnum,NULL,0);
   # F# P5 _+ g% I3 Z8 L# `# J7 F  E- [, O
10. return USBD_OK;
    ' l; @; z2 Y3 H/ @# |
11. }
    2 U, @8 o5 H6 ?% f+ h) X  f- \5 j
12. else
    / d. e% X) y  w: E- D0 u* [9 G9 p
13. {
    6 K- T$ \/ ?3 H0 g! |
14. if(pdev->pClassData != NULL)
    3 _# u" P2 t- z
15. {
    
16. hcdc->TxState = 0;
    7 t: j0 @4 u9 F) `5 p
17. return USBD_OK;
    
18. }
    
19. else
    ! r9 {* X" q: K3 S0 ?' F
20. {
    
21. return USBD_FAIL;
    
22. }
    
23. }
    8 I. G+ f7 E) \' o* [
24. }

复制代码

将修改后的代码进行测试，测试发送 64,256 长度字节内容均可以成功发送 :


  i" N3 l0 s- |! @- {
9 v. n$ u0 ]& d% _+ A: D

+ L8 {, @# ^2 {6 r( U/ K& F* O从上图可以明显看到最后那次空事务(transaction),同时，使用串口工具也能正常接收到 64 个字节数据 :


, v1 P+ @9 n5 \( X( E
由此证明此修改是生效的。

; d, z( n5 e* q+ j
' T$ T! k3 C" F0 N5 结束语
% z" m2 ]# y1 E* l1 此问题是在使用 CubeMx V4.17.0 发现的问题，不排除后续 CubeMx 更新版本中会解决此问题。
8 P* G5 d1 R8 D) F0 ]; }2 此问题同样适用于其他 USB 类，本着不轻易修改 USB 协议栈原则，因此没有将修改转移到 USB 协议栈的内核中。因此，在其他 USB 类中的非 0 端点出现类似问题时，可以参考本文的 DataIn()函数修改。
; i4 Y& w$ T* R2 z: \. B

19 位的 XFRSIZ 位宽表示的长度只有0.5Mbyte，但是我需要一包发送1.5Mbyte大小的数据，该如何在USBD_CDC_DataIn（）续包发送数据。因为上位机没有源码，所以无法通过上位机修改包的大小。

报:当前使用MX6.12.0版本生成的USB代码已修复该问题

static uint8_t USBD_CDC_DataIn(USBD_HandleTypeDef pdev, uint8_t epnum) { USBD_CDC_HandleTypeDef hcdc = (USBD_CDC_HandleTypeDef )pdev->pClassData; PCD_HandleTypeDef hpcd = pdev->pData;

if (pdev->pClassData != NULL) { if ((pdev->ep_in[epnum].total_length > 0U) && ((pdev->ep_in[epnum].total_length % hpcd->IN_ep[epnum].maxpacket) == 0U)) { / Update the packet total length / pdev->ep_in[epnum].total_length = 0U;

/ Send ZLP / USBD_LL_Transmit(pdev, epnum, NULL, 0U); } else { hcdc->TxState = 0U; } return USBD_OK; } else { return USBD_FAIL; } }