近期白嫖君在使用GD32這款芯片時候，發現了一個大概率是芯片設計上的BUG，貼出來和大家分享一下。

我們在使用串口發送數據時，無非是使用兩種方法，一種是逐字節發送，另一種是DMA發送。

一般串口發送數據前，我們需要先查看TBE標志位，判斷緩存區內是不是已經空了，如果空了我們才會往里填數據。

但是當發送緩存區為空時，并不代表我們的數據已經實際發完了，只是代表緩存區內的數據空了，這時物理意義上的發送可能還在進行中，如果你使用RS485器件，這時候把發送使能關斷的話，就會丟失一個字節的數據。

因此，一般發送完成后，需要檢查TC標志是不是已經被拉高了，以此來判斷數據線上的數據是不是確實已經發結束了。

void usart_sendbuf(uint32_t usart_periph, uint8_t *Buffer , uint16_t ucSend_num)
{        
    unsigned int i;
    usart_flag_clear(usart_periph, USART_FLAG_TC);  //在發送前要先清除TC
    for(i = 0; i < ucSend_num; i++)
    {        
        while(usart_flag_get(usart_periph, USART_FLAG_TBE) == RESET); 
        usart_data_transmit(usart_periph, Buffer[i]);
    }
while(usart_flag_get(usart_periph,USART_FLAG_TC)==RESET);
}

這次白嫖君的程序就是還按照這個套路來寫的，串口發送數據量比較大，在運行一段時間后，程序突然就死機了，查看一下，是死在了最后一行等待TC標志位這里。查看寄存器列表，TC始終為0。

下面是官方庫函數手冊上給出的說明：

TC標識是受單片機硬件控制的，并不受程序影響，這里無法拉高九成九就是芯片BUG了，于是白嫖君谷歌了一下，發現也有人遇到類似問題：

針對這種情況，硬件上無法做出改善，只能從軟件上規避了：

void usart_sendbuf(uint32_t usart_periph, uint8_t *Buffer , uint16_t ucSend_num)
{        
    uint32_t i;
    uint32_t j = 0;
    
    usart_flag_clear(usart_periph, USART_FLAG_TC);  //為了使用TC，在發送前要先清除TC
    for(i = 0; i< ucSend_num; i++)
    {        
        while(usart_flag_get(usart_periph, USART_FLAG_TBE) == RESET); 
        usart_data_transmit(usart_periph, Buffer[i]);
    }
    while(usart_flag_get(usart_periph, USART_FLAG_TC) == RESET)
    {
        if(j++ >= 0xFFFF) //在這里加超時機制
        {
            break;
        }
    }        
}

引入超時機制，當等待時間超過設定閾值，則不再等待TC置位，以此來避免程序阻塞假死。

特別注意：出現這種情況目前來說可能GD全系都有可能存在這個問題，且不區分是USART0還是USARTx，同時似乎只在數據量較大時會出現此種情況。我以前用GD的片子也不少，從沒遇見過這種情況。特此說明，避免抬杠嘛~

審核編輯 ：李倩