USART TC is set when initialising USART RCC

[Zainka]

Posted on December 16, 2017 at 14:20

Hello. I am currently in a discussion at stackoverflow.com regarding the USART1 TC flag which become set as soon as the USART clock (RCC) is enabled.

https://stackoverflow.com/questions/47838080/stm32f407-usart1-clearing-usart-flag-tc-requires-pgm-to-be-halted-before-actua

To repeat the problem short, the thing is that when RCC for USART1 is enabled, TXE and TC flag becomes set. It has been difficult to clear the TC flag thus when I send data and enables the TC interrupt I get the interrupt twice. Once because the flag is already set, and second when the actual data being sent is transmitted (i.e. transmission completed). When trying to clear the flag before enabling the interrupt by writing 0 to the SR register, the attempt to clear the flag is only working if stepping the code manually in the debugger.

However... If I enable the interrupt and clear the SR register in the IRQ handler the flag is cleared. After this the system works perfectly.

So there is two issues here.

1) In my opinion the TC flag should never have been set after initialisation of USART RCC before anything has been actually transmitted, A behaviour which the datasheet confirm that should have been the truth by : This bit is set by hardware

if

the transmission of a frame containing data is complete

and

if

TXE is set. TXE is indeed set, but there have not been completed any transmissions yet and thus TC should not have been set.

2) Clearing the flag should have work with code USART1->SR=0; also at runtime and not only when stepping the code.

Your opinions?

#usart #stm32f407 #irq

[Tesla DeLorean]

Posted on December 16, 2017 at 17:26

Why use TC? The TXE flag is what should be used to see if the DR register can take new data into the holding register. TC becomes important if you need to wait for the last bit to hit the wire, ie you want to change baud rate, or change direction of a two-way bus. TC is the SLOWEST method of feeding data, more so with STM32 designs using a USART with a FIFO

Bits in the SR are impacted by access to other registers, I would generally avoid using the debugger to peer into peripheral register states as it is apt to change them due to access side-effects.

If you have to step code to understand what the code does you've got to be very careful about the fact the clocks ticking millions of times faster than you can react and review what's happening. Better to instrument the code to understand the mechanics at operating speeds, and not by sticking your fingers in the gears.