USART_SR, clearing sequence of: IDLE, ORE, NF, FE, PE. A silicon level analysis.

[elKarro]

Applies to: STM32L100xx, STM32L151xx, STM32L152xx, STM32L162xx.

Hi,
in order to write robust drivers, I'm kindly asking a few questions to developers who are into the silicon design. This is the 1st:

ref. RM0038 Reference manual Rev 18, paragraph 27.6.1 Status register (USART_SR) vaguely says that error flag(s):
"It is cleared by a software sequence (a read to the USART_SR register followed by a read to the USART_DR register)."

which of the following describes the real case:

0) "It is cleared by a read to USARTx_DR which happens AFTER a read to USARTx_SR, without any other access in between to the USARTx memory space*."

1) "It is cleared by a read to USARTx_DR which happens AFTER a read to USARTx_SR, without any other access in between to the APBx* linked to the USARTx."

2) ???

(*) see 2.3 Memory map - Table 5. Register boundary addresses

Thank you very much in advance.

[TDK]

2) It is cleared by a read to USARTx_DR which happens AFTER a read to USARTx_SR.

No caveats needed.

You'll always have a race condition where the flag can be set again after you clear it, no way around that. But if that happens, your driver should detect it (again) and clear it (again).

[elKarro]

Hi TDK, so:

void fn1(USART_TypeDef *uart) // this will clear
{
uint32_t sr = uart->SR;
uint32_t dr = uart->DR;

...
}

void fn2(USART_TypeDef *uart) // this won't clear
{
uint32_t sr = uart->SR & (USART_SR_IDLE | USART_SR_ORE | USART_SR_NE | USART_SR_FE | USART_SR_PE);
uint32_t dr = uart->DR;

...

}

is that so?

[TDK]

Those will both clear. In both of them, you're reading SR, then you're reading DR.

[Tesla DeLorean]

Personally I think this is a Schrödinger's Cat problem.

I think SR will clear simply by reading DR, you don't have to look at it

On subsequent STM32 the U(S)ARTs can have sticky error bits, that must be cleared explicitly.

Just be conscious that any read of DR has the potential to change SR's state, which is why floating a debug view window over the peripheral registers is so invasive/dangerous.

Causes headaches on peripherals with FIFO's that present in the address space, potentially decoding over a broad range of addresses.

SR can also change independently of the APB bus accesses, and faster too.

This can be particularly problematic when using the TIM->SR &= ~1 RMW forms, the HW/IC is designed not to use those forms, but just a write which performs an atomic AND operation

[STea]

Hello @elKarro ,

After checking I can confirm that scenario 2 is the right scenario:

2) It is cleared by a read to USARTx_DR which happens AFTER a read to USARTx_SR.

even if other accesses are done in between. it does not matter, and it doesn't matter either if it is done by CPU or DMA.

The state machine of UART needs to detect the sequence as described in RM (a read to the USART_SR register followed by a read to the USART_DR register) things can happen in between and access to the UART address space as well.

BR

 

[elKarro]

Thank you very much @STea !
Maybe this post clarified that joke you asked me about :- D
Thanks again.

[STea]

Hello @elKarro ,

yep, it's clear as your clearing sequence of: IDLE, ORE, NF, FE, PE . :p

BR