最近使用CH552遇到一個(gè)枚舉失敗的問題。大概過程如下：

枚舉過程中，主機(jī)請求了一個(gè)設(shè)備不存在的描述符。

實(shí)際為：`80 06 00 06 00 00 0A 00`請求描述符`USB_DESCR_TYP_QUALIF`

SETUP事務(wù)觸發(fā)中斷，大約22us以后，將EP0設(shè)置為STALL

SETUP事務(wù)在設(shè)備ACK以后大約2us，主機(jī)又發(fā)起了一個(gè)IN事務(wù)，由于此時(shí)EP0還沒有設(shè)置為STALL，設(shè)備應(yīng)答NAK

ISR中將EP0設(shè)置為STALL以后，主機(jī)再發(fā)起IN事務(wù)，設(shè)備應(yīng)答STALL，然后主機(jī)重新請求設(shè)備描述符。過程如下圖所示：

主機(jī)發(fā)起SETUP事務(wù)請求設(shè)備描述符，設(shè)備應(yīng)答ACK并觸發(fā)中斷，在中斷設(shè)置EP0之前，主機(jī)又發(fā)起來了一個(gè)IN事務(wù)，由于EP0還是STALL沒有改變，設(shè)備應(yīng)答STALL，枚舉就失敗了。

主要是主機(jī)的IN請求發(fā)送的太快，而MCU響應(yīng)中斷又太慢，有沒有比較好的解決方法呢？

如果需要可以提供完整的邏輯分析儀抓包數(shù)據(jù)。

是這個(gè)問題，原作者給出了解決方案，但是感覺并不是太好。

https://whycan.com/files/members/1510/_20200127113747.png

通常我會(huì)建議客戶在進(jìn)入U(xiǎn)SB中斷前，不管進(jìn)入原因是什么，先將用到的端點(diǎn)的狀態(tài)都改成NAK，因?yàn)镹AK肯定不是一種錯(cuò)誤狀態(tài)，改成NAK之后就有充足的時(shí)間來處理事務(wù)本身，再改成ACK或者STALL。

同樣的這個(gè)問題也會(huì)存在于連續(xù)數(shù)據(jù)傳輸過程，如果不及時(shí)將ACK狀態(tài)改回NAK，可能會(huì)發(fā)生意外的數(shù)據(jù)傳輸。

一般這樣可以解決問題。

Thats a problem which occures in all WCH usbsamples. Whenever a STALL handshake?

is send back for any reason the next Setup request is stalled too because the chip

does not automatically unstall on recieving the next Setup. For that reason no example

(including the bootloader) will pass USB2CV tests from usb.org.

For me the following works:

...

case SETUP:

? ? ? ? UEP0_CTRL &=0xF2;?

....

現(xiàn)在看來，似乎只能進(jìn)SETUP的時(shí)候清除STALL來解決，如果USB的IP在STALL以后能發(fā)一個(gè)中斷請求，在STALL的中斷響應(yīng)中處理會(huì)更優(yōu)雅一些。這是我最終的處理方案：

case?UIS_TOKEN_SETUP?|?0:
????if((UEP0_CTRL?&?MASK_UEP_T_RES)?==?UEP_T_RES_STALL)
????{
????????//?STALL?->?NAK
????????//?xxxxxx11?->?xxxxxx10
????????UEP0_CTRL--;
????}