xilinx zynq的fsbl阶段的调试

1，什么情况下会使用zynq  fsbl的启动调试模式？

答：我们在进行zynq开发，常把项目生成bin文件或者mcs文件，然后加载到板子上进行调试运行。然而有时候把文件加载后，上电板子没任何响应，这时则需要启动zynq  fsbl启动调试模式，看看启动具体是在哪里卡住了。

2，启动调试步骤

         在myfsbl/src/fsbl_debug.h中添加#define  FSBL_DEBUG_INFO，打开fsbl中所有的调试信息，启动过程中会有各种调试信息打印出来，这样就会很容易知道启动具体卡在哪个位置。（打印的信息一般显示在串口工具如tearteam）

 

 

***附带xilinx官网的介绍：

在我们面对客户单板的时候，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就有问题，你只需要根据这里面值就可以大致判断出问题所在。