Trouble with the CRC unit on STM32F407

[Nils B]

Posted on January 17, 2018 at 10:52

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

Nils

PS

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-f4

[Amel NASRI]

Posted on January 17, 2018 at 10:56

Hello,

Please edit your thread and put a meaningful title for it, not a problem description.

-Amel

[waclawek.jan]

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

[Tesla DeLorean]

Posted on January 17, 2018 at 16:40

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.

[waclawek.jan]

Posted on January 17, 2018 at 17:06

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

[Tesla DeLorean]

Posted on January 17, 2018 at 17:36

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.

[waclawek.jan]

Posted on January 17, 2018 at 17:44

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

[waclawek.jan]

Posted on January 17, 2018 at 17:54

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

[Tesla DeLorean]

Posted on January 17, 2018 at 18:03

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

[waclawek.jan]

Posted on January 17, 2018 at 18:15

Yes, but as I've said above, in 'F4xx, CRC is *not* on APB; it's on AHB.

JW