大家在開發過程中遇到BUG？

真正的目的是給自己一個糾錯記錄，最近老是忘事，遇到的bug，過幾天再次遇到，就會忘了之前如何處理，遂留筆記一篇，也給后面可能遇到該問題的小伙伴一個借鑒。

問題匯總：最近沒得更新，主要是我們搞到了一批芯片，之前的項目可以重新提上日程，于是保留了之前的開發思路，在其他MCU平臺上進行重新開發，遇到的問題是一件接著一件。首先產品端最初是STM32F030，現在的情況大家都了解，這顆料肯定是無法再用了，雖然手里還有幾千片存貨，可能一周都堅持不住，于是主控換成了GD32E230F4，主頻更高，但是flash太小，我的代碼編譯之后會超出內存空間，此為所遇問題之一。我們有一個用于給產品配合的小玩意，一般一個客戶有幾個就行，小客戶一個便可。之前為了開發快捷迅速，選擇了STM32F103作為主控，所有功能開發完畢。

但是因為這個小玩意是免費贈送，而且現在STM32F103也買不到，這個問題只有換芯片才能解決，于是換了GD32E230F4，同樣面臨代碼空間不夠的問題，而且還附帶其他問題，此為其二。還有一個是用STM32F030遇到發送數據也會進入USART的空閑中斷，無論代碼如何處理。此為其三。

問題詳情及解決之道：

問題一：flash空間不足的問題我算是解決了一半，只能算解決了問題，而解決問題后所帶來的其他問題，本人暫時無法追蹤原因。因為之前STM32F030的flash足夠大，所以沒遇到這個問題，在資源緊張的GD32E230中遇到了。但是在缺貨的情況下，能找到一顆供應滿足的MCU實屬不易，想方設法也得用起來。在代碼編寫完之后遇到如下問題：

我第一次遇到這種問題，去搜索發現是代碼太大，無法燒錄進MCU的FLASH。檢查發現code的確超出容量了。

于是借鑒網絡上的方法提高優化等級。

 可以發現明顯變小，燒錄也沒問題，但是代碼不正常運行，沒有卡死在任何地方，但是確實功能異常，在debug后發現問題出在SPI通信，我使用DMA+SPI0,發送一個數組給傳感器例如tx[3] = {0x01,0x02,0x03};然后接受數組可以正常接收到傳感器數據rx[3] = {0x01,0x02,0x03},將優化等級提高到1，此時SPI收到的數據rx[3] = {0x03,0x01,0x02}。這就導致了我后面處理SPI數據的時候數據出錯。于是我將發送的數據改為4個，也就是多發一個字節，此時接收到的數據是rx[4] = {0x00,0x01,0x02,0x03}。我在取數據的時候取后三個便可，這是一個治標不治本的辦法，至今我沒找到解決之道。其實這個問題的根源就是硬件IIC的驅動太大了，我沒能簡化掉。但是發現提高優化等級可以將代碼空間壓縮，那FLASH不就有閑置空間了嗎？為何還要用外置EEPROM呢？于是舍棄外置EEPROM，更換片內FLAH。因為一頁flash足夠我用了，這里只寫一頁，下面的代碼是參考官方例程自己簡化的一個寫FLASH的驅動，灰常好用。

void fmc_program(uint8_t* p_buffer,uint32_t Start_Address,uint16_t number_of_byte)

{

        uint32_t u32data;//fmc解鎖

        fmc_unlock();

        fmc_flag_clear(FMC_FLAG_END | FMC_FLAG_WPERR | FMC_FLAG_PGERR);

    fmc_page_erase(ERASE_PAGE_START_ADDR);

        address = PROGRAM_ADDRESS;

        for(uint16_t i = 0;i<number_of_byte;i++)

        {        

                u32data = (uint32_t)p_buffer[i]; 

                fmc_word_program(address, u32data);

                address+= 4U;

                fmc_flag_clear(FMC_FLAG_END | FMC_FLAG_WPERR | FMC_FLAG_PGERR);

        }

        

        fmc_lock();        //fmc上鎖

}

GD的FLASH例程叫FMC，一開始都沒找到，以為例程沒有。

過程很簡單：

1.使用庫函數fmc_unlock();函數將FLAH解鎖，

2.使用庫函數清標志位fmc_flag_clear(FMC_FLAG_END | FMC_FLAG_WPERR | FMC_FLAG_PGERR);

3.使用庫函數fmc_page_erase(ERASE_PAGE_START_ADDR);擦除一頁，寫之前必須先擦除，而且一擦就是整頁，這里我有個內容沒寫，是需要先將原來的數據讀出來的，否則會造成不需要改的數據擦掉。讀數據直接取地址就行，將數據全讀到一個數組中，然后在數組中將需要改的數據修改，調用這個驅動進行寫便可。ERASE_PAGE_START_ADDR為該頁的首地址。4.調用函數fmc_word_program(address, u32data);循環寫入，我是從頁首開始寫，這個參數address就是上面的ERASE_PAGE_START_ADDR。5.寫完重新置位標志位并上鎖。

uint32_t data;

        address = PROGRAM_ADDRESS;

        for(uint16_t j=0;j<256;j++)//取出所有FLASH里面的數據

        {

                data = *(uint32_t*)address;

                i2c_rxbuff[j] = (uint8_t)data;        

                address += 4U; 

        }

上面是將整頁數據讀出放在數組i2c_rxbuff中。

這里忽然想到還有一個問題，這里得說一下：我的工程用到了IIC，目的是像24C04里面寫數據，但是我的項目要求沒有足夠的時間給我寫，每個上位機的指令過來我必須及時回復，間隔時間只有幾十微秒，而寫24c04需要的是ms級別的時間，而且GD32E230沒有足夠的DMA通道給我使用，會和URAT以及SPI的DMA沖突。于是擠壓了一點時間出來，在主循環執行IIC寫操作，其他應用用DMA處理，這樣每個指令之間都可以空出一點點時間來寫，慢慢寫唄，不影響正常通信就行。但是在調試的時候發現了一個問題，這個問題很嚴重，但是不會影響我之前的應用，前提是我不在主循環進行IIC的讀寫。問題很簡單，我退出不了串口接收中斷，這個問題在一般應用中很常見，但是因為項目需求的原因，我所有的應用都在中斷內完成，沒有中斷外的應用，都是一個中斷打斷另一個中斷。最后還是在論壇里找到了答案。這一點在GD的例程中是沒有體現的，

問題二：代碼空間不足的問題上文已經處理，這里不贅述。這里說一下其他問題。我們的產品為例節省成本，基本都是使用MCU內部時鐘，之前ST是，現在GD也是，所用外設為：USRAT,SPI,IIC。均無任何問題。但是在芯片荒之前用STM32F103做這個小玩意時加上了外部晶振，而這次改用GD32E230再次取消外部晶振，于是遇到了大問題。我通過定時器觸發SPI采集若干個數據，在MCU內部進行算法處理，得到的值有問題，我懷疑是MCU計算出錯，畢竟里面包括了浮點運算，三角函數等等。于是我將數據導入到EXCLE中，發現計算并無問題。最后問題定位在定時器不準，在使用內部時鐘時，其他通信外設沒有問題，我就覺得內部時鐘是可靠的，但是遇到定時器他就歇菜了。于是重新打板，問題得以解決。還有個問題就是很容易出現的SPI通信問題，在產品上，MCU和傳感器是在同一個PCB上，距離很近，用100Khz的通信速率可以讀寫傳感器內部EEPROM，但是用這個小玩意和產品通信時通過排線連接，100K的通信速率會導致通信失敗，降低通信速率，將速率降低到50K便可。

問題三：發送數據進入串口接收中斷直到寫這篇帖子之前才找到原因，在網上沒找到這個問題的解決之道，也懷疑過時清標志位的問題，但是無論我如何操作，都無法解決這個問題。然后用示波器點了一下rx

明明在發送數據，但是卻有一個下降沿，然后再看空閑中斷的定義：空閑中斷是接收數據后出現一個byte的高電平(空閑)狀態,就會觸發空閑中斷.并不是空閑就會一直中斷,準確的說應該是上升沿（停止位）后一個byte，如果一直是低電平是不會觸發空閑中斷的。因為這一個電平的下拉，導致電平回拉的時候產生了一個上升沿，導致誤判為空閑狀態。查看電路圖，發現了一顆礙事的下拉電阻。

于是將該電阻拆掉便可，這個問題之所以一直未發現，其實是之前所有的應用都用不到空閑中斷，電路一直這么設計并無問題，但是在空閑中斷應用中就會導致出錯。ps:硬件不是我設計，所以這個問題發現的比較晚，而且我之前發現這個問題后在軟件上做處理給抵消了。不影響使用。