Matching CRC32 from STM32F0 and zlib

问题

I'm working on a communication link between a computer running Linux and a STM32F0. I want to use some kind of error detection for my packets and since the STM32F0 has CRC32 hw and I have zlib with CRC32 on Linux I thought it would be a good idea to use CRC32 for my project. The problem is that I won't get the same CRC value for the same data on the different platforms.

#include <inttypes.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <zlib.h>

int
main(void)
{
  uint8_t byte0 = 0x00;
  uint32_t crc0 = crc32(0L, Z_NULL, 0);
  crc0 = crc32(crc0, &byte0, 1);
  printf("CRC32 value of %" PRIu8 " is: %08" PRIx32 "\n", byte0, crc0);
}

outputs CRC32 value of 0 is: d202ef8d which matches the result on several online calculators.

It seems though that whatever settings I use on the STM32 I can't get the same CRC. I have found a flowchart on how the CRC hw calculates its value in an application note from ST but I can't figure out how it's done in zlib.

Does anyone know if they are compatible?

[edit 1] They both uses the same init value and polynomial.

[edit 2] The STM32 code is relatively uninteresging since it's using the hw.

...
/* Default values are used for init value and polynomial, see edit 1 */
CRC->CR |= CRC_CR_RESET;
CRC->DR = (uint8_t)0x00;
uint32_t crc = CRC->DR;
...

回答1:

From the documentation, it appears that your STM32 code is not just uninteresting — it is rather incomplete. From the documentation, in order to use the CRC hardware you need to:

Enable the CRC peripheral clock via the RCC peripheral.
Set the CRC Data Register to the initial CRC value by configuring the Initial CRC value register (CRC_INIT).(a)
Set the I/O reverse bit order through the REV_IN[1:0] and REV_OUT bits respectively in CRC Control register (CRC_CR).(a)
Set the polynomial size and coefficients through the POLYSIZE[1:0] bits in CRC Control register (CRC_CR) and CRC Polynomial register (CRC_POL) respectively.(b)
Reset the CRC peripheral through the Reset bit in CRC Control register (CRC_CR).
Set the data to the CRC Data register.
Read the content of the CRC Data register.
Disable the CRC peripheral clock.

Note in particular steps 2, 3, and 4, which define the CRC being computed. They say that their example has rev_in and rev_out false, but for the zlib crc, they need to be true. Depending on the way the hardware is implemented, the polynomial will likely need to reversed as well (0xedb88320UL). The initial CRC needs to be 0xffffffff, and the final CRC inverted to match the zlib crc.

回答2:

The CRC32 implementation on STM32Fx seems to be not the standard CRC32 implementation you find on many online CRC calculators and the one used in zip.

STM32 implements CRC32-MPEG2 which uses big endian and no final flip mask compared to the zip CRC32 which uses little endian and a final flip mask.

I found this online calculator which supports CRC32-MPEG2.

If you are more interested on other CRC algorithms and their implementation, look at this link.

PS: The HAL driver from STM supports input in byte, half word and word formats and they seem to work fine for STM32F0x in v1.3.1

回答3:

I haven't tested this, but I suspect that you're not, in fact, doing an 8-bit write on the STM32.

Instead you're probably doing a write to the full width of the register (32 bits), which of course means you're computing the CRC32 of more bytes than you intended.

Disassemble the generated code to analyze the exact store instruction that is being used.

回答4:

I had similar issues implementing a CRC on an STM32 CRC module where the final checksum was not matching. I was able to fix this by looking at the example code in stm32f30x_crc.c that is provided with STMCube. In the source it has a function for 8-bit CRC that used the following code

(uint8_t)(CRC_BASE) = (uint8_t) CRC_Data;

to write to the DR register. As stated previously, the line CRC->DR is defined as volatile uint32_t which will access the whole register. It would have been helpful if ST had been more explicit about accessing the DR register rather than simply saying it supports 8-bit types.