This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Guru**** 2556740 points
Other Parts Discussed in Thread: TM4C1294NCPDT

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/934010/tm4c1294ncpdt-crc32-for-ethernet-bootloader

器件型号:TM4C1294NCPDT

您好、再说一次、

最近、我为我的项目使用了以太网引导加载程序、我已根据我的项目的需要对其进行了修改(引导加载程序基于 TivaWare 库中提供的示例)。 经过数天的测试后、发现它的工作效果绝对不错。

尽管现在我需要在引导加载程序中添加 CRC32检查、但我对 binpack 工具有疑问。 构建项目后、我获取输出.bin 文件、并使用 binpack 工具使用以下命令对其进行处理:

binpack -i initial.bin -o initial_crc.bin -a 0x00004000 -d 

在输出二进制文件(其中包含 CRC32)上、我可以看到以下十六进制值

0000-0010:01 00 10 00-bc 53 00 00-48 A3 00 20-01 42 00… S. H.... B. 

其中前两个字节包含由 binpack 工具添加的标记模式(0x01、0x00)、然后接下来的两个字节包含图像起始地址除以1024 (0x10、0x00)、接下来的4个字节包含二进制大小(0xbc、0x53、0x00、0x00)。 通过在 binpack 工具中使用上述命令添加所有这些字节。

如果我不通过指定闪存地址来处理初始 bin 文件、我将获得以下输出

0000-0010:48 A3 00 20-01 42 00 00-15 42 00 00-17 42 00 h...B. B. 

根据 binpack 工具的文档、这两个输出都是合理的。 尽管如此、如果我要在 TM4C1294NCPDT 上加载包含 CRC32的二进制文件、是否会正确加载应用? 我可以看到应用程序入口点已右移并放置在 binpack 工具添加的页眉之后。 但引导加载程序是否能够进入应用程序入口点?

APP_START_ADDRESS 已在引导加载程序中的0x4000处定义、但在使用 binpack 工具进行处理后、我可以看到应用程序从0x4004开始。 我是否需要更改 引导加载程序中的 APP_START_ADDRESS?

提前感谢您的帮助!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

     我从未亲自使用过 binpack 工具。 我想知道您是要使用 LM 闪存编程器来下载程序映像、还是要创建自己的实用程序? 在文档中、如果您要使用 LM 闪存编程器、则一定不能使用-d 选项。  

     下面的这个帖子也将有所帮助。  

    下面另一篇由 Peter 回复的帖子可能会回答您有关移位矢量表的问题。  您可以使用向量表偏移寄存器更改为新的向量表地址。

    https://e2e.ti.com/support/microcontrollers/other/f/908/p/688988/2541680?tisearch=e2e-sitesearch&keymatch=binpack#2541680

    您可能需要使用-d 和不使用-d 进行实验、并查看 LM 闪存编程器或您自己的下载工具会发生什么情况。 我建议您首先使用 LM 闪存编程器。 告诉我们您的发现、并请与社区分享、以便让希望使用-d 选项的人受益。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嘿、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、您的帖子也帮助您了解了正在发生的情况。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    大家好、 

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