2018-01-17 01:52 AM
Hello everyone
I have some trouble with the CRC unit on my STM32F407 MCU.
Before each time I am going to use it to calculate a checksum, I reset it and after doing so I double check that the CRC data register (CRC_DR) is as what is expected (just 1s, 0xFFFF_FFFF). This is not always the case and I'm confused why.So far my application, that uses the CRC unit, seems to be working fine. I don't get any false positive errors (i.e. the CRC unit says the checksum was incorrect when it wasn't).I could just ignore this check and hope that nothing is wrong, but I have a bad gut feeling about doing that (something might actually be wrong).I speculate that I perhaps there's a timing issue of some sort. That the CRC unit needs a few more clock cycles before its data register has the correct reset value.
Do you have any ideas about what could be wrong?
I would really appreciate any help with this issue.
Best regards
NilsPS
Before I use the CRC unit, I enable the CRC clock by setting CRCEN bit in RCC_AHB1ENR and then I set the CRCRST bit in RCC_AHB1RSTR and then clear it.I reset the CRC by setting the reset bit in the control register of the CRC unit (CRC_CR).#crc #stm32-f42018-01-17 01:56 AM
Hello,
Please edit your thread and put a meaningful title for it, not a problem description.
-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2018-01-17 07:24 AM - edited 2023-08-06 08:27 AM
Posted on January 17, 2018 at 16:24
I don't know if it's the same issue causing the symptoms you experience, but CRC certainly has timing issues
https://community.st.com/0D50X00009XkW6NSAV [reconstructed]
JW
2018-01-17 07:40 AM
In the debugger, or with code you share that demonstrates the issue?
Make sure the variables/register are defined as volatile. Not had issues with F4 CRC unit here.
2018-01-17 09:06 AM
As it is very likely a timing-related issue, it's vital to see the relevant disasm.
On second thought, it may be a different issue than the one what I've observed and linked to above - as reset is performed through RCC, this may be the result of different timing of RCC and CRC (which is an AHB peripheral - this issue is usually demonstrated as GPIO problems when set immediately after clock enabled in RCC).
Or it may be both.
JW
2018-01-17 09:36 AM
It would be depressingly sad if the CRC logic had timing issue, these things can be implemented at single cycle to very high speeds (should be faster than a 32-bit Full Adder). Seen reports of 4 cycles, but the AHB/APB are of that order too.
2018-01-17 09:44 AM
CRC is on AHB1 in 'F4 so AHB/APB shouldn't be an issue.
My findings were that you can churn in data as fast as you can, except with the first datum you have to wait the 4 cycles after having CRC reset by writing to its control register.
JW
2018-01-17 09:54 AM
I don't remember the details exactly, but IIRC the calculation takes 4 cycles per datum, too, except that fast writes to DR imply waitstates. As RM0090 puts it:
The write operation is stalled until the end of the CRC computation, thus allowing back-to-
back write accesses or consecutive write and read accesses.But don't worry, Cube's implementation hopefully inflicts more than 4 cycles per write.
JW
2018-01-17 10:03 AM
I think the write buffers to the AHB/APB are going to implicitly take 4 cycles
Things like
TIM2->CNT += 8; // Don't really advance the timer
2018-01-17 10:15 AM
Yes, but as I've said above, in 'F4xx, CRC is *not* on APB; it's on AHB.
JW