我正在将我的STM32F1xx项目转移到一个带有引导程序的解决方案中。部分原因是我希望能够计算现有引导加载程序和应用程序闪存范围的CRC值，以比较现有和可能的上传候选。
在STM32上使用一个简单的实现，只需执行以下步骤：
- 启用CRC周期
- 重置外围CRC值(设置为0xFFFFFFFF(
- 在闪存范围(在这种情况下为0x08000000到0x08020000(上迭代，将值传递给CRC外围设备
- 返回CRC外围输出
uint32_t get_crc(void) {
RCC->AHBENR |= RCC_AHBENR_CRCEN;
CRC->CR |= CRC_CR_RESET;
for(uint32_t *n = (uint32_t *)FLASH_BASE; n < (uint32_t *)(FLASH_BANK1_END + 1u); n ++) {
CRC->DR = *n;
}
return CRC->DR;
}
我从中得到的值是0x0deddeb3。
为了将这个值与一些东西进行比较，我通过两个工具运行.bin文件。
我从npm的crc-32得到的值是0x776b0ea2
我从zip文件的CRC-32中得到的值是也是0x776b0ea2
是什么原因造成的？在整个闪存范围内迭代和bin文件的内容(小于整个闪存范围(之间有区别吗？STM32使用的多项式是0x04c11db7，这似乎是CRC-32的标准多项式。zip工具和npm crc-32会使用不同的多项式吗？
我还尝试过在STM32上迭代字节和半字以及字，以防其他工具使用不同的输入格式。
这里已经有一个类似的问题，但我希望使用node-js解决方案，因为这是我的接口应用程序正在开发的平台。
计算CRC是一个矿场。你的问题已经有了一些要点：
在整个闪存范围内迭代和bin文件的内容(小于整个闪存范围(之间有区别吗？
当然可以。
zip工具和npm crc-32会使用不同的多项式吗？
文档会告诉您。我相信你可以通过一个选项，用这个工具使用另一个多项式。
总之，在计算CRC时需要考虑以下几点：
- 到"；总结">
- 二进制文件未覆盖闪存的内容，很可能所有位都设置为1
- 多项式的宽度(在您的情况下固定为32位(
- 多项式的值
- 寄存器的初始值
- 每个字节的比特在被处理之前是否被反映
- 算法是通过寄存器馈送输入字节，还是用一端的一个字节对其进行异或运算，然后直接输入到表中
- 是否应反转最终寄存器值(如反映的版本(
- 值与最终寄存器值进行XOR运算
点3到最后一个是无耻地从"；CRC错误检测算法的无对指南"；我建议阅读。
多项式只是定义CRC的几个参数之一。在这种情况下，不反映CRC，而反映使用相同多项式的标准zip CRC。此外，zip CRC是排他性的，或者结尾有0xffffffff，而您的不是。它们的初始化方式与0xffffffff相同。