In STM32F40x and STM32F41x Errata sheet DocID022183 Rev 8, 2.1.13 Delay after an RCC peripheral clock enabling, there are three workarounds suggested.
The third one is:
3. Or simply insert a dummy read operation from the corresponding register just after enabling the peripheral clock.
It is not clear, what is "corresponding register" - is it the register of RCC, or the register of peripheral which clock is being enabled?
However, regardless of this, it does not appear to be working in either case. In the following code (with all clocks settings at their reset defaults):
8000214: 2201 movs r2, #1
8000216: 6b18 ldr r0, [r3, #48] ; 0x30
8000218: f440 5080 orr.w r0, r0, #4096 ; 0x1000
800021c: 6318 str r0, [r3, #48] ; 0x30
800021e: 6b18 ldr r0, [r3, #48] ; 0x30 <------------------ readback
8000220: 600a str r2, [r1, #0]
8000222: 2000 movs r0, #0
8000224: bf00 nop
8000226: bf00 nop
where r3 is preloaded with RCC address and r1 with CRC address, the readback is performed just after the write to RCC, and subsequently the now-presumably-enabled CRC data register is written, which should result in CRC for one word containing 0x00000001 being calculated, so CRC->DR should read as 0xC3C5C0CC. However, placing a breakpoint at the last nop and reading out CRC->DR shows that it is at 0xFFFFFFFF, so the previous write to CRC->DR has been ignored.
I tried also
800021e: 6808 ldr r0, [r1, #0] <------------------ readback
with the same result.
The two nops or one dsb at that place (i.e. the two other suggested workarounds) work as expected, CRC->DR contains 0xC3C5C0CC at the breakpoint.
ST, please comment.
PS. I experimented with this as it appears to have a similar timing relationship as the CRC-reset-to-data issue I reported here.