waclawek.jan

Erratum "Delay after an RCC peripheral clock enabling" - suggested workaround fails to work

Discussion created by waclawek.jan on Apr 7, 2017
Latest reply on Apr 10, 2017 by waclawek.jan

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.

 

JW

 

PS. I experimented with this as it appears to have a similar timing relationship as the CRC-reset-to-data issue I reported here.

Outcomes