[参考译文] TM4C1294NCPDT：用于以太网引导加载程序的 CRC32

嘿、Charles、

感谢你的答复。 您提到的两个帖子大多回答了我的问题。 我唯一需要添加/要求添加的内容是关于矢量表偏移量。

正如 Peter 提到的、我们可以通过更改矢量表在相关源文件中定义的值来更改矢量表的偏移量。 尽管在不使用 binpack 工具上的-d 选项的情况下、矢量表会保持在同一地址(就像完全不使用 binpack 来处理.bin 文件一样)。 我在使用-d 选项时唯一可以看到的是它添加到二进制文件的标头、其模式为0x01 0x00 + APP_START_ADDREST/1024、并将其他所有内容向右移动。

1)那么、我关于这个(额外)标头的第一个问题是：如果标记(0xFF01FF02 & 0xFF01FF02)被放置在矢量表的末尾、为什么我们甚至需要这个标头？ bin 文件顶部的这个额外标头意味着什么？ 文档显示"向输出图像添加简单的下载标题"。 这意味着什么、我们为什么需要此下载标题？ 在引导加载程序和/或应用程序的哪个部分使用此标头？ (尚未经过测试、将在周一进行测试)

2) 2)我的第二个问题是关于矢量表偏移量的问题。 在 Amit 的帖子中、有人提到、在标记( 0xFF01FF02 & 0xFF01FF02)之后、我们应该添加4个保留字 0xFFFFFFFF。 binpack 工具文档中也提到了这一点。  在标记之后四次添加0xFFFFFFFF 是否有具体原因？ 从生成的二进制文件中、我可以看到它们将在矢量表的末尾添加这些额外的 FF。  (尚未经过测试、将在周一进行测试)

基于 此 链接、它说"... 某些下载工具使用此标头(0x01 0x00 + APP_START_ADDRESD/1024)..."。 因此、我认为由于我的下载工具未使用此标题、因此无需使用它(我认为这可能会回答上面的问题1、但也希望让它完全确定)。

仅供您参考、我不使用 LM 闪存编程器。 我在 Python 中编写了自己的工具来更新电路板、它基本上是读取 bin 文件并通过以太网和使用用于 TFTP 的 UDP 套接字来更新电路板(我删除了 BOOTP、因为我的项目的性质不需要它)。

再次感谢您的帮助！ 将在星期一24时返回一些结果。

您好！

 [引用 USER="Mpekatsa]1)那么、我关于这个(额外)标头的第一个问题是：如果标记(0xFF01FF02 & 0xFF01FF02)被放置在矢量表的末尾、为什么我们甚至需要这个标头？ bin 文件顶部的这个额外标头意味着什么？ 文档显示"向输出图像添加简单的下载标题"。 这意味着什么、我们为什么需要此下载标题？ 在引导加载程序和/或应用程序的哪个部分使用此标头？ (尚未经过测试、将在周一进行测试)

我不知道。 我最想的是、一些工具(例如、dfuwrap)将此页眉插入到矢量表末尾已插入的标记的顶部。 binpack 工具具有以下说明。

要添加此标头，请使用“-d”命令行调用 binpack
选项。 使用的标头结构与 dfuwrrap 实用程序添加的结构完全相同。 。
前半字包含固定值0x0001、后半字包含图像闪存
地址表示为千字节(地址/1024)、剩余的4个字节为
二进制映像的大小、不包括标头。

2)我的第二个问题是有关矢量表偏移量的问题。 在 Amit 的帖子中、有人提到、在标记( 0xFF01FF02 & 0xFF01FF02)之后、我们应该添加4个保留字 0xFFFFFFFF。 binpack 工具文档中也提到了这一点。  在标记之后四次添加0xFFFFFFFF 是否有具体原因？ 从生成的二进制文件中、我可以看到它们将在矢量表的末尾添加这些额外的 FF。  (尚未经过测试、将在周一进行测试)

我认为这些保留空间可能会用于将来的改进。

您好、Charles、

感谢您的回复。

我将返回我的测试结果。

1) 1)我已在矢量表中包含标头标记+图像长度+ CRC + FF、并且我已成功编译项目。 仅对于使用 Keil 的用户、可能需要在矢量表底部(在 startup_rvmdk.s 文件中)添加这些头文件、他们只需要在最后一个中断后包含以下代码

DCD header_first_marker ;装订工具
DCD 使用的标题标记1 HEANDER_second_marker ;装订工具
DCD 使用的标题标记2 HEADER_IMAGE_LEN ; binpack 工具
DCD 使用的标题图像长度 HEADER_IMAGE_CRC ; binpack 工具
DCD 使用的标题图像 CRC HEADER_RESERVE_1 ; binpack 工具
DCD 使用的保留字 HEADER_RESERVE_2 ; binpack 工具
DCD 使用的保留字 头文件_保留_3 ; binpack 工具
DCD 使用的保留字 HEADER_RESERVE_4 ；binpack 工具使用的保留字 

至少是我将这些头文件包含在项目中的方式。

2) 2)然后、在编译并从 Keil 获取生成的 bin 文件后、我使用 binpack 工具来处理该文件并嵌入 CRC。 我使用十六进制编辑器检查了该 bin 文件、实际上我在矢量表的末尾找到了上述头文件、其中包含正确的长度和 CRC 值。

3) 3)使用 binpack 工具处理后、我已获取新生成的 bin 文件、并使用 LM 闪存编程器将其加载到 TM4C1294NCPDT 中。  

4) 4)然后、我打开了用于通过以太网更新电路板的 Python 脚本、并使用新的固件映像更新了电路板、以确保新映像通过 CRC。 实际上、CRC 完全正常、并且成功地更新了电路板、没有任何问题。

我尝试的另一项测试是加载损坏的二进制文件、其中一半由0x00手动填充、其余部分保持不变。 在电路板上加载损坏的文件后、引导加载程序无法检测到 CRC 和其余头文件、因此它开始发送 TFTP 请求、以便使用有效映像更新电路板。  

仅供您参考、我根本没有使用 LM 闪存编程器。 以太网更新是使用我自己的脚本执行的。 LM Flash Programmer 仅在我需要通过 JTAG 加载固件时使用。

4) 4)为了稍微自动化使用嵌入式 CRC 生成二进制文件的过程、我添加了编译后处理命令。 首先、我使用以下命令创建了一个.cmd 文件

..\thirdparty\binpack\binpack.exe -i .\rvmdk\initial.bin -o .\rvmdk\processed_CRC32.bin -x 

然后、在编译后处理命令中、我添加了以下命令

..\thirdparty\binpack\binpack.cmd 

在 Keil 内(成功)编译项目后立即生成最终的二进制文件(包含 CRC 的文件)。

因此、我可以放心地说、使用 binpack 工具进行处理时无需使用-d 命令。 实际上、这取决于您的需求。 对于我的项目、无需在文件顶部添加额外的下载标题。 我只需要添加计算出的 CRC。 此外、如果未添加-d、则无需更改矢量表的偏移量。

最后、CRC 在引导加载程序中进行检查、但我稍微更改了 CRC 检查的位置。 我已经修改了以太网引导加载程序的某些部分、以满足我对该特定项目的需求。  

所有这些都与任何固件的 binpack 和 CRC 有关。 我很乐意回答其他可能有助社会解决问题的问题：)

Charles、再次感谢您的回复。 Amit 和 Peter、您的帖子也帮助您了解了正在发生的情况。  

大家好、 Mpekatsa、

 我很高兴您能够测试并确认其工作正常。 我会将您的帖子推荐给将来可能会提出相同问题的人。