[参考译文] TMS320F28377S：在不使用引导模式引脚的情况下进行串行固件更新。

尊敬的 Asad：

这是您可在 CAN 范围内为此器件实施的一个可行解决方案。 我将首先介绍我们当前针对 CAN 的解决方案、您可以在 C2000微控制器的 CAN 闪存编程 应用手册中查看该解决方案并对其进行修改以进行固件更新。

需要考虑的一些因素：

-如果板是分开的,是否每个有自己的 CAN 收发器? 如果没有、您是否需要实施它们？

- 如果你不需要执行它们? 另外、如果您有 Visual Studio 许可证、则可以修改该器件的现有闪存内核。 我们使用 PEAK API 来处理 CAN 消息。  

谢谢。此致、

Charles

尊敬的 Charles Roberson：

非常感谢您的指导。

关于您的问题：是的、这些电路板是单独的、每个电路板都有自己的 CAN 收发器。 我们对使闪存内核成为固件更新的一部分有一个担忧。 我们假设出现以下两种情况：

1. 新的固件更新包含闪存内核代码中的错误。
2. 固件更新中断、例如、由于电源故障。

在这些情况下、电路板不再能够通过串行固件更新进行更新。 您是否有任何降低此类风险的建议？ 我当时正在考虑将闪存内核存储在其中一个闪存扇区并对该扇区进行写保护的方法。 在这种情况下、我们可以先使用闪存内核对电路板进行编程、然后仅发送应用更新。

在这方面：

1. 您是否同意这将是一种可行的方法？
2. 您预计此方法会带来哪些挑战？ 是否需要修改链接器文件来将应用程序重新定位到闪存中的不同偏移量？ 是否需要重新映射中断矢量表？
3. 是否可以从闪存应用程序调用 ROM 引导加载程序代码？ 如果可能的话、这可以大大简化整个过程、并且我们可以使用标准实现。
4. 如果我们为 CAN 引导模式设置引导模式引脚、以便器件始终以 CAN 引导模式启动、该怎么办？ 应用程序的软件复位会在 CAN 引导模式下调用器件吗？  那么、在需要从闪存正常执行的情况下、是否有可能从 CAN 引导模式跳转到闪存执行？  

其理念是以最少的开发工作量实现最可靠的实施。 再次感谢您的支持、我期待您对这种方法的看法。

尊敬的 Charles Roberson：

非常感谢您的指导。

关于您的问题：是的、这些电路板是单独的、每个电路板都有自己的 CAN 收发器。 我们对使闪存内核成为固件更新的一部分有一个担忧。 我们假设出现以下两种情况：

1. 新的固件更新包含闪存内核代码中的错误。
2. 固件更新中断、例如、由于电源故障。

在这些情况下、电路板不再能够通过串行固件更新进行更新。 您是否有任何降低此类风险的建议？ 我当时正在考虑将闪存内核存储在其中一个闪存扇区并对该扇区进行写保护的方法。 在这种情况下、我们可以先使用闪存内核对电路板进行编程、然后仅发送应用更新。

在这方面：

1. 您是否同意这将是一种可行的方法？
2. 您预计此方法会带来哪些挑战？ 是否需要修改链接器文件来将应用程序重新定位到闪存中的不同偏移量？ 是否需要重新映射中断矢量表？
3. 是否可以从闪存应用程序调用 ROM 引导加载程序代码？ 如果可能的话、这可以大大简化整个过程、并且我们可以使用标准实现。
4. 如果我们为 CAN 引导模式设置引导模式引脚、以便器件始终以 CAN 引导模式启动、该怎么办？ 那么、在需要从闪存正常执行的情况下、是否有可能从 CAN 引导模式跳转到闪存执行？ ROM 引导加载程序是否支持从闪存执行的命令？

其理念是以最少的开发工作量实现最可靠的实施。 再次感谢您的支持、我期待您对这种方法的看法。

最新动态：  我曾浏览过 e2e 论坛、并浏览过软件控制的固件更新文档。 这似乎是解决我们问题的可行办法。 唯一的问题仍然是固件过程因任何原因中断。 在这种情况下、器件将始终以闪存模式引导、可能无法将其置于引导模式。 第4点仍然是个问题。