Why doesnt the Tc flag in usart clear?

[Mohammad Rostamian]

Posted on March 07, 2018 at 22:25

Hi

I use stm32f407 to communicat with rs485.

I use DMA to transmit data. For controllig dirction pin, I check the USART_FLAG_TC. Whet it is set, I will push Dirction pin low and clear the 

USART_FLAG_TC by writing with 0. But it dosent clear. I must clear again. Other side, if using delay about 1us befor clearing that flag, it will be clear.

Does anybody have idea?

Best regards

[Tesla DeLorean]

Posted on March 07, 2018 at 22:57

I would not probe the state of the USART->SR in the debugger.

It is not clear to me why you would need to explicitly clear it, when you see it is high change the direction control to input, and when you next go to output reverse the direction to output and write the USART->DR, this should immediately clear TC, and it will reassert when TXE=1 and the data transits the shift register on to the wire.

In the time it takes you to eye-ball it in the debugger, the data has already cleared the wire.

[Mohammad Rostamian]

Posted on March 08, 2018 at 15:22

I use this flag in pulling mode. To optimise my code, I check this flag, when this flag is set, then I clear this flag and push the driction pin low for waiting receiving new packet. If I dont clear this bit, I must push low the driction pin in every interval, that not necessary.

[Tesla DeLorean]

Posted on March 08, 2018 at 17:50

Ok, but if that isn't working properly for you, consider alternatives where you carry state information, and don't rely on the flag in the same way.

If you believe the hardware isn't behaving properly/appropriately you're going to need to decompose this into a very clear example/sample to provide to the validation groups.

Consider abstracting ALL code that reads USART->SR to a SINGLE function, which also reflects the TC bit to a GPIO so you can monitor/review with a scope.

[Mohammad Rostamian]

Posted on March 09, 2018 at 16:16

Please Can you explain your answer,clearer?

I dont undrestand your purpose.

[Tesla DeLorean]

Posted on March 09, 2018 at 16:31

Which part?

That your driver understands if it is in a receive/transmit mode and which direction it has set the interface independent of TC?

That you isolate the code touching USART->SR so there aren't multiple places that clear/review the TC bit?

That you create an example demonstrating your failure case?

That you reflect the TC bit onto a GPIO pin so you can compare/contrast that against the direction of the interface or other signalling in the time domain with a scope?