我正在努力使用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接地。
谢谢你的帮助,所有。