我正在努力使用Atmel AT91SAM9G20板调试启动问题。对于前700毫秒或所以，一切都很棒。重置后大约700毫秒，处理器冻结。好奇的是，在释放重置按钮后，CPU驱动复位线。
这是一个显示正在发生的事情的镜头。黄色的轨迹是复位线。第一次下降是我按下重启键的时候。我认为第二个下降是由CPU产生的。
蓝色跟踪是CPU的串行数据。前两个突发来自初始引导程序。第三个突发是U-Boot启动。CPU在第三个蓝爆结束时停止发送掉字符。
如果我正确地解释了这些轨迹，这意味着在处理器从NAND闪存加载U-boot时，重置线几乎恰好是低的。
我有几个问题:
- 这种cpu控制的复位是正常的吗?
- 对如何调试有什么建议吗?
还有一些细节：我应该补充一下，我应该看看电源铁轨，他们看起来很干净。以下行为是可重复的。我可以在几秒钟内改变初始重置倾向（以黄色）的长度，并且其余的行为就是相同的方式。如果我插入JTAG电缆，行为发生变化 - 有时它是靴子，有时它没有，但在几秒钟后，JTAG接管，处理器停止。
在JTAG下，可以成功启动。下面是一个成功的jtag控制引导的样子:
请注意，时间刻度是不同的，我并没有按下重置按钮——这是软件控制的。同样的复位下降发生。在这两种情况下，长度都在500毫秒左右。
更新(仍然困惑)
Taffey先生提示下面的建议，我已经更详细地调查了看门狗定时器和重置控制器。看门狗定时器实际上由第一个引导加载程序禁用;我很确定正在执行代码，因为它发生在文本之前发出调试串行端口，我可以成功阅读文本。
在阅读关于复位控制器的细节时，我了解到处理器是应该抓住复位销的控制并将其拉低短时间。这是为了确保电路板上的其他硬件侦听相同线接收足够长的重置。通过U-Boot挖掘，我发现使用erstl字段设置重置的持续时间为0x0d：
AT91_SYS_WRITE（AT91_RSTC_MR，AT91_RSTC_KEY |（AT91_RSTC_ERSTL＆（0x0d << 8））| AT91_RSTC_URSTEN）;数据表解释了持续时间设置为2^(ERSTL + 1)慢时钟周期。
重置持续时间长时间为500毫秒，慢时钟晶体为32768 Hz，谷歌告诉我，日志（0.500 * 32768）/ log（2）= 14，0x0d + 1 = 14，所以这一切都是有道理的。
我认为真正的问题可能是U-boot崩溃;它发生在重置之后的事实可能与此无关。让人困惑的是为什么U-boot只会在JTAG崩溃的时候崩溃不是连接。
第二次更新
我仍然不知道是什么Awry或者为什么JTAG让它表现不同，但我想我已经弄清了一个解决方法（有点）。它看起来像U-Boot Crash正在以某种方式由NAND闪存在电路板上。偶然，刚刚到最近到达的董事会的下一次修订，使用MicroSD卡而不是NAND Flash用于散装非易失性存储（嗯，在MicroSD卡片内有NAND闪存，但您看到了该点）。
我的“解决方案”就是开始使用下一个版本的板子。U-boot也会因此崩溃，但原因是众所周知的——它被配置为寻找NAND闪存，但它找不到。因此，它死于火中。
所以,问题解决了。”(接下来的问题是“如何让AT91Bootstrap从串行flash加载U-boot ?”或“如何让U-boot与microSD卡一起工作?”或“为什么我要这样做?”)
我猜绿色的复选标记是乔比注意到重置线可以由微驱动，即使它被证明是不相关的长期。谢谢你们所有人的帮助。我很感激。
第三次更新（大约一周）
我最近一直在努力解决其他事情，但我确实弄清楚了最终问题的原因。我上面的最后一个神秘是：
让人困惑的是为什么U-boot只会在JTAG没有连接的情况下崩溃。
事实上，事实证明我误解了U-Boot，无法向U-Boot崩溃发送调试串行端口。我仍然不了解细节，但我发现它不是JTAG使U-Boot工作 - 我的电路与我的电脑的USB主机之间是一个共同点，因为它通过了USB端口。事实上，U-Boot在整个时间都工作得很好，但是每当JTAG断开连接时，我有RS-232到USB电平移位器我才会停止工作，串口会失败，我会假设U-Boot是死的。实际上，我发现我可以仍然可以依赖于ping命令，并且即使我的字符在终端上没有回声，也可以看到生成的ICMP报文。
我不知道到底是哪里出了问题，但我真的不在乎——我可以很容易地找到另一种方式来读取串口，而且在短期内，我可以只用一根电线连接到USB接地。
谢谢你的帮助，所有。
