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.

[Nils B]

Posted on January 30, 2018 at 09:52

Hello everybody

Thank you for your responses.

I believe that I've solved the problem.

I changed my reset function. Instead of just checking the CRC return value (the DR registry) once right after the CRC reset (writing a 1 to the reset bit in the CR registry), I added a for loop that does this check twice.

If the check returns the correct value, the reset function returns successfully. If both of these attempts return an incorrect answer the function will throw a run-time exception. So far, the latter has never happened so I believe I have solved the problem. My guess is that the CRC unit simply needed a few extra clock cycles to reset properly.

I hope that this can help.

Best regards

Nils

[waclawek.jan]

Posted on January 30, 2018 at 10:20

My guess is that the CRC unit simply needed a few extra clock cycles to reset properly.

This is what I've said in

https://community.st.com/0D50X00009XkW6NSAV

linked to above, except that I didn't attempt to read back (I see no reason to do that), just dumped data on it, as expected functionality-wise.

I'd l¤ve to hear ST to comment in a relevant way.

JW