Atomic register write from cmsis by stm32HAL, what's the point?

[SeyyedMohammad]

On the code below:

/* Enable the DMA transfer for transmit request by setting the DMAT bit
		    in the UART CR3 register */
		    ATOMIC_SET_BIT((&huart1)->Instance->CR3, USART_CR3_DMAT);

The HAL used:

/* Use of CMSIS compiler intrinsics for register exclusive access */
/* Atomic 32-bit register access macro to set one or several bits */
#define ATOMIC_SET_BIT(REG, BIT)                             \
  do {                                                       \
    uint32_t val;                                            \
    do {                                                     \
      val = __LDREXW((__IO uint32_t *)&(REG)) | (BIT);       \
    } while ((__STREXW(val,(__IO uint32_t *)&(REG))) != 0U); \
  } while(0)

But how it, and it's subassembly codes really works, and why such wierd instruction to modify a register?

[waclawek.jan]

Cube/HAL anticipates, that UART CR3 will be accessed in both "main" and "interrupt" (or in different tasks in a multitasking environment), and this is one of the standard mechanisms to prevent collisions in this case.

 

JW

[SeyyedMohammad]

Hi @Community member​ 

Thanks for good referencing and simple description.

I'm courious in what scenario we need to have to use it? What scenario will procuces wrong behaviour?

[Tesla DeLorean]

Hard to say, look at the bits where it's used, and the specific MCU it's being applied on, say a multi-core H7..

Peripherals tend to be particularly difficult to work with atomically, as these are windows into complex state-machines, not memory cells.

Where atomic behaviour is critical, the IC designer has typically created a way to do a singular WRITE to the register to change it in a single cycle / action. ie clearing TIM->SR bits, or GPIO->BSRR

The classic RMW on TIM->SR for example can span many TIM CLK cycles, resulting in it clearing/missing interrupts

ie

TIM->SR &= ~1; // Has side-effect of clearing more than UIF if other sources signal between read and write phases.

TIM->SR = ~1; // This is the prescribed usage

This is also a critical failing of Bit-Banding

[SeyyedMohammad]

Hi @Community member​ 

You mean this atomic is to enforce peripheral to accept the change of it's registers or show to us(CPU) it's register in a single clock of CPU, though CPU is not at the same clock frequency of peripheral? doesn't it? But isn' it a contradiction? since they are not typycally in the same clock frequency!

Best regards!

[Tesla DeLorean]

I'm struggling with the value of this ATOMIC macro.

I suspect ST is just using it across a number of STM32 MCU and MPU libraries for consistency sake, or to pass some validation suite.

It looks to be worthless and dangerous from a peripheral side perspective.

Jan's observation about two thread in a single machine seem like reason to use it on certain bits, ie where your main code, or one or more interrupts can modify USART->CR3 to set/clear bits, and without it there's a hazard / race-condition

[SeyyedMohammad]

Then the CPU must be freezes in some cycle to pretend it doing it on single cycle, doesn't it?

[waclawek.jan]

> Then the CPU must be freezes in some cycle to pretend it doing it on single cycle, doesn't it?

No, the mechanism is different here: it does not prevent the "interrupting" process to change the register in question; rather, it is the "interrupted" process which learns that it has been interrupted and then can retry the whole RMW process (that's what the inner do-while cycle does).

JW

[SeyyedMohammad]

Since I'm newbie in this context I can't understand completely, can you explain more, pleasae? I only could understood RMW=ReadWriteModify.

Do you mean:

It doesn't prevent interrupt or thread2 access, it can understand the new interupt is in progress, it wait until thread1 finishes it's job and server interrupt/thread2.

In other word you mean it only freezes on collision, not everytime, doesn't it?

But since it's engaged in while(), then the CPU is actually freezed, but interrupt!!!!!!!! must not happened!?

[Pavel A.]

> It looks to be worthless and dangerous from a peripheral side perspective.

This was already discussed here for STM32F4. IIRC, the ARM docum says that LDREX/STREX should be used only on "normal" memory. How it works on device registers is vendor specific. ST folks wrote this code and tested, so...

The alternative would be __disable__irq() around the RMW operation.