大家好、
我有一位客户 在从闪存启动 CPU 时遇到问题。 它们将 GPIO 设置为选择引导选项、但某些单元可以引导、但大多数单元无法引导。
我们观察到的内容的摘要:
- 我们有一个包含一些代码的.hex 文件(与它的代码无关、因为即使是简单闪烁的 LED 应用程序也会发生故障)、我们几乎可以确定看门狗和 ECC 已被禁用。
- 此.hex 文件是从一台 PC 构建的、并在新加坡和其他国家/地区进行了测试。
- 我们通过 SCI 通道(使用 C2Prog 软件)或 JTAG 将.hex 文件下载到处理器的内部闪存(TMS320F28388D)
- 断电并将引导模式引脚更改为从闪存引导后;引导失败( 在某些设备上 )
- 此外(对于故障单元)、我们观察到 XRSn 复位引脚由处理器驱动、并且周期性地变为高电平、然后再次变为低电平、速率大约为~200ms
- 我们还观察到、对于下载到某些单元的完全相同的.hex 文件、引导工作完全正常。
这似乎指向硬件中非常微不足道的东西、但我们没有确切的引脚点来确定故障的发生位置。 我们需要帮助缩小搜索范围。
我们已经浏览过 TI 论坛、但似乎没有任何匹配行为。
我们始终怀疑看门狗以及我们检查的内容:
- codestart.asm 似乎指向正确的位置
- codestart.asm 的汇编代码肯定会禁用看门狗
- 我们已验证编译器输出文件位置是否链接了正确的 codestart.asm 文件
- 我们从 JTAG 运行了代码、一切都正常
- 我们从 JTAG 进行了检查、以从地址0x80000 (内部闪存的开始)运行、以遵循代码开始的顺序、看起来是正确的
如果有任何其他需要我们检查的问题、以及是否有问题、请提供建议。
非常感谢。
此致、
欧内斯特