1 問題現(xiàn)象

有客戶使用STM32F405并參照ST官方USB標準庫下的HID+CDC的示例代碼做產品，發(fā)現(xiàn)在WIN7上使用得好好的，可放到WIN10上，CDC第一次能夠識別，再次拔插后就不能再識別，且此后無論插拔多少次都無法再識別，除非再次上電，又會重復上述現(xiàn)象，只有板子上電后第一次才能正確被識別，后續(xù)均不行。

2 問題分析

客戶使用 ST官方示例代碼STM32_USB-Host-Device_Lib_V2.2.0\Project\USB_Device_Examples\Composite_Examples\CDC_HID_Composite當我嘗試使用此示例代碼重現(xiàn)客戶所遇到的問題時，發(fā)現(xiàn)此代碼在WIN7運行OK，但與客戶不同的是，我測試到的情況是在WIN10下CDC一次都無法識別，HID卻一直可以識別。

下面來分析下問題，既然WIN7下HID和CDC都能正常識別，放在WIN10上才不正常，那么初步可以判斷，此問題可能與WIN10操作系統(tǒng)的USB主機驅動實現(xiàn)有關。

通過USB分析儀分析客戶代碼在WIN10下USB枚舉異常的數(shù)據(jù)通訊：

Figure 1 第一次USB枚舉過程

上圖是客戶代碼第一次正常枚舉的通訊數(shù)據(jù)，從圖中可以看出，WIN10 USB主機在正常獲取HID報告描述符后，緊接著會獲取虛擬串口狀態(tài)和設置波特率，這樣就正常枚舉結束了。我們再來看看采集到的異常USB枚舉過程：

Figure 2 異常枚舉過程

上圖是WIN10下異常枚舉過程。從圖中可以看出，WIN10系統(tǒng)上USB主機在獲取到設備描述符和配置描述符后直接將設備掛起了。很明顯，WIN10系統(tǒng)的USB主機驅動實現(xiàn)對設備描述符或者配置描述符的內容并不認可，才會導致無法識別HID+CDC復合設備。

我們不妨檢查下客戶代碼中的設備描述符：

Figure 3 獲取的設備描述符

復合設備的class,subclass,protocol

必須為0xef,0x02,0x01,這里

VID=0x0483,PID=0x3256(Cube庫下為0x5740,但這個不重要),接下來看配置描述符:

Figure 4 win10不能識別的配置描述符

由此可見，客戶的描述符是HID interface + IAD + CDC interfaces結構。對于WIN7，這種結構可以識別，但對于WIN10，這種結構WIN10未必能夠兼容，我們嘗試在HID interface外部加上一層IAD結構，使其成為IAD1 + HID interface + IAD2 + CDC interfaces結構，此時客戶的問題得以解決，在WIN10也可以正確識別了，修改后的描述符結構如下：

Figure 5 win10能夠正確識別的配置描述符

結束本篇實戰(zhàn)經(jīng)驗之前，讓我們再次回顧IAD的概念：

IAD（Interface Association Descriptor），為USB設備定義了一個標準來表述捆綁在一個邏輯功能（比如這里的CDC虛擬串口）上的多個接口的聚合的方法。USB協(xié)會分配了一個設備級別的類編碼（即圖3中0xEF），使用IAD的設備必須使用它（如圖3的設備描述符）；這樣可以很容易在設備枚舉時就能識別出采用了IAD的設備。IAD描述符通常放在它所要捆綁的多個接口的接口描述符之前。

3 結論

在WIN10系統(tǒng)中，建議復合設備每個邏輯功能的接口描述符前都搭載一個IAD描述符，不論這個邏輯功能是單個接口描述符完成（比如這里的HID功能）還是要由多個接口描述符完成（比如這里的CDC功能）。