[参考译文] CCS/TMS320F28062：在汇编源文件中设置入口点

你好

生成 ASCII 十六进制文件时、可以使用命令参数--entrypoint 指定将从引导加载程序中提取的入口点、然后在执行结束时分支到该入口点。

另请参阅 TRM、以熟悉连接 JTAG 时的启动行为与未连接 JTAG 时的启动行为之间的差异。

此致
Chris

好的、那么它肯定是不同的...
我将尝试解释升级的行为。
1.闪存和 RAM 由 CSM 锁定、因此在进行固件升级之前、我将闪存擦除器下载到不安全的 RAM 以擦除闪存 A 以解锁所有区域。
然后、我下载一个自定义 RAM 引导加载程序、该加载程序能够下载位于 FlashA 中的静态自定义引导加载程序。
使用此引导加载程序、我可以进行固件升级。

步骤1. 和2. 仅在我需要更改静态引导加载程序时完成。

如果我执行上述所有步骤、静态引导加载程序能够在完成闪存例程且固件正在运行时跳转到固件。 因此、我生成的输出文件在某种程度上似乎是错误的。

但是、如果我关闭器件电源并将其重新打开、静态引导加载程序不会跳转到主固件。

因此、为了将所有内容组合在一起：当我将新的静态引导加载程序上载到 FlashA 时、.InitBoot 会正常执行、并且跳转到主应用程序会正常工作。 如果我断开 Vcc 并再次连接、引导加载程序将无法再跳转到主应用程序。

问题是、我真的必须去初始化堆栈等吗？ 当新程序启动时、codestart 段会初始化堆栈、因此不需要进行初始化？

你好

是的，调用 code_start 将调用_c_init00，它执行堆栈初始化并最终调用 main()。
当它无法再跳转到 main 时、您会看到什么行为？ 您是否能够跟踪它将到达的地址？ 它是否会到达引导加载程序？

此致
Chris

是的、引导加载程序正在引导、我可以通过 LED 看到不同的阶段。 调试并不容易、因为如果我使用调试器、它就能正常工作。 如果我执行前面介绍的所有步骤(解锁和擦除闪存、将引导加载程序加载到 RAM 中、该 RAM 能够将静态引导加载程序刻录到闪存 A 中、 最后、使用闪存 A 中的引导加载程序加载主应用程序)它正在工作、而闪存 A 中的引导加载程序跳转到主应用程序。 但是、当我拔下器件并再次应用 Vcc 时、引导加载程序不会跳转到主应用程序
在此"不工作"版本中、我使用。 InitBoot 部分、如"f28069_flash_kernel"示例中。 在此版本中、我可以从 Main 返回地址(我希望在后面跳转)、Exitboot 将处理其余地址。
我有一个正在工作的版本、在其中我对主应用程序启动的地址执行简单的"Longbranch"。 这种 nö 每次都能正常工作、我遇到了很多问题。 但我认为、TI 在其引导加载程序中执行所有这些 Stack 去初始化操作必须有一个原因。

但是、如果您告诉我、手动跳转到主应用程序绝对是可以的、因为_c_init 会以任何方式重新初始化、我将使用此工作解决方案。

感谢你的帮助