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

@waclawek.jan FWIW, I can't quite duplicate this on a STM32F411 with max clock (this particular chip errata is the same). I tested GPIO->ODR, CRC->DR and TIM2->ARR. Only GPIO and CRC needed a delay, and a delay of 1 NOP or 1 read from either register worked. TIM2 matched your results (no delay needed). I even used maxed AHB/APB prescalers which made no difference in the results (despite what errata suggests).

Ticks were the difference in DWT->CYCCNT before/after the stores and loads.

GPIOB->ODR:
[00.008080] NOP=0, READ_ENABLE=0, READ_PERIPHERAL=0, result=0, ticks=5 <--
[00.012273] NOP=0, READ_ENABLE=1, READ_PERIPHERAL=0, result=1, ticks=6
[00.016467] NOP=0, READ_ENABLE=0, READ_PERIPHERAL=1, result=1, ticks=6
[00.020661] NOP=0, READ_ENABLE=0, READ_PERIPHERAL=0, result=0, ticks=5 <--
[00.024854] NOP=1, READ_ENABLE=0, READ_PERIPHERAL=0, result=1, ticks=6
[00.029048] NOP=2, READ_ENABLE=0, READ_PERIPHERAL=0, result=1, ticks=7
[00.033250] NOP=3, READ_ENABLE=0, READ_PERIPHERAL=0, result=1, ticks=8
[00.037444] NOP=4, READ_ENABLE=0, READ_PERIPHERAL=0, result=1, ticks=9
[00.041637] NOP=0, READ_ENABLE=0, READ_PERIPHERAL=0, result=0, ticks=5 <--

CRC->DR:
[00.008093] NOP=0, READ_ENABLE=0, READ_PERIPHERAL=0, result=4294967295, ticks=5 <--
[00.012312] NOP=0, READ_ENABLE=1, READ_PERIPHERAL=0, result=3284517068, ticks=10
[00.016532] NOP=0, READ_ENABLE=0, READ_PERIPHERAL=1, result=3284517068, ticks=10
[00.020749] NOP=0, READ_ENABLE=0, READ_PERIPHERAL=0, result=4294967295, ticks=5 <--
[00.024968] NOP=1, READ_ENABLE=0, READ_PERIPHERAL=0, result=3284517068, ticks=10
[00.029188] NOP=2, READ_ENABLE=0, READ_PERIPHERAL=0, result=3284517068, ticks=11
[00.033416] NOP=3, READ_ENABLE=0, READ_PERIPHERAL=0, result=3284517068, ticks=12
[00.037636] NOP=4, READ_ENABLE=0, READ_PERIPHERAL=0, result=3284517068, ticks=13
[00.041853] NOP=0, READ_ENABLE=0, READ_PERIPHERAL=0, result=4294967295, ticks=5 <--

TIM2->ARR:
[00.008078] NOP=0, READ_ENABLE=0, READ_PERIPHERAL=0, result=123, ticks=5
[00.012276] NOP=0, READ_ENABLE=1, READ_PERIPHERAL=0, result=123, ticks=6
[00.016476] NOP=0, READ_ENABLE=0, READ_PERIPHERAL=1, result=123, ticks=23
[00.020675] NOP=0, READ_ENABLE=0, READ_PERIPHERAL=0, result=123, ticks=5
[00.024873] NOP=1, READ_ENABLE=0, READ_PERIPHERAL=0, result=123, ticks=6
[00.029071] NOP=2, READ_ENABLE=0, READ_PERIPHERAL=0, result=123, ticks=7
[00.033277] NOP=3, READ_ENABLE=0, READ_PERIPHERAL=0, result=123, ticks=8
[00.037476] NOP=4, READ_ENABLE=0, READ_PERIPHERAL=0, result=123, ticks=9
[00.041674] NOP=0, READ_ENABLE=0, READ_PERIPHERAL=0, result=123, ticks=5

Example code where READ_ENABLE=1:

08002aa8: ldr r2, [r6, #0] start = DWT->CYCCNT;
08002aaa: str r0, [r4, #0] RCC->AHB1ENR |= RCC_AHB1ENR_GPIOBEN;
08002aac: ldr r1, [r4, #0] [r1] = RCC->AHB1ENR
08002aae: str.w r12, [r5] GPIOB->ODR = 1;
08002ab2: ldr r3, [r6, #0] end = DWT->CYCCNT;
08002ab4: ldr r1, [r5, #0] result = GPIOB->ODR;

 Registers at start of that code:

96 MHz clock, prefetch enabled, data cache enabled, instruction cache enabled.

[00.002678] Clock description:
[00.002839] - System clock selection: PLLCLK using HSE @ assumed 8 MHz
[00.002994] - PLL scalers: M=/4, N=x192, P=/4, Q=/8
[00.003133] - Prescalers: AHB=/1, APB1=/2, APB2=/1
[00.003324] - Clocks: VCO=384 MHz (in range), SYSCLK=96 MHz, HCLK=96 MHz
[00.003508] - Clocks: PCLK1=48 MHz (timers 96 MHz), PCLK2=96 MHz
[00.003612] - Clocks: 48MHz=48 MHz

> I'm not necessarily defending the HAL implementation, but they do more than just read the register with a single LDR instruction so probably introduce enough of a delay to not cause issues.

Let's see:

#define __HAL_RCC_GPIOA_CLK_ENABLE() do { \
 __IO uint32_t tmpreg = 0x00U; \
 SET_BIT(RCC->AHB1ENR, RCC_AHB1ENR_GPIOAEN);\
 /* Delay after an RCC peripheral clock enabling */ \
 tmpreg = READ_BIT(RCC->AHB1ENR, RCC_AHB1ENR_GPIOAEN);\
 UNUSED(tmpreg); \
 } while(0U)

Maybe. As result of readback+masking goes into a volatile variable, at least the mask (AND) should be performed, even if an aggressive optimizer may locate the variable into register and thus perform nothing more than the mask (note that according to C99, what constitutes a volatile access is implementation-defined). But I am not particularly interested in Cube/HAL.

> Feels like a DSB would be a lot cleaner.

I am not fan of using DSB for this kind of problems. It has enough mystical air to sound to be the ultimate solution, but it's not. It does not see beyond the boundary of the processor, and this is exactly the problem which happens completely outside the scope of the processor - in the mcu's fabric. That's why we see different results for different STM32 variants, even if they are all based on the same processor.

I never subscribed to the notion of "hardware abstraction" or "drivers" or any similar high-level concept. So I don't use one ultimate solution, and I also don't feel a need to have one. I feel a need to *understand* the need for solution, and to have a clean avenue towards it.

I use the STM32 as I ever used any other microcontroller, and I've always enabled clocks, set up (most of the) pins etc. at one single point, at the startup (there are of course justified exceptions, where a clock or pin setting has to be modified runtime - but they are exactly that, exceptions). And there are always several other clock registers to set up before I got to setting up the pins or any other peripheral. So this issue simply never had a chance to catch me... :)

Nonetheless, this is just another of the zillions of gotchas one has to be aware of.

My real concern is the erratum, which at least for the 'F407 is incorrect and this is because I consider documentation (i.e. PM+RM+DS+ES+AN) to be the ultimate source of the most accurate and detailed data on the STM32's internals. So, if it's incorrect, it's of utmost importance to correct it ASAP.

I wish ST to adopt this attitude.

JW

I've reconstructed the CRC-specific thread.

JW

There is an another topic about these issues. By the way, the document Jan talks about, is now ES0182 - Rev 14 and the section is "2.2.13 Delay after an RCC peripheral clock enabling". And for L4 and F7 series the issue is not present in errata, because they documented it in the reference manuals. Actually that is the place, where it should be, because it is not a flaw, but a deliberate design feature. Anyway, there are two potential code issues with peripheral clock enabling.

First, the code must ensure that the write to the corresponding RCC register has actually been completed. The DSB instruction introduces a delay of at least 1 cycle and drains the CPU write buffer, but it doesn't know about the buses, peripherals or anything outside of the CPU. For this issue the less restrictive DMB instruction does the same, but ST doesn't mention it because they don't understand the difference between these two instructions. The NOP instruction architecturally doesn't guarantee anything at all and should be used only for padding. Though it does provide a delay of 1 cycle on at least the Cortex cores M0/M3/M4. I don't know about M23/M3x and I definitely wouldn't rely on it on M7/M55/M85. The only correct solution, which forces the write to always go completely though down to the RCC, is to read back the corresponding or any other RCC register.

Second, the code must wait for a clock enable logic to synchronize with the peripheral bus and actually enable the peripheral clock. For F4 series ST states that the delay is 2 cycles for AHB and 1+PRESC cycles for APB buses. For AHB they say that it's AHB cycles. For APB they don't say anything, but it should also be AHB (!) cycles. If so, this translates to 2 peripheral clock cycles for AHB and (1 .. 2] peripheral clock cycles for APB. This also becomes clear by reading the F7 reference manuals like RM0410 Rev 4 section "5.2.12 Peripheral clock enable register (RCC_AHBxENR, RCC_APBxENRy)", which simplifies this and explicitly states that the delay must be 2 peripheral clock cycles. The same is stated in the reference manuals for L4 series, just the very important word "peripheral" is missing in those.

Taking it all into account, a correct code looks like this:

RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN;
(void)RCC->AHB1ENR;
// Wait for 2 peripheral clock cycles.

// Use the peripheral.

So, from the three "workarounds" in errata, the two DSB and NOP related ones are just a complete nonsense and doesn't guarantee anything. The third read-back related one actually means a read-back from RCC, which they also fail to state, and solves just the first issue, but ignores the second one, and this is what the HAL and LL implements. The HAL and LL in addition does a bitwise AND operation, but that is also a nonsense, which doesn't guarantee anything. As I'm saying it all the time - almost all of the SPL/HAL/LL/Cube code is broken. And not only the code, but even, when ST's documentation gives some advice on how to write the code, the advice is also often inadequate, wrong or just a nonsense.

> And for L4 and F7 series the issue is not present in errata, because they documented it in the reference manuals.

Oh, I didn't know that, thanks.

> The NOP instruction architecturally doesn't guarantee anything at all and should be used only for padding.

I don't really care for the "architectural" things. That's just another word to say "nonportable", but I don't subscribe to the notion of universal portability in microcontrollers, in the same way as I don't subscribe to thus don't seek an universal bulletproof solution independent of context (a.k.a. driver).

So, if a NOP does provide a reliable at-least-one-cycle delay on CM4, and if the problem's reliable solution is at-least-N-cycles delay, then for me N NOPs on CM4 are a perfect solution too. I really don't care that it won't work on CM7 or CM23, as they are attached to a different harness which modifies the problem anyway.

JW

https://community.st.com/t5/stm32-mcus-embedded-software/stm32-clock-and-delay-helper-functions/td-p/593082

Hello @waclawek.jan  

Thank you all for this interesting discussion.

Workarounds are a list of applicable measures. So, it is possible some measures are recommended in specific situations and dependent from the use case.

>if a NOP does provide a reliable at-least-one-cycle delay on CM4

NOP instruction does not guarantee one cycle delay. It can increase execution time, leave it unchanged, or even reduce it. However, it is used for instruction alignment, not necessarily time-consuming. Maybe 2 LDR instructions introduce enough delay.

Did HAL macro fail? If not, what do you suggest?

Hi @FBL ,

An error is an error. No matter whether any Cube/HAL macro works or not, no matter that in other STM32 the workaround works, no matter that there exist specific circumstances when the workaround works - if in STM32F407 exist conditions when the workaround does not work, as proven by the experiment, it's then not a workaround and shall be removed from the STM32F407 errata.

JW

PS. You are quoting from Cortex-A manual, which is irrelevant for Cortex-M4.