[参考译文] TM4C123GH6PM：引导加载程序问题

Mathias、
我们采取类似的措施、并采取以下策略：
-主应用程序中有一个“更新 API”。 当它通过 UART 接收到更新消息时、它会将新代码存储在单独的存储器位置。 如果所有软件包都正确到达、如果在 EEPROM 上设置了一个标志、那么我们自己的引导加载程序就知道有新的可用固件。
-然后电路板被复位、引导加载程序将新存储的代码复制到闪存中的默认运行位置-在将旧代码的备份到其他位置之后。
-引导加载程序尽可能小、驻留在与主应用程序分开的0x00位置。 在"正常情况"下、它开始运行、验证存储器中没有更新、并将代码执行转移到主应用程序的开头。
作为"更新 API"的一部分、有一个看门狗-如果新代码未正确地为狗馈送、引导加载程序下次运行时将恢复以前的固件、以避免永久欺骗。
-我们使用的端口不是仅用于更新，而是作为应用程序的“正常通信通道”之一的 IT 服务器-更新消息必须遵循特定的协议，以便将它们识别为这样的协议。
-由于更新传输实际上发生在主应用程序中，因此可以使用与 MCU 的任何连接(UART、SPI、蓝牙、以太网等)。
-有一个小型外部程序用于将.bin 发送到由此类协议封装的 MCU -我们在 Windows 或 Android 中使用此类程序。
话虽如此，说起来比做起来容易得多，但它应属于您所描述的"任何提示"类别。
谢谢
布鲁诺