以下是從安富利工程師的技術支持的郵件中摘抄的，在此再次對他們表示感謝。
在我們面對客戶單板的時候，fsbl階段的調試多少會有些問題，在這個過程中怎么快速定位客戶的問題，並將有效的信息反饋給希望能幫助到你的人是決定解決問題時間長短的一個重要因素，在這里我寫下一些我個人的調試經驗，希望對你們有幫助，即使你不打算親自去用這里面寫的東西，也請將你轉發給你的客戶。我不希望聽到看到收到關於問題的描述是只是僅僅是一句：客戶的單板上電后沒有任何反應。在這種情況下你要像了解女\男朋友一樣去了解我們的芯片，我們的代碼、我們的工具。如果你不能理解我這篇文章，那只能接受馬伊琍式的悲劇，等待第三方的出現。
首先在我們的fsbl工程中是有調試開關的，在src/fsbl_debug.h中增加FSBL_DEBUG_INFO的宏定義，這樣就將fsbl中所有的調試信息打開，啟動過程中會有各種打印信息。
如果很不幸你的fsbl工程已經將這個調試宏配置了，系統啟動后還是沒有任何打印，在進一步調試之前你先要確定以下幾個事情：
1：BOOT.BIN是否正確燒入flash中或保存在SD卡中
2：XPS硬件工程中的串口是否和硬件實際設計一致
3：波特率的設置有沒有問題、串口線是否正常
當你通過一系列的交叉實驗確認上述一切正常，那只能往更低層進行分析了，因為這個時候有可能是在芯片的BootROM運行階段就出錯了。將你的JTAG線連上單板，確認它正常工作后，我們可以繼續。
首先我會在xmd里面通過connect arm hw命令連接到芯片，如果一切正常，你會看到下面的信息：
OK，這個時候已經連接到芯片上了，接下來應該干什么？要知道該做什么跟我們想知道什么是息息相關的，這個時候我們最想知道的是處理器到底運行得怎樣的，處理器運行的怎么樣通過什么東西能體現的最直接？當然是CPU的那些通用寄存器，那怎么查看這些通用寄存器？當然是用rrd的命令：
通過rrd，你可以看到當前的PC指針指向的位置，為什么是0xfffffe1c這個位置？不為什么，因為我還沒有將fsbl通過JTAG下載。那我們繼續吧，通過dow命令來下載fsbl的elf文件。
通過dow加載fsbl成功后，你可以再通過rrd命令看現在CPU的寄存器的值：
你可以看到pc已經被設置到0地址了，隨時准備運行，只等你的發令槍響起來，OK，那我們繼續，執行run命令：
OK，你的fsbl已經跑起來了，這個時候你的問題發生了，只要不發生人力不可抗的事故，基本上你還是可以通過stop命令將運行的CPU打住的：
你看到沒有，CPU穩穩的停在了0x0000cd30的位置。當然我這里是正常情況，也許你那邊根本就不是這個地方，但是只要是在dow命令那張圖中的其中一個段中的地址，你還是有機會查看到CPU運行到什么位置的。比如我這里0x0000cd30會對應fsbl工程里面哪行代碼呢？讓我們回到SDK中fsbl的工程目錄，找到Binaries里面對應的elf文件，猛烈雙擊它，在右邊的窗口你就可以看到反匯編的結果：
我們在打開的反匯編結果里面查找cd30，這樣很快就可以找到對應的C代碼行了：
當然像上面這些正常情況下的調試都很順利，也許你面對的情況是將BOOT.BIN文件燒入到外部存儲器之后，系統上電什么反應都沒有，即使你的fsbl里面也加了打印。這個時候我們就要關注一下以下問題：
fsbl是否被BootROM正常加載到OCM里面了，如果正常加載到了OCM里面，那就是fsbl執行階段的問題，如果沒有正常加載到OCM里面，那就是BootROM執行階段的問題。
OK，我們先看看怎么判斷fsbl是否被BootROM正確加載到OCM里面去了沒？
很簡單，如果fsbl正常加載了，那OCM里面的數據不會是空的，它里面會是BootROM讀取進來的代碼和數據，就像下面這樣：
如果沒有被BootROM正常加載，那上面的數據就是全0.
OK，接下來分析一下如果沒有被BootROM加載到OCM里面的情況，此時一般都是BootROM訪問外設出了問題。再OK一下，我們需要有個方法來確認是什么問題。在我們的芯片里面有一段slcr寄存器，這里面有個記錄復位原因的寄存器REBOOT_STATUS，別被這個名字忽悠到，這里面確實有跟復位相關的信息，但更重要的是我們可以從它的低16位獲取到本次啟動失敗的原因：
通過mrd命令將該寄存器的值讀出來：
是個2是不是，2就對了，因為在UG585里面的的Debug Status章節里面的BootROM Error Output Codes里面寫着2就是成功的。不2就有問題，你只需要根據這里面值就可以大致判斷出問題所在。
如果你看到了這里說明你是位好同志，請給我發郵件，我會建議領導給你加薪。