[参考译文] TMS320F28377S：使用 CAN 接口进行固件更新。

尊敬的 Asad：

相关应用手册： C2000微控制器的 CAN 闪存编程

1) 1)我们目前提供了适用于 F28003x、F280015x 和 F28P65x 器件的示例。 您需要进行的主要更改是为该器件创建 DCAN 闪存内核(可以以 SCI 闪存内核为基础、并以 F28003x DCAN 闪存内核为基础以获取必要的函数)、并使用为 F28377S 器件提供的闪存 API 库。

2) 主机应用程序可用于 F28377S 器件、但可能需要针对用户器件输入(F28377x 而不是 F28003x)和器件睡眠时间变量(F28377S 闪存 API 将 DCAN 闪存内核收集的数据写入闪存所需的时间、以 ms 为单位)进行修改。

谢谢。此致、
Charles

感谢 Charles Roberson 的指导。 关于第1点、我有个问题：建议针对28377S 修改28003x 的 DCAN 闪存内核工程、还是使用 CAN 函数修改 TMS320F28377S 的 SCI 闪存内核工程？

我建议使用 CAN 函数修改 TMS320F28377S 的 SCI 闪存内核工程、因为它已具备特定于该器件的库。  

谢谢！

Charles

我们希望在调查和实施 CAN 固件更新流程时确认一些要点。
1 -我们有一个 TMS320F2837x LaunchPad。 我们想使用该板测试 CAN 固件更新、但似乎无法实现、因为 CAN 引导需要针对 CAN RX/TX 使用 GPIO70/71或 GPIO62/63。 请确认这是正确的理解还是存在其他一些可能性？
2 - 要从 CAN 引导、需要为 Get/闪存模式设置引导模式引脚？  
3 -如果是 CAN BOOT0、则 BMODE 值需要为0x07、如果是 CAN BOOT1、则需要0x87。 我们在这方面有一个问题。 如果我们将 OTP 配置为 BMODE 以便可以完成、那么在更新固件后如何从闪存引导？ 器件复位时、它是否不会始终跳转到 CAN 引导？ 它需要 CAN 接口上的任一命令从闪存引导吗？ 如果是这种情况、那么是否意味着 DSP 永远不会以独立模式引导至闪存(需要从另一个器件的 CAN 接口上的一些命令从 FLAH 引导)？

尊敬的 Asad：

1.正确。 LaunchPad 上的 CAN 收发器连接到 GPIO 12和17、这不是 CAN 引导使用的组合之一、

2.是的、您必须修改 BOOTCTRL 寄存器才能让器件进入能够引导。 出于测试目的、您可以使用仿真引导模式而不是修改 OTP。

3.请查看 此主题、我相信它可以解答您的问题。

此致、

Skyler

Skyler Baumer: 非常感谢您的回答。 如果 BMODE 设置为从 CAN 引导、我仍然无法理解从闪存引导的过程。 我已经完成了您提到的主题、但找不到答案。 如果您能详细解释、我将不胜感激。

Charles Roberson : 我们 修改了 F2837xS_sci_flash_kernel 项目,并进行了如下修改,将其转换为 CAN 闪存内核:

1- 将"C：\ti\C2000Ware_5_02_00_00\libraries\boot_rom\f2837xs+ RevB\rom_sources\F2837x_bootROM\cpu01-bootROM\source"中的 DCAN_Boot.c 文件复制到中     工程、因为它包含 CAN 和 API 从 CAN 读取数据所需的初始化。 但是、进行了以下两处修改：
 i -注释掉以下代码部分：

//	entryAddr = TI_OTP_C1BROM_ESCAPE_POINT_9;
//	if((entryAddr != 0xFFFFFFFF) &&
//		   (entryAddr != 0x00000000))
//	{
//	   /*if OTP is programmed, then call OTP function*/
//	   ((void (*)(void))entryAddr)();
//	}
//
//	//Send two test frames if the OTP says so
//	if (bootMode & DCAN_BOOT_SENDTEST)
//	{
//		DCAN_SendWordData(0x0320);
//		DCAN_SendWordData(0x2837);
//	}

之所以这样、是因为 T1_OTP_C1BROM_Escape _POINT_9无法解析、我们认为可能不需要解析。 请提供建议。

II-以下宏被定义为编译器无法解析 DcanaRegs：  

#define DcanaRegs CanaRegs

2-  在 main()函数中、对 SCI_GetFunction()的调用被对 DCAN_Boot()的调用所取代。  

3-  以下两个文件特定于 SCI 接口、因此从工程中排除。

  i- SCI_Boot.c

  II- SCI_GetFunction.c

附加了项目文件夹以供审核。 如果您或任何其他 TI 专家能够检查它并让我们抢先了解可以在 kernel.e2e.ti.com/.../F2837xS_5F00_can_5F00_flash_5F00_kernel.rar 中发布的内容、我们将不胜感激

尊敬的 Asad：

如果您计划使用 CAN 引导、您可以修改 BOOTCTRL 寄存器以允许这一点、但闪存引导不再可用。 如果要保留引导至闪存的选项、可以编写存储在闪存中的自定义引导加载程序。 因此、当您将引导模式选择引脚设置为引导至闪存时、您可以让它运行设置 CAN 引导的自定义引导加载程序。 您可以在此自定义引导加载程序中添加一些逻辑、以对新接收到的 CAN 数据进行编程/执行、或引导至存储在闪存另一个位置的应用程序。 无论哪种方法、都必须使 GPIO72 == GPIO 84 == 1。

此致、

Skyler

尊敬的 Skyler Baumer：

 很抱歉、我可能没有清楚说明这一问题。 让我再详细地重新表述一下：

• 我们的应用程序将驻留在闪存中、在正常操作期间、我们可以让 DSP 在电源复位时执行此应用程序。
• 我们具有另一个片上系统 (SOC)、可通过 CAN 接口与 DSP 进行通信。 该单板计算机将可以访问互联网、并可在需要时下载用于 DSP 的新应用。
• 此 SOC 具有与 DSP 的 CAN 接口、因此我们希望使用 CAN 接口将新应用传输到 DSP 闪存。 一旦新应用程序被写入闪存、DSP 就应该能够从闪存执行它。

在我们的旧设计中、我们有带有 DSP 的 SCI 接口。 在这种情况下、当需要传输新应用时、我们只调用 SCI 引导加载程序(为 SCI 选择引导模式引脚)。 将新应用程序写入闪存(通过闪存内核)后、我们再次将引导模式更改为闪存(并复位 DSP)、以便它 执行新的应用程序。 SCI 引导加载程序非常可靠、驻留在 ROM 中、因此、如果编写了任何不良的应用程序或过程在完成前中断、我们始终可以恢复系统。 我们期望 CAN 固件更新是相似的。  

如果我们在闪存中编写自定义引导加载程序、则会存在以下两个缺点：

1 -如果引导加载程序因任何原因而被擦除或存在一些错误、则如果不再次手动刷写、可能无法写入新的应用程序。
2-在发货前将自定义引导加载程序上传到每个 DSP 会向汇编行中添加另一个手动过程。

我需要指出的一个基本要点是：如果我们可以 通过 ROM 在闪存中对应用程序重新编程、驻留在 ROM 中的 CAN 引导加载程序的实际实用程序是什么  但 随后将无法执行该应用 ？