最终二进制文件中的STM32链接crc固件值

问题描述

我正在尝试为自定义STM32F401RE板编写引导加载程序+应用程序，但我有一些疑问。

当前，我的布尔加载器的生存时间为0x08000000，应用程序的生存时间为0x08020000。这个想法是让引导加载程序在跳到应用程序之前执行CRC检查。

我使用链接程序脚本在.fw_crc之后和.isr_vector之前创建了一个名为.text的部分。在应用程序代码中，我可以将其直接写入闪存中的该地址。但这就是我被困住的地方。

如果我理解正确，我应该...

1. 在应用程序中将CRC值默认为0。
2. 构建二进制文件。
3. 生成此二进制文件的CRC。
4. 使用一些十六进制工具用计算出的CRC值覆盖此部分。
5. 再次重新生成二进制文件以进行最终刷新。

以上假设正确吗？不会使用更新后的CRC值第二次重新生成二进制文件最终改变最终二进制文件的CRC结果吗？

还要在引导加载程序中，从application_address到application_address + binary_size的开头执行CRC检查吗？

解决方法

以上假设正确吗？不会使用更新后的CRC值第二次重新生成二进制文件最终改变最终二进制文件的CRC结果吗？

• CRC的默认值可能设置为您喜欢的任何值。无论如何，它将被您的构建后过程覆盖。

• 在构建后的步骤中，必须计算除.fw_crc之外的整个应用程序二进制文件的CRC，并将CRC结果写入该特定的内存区域。但是，由于.fw_crc是在.isr_vector和.text区域之间定义的，因此您应该考虑分别计算这两部分的CRC并将它们组合。建议重新安排您的存储区域，使.fw_crc处于开始位置。为此，您必须在Flash中使用必要的偏移量重新定位ISR向量表。然后，您将能够更轻松地计算应用程序二进制CRC。

还要在引导加载程序中，从application_address到application_address + binary_size的开头执行CRC检查吗？

如前所述，根据您当前的存储安排，您将必须计算两个存储区域即.isr_vector和.text的CRC。当然，您将需要在引导加载程序中执行相同的CRC计算和比较，以验证应用程序binray的有效性。

,

它非常复杂，而且非常简单。在中断向量放置图像的长度之后（链接脚本-简单添加FLASH部分的长度）。

在生成后操作中，计算CRC并将其附加到bin图像中。简单地刷新图像时，请执行整个图像的CRC（包括末尾附加的CRC）。结果应为0。