求組:使用CH552模擬CH9326,上位機(jī)發(fā)送GET_REPORT請求1496次后,設(shè)備會斷開并重新接入

spacer.gif微信截圖_20201104084241.png



如圖所示,每次在使用GET_REPORT命令1498次之后,設(shè)備都會自動斷開,導(dǎo)致每次我都要重新在上位機(jī)上重新打開設(shè)備,請問如何避免這種情況,我的應(yīng)用場景需要用到GET_REPORT一直獲取IO口的輸入信息,求助。

icon_rar.gifCH558&9模擬HID.zip

你好,用這個例程試一下


抱歉上面發(fā)錯了,不是CH552的例程,但是也可以參考一下,主要是針對非標(biāo)準(zhǔn)命令的處理。從你的抓包結(jié)果看,你的程序應(yīng)該沒有加針對非標(biāo)準(zhǔn)命令的操作處理,導(dǎo)致發(fā)get report命令時一直置stall。



我看了下558的代碼,對于消息響應(yīng)部分沒有差別,我對于非標(biāo)準(zhǔn)請求的代碼貼在下面了,對于len的響應(yīng)我新增了一個0xf0作為標(biāo)記傳送我需要的數(shù)據(jù),我看不懂的是為啥每次都是到149x多的時候出現(xiàn)這個錯誤

if?(?(?UsbSetupBuf->bRequestType?&?USB_REQ_TYP_MASK?)?!=?USB_REQ_TYP_STANDARD?)/*?非標(biāo)準(zhǔn)請求?*/
{
	if(?(UsbSetupBuf->bRequestType?==?0xa1)&&(UsbSetupBuf->bRequest?==?HID_GET_REPORT)?)
	{			
		len?=?0xf0;???
	}
	if(?(UsbSetupBuf->bRequestType?==?0x21)&&(UsbSetupBuf->bRequest?==?HID_SET_IDLE)?)
	{					
		UEP0_T_LEN?=?0;????????????//Status?stage?complete,?upload?0?data?packet,?end?the?control?trans
		len?=?0;???
	}
														????????????????
}
////////////////////////////////////////////////////////////

????????if(len?==?0xff)
????????{
????????????????SetupReq?=?0xFF;
????????????????UEP0_CTRL?=?bUEP_R_TOG?|?bUEP_T_TOG?|?UEP_R_RES_STALL?|?UEP_T_RES_STALL;//STALL
????????}
????????else?if(len?==?0xf0)???????????????????????????????????????????????????????//上傳數(shù)據(jù)或者狀態(tài)階段返回0長度包
????????{		
		memcpy(?Ep0Buffer,?UserEp0Buf,?2);??????//加載上傳數(shù)據(jù)
????????????????UEP0_T_LEN?=?2;
		UEP0_CTRL?^=?bUEP_T_TOG;?
		KeyCode=0;
?????????}						
????????????else?if(len?<=?8)???????????????????????????????????????????????????????//上傳數(shù)據(jù)或者狀態(tài)階段返回0長度包
????????????{
????????????????UEP0_T_LEN?=?len;
????????????????UEP0_CTRL?=?bUEP_R_TOG?|?bUEP_T_TOG?|?UEP_R_RES_ACK?|?UEP_T_RES_ACK;//默認(rèn)數(shù)據(jù)包是DATA1,返回應(yīng)答ACK
????????????}
????????????else
????????????{
????????????????UEP0_T_LEN?=?0;??//雖然尚未到狀態(tài)階段,但是提前預(yù)置上傳0長度數(shù)據(jù)包以防主機(jī)提前進(jìn)入狀態(tài)階段
????????????????UEP0_CTRL?=?bUEP_R_TOG?|?bUEP_T_TOG?|?UEP_R_RES_ACK?|?UEP_T_RES_ACK;//默認(rèn)數(shù)據(jù)包是DATA1,返回應(yīng)答ACK
????????????}



猜測是主機(jī)有相應(yīng)的重傳機(jī)制吧,之前應(yīng)該是沒有增加對非標(biāo)準(zhǔn)請求的處理,增加相應(yīng)的處理應(yīng)該問題就解決了。


上次的問題增加了非標(biāo)準(zhǔn)請求還是沒有解決,設(shè)備斷開我現(xiàn)在確定芯片是復(fù)位了的,我查看了一下PCON里的復(fù)位標(biāo)志,表示的是看門狗復(fù)位,但是GLOBAL_CFG?寄存器里bWDOG_EN位讀出為0,為什么還會產(chǎn)生看門狗復(fù)位?



你加我一下微信18951773083,然后把相應(yīng)的上位機(jī)工具以及軟件工程發(fā)我一下,我這邊實(shí)際測試一下。


add the following line at case SETUP

case SETUP: UEP0_CTRL &= 0xF2; .....

This fixed that bug for me.


只有登錄才能回復(fù),可以選擇微信賬號登錄

国产91精品新入口,国产成人综合网在线播放,九热这里只有精品,本道在线观看,美女视频a美女视频,韩国美女激情视频,日本美女pvp视频