[参考译文] TMS320F28388D：从引导加载程序跳转到应用程序在调试器上工作、但从闪存引导时不工作

闪存可能不会处于安全模式、除非您特意为此配置了用户 OTP。

1. 当您将应用程序刷写到0x80000 (C2000ware 中提供的默认配置)时，它是否正常工作？ 这将有助于我们确认引导 ROM 执行没有任何问题。
2. 您用于从0x80000跳转到0x90000的指令是什么？您是否已验证这些指令是否正常工作？
3. 当您说复位时、什么是程序计数器值

感谢您的回答。 我很高兴它不能成为安全模式。

关于您的问题：

在0x80000处最小化我的应用程序之前、它是我的引导加载程序。 它在 UART 中进行响应。 当我单击 Enter 时、我收到一个提示、我使用它对地址0x90000中的应用程序进行编程、并且我有一个用于跳转到0x90000的特殊 UART 命令。 我还打开了一个 LED。 当我从调试器运行相同的最小化程序时、我可以单步进入该程序并查看跳转。 根据跳转、memcopy (ramfuncs...)和 InitSysCtrl 之间的顺序、它将正确跳转至0x90000并正确运行、或者在分支后转至 Estop。 当然、我只能从闪存运行适用于调试器的选项。

2.我使用了两个看起来相同的选项：asm ("LB #90000h")或将函数指针初始化为0x90000、然后调用函数。

3.我无法读取 PC 值，因为它仅在闪存模式下引导时发生。 要连接调试器、我必须循环通电。 无论如何、我知道、当有一个程序执行的不仅仅 是跳转时、0x80000中的程序就会重新启动。 我可以看到 LED 暂时熄灭、然后再次亮起、然后引导加载程序响应 UART。 我的最小程序仅会跳过重置指示、即板上有一个继电器、我听到它发出咔嗒声。 在我写这些行时、我想知道为什么我只听到它点击一次。 我希望它返回到0x80000处的 beigning 并再次跳转。 几个小时后、我才会靠近硬件。 我将重复实验并仔细聆听。 如果点击次数更多、将会更新。

再次感谢、

Rachel

正如我所理解的、引导 ROM 持续跳转到0x80000处的代码。 这一点没有问题。

从引导加载程序跳转到应用程序时(0x90000)出现问题。我的回答是否正确？

当您说最小化应用程序时，它是否类似于简单的 while (1)循环？ 在本例中、您可以看到程序计数器跳转到0x90000。

当您放入实际应用程序时、您会发现问题。 请确认我的理解是否正确。  

跳转至0x80000没有问题。

我的“最小化”项目实际上是我的引导加载程序，main()中的第一行中只有一个是跳转。 在调试器中运行时、我可以看到程序计数器跳转到0x90000。

问题似乎与0x90000上的代码无关。 我使用"闪烁"示例、因为它比实际的应用项目小得多。 无论我是使用带 UART 命令的完整引导加载程序进行跳转、还是在主程序开头使用跳转、都将出现跳转问题。

我再次从闪存运行程序、然后使用调试器连接到电路板。 PC 为0x3FD2AE。 我知道它位于引导 ROM 中。 与其他情况一样、调试窗口显示以下消息：

sendAndReceiveBytes_SPI (struct spi_driver_struct*、unsigned char*、unsigned char*、unsigned short、unsigned short)() 0x3FD2AE (发生错误：无法解析前一帧 FP)

此函数确实在0x80000项目中调用、但甚至未达到该调用。 它不会出现在闪烁项目中。

因此、当前序列是从0x80000到0x90000的程序的简单跳转。

您提到了这是在连接调试器的情况下工作的。 您也禁用了看门狗。

所以我看不到为什么它不会跳到0x90000。

上述理解表明程序在0x90000发生故障、程序计数器进入引导 ROM 中的错误处理程序。

另外、请从存储器窗口中检查0x80000和0x90000上的程序是否完整且未被其他内容覆盖。

经过一些进一步的调查、我意识到可能由于我在0x90000的程序中分配 RAM 的方式、必须从 RAM 运行的函数没有足够的内存。 至少重新分配 RAM 会使跳转工作。 您认为我向自己解释这一点的方式是否有意义？ 您能提供更好的解释吗？ 我真的想用这个问题来学习一些东西。 感谢您的所有帮助！

是的、有道理。 正如我在之前的响应中提到的、从0x80000处的引导加载程序跳转到0x90000处的应用程序、这是意料之中的事。

应用程序中的某些故障导致跳转至引导 ROM。

如果在连接了调试器的情况下运行应用程序时出现这种情况、您应该会看到相同的问题。