通过 STM32 闪存获取 CRC-32 以及与其他 CRC-32 工具的一致性

Question

我正在将我的 STM32F1xx 项目移动到带有引导加载程序的解决方案。部分原因是我希望能够计算现有引导加载程序和应用程序闪存范围的 CRC 值，以比较现有和可能的上传候选对象。

在 STM32 上使用简单的实现，只需执行以下步骤：

启用 CRC 外设
重置外设CRC值（设置为0xFFFFFFFF）
迭代闪存范围（在本例中为 0x08000000 到 0x08020000），将值传递给 CRC 外设
Return 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

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

我还尝试在 STM32 上迭代字节和半字以及字，以防其他工具使用不同的输入格式。

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

Answer 1

多项式只是定义 CRC 的几个参数之一。在这种情况下，不反映 CRC，而反映使用相同多项式的标准 zip CRC。此外，该 zip CRC 是 exclusive-or'ed，最后是 0xffffffff，而你的不是。他们都得到相同的初始化，即 0xffffffff.

Answer 2

计算 CRC 是一个雷区。你的问题已经有几点可以看：

Is there a difference between iterating over the entire flash range and the contents of the bin file (smaller than entire flash range)?

当然可以。

Would the zip tool and npm crc-32 be using a different polynomial?

文档会告诉你。而且我确信您可以通过一个选项将另一个多项式与此工具一起使用。

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

要“总结”的字节数（字，...）。
闪存的内容未被二进制文件覆盖，很可能所有位都设置为 1。
多项式的宽度（在您的情况下固定为 32 位）。
多项式的值。
寄存器的初始值。
每个字节的位是否在处理之前被反映。
算法是通过寄存器馈送输入字节还是将它们与来自一端的字节进行异或，然后直接进入 table。
是否应反转最终寄存器值（如反射版本）。
与最终寄存器值进行 XOR 的值。

从"A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS"推荐阅读的"A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS"无耻抄袭

到最后的第3点

通过 STM32 闪存获取 CRC-32 以及与其他 CRC-32 工具的一致性

Getting CRC-32 over STM32 flash and consistency with other CRC-32 tools

c

embedded

stm32

crc