關于 GD32 虛擬串口的兩個 BUG

來源：公眾號【魚鷹談單片機】ID ??：emOsprey

最近魚鷹在搞調試器，折騰了好多天終于理解了 MDK 、下載算法、調試器、MCU 之間的關系。

簡單來說，就是，調試器作為 USB 轉 SWD 協(xié)議的轉換工具，MDK 通過 USB 驅動這個工具，下載算法包含了一些 MCU 內部 FLASH 擦除、編程代碼，和普通代碼不同的是，該代碼可以下載在任意位置運行。如果需要校驗，還會加入 CRC 校驗代碼，扇區(qū)檢測代碼。

MDK 首先通過調試器將算法寫入內部 RAM，然后把需要寫入的固件程序寫入 RAM，再由 MDK 控制（通過調試器） MCU 執(zhí)行相應代碼（擦除或寫入扇區(qū)），通過 MCU 的寄存器和設定軟件斷點得到執(zhí)行結果，如此來回搬運，就可完成固件下載。

說起來簡單，做起來很麻煩（調試器工具功能簡單，只做協(xié)議轉換，如何控制通過 MDK），這里點到為止，有時間會好好整理分享一下。

之后準備 USB 相關的工作，發(fā)現(xiàn)總是沒有滿意的 USB CORE 庫，官方的庫感覺還不錯，可惜被封裝了，看不到源碼，放棄。

之前魚鷹分享過虛擬串口的代碼，于是下載下來使用，發(fā)現(xiàn)竟然在 GD32 中用不了，當初明明 ST 測試沒問題的。

還以為是 GD 芯片問題，然后使用之前的 USB 雙緩沖讀卡器代碼，發(fā)現(xiàn)沒有問題。

只能在線調試比較差異，借助邏輯分析儀，總算解決了這兩個 BUG，順利自發(fā)自收。

BUG 1

枚舉失敗。

通過邏輯分析儀發(fā)現(xiàn)，電腦發(fā)送控制幀給 USB 設備，竟然沒有任何回應，即沒有 NAK，也米有 STALL，更不用說 ACK 了。

正?；貞?/p>

無回應

通過調試發(fā)現(xiàn)，該端點接收狀態(tài)為?0，禁用狀態(tài)，再參考可用代碼，發(fā)現(xiàn)在復位之后，應該設置為接收有效才對。因此修改如下：

void USBD_Reset (void){??………………??……  ……??EPxREG(0)?=?EP_CONTROL?|?EP_RX_VALID;?// 除了設定端點類型外，還要使能接收  DADDR = DADDR_EF | 0;                 /* Enable USB Default Address         */}

很奇怪的是，ST 我以前測試是沒問題的，可能也是兩者之間的差異吧。。

BUG?2

枚舉成功后，又出現(xiàn)另外一個問題，就是串口只能發(fā)送第一幀數(shù)據(jù)，第二次卡死……

經過邏輯分析儀發(fā)現(xiàn)，發(fā)送的數(shù)據(jù)會被 NAK。后來才發(fā)現(xiàn)下面的語句不滿足，直接沒有讀 USB 數(shù)據(jù)包，從而沒有恢復接收有效狀態(tài)，導致串口助手卡死。

這段官方代碼也確實比較迷，沒有最大利用緩存空間（最少需要滿一包的空間，但實際可能不滿一包），不過按下不表。

那就是第一次收到的數(shù)據(jù)未讀唄，在 main() 函數(shù)里面發(fā)現(xiàn)根本沒進來，發(fā)現(xiàn)竟然一直在 USB 中斷執(zhí)行……

void main() {   while(1)   {    ……     if (usb_rx_ch == -1)            usb_rx_ch = USBD_CDC_ACM_GetChar();    ……     }?}

然后看到這個標志一直在，未清除導致。

但很奇怪的事，該代碼在 ST 里面跑的挺好的。不管它，加上處理：

void USB_LP_CAN1_RX0_IRQHandler(void) { ……  if (istr & ISTR_ESOF)  {      if (USBD_P_Error_Event)    {      USBD_P_Error_Event(3);    }    ISTR = ~ISTR_ESOF;  }    ……?}?

這下串口助手一下子絲滑了，舒服！