[参考译文] TMS320F280049C：长时间刷写后、代码无法使用基于 CAN 的引导加载程序。

您好：

您是否能够在问题开始工作后再次重现？ 当应用程序无法执行时、器件处于什么状态（PC 在哪里等）？

此致、

Alex

您好 Alex、

我们目前无法确定问题的确切原因、我们正在尝试了解可能触发问题的原因。 具体来说、我们想知道任何 GPIO 连接更改或寄存器值修改是否会导致该行为。 您能否就可能导致此类问题的情景提供建议？

我们尝试了多次刷写、刷写过程成功完成、但之后应用程序代码不会运行。 有趣的是、我们的自定义引导加载程序仍然可以工作、这使我们怀疑下电上电后发生了闪存复位、或者应用程序入口点有问题。

一切都发生在我们的测试区域内。

您好：

我们尝试了多次刷写—刷写过程成功完成、但之后应用程序代码不会运行。 有趣的是、我们的自定义引导加载程序仍然可以正常工作

使用 JTAG 或自定义引导加载程序刷写后、应用程序代码无法运行？ “Still works“表示引导加载程序是否正确刷写代码、但不表示分支？ 您的应用程序和引导加载程序的入口点是什么？ 您能否使用内存浏览器或片上闪存工具确认闪存实际已写入？

如果您能够连接到器件以读取程序计数器和/或加载符号、这将提供有关执行位置的线索。

此致、

Alex

您能否说明不进入闪存入口点的原因、以及 JTAG 引导序列和 CAN 引导加载程序引导序列的差异。

您好：

您能否连接到器件、然后对其进行复位并查看程序计数器在哪里？ 这将有助于确定器件在无法启动应用程序时所处的状态。

您还可以通过 CCS 将内核加载到 RAM 中、然后逐步执行以查看其是否按预期运行。

我们正在刷写我们的服装引导加载程序

是刷写还是从 RAM 运行？

要进行调试、我们连接了 JTAG 并加载了我们的应用程序、 之后它开始工作、之后我们使用引导加载程序进行测试、它也正常工作

是否可以在这两个测试之间擦除所有闪存？ 结果是什么？

您能否通过检查存储器来确认引导加载程序是否成功将应用程序写入闪存？

引导模式选择引脚是配置用于 CAN 引导还是闪存引导？

此致、

Alex

您能否连接到器件、然后将其复位并查看程序计数器在哪里？ 这将有助于确定设备在无法启动应用程序时所处的状态。

如何操作？ 您能告诉我整个流程、我需要连接什么工具吗？

您还可以通过 CCS 将内核加载到 RAM 中、然后逐步执行它以查看其行为是否符合预期。

我们做了这一个、它运行正常。 现在、我也尝试了它是否按预期工作

您正在刷写它还是从 RAM 运行？

从 RAM 运行。

您能否通过检查存储器来确认引导加载程序是否成功将应用程序写入闪存？

是的,这是成功的写入,因为每一帧我们都在确认,写入失败,擦除失败,和调味的事情。

是否为 CAN 引导或闪存引导配置了引导模式选择引脚？

默认情况下为闪存模式。 我们有推入引脚用于进入引导模式。

如何操作？ 您能告诉我完整的流程、以及我必须连接的工具吗？

您可以在 CCS 的调用栈视图中查看当前 PC：

要重置：

您还可以尝试为您的应用或引导加载程序加载符号 (Load > Load Symbols)。

默认情况下为闪存模式。 我们有推入引脚可进入引导模式

引导加载程序是否存储在闪存中、但在运行前已加载到 RAM 中？ 还是先通过 SCI 发送引导加载程序、然后再通过应用程序发送？ 推入引脚是否会修改（拉高/拉低）引导模式选择引脚？

此致、

Alex

引导加载程序是否存储在闪存中、但在运行前已加载到 RAM 中？ 还是先通过 SCI 发送引导加载程序、然后再通过应用程序发送？ 推入引脚是否修改（拉高/拉低）引导模式选择引脚？

不需要。通过将 GPIO 24 设置为高电平 并将 GPIO 32 设置为低电平以进入 CAN 引导模式、我们正在发送服装内核文件、它将直接从 RAM 运行、并且我们不会存储在闪存中。 之后、我们将两个 GPIO 设置为高电平以进入闪存模式。

您好：

>您是否可以连接到设备,然后重置它,运行,并查看程序计数器的位置? 这将有助于确定器件在无法启动应用程序时所处的状态。

您是否能够执行这些步骤？

此外、您可以使用 CCS 的片上闪存工具来验证闪存中应用程序的完整性吗？

为此、请在工程属性中将 CCS 闪存加载程序设置更改为“verify only“、然后对.out 文件照常执行 Run > Load Program。

此致、

Alex

您好 Alex

我无法做到这一点、因为我没有出现问题的 MCU、修复后、我也无法复制它

您好：

如果问题不再可复现、则很难调试。 如果它再次显示、请尝试捕获设备状态、该状态将提供有关根本原因的信息、然后打开一个新线程。

此致、

Alex