書接上文，上回修改了代碼以后程序已經(jīng)正常運(yùn)行了，上傳的數(shù)據(jù)也非常正常沒有丟包。
然后我在測(cè)試的時(shí)候向電腦上插了兩個(gè)CH569，他在上傳了1000多個(gè)包以后又出現(xiàn)了
這個(gè)錯(cuò)誤。
無法理解，同一個(gè)USB設(shè)置了獨(dú)占的，用CH375那個(gè)DLL的官方數(shù)據(jù)上傳函數(shù)接口，按理說不應(yīng)該就對(duì)這個(gè)IO進(jìn)行讀寫嘛？為什么我插入另一個(gè)CH569會(huì)對(duì)這個(gè)CH569造成影響
補(bǔ)充一下，可以排除原來修改的固件程序本來就會(huì)導(dǎo)致這個(gè)報(bào)錯(cuò)卡死這個(gè)可能性，我用那個(gè)程序連接單個(gè)CH569跑了兩天數(shù)據(jù)沒有卡死和丟包，插上另一個(gè)CH569后1分鐘之內(nèi)必定報(bào)這個(gè)錯(cuò)誤并卡死。
關(guān)鍵代碼如下：
void EP1_IN_Callback(void)
{
? ? UINT8 nump;
? ? nump = USB30_IN_Nump(ENDP_1); //nump: 剩余待發(fā)送包數(shù)量
? ? switch(nump)
? ? {
? ? case 0://全部發(fā)完
? ? ? ? R32_PA_OUT |= ( 1 << 8 );
? ? ? ? R32_PA_OUT &= ~( 1 << 8 );? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? //這個(gè)標(biāo)志位別清除，雖然不知道為什么，但是清除就傳一會(huì)兒數(shù)據(jù)以后報(bào)錯(cuò)
? ? ? ? USB30_IN_ClearIT(ENDP_1);? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?//清除端點(diǎn)狀態(tài) 僅保留包序列號(hào)
? ? ? ? HSPI_Rx_Notice_Status=1;
? ? ? ? break;
? ? default://還剩一包未發(fā)完; 在突發(fā)過程中主機(jī)可能一次不能取走全部的數(shù)據(jù)包 因此要判斷當(dāng)前剩余包數(shù)量 通知主機(jī)還有幾包未取,end of burst位需寫enable
? ? ? ? R32_PA_OUT |= ( 1 << 8 );
? ? ? ? R32_PA_OUT &= ~( 1 << 8 );? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? //這個(gè)標(biāo)志位別清除，雖然不知道為什么，但是清除就傳一會(huì)兒數(shù)據(jù)以后報(bào)錯(cuò)
? ? ? ? USB30_IN_ClearIT(ENDP_1);? ? ? ? ? ? ? ? ? ?//清除端點(diǎn)狀態(tài) 僅保留包序列號(hào)
? ? ? ? USB30_IN_Set(ENDP_1, ENABLE, ACK, nump, 1024); //能夠發(fā)送1包
? ? ? ? USB30_Send_ERDY(ENDP_1 | IN, nump);
? ? ? ? break;
? ? }
}
void HSPI_IRQHandler( void )
{
? ? static UINT32V addr_Cnt=0;
? ? if( R8_HSPI_INT_FLAG & RB_HSPI_IF_R_DONE )
? ? {
? ? ? ? /* 單包接收完成中斷 */
? ? ? ? R8_HSPI_INT_FLAG = RB_HSPI_IF_R_DONE;
? ? ? ? if(addr_Cnt%2)
? ? ? ? {
? ? ? ? ? ? R32_HSPI_RX_ADDR0 = (UINT32V)(UINT8 *)DEF_HPSI_DMA_RX_ADDR0;
? ? ? ? ? ? USBSS->UEP1_TX_DMA = (UINT32V)(UINT8 *)DEF_HPSI_DMA_RX_ADDR1;? ? ? ? ? ? //突發(fā)傳輸 DMA地址偏移 需重重置
? ? ? ? }
? ? ? ? else
? ? ? ? {
? ? ? ? ? ? R32_HSPI_RX_ADDR1 = (UINT32V)(UINT8 *)DEF_HPSI_DMA_RX_ADDR1;
? ? ? ? ? ? USBSS->UEP1_TX_DMA = (UINT32V)(UINT8 *)DEF_HPSI_DMA_RX_ADDR0;? ? ? ? ? ? //突發(fā)傳輸 DMA地址偏移 需重重置
? ? ? ? }
? ? ? ? addr_Cnt++;
? ? ? ? USB30_IN_ClearIT(ENDP_1);? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?//清除端點(diǎn)狀態(tài) 僅保留包序列號(hào)
? ? ? ? USB30_IN_Set(ENDP_1, ENABLE, ACK, DEF_ENDP1_IN_BURST_LEVEL, 1024);? ? ? //能夠1號(hào)端點(diǎn)能發(fā)送HSPI_Rx_Data_LoadNum包
? ? ? ? USB30_Send_ERDY(ENDP_1 | IN, DEF_ENDP1_IN_BURST_LEVEL);? ? ? ? ? ? ? ? ?//通知主機(jī)取HSPI_Rx_Data_LoadNum包
? ? }
? ? else if( R8_HSPI_INT_FLAG & RB_HSPI_IF_FIFO_OV )
? ? {
? ? ? ? /* FIFO溢出中斷 */
? ? ? ? R8_HSPI_INT_FLAG = RB_HSPI_IF_FIFO_OV;
? ? }
}
實(shí)際就是讓DMA交替對(duì)兩片存儲(chǔ)空間存入HSPI數(shù)據(jù)和讀出USB數(shù)據(jù)，mian函數(shù)的死循環(huán)中并沒有進(jìn)行任何處理。
在USB讀出速度遠(yuǎn)大于HSPI接收速度的情況下，理論上絕對(duì)不會(huì)丟包。
繼續(xù)補(bǔ)充，我測(cè)試了官方的代碼和一些大佬開源的代碼，發(fā)現(xiàn)他們一般都會(huì)在main函數(shù)的死循環(huán)中對(duì)ERDY包進(jìn)行處理，而我是在HSPI中對(duì)ERDY包進(jìn)行處理，會(huì)不會(huì)是這個(gè)原因?qū)е碌模倚薷牧顺绦蜻M(jìn)行相關(guān)測(cè)試，發(fā)現(xiàn)確實(shí)在Main函數(shù)的死循環(huán)中進(jìn)行處理后插入多個(gè)USB極少會(huì)出現(xiàn)這個(gè)報(bào)錯(cuò)
查詢百度后我可以知道的就是，上訴的C0000011錯(cuò)誤出現(xiàn)在上位機(jī)詢問下位機(jī)多次無反應(yīng)后產(chǎn)生
由此我產(chǎn)生了一個(gè)疑問，到底是什么原因?qū)е挛疑鲜龃a出現(xiàn)這種報(bào)錯(cuò)，是否是用HSPI發(fā)送令牌包導(dǎo)致的錯(cuò)誤。多個(gè)CH569的通訊處理機(jī)制上DLL莫非會(huì)詢問其他CH569？
我無法理解，并希望獲得解答。再次感謝
