[参考译文] LP-EM-CC2340R5：OAD 构建的 bin 输出每次都不同

您好 Kei、

感谢您的咨询。 我想问一下、您在构建图像时看到了哪些不同之处？ 没错、该 bin 文件是在执行编译后处理步骤期间通过 imgtool 可执行文件来生成头文件的。

BR、

David。

David、您好！

在该示例中、编译后处理步骤配置为使用以下设置进行编译：

${CG_TOOL_HEX} -order MS --memwidth=8 --romwidth=8 --intel -o ${ProjName}.hex ${ProjName}.out
${CG_TOOL_ROOT}/bin/tiarmobjcopy ${ProjName}.out --output-target binary ${ProjName}_noheader.bin --remove-section=.ccfg
${COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR}/tools/common/mcuboot/imgtool sign --header-size 0x100 --align 4 --slot-size 0x44000 --version 1.0 --pad-header --key ${COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR}/source/third_party/mcuboot/root-ec-p256.pem ${ProjName}_noheader.bin ${ProjName}_v1.0.bin
${COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR}/tools/common/mcuboot/imgtool sign --header-size 0x100 --align 4 --slot-size 0x44000 --version 2.0 --pad-header --key ${COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR}/source/third_party/mcuboot/root-ec-p256.pem ${ProjName}_noheader.bin ${ProjName}_v2.0.bin

bin 文件的差异是否意味着它们是使用 imgtool 处理的？e2e.ti.com/.../bin.zip
作为参考、我将共享实际的出纸槽文件。

您好 Kei、

您能强调一下_v1构建1和_v1构建2二进制文件之间的差异吗？ 我似乎没有看到任何。

BR、

David。

David、您好！

抱歉。
它是误发的。
请参阅此处。

e2e.ti.com/.../bin_5F00_fix.zip

您好 Kei、

我看到区别在于最后几个字节、其中一部分是生成的 CRC。 我认为在编译后处理步骤期间将 hex 文件解析为 bin 文件的工具(img 工具)会引入 CRC 之前的字节。 我会向您介绍这方面的信息。 与此同时、我能理解这个用例吗、或者这是否会因某种原因阻碍您的进度吗？

BR、

David。

David、您好！

感谢你的评分

使用它的方法是将此 bin 文件写入器件、然后在器件中获取固件校验和。
我们获取固件校验和并将其传送到发布目标。

如果每次执行构建时校验和不同、则可能无法识别所使用的固件、因此我们希望在考虑操作的同时牢记该机制。

您好 Kei、

我看到了、能否问一下校验和是否还应包括映像的 CRC？

BR、
David。

David、您好！

我认为可以在计算中包含 CRC。
目的是测量器件的完整性。

David、这是否意味着 bin 文件与映像工具生成的其他数据之间存在差异？

您好 Kei、

区别在于 CRC (32字节)加上我在上一个答案中突出显示的其余字节(另32字节)。 我要弄清楚这些是如何由 imgtool 生成的。 如果映像中有任何内容发生更改、CRC 就会不同、也是之前的32个字节、我可以通过比较两个 bin 文件映像来查看。

BR、

David。