CRC computation shows different results

cancel
Showing results for 
Search instead for 
Did you mean: 

CRC computation shows different results

Jump to solution
1,208 Views
nicolasguigo
Contributor II

Hello,

I have TWR-K64F120 and I use KDS (3.0.0) with KSDK (1.3.0). To compute the CRC, I use the fsl_crc module which provides the function "CRC_DRV_Get_CrcBlock" to compute the CRC. The module is configured to compute the CRC16 CCITT (polynomial is 0x1021). The result given the first time is correct and then... all the subsequent results are false, even if the same data is given!

My (simplified) test code is as below:

    uint8_t test_array[2] = { 0 };

    test_array[0] = 0x01;

    test_array[1] = ~test_array[0];
    uint32_t crc_computed = CRC_DRV_GetCrcBlock(crc16_CCITT_IDX, test_array, 2);

The first time the function is called, the result is 0x20EF which is expected. Calling the function after that always give a wrong (and different) result. Could you kindly help me to understand what I do (or don't do) which could cause the error?

Labels (1)
Tags (3)
0 Kudos
1 Solution
403 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi,

Please download the latest MCUXpresso SDK software package (Rev.2.3.0) for TWR-K64F board.

There with the CRC example demo, which located at default path:

..\SDK_2.3.0_FRDM-K64F\boards\frdmk64f\driver_examples\crc

There need to re-config the CRC parameters.

Wish it helps.


Have a great day,
Mike

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

5 Replies
403 Views
nicolasguigo
Contributor II

I noticed that the results are always the same and I managed to track down the cause of these results: the initial value (seed) takes the value of the computed CRC. Is it the expected behaviour? Do I have to call the CRC_DRV_Configure() function before each call to CRC_DRV_GetCrcBlock()?

0 Kudos
404 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi,

Please download the latest MCUXpresso SDK software package (Rev.2.3.0) for TWR-K64F board.

There with the CRC example demo, which located at default path:

..\SDK_2.3.0_FRDM-K64F\boards\frdmk64f\driver_examples\crc

There need to re-config the CRC parameters.

Wish it helps.


Have a great day,
Mike

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

403 Views
nicolasguigo
Contributor II

Thanks for the pointers. The demo provided compute different types of CRCs so it makes sense that the CRC module is reconfigured at each call. It still seems a bit strange to have to reconfigure the CRC module before using it even though the CRC computed is exactly the same... writing so, I understand how the module is used in a re-entrant manner. It does make sense but having to call the "configure" function is not intuitive.

0 Kudos
403 Views
Ray_V
Contributor V

It does seem counter intuitive at first, but it is useful to do it this way.

Say you want to use the function to verify the contents of a serial flash and you don't have enough RAM to load it all.

You can load to RAM a portion at a time and call the function each time without re-initializing in between and this way you can get the CRC for the entire flash, if needed.

Besides, you don't need to re-initialize every time you want to calculate a CRC using the same algorithm, all you need is to "seed"(load initial value) before each calculation.

403 Views
nicolasguigo
Contributor II

Thank you for the input, I didn't think of it as I only use the CRC to validate data in a communication protocol and some small parts of the flash (config data). Checking the CRC for the entire flash is indeed one good reason for designing it the way it is.

0 Kudos