CRC calculation problem

[matic]

Posted on December 16, 2015 at 15:40

Hi.

I'm trying to calculate CRC on STM32F303 using CRC peripheral. I check the correctness of calculation with this on-line application:

https://ghsi.de/CRC/

 But I have problems, when I want to calculate CRC above more than 32 bits. If I write to CRC->DR register 32 bits it returns the same as on-line app. For example: - Init value: 0x00000000 - Polynomial: 0x97 - Input data: 0xA5A5A5A5 Here I get CRC value of 0x5A. And the same result I get with on-line app. But if I want to calculate CRC above 40 bits, I don't get the same value anymore. For example: - Init value: 0x00000000 - Polynomial: 0x97 - Input data: 0xA5A5A5A5CC Write CRC->DR = 0xA5A5A5A5  returns 0x5A.  Above that I write CRC->DR = 0xCC. And I get 0xFF. Then I use on-line app. And I write input data as: 0xA5A5A5A5CC. It returns 0x44, which is not the same as uC returns. Obviously, I'm doing something wrong. I have set REV_OUT and REV_IN in CR register to 0. Do you have any advice? Thanks #worst-forum-software-ever

[Tesla DeLorean]

Posted on January 05, 2016 at 18:58

Weird, that one didn't show up at the top level either, this one should, but I'm at the point where I don't care...

[waclawek.jan]

Posted on January 05, 2016 at 19:06

> It's the forum, I tried to do a reply from two different browsers, and also updated Firefox, and retried a couple of times. The ''Reply'' panel kept coming up with no thread history for that post.

AH. So not only the forum software is crap: it's crap in many inventive ways... > I'm at the point where I don't care... +1, as it appears to be hardly reproducible. Sorry for the OT digression. Jan

[Tesla DeLorean]

Posted on January 05, 2016 at 22:54

You're tilting at windmills here.

It's a 6 bit polynomial that you'll need to code as 0x03.  It's written as 0x43 because both the high and low order bits are 1, the high order is inferred. The frequently used 16-bit polynomial 0x11021 is coded as 0x1021. The STM32's 32-bit one is 0x104C11DB7 The HW doesn't support your CRC length, your data doesn't divide into the the CRC length either. ie 14 is NOT divisible by 6. In my opinion it's going to be very difficult to push the require number of bits through. You have a protocol that's highly non-conducive to the use of the STM32 HW CRC generator in any helpful form/fashion. I could probably build a slightly faster table driven version if you could decide on a bit/byte ordering schedule, but you'd need to come up with some better BiSS generated test vectors, not ones you pull off some on-line CRC tool.

[matic]

Posted on January 05, 2016 at 23:53Ok, thanks then. I will look for some SW type of calculation.But still don't know one thing. What is this POLYSIZE field in CRC_CR register for? There is option to choose for 32, 16, 8 or 7-bit polynomial. Is this the same information as 6-bit is for 0x43 polynomial?

[Tesla DeLorean]

Posted on January 06, 2016 at 01:13

It's the number of bits in the remainder/residual from the polynomial division.

You have a CRC that generates 6-bits in a cyclic (rotating) register. The polynomial is in the form x6 + .. + 1, remember that 20 is 1, and 26 is 64 The register shifts left, so the bit 5 becomes bit 6, and the feedback term rotates back in at bit 0. So you look at bit 5 before the shift to decide if to apply the feedback terms after the shift, and then the sixth bit is lost. It reappears at bit 0 due to the +1 term. The amount of bits processed will depend on the width of the write to the CRC->DR register, ie if you've cast it as a 8-bit (byte), 16-bit (half-word) or 32-bit (word) write. You can configure the size, polynomial, and shift direction, as I recall, review the block diagrams and experiment. There are a number of books and academic papers on CRC and LFSR implementations.

[matic]

Posted on January 06, 2016 at 07:37 I looked in the SPI chapter of ref. manual  and there is also possible to set custom polynomial for CRC calculations. Of course, this is coupled with SPI peripheral, but anyway. The default value for polynomial there is 0x7. Which is also less than 8 bits. So, why is this allowed there and not here in a CRC peripheral?

[Tesla DeLorean]

Posted on March 14, 2016 at 18:27

The default value for polynomial there is 0x7. Which is also less than 8 bits. So, why is this allowed there and not here in a CRC peripheral? 

Yes, because with the 0x107 polynomial, the 0x100 portion is inferred because it is 8-bit. 

polynomial x8+x²+x+1

You take small fragments of detail, which you don't grasp well, and extrapolate that into other things also not understood well, this is a recipe for more confusion.