topic Re: DMA CRC Calculation over flasharea in S32K

DMA CRC Calculation over flasharea

FelixR — Tue, 13 Feb 2024 12:20:45 GMT

Hello there,

I resently played around with the DMA CRC Hardware acceleration. There I noticed that I get different results for the CRC-Data provided by the Crc_Ip_Example.

When I calculate the CRC over the RAM structure inside the Codeflash Area (here 0x004255E4) I get the expected result of 0x0E551D7CU inside my crc_result variable as shown below.

However, if I write the CRC_data into the Dataflash Memory (using the example Codes from the C40_Ip_Example) at the location 0x10000000 and then pass this address to the CRC engine the resulting data I get a different result.

The memory dump inside the second picture confirmed that Data inside the Memory of the S32K344 is in the same order in Flash aswell as in the RAM section.

Is it not possible to read from flash using the DMA in such a way that I can build checksums over known locations with hardware acceleration or does the flash has some different properties when I want to read from it?

Re: DMA CRC Calculation over flasharea

VaneB — Tue, 13 Feb 2024 21:52:09 GMT

Hi @FelixR

The CRC module provides a programmable polynomial and other parameters necessary to implement the 16-bit or 32-bit CRC standards. What algorithm are you using? This is to test from our side.

Furthermore, we have observed that in some external ways to calculate the CRC other than the S32K3 module, the result is influenced by how the data is provided.

If you try with a single value, do you see that there are still differences in the results?

B.R.

VaneB

Re: DMA CRC Calculation over flasharea

FelixR — Wed, 14 Feb 2024 09:59:39 GMT

The error occurred at the 128 Byte boundary, resulting in different results on the 129th Byte. The mistake was on my end during the Nvm write process where I accidentally wrote the same 128 Byte block on the flash, leading to a different CRC calculation. However, I have fixed the bug and written the correct data in the D-Flash, resulting in the same CRC value.

Still thank you for response Vane.