對于串口的輸出，210按照前面的操作是下面的亂碼。

1. 第一想到的很可能是波特率的問題，這是串口亂碼的一般情況。排除這一點的是前面的putc函數是可以實現的。驗證：

如上面，先把主函數里的printf信息給注釋掉。加上putc函數。重新編譯和加頭：

開發板先格式化

再下載：

下載成功之后，卻換到NandFlash啟動，看看串口有沒有輸出：

可以看到終端上面有信息的正常輸出，說明了putc是可以工作的，也就是波特率沒有錯。

上面就確保了波特率沒有問題，接下來想到的是串口打印函數printf有問題。在printf函數里我們就實現了兩個功能：1）格式化輸入的信息。2）輸出格式化后的信息。

    一般想到的是，很可能是在1）格式化輸入的信息的時候出錯了，導致輸出的是亂碼。也有可能2）輸出格式化后的信息有錯。

    之所以說輸出信息的地方出錯的可能性很小，這是因為前面的putc已經正常工作了。接下來就是排除這種情況。

主函數，直接調用printf：

做了上面的修改之后重新編譯，燒寫到開發板，設置從NandFlash啟動：

可以看到仍然是亂碼。上面轉化已經被注釋掉了，可還是亂碼。說明在輸出的時候就已經有問題了。

解析來就是注釋掉for循環，直接輸出一個變量：

重新編譯，燒寫到開發板，NandFlash啟動：

當改為變量之后，干脆就沒輸出了。

說明了輸出一個變量都有問題，接下來測試一下輸出一個字符：

重新編譯，燒寫到開發板，NandFlash啟動：

換成字符之后又沒問題了。

從上面的結果知道，問題出在變量上面。由于上面的變量是已經初始化的，存在于數據段，接下來就是檢查數據段的位置和內容是否正確。

數據段的位置是在代碼段之后的，打開lds文件即可確定：

可以看到是沒有問題的。

接下來是確認數據段的內容里有沒有tmp變量。

打開dump，搜索tmp變量：

可以看到，tmp是在elf文件里，也是在數據段的。但是存不存在與gboot.bin文件中呢！？

上面可以看到，定義的內容已經編譯進入了.bin文件。

就是數據段的內容也是正確的。

問題是，210里的uboot是需要加上一個頭信息的：gboot-210.bin，打開gboot-210.bin之后：

發現加了頭信息之后的uboot.bin里的內容變了好多，根本就沒有我們定義的信息。

查看兩個文件的大小：

上面可以到，gboot-210.bin比gboot.bin小了很多，但是，按道理，由于gboot-210.bin比gboot.bin多了一個頭信息，應該是要大一點才對，反而小了。

可以得出的結論了，就是沒加頭信息的uboot.bin是正常的，加了頭信息后，反而不正常，且是數據段的內容減少了。所以問題就出在加頭程序了。

打開加頭程序后，可以看到：

可以看到，上面BUFSIZE和IMG_SIZE的大小都是16k，然后是不是定義的BUFSIZE和IMG_SIZE太小，然后把后面的內容忽略了。所以改16k設置為32k。再把那些調試信息刪掉。重新編譯，燒寫，NandFlash啟動：

現在問題好像有點更嚴重了，啥信息都沒有，原來是有亂碼輸出的。開發板還一直在叫。

為什么單單改了一下長度：

開發板會在一直叫呢？

我們來回顧一下前面學過的東西：

如上圖，在210的uboot啟動的過程中，首先是先運行IROM里的BL0里的程序。BL0程序會把BL1里的程序往SRAM里復制。BL1的最大值是16k。復制進來之后，BL0會做相應的操作：

其中的一個操作是：

是去檢查Checksum。

具體的過程是這樣的：在BL0去把BL1里的16k程序復制到SRAM里的時候，回去統計BL1里1的個數。然后在我們的BL1里，4字節的頭：

可以看到也有CheckSum，就是BL1里1的個數。當上面的兩者不一致的時候，BL0就認為傳遞過來的映象有問題，就會產生叫聲。

問題是出在：

在加頭程序里，有一個for循環，就是統計加頭文件里1的個數的。本來BL1的最大值是16k的，這里的IMG_SING已經被賦值為32k，所以統一1的個數不只是BL0里的1，也有BL2里的1，導致與BL0統計的1的個數不一樣，所以會嘯叫。這里把它改回16k

改了之后重新編譯，重新加頭信息：

重新下載，設置NandFlash啟動：

可以看到控制臺已經正常輸出了。問題終于解決了。

上面就是一個解決嵌入式異常的流程，要善于用排除法，排除干擾因素等。