[参考译文] TMS320F28388S：TI 引导加载程序中定期复位

尊敬的 Ed：

50 us XRS！ 信号指向看门狗复位(请参阅 TRM 第3.3.7节)

您应尝试连接 到器件并在仿真模式下调试引导加载程序/引导 ROM、以查找导致 WD 复位的原因。 您还可以检查寄存器、以查看它们是否提供了有关故障的指示。

此致！

Matt

供参考：

您可以通过将引导 ROM 符号(.out 文件)加载到器件来单步执行器件引导 ROM。  此选项会添加生成的项目".out"文件中提供的符号以进行调试、而不是通过 CCS 将实际的".out"程序加载到内核中-这也是您可以将此方法与引导 ROM/内 置引导加载程序一起使用以进行调试和获得可见性的原因。

1. 将 CCS 打开到工作区
2. 点击"View">"目标配置"：
   1. 
3. 您可以将此器件的工程导入 CCS 并使用该工程连接到器件、或在此窗口中将原始目标配置从 C2000Ware 复制到"用户定义的"目标配置。 无论通过哪种方式、均可查找器件目标配置(下面的 F28377D 示例)并启动：
   1. 
4. 当它打开调试窗口时、选择器件 CPU 并连接到目标：
   1. 
5. 导航至工具栏并单击按钮至"LOAD symbols"(加载符号)
   1. 
6. 加载 bootrom .out 文件。 对于该器件、它应该位于中  
   1. C：\ti\C2000Ware_5_03_00_00\libraries\boot_rom\f2838x\revA\rom_sources\CPU1\ccs_files\Release
   2. 如果弹出一个窗口、表明找不到源文件、可以选择"Locate File"并在 C2000Ware 中找到它
      1. 通常在此处为 C：\ti\C2000Ware_5_03_00_00\libraries\boot_rom\f2838x\revA\rom_sources\CPU1\f2838x_rom\bootROM\source
7. 该文件应打开以显示您所在的 Bootrom 位置、而您可以单步执行/调试

尊敬的 Matt：

这是很棒的信息！  谢谢！

我可以看到 WDT 确实是此处的罪魁祸首。  我还可以看到、引导 ROM 在 USB_GetWordData 开始处出现循环。  但硬件设置为让引导 ROM 退出到我们的代码。  我们可以采取什么措施来导致引导加载程序无法退出到我们的身边？  我们怎样做才能让它访问 USB？

BTW、WDT 以及在闪存中加载的不同模块的另一个实验表明、引导加载程序确实会退出到我们的代码一次。  但我们所做的是阻止引导加载程序再次执行此操作。

谢谢！

据

尊敬的 Ed：

您如何对设备进行编程以启动？ 您是否使用器件默认引导模式(使用 GPIO 72/84配置)或者对 OTP 进行编程以用于独立引导？ 如果是独立的、您曾向 BOOTPINCONFIG、BOOT-GPREG2 、 BOOTDEF-LOW、BOOTDEF-HIGH 寄存器写入什么内容？  

此致！

Matt

尊敬的 Matt：

我们使用 GPIO72/84引导、两者都是1。  我们已经通过示波器和使用 CCS 读取值进行了确认。  未涉及 OTP。

此致、

据

尊敬的 Ed：

此操作看起来像是 正在触发闪存至 USB 开关(请参阅 TRM 的表5-7)。  

您的闪存入口点地址(默认为0x0008 0000)是否始终未编程(0xFFFFFFFF)？ 这很可能是您无意中进入 USB 启动的原因。  

此致！

Matt

尊敬的 Matt：

有。  我也在看那个部分。  我们的入口点0x80000始终是编程的。  每次它失败时、我都会仔细检查这一点。

这里是其他一些数据。  我当时想、正是我们的代码导致引导加载程序无法退出代码。  现在、我有一个失败的代码版本、另一个没有失败的版本。  但是、两个版本之间唯一更改的文件不会用于产生问题的工程中。  作为一项仔细检查、我对两个版本的构建结果进行了二进制比较、它们是相同的。  为了消除硬件差异、两个版本都在同一个硬件副本上运行。

所以问题肯定在别的地方,两个版本的出现产生不同的结果是偶然的。  这种线索可能有用的是、当 TI 引导加载程序未输入代码时、处理器正在尝试访问 USB。  根据 TRM、如果 GPIO72/84不是0b11或闪存未被识别为已编程、则会发生这种情况。  示波器显示 GPIO 均为1、因此未对闪存进行编程。  但 CCS 中的 Memory Browser 显示了这个消息。  引导加载程序会尝试使用 USB 而不退出到我们的代码吗？

谢谢！

据

尊敬的 Ed：

您可以尝试仿真闪存启动吗？ 我很想了解在模拟独立闪存启动时是否也会出现这种情况。

此致！

Matt

尊敬的 Matt：

不幸的是、我无法再重现此问题。  调查以一个"有效"的代码版本和一个"失败"的版本结束。  它们之间的区别在于、在用于复制此问题的工程中、不使用单个文件。  我要规范代码、以便从代码中获取更多信息、但由于我无法使代码失败、需要等待。

抱歉、

据

尊敬的 Ed：

很遗憾听到它没有全景、 我要暂时关闭此主题。 如果您最终找到了解决方案或需要进一步的帮助、请随时更新此主题。

此致！

Matt

尊敬的 Matt：

作为运气会有它,我一个单位是失败的,然后工作,现在再次失败。  我一直在想、TI 引导加载程序是否退出到我们的代码中、是什么导致它返回到 TI 引导加载程序并保持不变。  我做了一个实验、证明 TI 引导加载程序从来就没有用到我们的代码。

您之前已经提到了仿真闪存启动。  假设您是指 spruii0e 第5.5.1节中描述的启动操作？  无论是否连接仿真器、这都会失败。  如果需要帮助、我们将使用 XDS100v3。

谢谢！

据

尊敬的 Ed：

Unknown 说：

假设您是指 spruii0e 第5.5.1节中描述的启动操作？

是的、 该节中的图5-2描述了 器件引导 ROM 所经历的仿真引导流程。  

Unknown 说：

无论是否连接了仿真器、此操作均失败。  如果需要帮助、我们将使用 XDS100v3[/QUOT]

您的意思是您遇到了 JTAG 连接问题？ 它在引导 ROM 中的什么地方卡住了？它将在哪里？

作为参考、CCS 中有一个快捷方式可用于设置 EMUBOOTPINCONFIG 和 EMUBOOTDEF 寄存器以模拟引导至闪存。  

连接到器件后、转到"Scripts">"EMU Boot Mode Select">"EMU_BOOT_FLASH"。 这样会使用正确的值配置仿真引导寄存器、您可以在存储器浏览器中确认这些值。  复位时、器件将进入仿真闪存引导模式。  

 

此致！

Matt

尊敬的 Matt：

抱歉。  应该更清楚一些。  是的、来自这个部分。

我们不存在 JTAG 连接问题。  发生这种情况时、无论是否连接了 JTAG 都会发生这种情况。

我还找到了0xD00位置、并注意到整个区域中似乎是随机值。  但它没有0x5A 密钥。  我不知道非零值是否为线索。

无论如何,它现在不再失败-再次。  请持续关注…

谢谢！

据