[参考译文] RTOS/TM4C129XNCZAD：BOOT_EMAC_FLASH 失效防护

尊敬的 Peter：

[引用用户="Peter Borenstein"]

是否有一个 BOOT_EMAC_FLASH 版本、允许在尝试下载新映像时出错后恢复到当前(较旧)固件？

如果没有、是否有类似的引导加载程序选项可实现此目的？

如果两者都不能、如何 更改 BOOT_EMAC_FLASH 以获得此功能？

如果以太网固件更新失败、我需要能够恢复到当前映像。 当 新应用程序映像到达时、BOOT_EMAC_FLASH 似乎会擦除当前应用程序代码。 下载中途出现故障会导致无法恢复、因为当前映像的一半已被擦除。

[/报价]

否、没有这样的引导加载程序版本会恢复到当前映像。 一旦您开始更新、闪存中的当前映像将首先被擦除。  

在 TivaWare 示例中、应用程序将调用引导加载程序(BOOT_EMAC_FLASH)中的更新例程以启动新的更新。 您可以尝试在引导加载程序中构建一些智能、例如、在成功更新结束时、将唯一的密钥(即0x12345678)写入闪存中的预定义地址。  如果更新在中间失败、则该唯一的密钥位置仍将处于已擦除状态。 引导加载程序不仅会检查新应用程序是否具有有效的堆栈指针和复位矢量、还会检查该唯一的密钥位置。 如果未写入唯一的密钥位置、引导加载程序将再次强制更新映像 A。我认为在 BOOTP 数据包请求中、您可以指定相应的 bin 文件名。 请参阅 BootP 消息格式中的引导文件名字段。 但是，我认为您需要使用 BootP 服务器来解码引导文件名字段，以便 BOOTP 服务器知道要更新的应用程序映像。 我认为 LM 闪存编程器今天不支持这一点。  

[引用用户="Peter Borenstein"]

我知道引导加载程序具有2个映像。 存储器分为两半、较新的映像下载到不同的存储器区域、而不删除当前映像。 双映像设置是否比下载一个映像比下载另一个映像更安全？ 在此配置中、映像 A 最好下载映像 B、还是让引导加载程序下载映像 B？

[/报价]

TivaWare 应用示例将控制权转移到引导加载程序以更新新映像。 应用程序不会自行直接下载新映像。 我建议您按照 TivaWare 示例进行操作。  

[引用 user="Peter Borenstein]TivaWare 中的应用代码将接收 LM 闪存编程器在 swupdate.c 中发送的"魔术包" 此示例代码使用 lwIP。 是否有使用 TI NDK 的 TivaWare 代码？[/QUERP]

不可以、TivaWare 示例不使用 NDK。  

[引用用户="Charles Tsaaa"]然后引导加载程序将再次强制更新映像 A[/quot]

这是我试图避免的一个陷阱。

定义 enforce_crc 的效果与您的主要想法类似。 为了确保新映像完全成功下载、计算 出的 CRC 将与 矢量表后面的预计算值进行比较。

如果与 BootP 服务器的连接丢失、则密钥丢失或 CRC 损坏都会导致器件成为砖型器件。

您的意思是、该器件会被欺骗？ 引导加载程序将一直发送 BOOTP 请求，直到 BOOTP 服务器恢复。 如果 BOOTP 服务器永久停机，则我同意客户端只会无限期地发送 BOOTP 请求，而不会执行任何操作。 如果您担心这一点、则需要以某种方式将原始固件映像保存在不会擦除的闪存部分。 希望固件映像大小小于总闪存大小的一半。 如果您的 FW 映像大于总闪存的一半、则您可以选择先保存到外部存储器。

在您研究固件的恢复选项时、我建议您对 BootP 服务器执行同样的操作。 为什么它会处于不可恢复的状态、以及如何防止这种情况？