[参考译文] TMS570LS0914：CAN 引导加载程序更新程序

尊敬的 Alberto、

我们已开始处理您的问题、并将很快提供更新。

--

谢谢。此致、
Jagadish。

很抱歉耽误你的时间、我将把该线程转给专家。

尊敬的 Alberto、

要更新引导加载程序、您需要擦除分配给引导加载程序的第一个闪存扇区。 应用程序固件会下载引导加载程序、并将 F021闪存 API 相关代码复制到 SRAM、并使用 SRAM 中的闪存 API 将引导加载程序代码编程到已擦除的扇区中。

很抱歉、我们没有引导加载程序本身更新的示例。

您好 QJ Wang：

感谢您的回答。 请问您、我已经使用 TI FEE API 在应用程序固件的闪存中写入数据、这是否能够为引导加载程序扇区布线？

我还想知道、引导加载程序的扇区是什么？ 说应从地址0x0000开始擦除存储器是正确的吗 ？ 应用程序状态地址为0x40000、我如何知道需要擦除多少个扇区？

谢谢！  

尊敬的 Alberto、

正确地说内存应从地址0x0000开始擦除吗?

正确。 引导加载程序位于从0x00000000开始的前几个扇区中。

如何知道我需要擦除多少个扇区?

Fapi_BlockErase (0x00000000、引导加载程序的大小)；

下载引导加载程序时、驱动程序将计算大小。 您可以检查项目调试文件夹中引导加载程序映射文件的大小。

谢谢 QJ、

我会尝试的。如果在我的应用固件中已经在 HALcogen 中配置了 TI FEE、那么我应该不需要重新配置闪存2021 API 了。  

1.您需要将闪存 API 复制到 SRAM 并从 SRAM 执行它们、因为您的应用程序固件和引导加载程序位于同一个闪存组中。  

2.应启用闪存存储体。 引导加载程序和应用程序位于 BANK0中、但 EEPROM 为组7。

3.引导加载程序应启用闪存扇区，请参阅 Fapi_Init (..) 在我们的引导加载程序示例中、

您好、QJ：  

我正在修改引导加载程序固件、以将其用作应用固件来更新引导加载程序；这应该会使从特定应用更新引导加载程序变得简单直接。 到目前为止、我更改了：

APP_START_ADDRESS 以匹配0x00000

将 APP_STATUS_ADDRESS 设置为0x30000 (在引导加载程序中、由于我在引导加载程序中使用 TI_FEE API、因此我必须进一步移动它(在引导加载程序中实际上运行良好)。  

是这样吗？ 这样、如果我将作为地址发送、以便在何处启动闪存过程0x00、我将收到错误。

我不明白我在示例中发现的这种情况：

1)为什么声明"ENABLE_BL_UPDATE"标志、条件是检查地址是否不同于0x00？ 我应该从0开始刷写引导加载程序。 能否解释一下、这是否已纠正或者它是否存在错误？

2)我是否需要声明此标志才能成功？

3)为 APP_STATUS_ADDRESS 使用不同的地址以避免两者混合是正确的吗?

4)是否需要修改 bl_link.cmd，而不是从地址0x40020启动程序？

请告诉我、谢谢

我的引导加载程序示例不支持自动更新机制。 只有更改应用程序起始地址、更新才起作用。

引导加载程序位于闪存中、默认情况下从闪存执行。 要自行更新、意味着引导加载程序必须调用闪存 API 来擦除自身使用的闪存扇区。  

若要更新自身、必须将整个引导加载程序复制到 SRAM 并从 SRAM 执行。  

可能会从引导加载程序本身或从应用程序更新引导加载程序。 如果更新失败、MCU 将无法正常引导。  

您好！

别误会我的意思、我的想法是不要从引导加载程序本身更新引导加载程序。

我的想法是闪存一个包含与引导加载程序相同代码的应用程序固件。 当实际的引导加载程序在闪存完成后跳转到应用程序时，想法是应用程序(包含与引导加载程序相同的代码)将从此处更新真正的引导加载程序。 为此、应用程序需要将 APP_START_ADDRESS 指向0x00、以便刷写过程将考虑从地址0开始擦除和刷写新的引导加载程序。

简单来说、之前的一些答案告诉我、应用程序需要在 SRAM 中加载闪存 API 才能实现这一点、我认为使用与实际引导加载程序相同的代码应该可以正确完成任务？

如果不是、您建议如何更新引导加载程序？ 您是说、每次我需要更新时、我都需要通过 JTAG 访问编程吗？ 因为在商业程序中这将是非常困难的。

关于另一个问题、您能否澄清答案？ 非常感谢

此外、我知道从应用程序更新引导加载程序可能存在风险、但有一点是、在该 CA 中、您需要使用 JTAG。 如果 没有办法更新引导加载程序、那么在任何情况下我都需要使用 JTAG