Thread 中讨论的其他器件：C2000WARE
工具与软件：
你好。
我不熟悉 TI 微控制器、包括我正在使用的 TMS320F28P659。 我希望实现驻留在闪存中的引导加载程序。 我的理解是、在这个 MCU 上、引导加载程序可以从组0中的闪存执行、同时擦除和重新编程不同的闪存组。
我们的应用程序将通过 SCI 端口 A 从固件更新程序接收到一条串行命令、以使 MCU 复位、然后直接在闪存引导模式下调用引导加载程序。 硬件存在一个问题、因为硬件已经过硬接线、所以引导加载程序无法读取默认 SCI 引导引脚来知道它应该采用哪种模式引导、这就是它会直接引导至闪存引导模式的原因。 我们仅使用 CPU1、因此我不必将其纳入引导加载程序。 内部引导加载程序将启动从闪存运行的引导加载程序、它将验证闪存中的应用并从闪存执行该应用、或者接收到的引导加载程序将接收到启动固件更新的命令、此时它将跳转到从闪存组0中的闪存执行的闪存内核。
我们使用的器件上有5个闪存组被分配给 CPU1 (0-4)。 我想使用组0来包含引导加载程序代码。 组1将被分配给该应用程序。 到目前为止、该应用程序只适合一个存储体。
在我们的设置中、正常的引导过程是引导至从组1中的闪存运行的应用程序。 启动固件更新的唯一方法是通过闪存更新程序中的 SCI A 端口发出命令。 必须有一种方法可以确定引导是通过上电复位还是通过命令式重启来进入引导加载程序、以便执行闪存内核来进行固件更新。 此部分已被阻止、因为似乎不存在热启动标志可以存储在其中的寄存器或 NVM、引导加载程序可以读取此标志来指示它需要将闪存内核加载到 RAM 中并跳转到该 RAM。
要从应用程序重新启动 MCU、有多种可能：
1.软件复位-看起来相当于参考手册中的上电复位(通过 SIMRESET 寄存器)。
2.设置看门狗计时器,让其在短时间间隔后过期。
3. NMI 看门狗复位。 如果其他一些模块导致出现此问题、使用此功能不是一个好主意。
=
在上述两种情况下、原因的状态1和2都可以从寄存器中读取、但我需要一种方法来明确告知固件更新已重新启动。
我也不确定内部 bootrom 或其它启动代码是否完全清除了 RAM。 如果不是、我可以调整堆栈指针、使小 RAM 块未清除、以进行重新启动标志。
我目前在查看 C2000软件(C：\ti\c2000\C2000Ware_5_01_00_00\driverlib\f28p65x\examples\c28x_dual\flash_kernel)中的 flash_kernel 示例、但仅从 RAM 运行。 我需要一个在闪存中运行并从闪存执行 flash_kernel 的 bootrom 的有效示例。
到目前为止、我还没有找到针对我所使用的 MCU 的所有内容。
如果有任何帮助、将不胜感激。
此致、
Joel Estes
