[参考译文] TMS320F28379S：将 SCIBOOT 模式更改为使用备用 IO

尊敬的 Andy：

谢谢！ 好的、您可以考虑以下想法。

1.为 SCI 引导配置目标
2.通过 SCI 将应用程序编程到闪存中
3、编程完成后、跳到 Flash 中应用程序的入口点、启动应用程序。

您可以考虑开发一个简单的监控程序、该程序会提出一些简单的问题。
启动时、监护仪会等待预定的用户输入时间(例如5秒)
以查看是否有在闪存中进行应用更新的请求。 如果是、则更新闪存
并启动应用程序。

如果答案为“否”或没有响应，则显示器只会启动现有应用程序
如果闪存中有一个编程的闪存。 如果闪存中没有应用程序、它将继续在监视器中等待。
这是一个执行非常简单任务的非常简单的监视器。

您可以考虑为您的设计提供其他想法。 例如、5秒启动延迟可能是不可接受的
系统的所有组件。 在这种情况下、一旦将应用程序编程到闪存中、您只需启动应用程序
立即启动。 如果选择此选项、则如何在以后更新闪存？ 地址
将来更新时、应用程序将需要通过某种方式支持接受用户命令以返回
因为有一个挂起的闪存更新。

另外请记住、在对闪存进行编程时、必须以与您相同的方式设计方法
切勿“砖头”:-)目标/产品。 这意味着、执行闪存更新时出错不应导致
目标/产品中的永久性故障。 您应该始终能够恢复。

那么、让我们稍微定义一下潜在的问题。 我们假设您的应用无法承受5秒的延迟
启动时、您决定显示器将在启动时立即启动应用程序。
您设计了应用程序中的必要挂钩、以便它知道如何返回监视器来执行
未来可能进行的闪存更新。 将来的某个时候、您会使用此方法并执行闪存更新。
除了这一次、编程期间会出现某种问题(电源干扰或其他问题)、
在更新过程中、闪存更新失败。 编程会停止、您认为编程已经完成
更新。 重启目标电源后、应用程序会立即启动、但会丢失部件
执行。 您无法命令应用程序返回到监视器，因为
应用程序不再按设计工作。

我将留给您思考如何从这类问题中恢复的方法。

我希望这种反馈足以激发人们对如何进行系统设计的思考。
请随时询问您是否需要进一步的帮助。

谢谢！
Krishna