通过STM32闪存获取CRC-32并与其他CRC-32工具保持一致

如何解决通过STM32闪存获取CRC-32并与其他CRC-32工具保持一致

我正在将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 file's CRC-32获得的值也是也是0x776b0ea2

可能是什么原因造成的？遍历整个闪存范围和bin文件的内容（小于整个闪存范围）之间有区别吗？ STM32使用的多项式为0x04c11db7，对于CRC-32来说似乎是相当标准的。 zip工具和npm crc-32是否使用其他多项式？

在其他工具使用不同输入格式的情况下，我也尝试遍历字节，半字以及STM32上的字。

这里已经有一个similar question，但是我希望使用node-js解决方案，因为这是开发我的界面应用程序的平台。

解决方法

计算CRC是一个雷区。您的问题已经有一些要注意的地方了：

遍历整个闪存范围和bin文件的内容（小于整个闪存范围）之间有区别吗？

是的，当然。

zip工具和npm crc-32是否将使用其他多项式？

文档将告诉您。而且我确信您可以选择通过该工具使用另一个多项式。

无论如何，这些是计算CRC时要考虑的事情：

1. “加总”的字节数（字，...）。
2. 二进制文件未涵盖的闪存内容，很可能所有位都设置为1。
3. 多项式的宽度（在您的情况下，固定为32位）。
4. 多项式的值。
5. 寄存器的初始值。
6. 每个字节的位在处理之前是否都已反映。
7. 算法是通过寄存器馈送输入字节，还是将输入字节与一端的字节进行异或，然后直接进入表。
8. 是否应反转最终寄存器的值（如在反射版本中一样）。
9. 与最终寄存器值进行XOR的值。

我建议阅读的"A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS"中无耻地复制了最后3点。

,

多项式只是定义CRC的几个参数之一。在这种情况下，不会反映CRC，而会反映使用相同多项式的标准zip CRC。另外，zip CRC在末尾与0xffffffff进行异或运算，而您的不是。它们都使用0xffffffff进行了相同的初始化。