STM32 Hardware CRC32 Use

Recently used STM32 CRC32 module, look at the official website Lib, feel very simple to use. However, you will find that the direct use will appear, and many online CRC32 Web sites or PC-side CRC32 Verification Tool calculation results inconsistent!

It's just no words ...

A search, in the 21IC forum above on the use of STM32 CRC32 big discussion, but 09 years of Post. The main conclusion is that STM32 's CRC32 is inconsistent with some of the data sequences and methods used by most PC-side software. Here are the main recommendations to see this link: STM32 the use of the built-in CRC module is a very hot discussion.

If it's true, that's what the post says. So as the end of the MCU, it is necessary to convert, to adapt to the trend. Of course, this is not to say St bad.

Follow the conclusion of the post:

1. The bit order of each byte is reversed. STM32F is 32-bit, high-order. And the mainstream instance is from the low in every byte.
2, the result comes out, the mainstream instance and 0xFFFFFFFF XOR. and stm32f didn't.

Then we can probably post the following code.

  /******************************************************************************** Function Name  : CRC32_ forwords* Description    : Input is the pointer and length of 32bit buffer * Input          : * Output         : * Return         : * Description           :* *************** /u32 crc32_forwords (u32 *pdata,u32 ulen) {u32 i = 0, UData = 0;if ((rcc->ahb1enr & rcc_crc_bit) = = 0) {rcc->ahb1enr |= rcc_crc_bit;}  /* Reset CRC Generator */CRC->CR = crc_cr_reset;for (i = 0;i < ulen;i++) {#ifdef used_big_endianudata = __rev (* (pData + i); #elseuData = * (PData + i); #endifCRC->dr = Revbit (uData);} Return Revbit (CRC->DR) ^0xffffffff;}

Description: The function of the __rev () function is to reverse the data by the size of the knuckles, as the original data is 0x41424344, after this function becomes 0x44434241

Where the code of the data is reversed (because it is the GCC compiler and therefore does not know why it is not supported) someone else's code:

Crc_16_32 revbit (crc_16_32 data) {  asm ("Rbit r0,r0");  return data;};

The code that modifies itself is as follows:

/******************************************************************************** Function Name  : revbit* Description    : The bitwise reverse of the incoming parameter udata. Example: 0111-->1110* Input          : uData: Transferred data * Output         : none* Return         : Converted data *********************************** /u32 revbit (u32 uData) {   u32 urevdata = 0,uindex = 0;   Urevdata |= ((uData >> uIndex) & 0x01);   for (UIndex = 1;uindex < 32;uindex++)   {urevdata <<= 1;  Urevdata |= ((uData >> uIndex) & 0x01);   }   return urevdata; }

After testing, the results are verified to be consistent with the PC-side code.

Then there is a problem, if I pass in buffer not 4 bytes to it can use STM32 CRC32 can.

Of course, the answer is yes. But software mates are required. Here is a direct recommendation, my Code reference post: Implementing a CRC32 method that is not 4 bytes

My code is as follows:

#defineCRC32_POLYNOMIAL ((uint32_t) 0xedb88320) #defineRCC_CRC_BIT ((uint32_t) 0x00001000)//#defineUSED_BIG_ENDIAN/ *==================================================================* function:crc32_forbytes* Description: CRC32 input as 8bits buffer pointer and length * input Para: * Output Para: * Return Value: ================================================= =================*/u32 crc32_forbytes (U8 *pdata,u32 ulen) {u32 uindex= 0,udata = 0,i;uindex = Ulen >> 2;if ((RCC-> Ahb1enr & rcc_crc_bit) = = 0) {rcc->ahb1enr |= rcc_crc_bit;}  /* Reset CRC generator */CRC-&GT;CR = Crc_cr_reset; while (uindex--) {#ifdef used_big_endianudata = __rev ((u32*) pData); #elsememcpy ((u8*) &udata,pdata,4); #endifpData + = 4;udata = Revbit (UData); CRC-&GT;DR = UData;}    UData = Revbit (CRC-&GT;DR); uIndex = Ulen & 0x03;while (uindex--) {uData ^= (u32) *pdata++;      for (i = 0;i < 8;i++) if (UData & 0x1) UData = (uData >> 1) ^ crc32_polynomial; else UData >>= 1;} Return UData^0XFFFFFFFF;} 

Test, "Hello World" results are 0x4a17b156, confirm with PC software consistent.

Is CRC32 so over? No, there are problems.

That's the problem with the data size end. From my code, I think if the big-endian would need to reverse the data, and then into the STM32 CRC32 hardware to do the operation. This gives you the same results as a PC.

But since I'm using Keil's gcc compiler, this can't support big-endian at the moment. So can only be left to the willing to help to do the rest of my conclusion verification.

Keil the GCC compiler compiled error messages are also affixed to see if there is a master support to solve:

I think the reason why the compiler does not support big-endian compilation is the following link: The discussion of the big problem of GCC may be supportive, the chicken intestines are not good enough to understand the wrong, welcome to correct.

from:http://blog.csdn.net/lan120576664

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

STM32 Hardware CRC32 Use