The CRC unit, before performing one round of calculation, should be reset by setting CRC_CR.RESET bit. This is a self-clearing bit, i.e. software sets it, hardware clears. The net result is, that the CRC_DR is set to its default value, 0xFFFF'FFFF. After this, the user can simply dump the data onto CRC_DR and then read out the calculated CRC value from the same CRC_DR. While one calculation step takes 4 AHB cycles, there is no risk of overwhelming the CRC unit, as it automatically inserts waitstates to throttle the writes appropriately.

However, in STM32F407, if a datum is written too soon after setting RESET bit, it gets ignored. Apparently, the reset procedure takes a couple of AHB cycles, and the waitstate mechanism does not cover this case.

In the majority of cases, this problem is covered up by the fact that normally, after writing to CRC_CR, software has to fetch the first datum from the memory before writing to CRC_DR, and time needed for this is apparently sufficient for the CRC unit to finish its reset process. However, in some cases, the first datum to be written is already loaded in some of the processor's registers - e.g. because it has been calculated or fetched beforehand for some other operation, or because it's known to be 0x0000'0001 i.e. identical to the word written into CRC_DR) and the compiler optimalizator spots this and generates two successive instructions to write into the CRC_CR and CRC_DR, thus revealing the problem.

This is one of those issues which has not been confirmed by ST. The suggested workaround (see the thread in STM32 forum linked below) is to read back CRC_DR until RESET bit reads as zero. However, there is no mention of this procedure in RM0090, nor is it followed in any example code (e.g. in Cube). As such, it may work purely coincidentally, wasting enough time to cover up the problem; but then potentially also wasting more than absolutely needed.

As newer STM32 models have extended CRC unit, it is unclear whether this problem pertains to them, too.