[参考译文] TMS320F280039：需要一些有关定制 LFU 的建议

请注意、由于美国假期、大部分团队都是 OOO。  请在下周回复。

挂起、

1.对于版本、由于擦除的闪存为 FFFF、通常我们使用递减法。 但是、这仅用于说明目的。 客户实际上必须决定版本控制方案并使用它。 为什么 cmd 文件需要根据版本进行更改？ 我同意他们需要为不同的存储体具有单独的 cmd 文件。

2.在我们的 LFU 示例中、在主机发出 LFU 命令时、执行将从应用切换到引导加载程序。 但是、中断仍然启用。 这意味着每当发生中断时、都会执行应用中的 ISR。 在空闲期间、执行回退到引导加载程序。 这与您在上面所描述的内容是一致的。 ISR 上下文保存由 C 编译程序在软件中完成、因此用户无需在此采取任何特殊步骤。 (除非用户编写了一些汇编代码 ISR、在这种情况下、他们需要按照必要的运行环境保存和恢复步骤操作)。

我们的 LFU 示例不能解决的部分是您提到的"引导加载程序错误"。 因此、我们的闪存中只有一个引导加载程序。 我想了解在什么上下文下可能会出现引导加载程序错误、之后您需要返回到应用 我可以了解引导加载程序升级过程中出现错误的可能性、因此需要备份/默认设置。 只要引导加载程序升级和应用程序升级是单独完成的、我就不会看到问题。

谢谢！

SIRA

尊敬的 Sira：

为了阐明它们的用例：

为什么 cmd 文件需要根据版本进行更改？

->例如、该器件目前在组0上有引导加载程序、在组1上有应用 v1.0、在组2上有应用 v1.1。 此时、他们希望将 app v1.2建立在 app v1.1之上。 请注意、应用 v1.2应到达 bank1、覆盖 app1.0、因为如果 LFU 到 app1.2失败、例如、由于连接丢失、app1.0将损坏、器件应将 app1.1作为备份运行。 由于 app1.2是根据 app1.1被修改的、因此它使用 bank2 cmd、并且它们需要更改为 bank1 cmd。 从 app1.2制作 app1.3时会发生相同的过程。  

ISR 上下文保存由 C 编译程序在软件中完成、因此用户无需在此采取任何特殊步骤

-> 我同意,用户不需要担心 ISR 的上下文保存,但应用背景如何?  如果应用 使用 LB 指令切换到引导加载程序、则在引导加载程序完成任务后、引导加载程序应该如何切换回应用、但让应用在 LB 指令后立即执行行而不是从应用条目中执行这一行？

 "引导加载程序错误"

->请客户提供此详细信息  

此致、

挂起。

挂起、

是的、备用版本将使用备用链接器 cmd 文件、这是理解的。 但是、"确切版本名称"和链接器 cmd 文件之间没有额外关系。 只要使用链接器 cmd 文件维护替代版本控制关系、就没有问题。

是的、您将使用 LB 从应用分支到引导加载程序、同样、您将使用 LB 从引导加载程序分支到新应用(LFU 入口点)。 TIDM-02011中详细说明了这一点。

谢谢！

SIRA

尊敬的 Sira：

从应用程序分支到引导加载程序后、在某些情况下(__LW_AT__例如、新应用程序未完全下载）它们需要分支回同一个应用程序、并在分支到应用程序之前继续上一个作业。 为了实现这一目标、他们需要设计某种上下文保存、以便当引导加载程序分支到应用时、它会分支到应用程序在分支到引导加载程序之前运行的位置。而不是分支到应用程序条目、对吗？ 希望避免设计这种上下文保存机制。

此致、

挂起。

挂起、

在这种情况下、您可以使用 LCR 指令而不是 LB 指令、并返回 LRETR 指令。 这将导致它从分支的位置返回到相同的位置。 您可以参考 spru430f。

谢谢！

SIRA

尊敬的 Hang：

TI 链接器具有集成的预处理器、如果版本传递给链接器、则可以使用它来根据版本更改应用程序的起始地址。 或者、您可以为两个组构建固件(具有两个链接器脚本)。 这样、您就可以为每个固件版本使用每个组。 您必须实施某种协议、以选择最旧版本的存储体。

对于您的第二个问题：如果您在应用程序本身中实施新固件的上传和存储、会怎么样？ 上载第二个组后、可以检查上传的映像、然后可以通过调用引导加载程序来重新启动应用程序。

如果确实需要保存固件的上下文、则还必须将一个版本固件的上下文传输到新版本的固件。 如果不需要这样做、那么我就看不到、为什么在极少数情况下需要这样做、那就是固件上传失败。

如果您确实想保存 固件的状态、并将其加载到另一版本的固件中、则应考虑采用某种受版本控制的 RAM 数据库来适应固件状态。

此致、

Torsten