[参考译文] TMS320F28379D：引导模式混乱

好的、让我改回这句话、以确保我理解正确：

1) 1)由于 ROM 引导加载程序将在 SCI RX 上等待"A"、因此我的主机可以驱动 GPIO84、直到主机准备好传输"A"。

2) 2)我的主机释放 GPIO84并将其 I/O 引脚配置为 UART 输入引脚。

3) 3)我的主机随后在 GPIO85上传输'A'

4) 4) ROM 引导加载程序执行波特率检测、将 GPIO84作为 SCI TX 输入、并开始处理臂架引导数据结构、通过 SCI TX 回传每个字节。

好的、那么 SCI 引导模式没有引脚冲突

有关 CAN 引导模式的几个相关问题：

a) SCI 引导模式具有额外的波特率检测字符"A"、ROM 引导加载程序块等待该字符。 我假设 CAN 引导模式不需要速率检测、因此它只是等待邮箱1中的第一条 CAN 消息、该消息应为0x08AA。 对吧？

b) ROM 引导加载程序是否有任何形式的确认、或者我们是否认为 CAN 总线是可靠的？

c)在任何基于器件的引导模式(SCI、CAN、..)中、对于"引导至闪存"、闪存入口点的地址将用作引导数据流结构中的"入口地址"、并且第一个数据块的大小将为0。

d)为了更新闪存、我将使用 RAM 入口点作为"入口地址"、数据块将包含基于 RAM 的闪存内核

e)我们将在 CAN 总线上有多个 Delfino。 如果我们使用 CAN 引导模式、似乎所有人都必须在锁定步骤中引导、因为他们都使用相同的 CAN 邮箱编号。 要么全部引导至闪存、要么全部加载基于 RAM 的闪存内核。 不同芯片在准备好接受第一条 CAN 消息(0x08AA)之前的时间变化有多大？ 任何变化似乎都是一个时间窗口、让事物不同步。

Mike

尊敬的 Mike：

感谢您的回答。

实际上、该过程可能比您描述的过程更简单、因为主机系统实际上不应"驱动"其自己的 RX 线(C2000的 TX)。

作为引导模式引脚配置的一部分、主机的 SCIRX 应配置为上拉电阻。 或者、您可以像上一个帖子中提到的那样"驱动"引脚、但是、一旦退出复位且 C2000正在等待"A"、您就必须确保停止驱动引脚。 因此、我建议将您的主机 RX 配置为上拉电阻器。 然后、该过程仅为：

1) 1)主机复位 C2000

2) 2)主机发送"A"

3) 3)此处的引导加载程序过程

有关相关的 CAN 引导问题：

a)正确

b)假设 CAN 总线可靠

C) 如果您将“引导至闪存”作为引导选项，则它是与其他引导模式完全不同的引导模式(假设我正确理解了您的问题)。 另外、请参阅 TRM 中表4-28 (8位数据流中的 LSB/MSB 加载序列)中的以下信息、其中讨论了0块大小表示的含义：

“块大小，以要加载的第一个块的字为单位。 如果块大小为0、则表示源程序结束。 否则后面会跟随另一个块。 例如，块大小为0x000A 表示块中有10个字或20个字节”

d)正确、然后您可以通过这个新加载的内核将代码加载到闪存中。

e)我将在本周结束前向您提供有关此内容的更新。

此致、

Vince

尊敬的 Mike：

下面是在 CAN 总线上的多个 C2000器件上加载基于 RAM 的闪存内核的后续操作(问题"e")：

器件之间的时序差异并不是此类设置的真正问题、因为它们将全部完成引导过程、2)开始等待第一条 CAN 消息。 然后、您可以开始将内核加载到总线上器件的 RAM 中。 将内核传输到 C2000器件时、CAN 通信的相对时序不会成为问题。

问题是、内核加载过程中这些节点的 ACK 响应都将同时发生(因为它们将具有相同的消息 ID)。 由于所有这些都同时发生、如果同时发生一个 ACK、任何 NACK 基本上都将"淹没"、您将无法直接知道是否有任何设备发生内核加载故障。

由于这种情况、我建议您在自定义内核中加载到这些器件的 RAM 中、让所有节点立即回复它们是否成功加载了内核。 为此、请使用唯一的 ID 对每个器件进行响应。

您可以在电路板上通过 GPIO 和 DIP 开关实现唯一 ID、并在中读取这些 ID 并将其传递给其他人、但由于您提到引脚上的限制、因此我将改用"UID_REGs"中的"UID_UNIQUE "寄存器。 基本上、在内核加载到器件上后立即传输该值、并在主机上侦听该值。 如果您知道从那里启动的 UUID、则可以判断哪些 UUID 无法加载内核。

请告诉我这是否可以解决问题。

此致、

Vince