problem w/ setting polynomial for CRC

[BradWalker]

I'm trying to set the polynomial for the CRC block and having some difficulty. I want to set the CRC block to compute a CRC-32K (Reversed Koopman) over my data.

Here are the details

CRC-32K (reversed Koopman polynomial) - 0xEB31D82E

Input data - 0x31, 0x32, . . ., 0x39

I expect the resulting CRC to be 0x2D3DD0AE

How I setup my STMh755 CRC block

#define CRC_POLYNOMIAL_32B 0xeb31d82e
static const uint8_t aDataBuffer[] = {
0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39
};

/*##-1- Configure the CRC peripheral #######################################*/
CrcHandle.Instance = CRC;

/* The default polynomial is not used. It is required to defined it in CrcHandle.Init.GeneratingPolynomial*/
CrcHandle.Init.DefaultPolynomialUse = DEFAULT_POLYNOMIAL_DISABLE;

/* Set the value of the polynomial */
CrcHandle.Init.GeneratingPolynomial = CRC_POLYNOMIAL_32B;

/* The user-defined generating polynomial generates a
8-bit long CRC */
CrcHandle.Init.CRCLength = CRC_POLYLENGTH_32B;

/* The default init value is used */
CrcHandle.Init.DefaultInitValueUse = DEFAULT_INIT_VALUE_ENABLE;

/* The input data are not inverted */
CrcHandle.Init.InputDataInversionMode = CRC_INPUTDATA_INVERSION_NONE;

/* The output data are not inverted */
CrcHandle.Init.OutputDataInversionMode = CRC_OUTPUTDATA_INVERSION_DISABLE;

/* The input data are 32-bit long */
CrcHandle.InputDataFormat = CRC_INPUTDATA_FORMAT_BYTES;

if (HAL_CRC_Init(&CrcHandle) != HAL_OK)
{
/* Initialization Error */
Error_Handler();
}

/*##-2- Compute the CRC of "aDataBuffer" ###################################*/

uwCRCValue = HAL_CRC_Calculate(&CrcHandle, (uint32_t *)&aDataBuffer, BUFFER_SIZE);

A couple of issues:

1 - I get a return error from HAL_CRC_Init(). Why does HAL layer only allow ODD parity polynomials?

  /* Ensure that the generating polynomial is odd */
  if ((Pol & (uint32_t)(0x1U)) ==  0U)
  {
    status =  HAL_ERROR;
  }

2 - Am I missing something in setting up the CRC block?

Thanks.

[Tesla DeLorean]

The polynomial left aligns, so the top end bit abuts the end of the register for the application of the data and the feed back. Consequently the LOW order bits not used by the polynomial can be ZERO

[Tesla DeLorean]

>>.. it could be never tested/verified as at industry level

I'm going to disagree with this sentiment, but notwithstanding, it's not the place of the application (library) code to formally test the polynomial supplied by the user for viability.

It's the user's responsibility to select and test the polynomial and viability of their implementation with test vectors and validation patterns. Usually such things are bounded by a specific algorithm or protocol they are attempting to implement / replicate.

From my perspective "functional safety" for this, hash, and crypt, units are achieved by applying and checking industry / government supplied test vectors / patterns, ie FIPS, NIST, etc.  The secondary benefits being of substantially exercising a lot of gates and logic deep in the design and diffused on silicon. And provide end-to-end confirmation.

I test these things, because frankly some of the library code does things that are incredibly dangerous, like fiddling with the CRC unit on-the-fly to validate STM32 hardware is being used, and tampering with initialization and seeding values. I seriously struggle to understand how these passes muster.