Which 32 bit CRC does the CRC calculation unit on the stm32f429 calculate?

[BPort.2]

The documentation I have says the Ethernet calculation with 0x4C11DB7... but I don't get results matching what I get from any other calculator. To remove any endianess or mirroring questions I've tried 0x00000000 and 0x66666666 (e.g.). All calculators I have produce 2144_DF1C and E425_C810 for those 2 inputs. From the CRC unit I get 6904_BB59 and 7B91_8196 (which don't seem to be related by combinations -- on the final value -- of bit flipping and reflection).

Yes I asked what the results are -- because I can't imagine what I' don't see in the 1 -> CR; XXXX -> DR; Result <- DR sequence.

TIA,

Brett

[BPort.2]

Hi,
Apologies in advance for drifting to a question more tenuously STM-connected (resulting more from a KEIL choice – and I’m still new to CRC intricacies).
The KEIL tools have stuck a location for filling in a CRC into the flash image between the end of all the text-and-constants and the compressed initialized RW data (my guess is for the convenience of the compression being after the bulk of the linking work). The easiest way for checking the image (run time – upgrade time….) would be to stick the right value into their CHECKSUM location (modify that location in the hex file), so that running the STM CRC Unit over the entirety of the flash image ends with a 0. So my question (illustrated with a simple example) is
Given the words b1 b2 b3 CK a1 a2 (where a-s and b-s can’t be modified), is it possible to calculate the value to stick into CK so that the checksum run over all 6 words in order produces a 0?
TIA,
Brett

[waclawek.jan]

Without answering your final question - why would it be difficult to skip that one position while performing the checksumming?

JW

[BPort.2]

That would almost certainly be the next best thing (the skip at runtime would be no problem), the scripts (batch files using srec_cat and related tool) is a bit messier at the moment – and not doing the entire job… but should be fixable.

[Tesla DeLorean]

>>Given the words b1 b2 b3 CK a1 a2 (where a-s and b-s can’t be modified), is it possible to calculate the value to stick into CK so that the checksum run over all 6 words in order produces a 0?

Yes,

I also provided a method to drive it backward.

You'd drive it back from the end, and from front to the gap, and then compute a bridging value.

[BPort.2]

Hah – I didn’t realize that. I guess that driving it backwards involves setting the initial CRC to zero (and running on a2 then a1), and I can figure out just how to use CcrRev for determining the bridge value ….. trying now….

[waclawek.jan]

With srecord, I believe you would need to use the -exclude filter, to exclude the CRC's position from calculation. I did not try,though.

JW

[BPort.2]

Sorry,
I don’t know what you mean by driving it backwards. What I see on this thread are the 2 functions Crc32 and Crc32Rev and nothing about ‘driving backwards’…. Unfortunately, I also don’t see that the value returned from Crc32Rev, when input into Crc32 (whose current Crc value is the CurrentCrc input to Crc32Rev) matches CrcDesired. I thought that is what the Data returned from Crc32Rev would effect.
Cheers,
Brett

[Tesla DeLorean]

It's an LFSR like a Fire Code, we have to apply data in reverse to unwind things.

uint32_t test1[] = { // Should have zero remainder divided into STM32 32-bit polynomial, init 0xFFFFFFFF

0x11111111,0x22222222,0x33333333,0x44444444,0x55555555,0x66666666,

0x77777777,0x88888888,0x99999999,0xAAAAAAAA,0xAE692FF9,0xBBBBBBBB,

0xCCCCCCCC };

uint32_t test2[] = {

0xE5E5E5E5,0xE5E5E5E5,0x7042D51B,0xBBBBBBBB,0xCCCCCCCC };

Done with math, not brute force.

https://paypal.me/cliveone

[BPort.2]

These 2 lines of bash muck the hex file just right:
read c1 c2 < <(awk -n '/^[ ]*CHECKSUM / {printf "0x%X 0x%X\n", $2, $2+4}' $Build_Map)
srec_cat $Build_Hex -intel -exclude $c1 $c2 -STM32 $c1 -output wcrc.hex -intel
Would rather get the CHECKSUM from the executable – but the mapfile was just too handy.
srec_cat warns mightily that I could not really want to run the checksum over a file with a hole in it – but it
works just right. It is a well done tool… examples I’ve seen don’t get its flexibility – kind of understandable… a bit more of how-it-works documentation would help folks take better advantage.
I can’t say “well done�? about any of the Keil ARM toolchain – in this case the linker (and the documentation maybe more so) is sadly confused and confusing…. but I found the Load$$LR$$LR_IROM1$$xxxx names to give the load region boundaries to the embedded application code.