STM32 USART Tx inaccuracy issue

[adamajames]

Posted on September 22, 2013 at 16:39

I'm seeing an issue when I transmit a byte using the USART (USART 2 in my case).

I need an accurate delay between bytes of 5ms. So when a 5ms timer expires I transmit a byte. However with the code below I'm seeing a small variable time (0-120us) between instructing the USART to transmit and when it actually starts.         TimerInterrupt(TRUE);          TransmitByte(IsoTxBuffer[TxByteCounter++]);                    TestPinToggle();    // Uncomment this line when performing timing checks with a scope          while (USART_GetFlagStatus(USART2, USART_FLAG_TXE) == RESET);         TestPinToggle();   // Uncomment this line when performing timing checks with a scope Now a way around it I have found is to disable the USART and immediate re-enable it. This process takes a constant time of around 1ms so I could do this each time and reduce my delay:     TimerInterrupt(TRUE);      UartEnable( FALSE ); // Having these two line in adds a 1ms delay...     UartEnable( TRUE ); // But stops the time inaccuarcy waiting for the TXE flag     TransmitByte(IsoTxBuffer[TxByteCounter++]);      TestPinToggle(); // Uncomment this line when performing timing checks with a scope      while (USART_GetFlagStatus(USART2, USART_FLAG_TXE) == RESET);     TestPinToggle(); // Uncomment this line when performing timing checks with a scope    However I would like to understand why I'm getting this issue and if there's a better solution KR Adam

[Tesla DeLorean]

Posted on September 22, 2013 at 17:15

Perhaps you should be front testing for TXE, to know the buffer is empty, or be using the TC bit to appreciate when the last bit hit the wire?

[adamajames]

Posted on September 22, 2013 at 19:33 Hi Clive1, Thanks for your response - I have front tested for TXE, but it becomes 'un-empty' again for this random 0-120us period as soon as I call the transmit and then after this delay the transmit begins.

[adamajames]

Posted on September 22, 2013 at 19:50

Hi Clive1,

Thanks for your response - I have front tested for TXE, but it becomes 'un-empty' again for this random 0-120us period as soon as I call the transmit and then after this delay the transmit begins.

[Tesla DeLorean]

Posted on September 23, 2013 at 00:30

Does the 120us relate at all to the baud rate? What is the baud rate? 9600?

[adamajames]

Posted on September 25, 2013 at 15:08

Baud rate is 10k4. I don't see a connection.

[waclawek.jan]

Posted on September 25, 2013 at 15:22

The connection is, that the bit-duration counter might be free-running, not being reset from writing to the data register.

Try disabling/enabling the transmitter between bytes (USART_CR1.TE); and if it does not help (which might be the case, given note 2 in this bit's description), try rewriting the baudrate divider to 1 betwen bytes. JW

[adamajames]

Posted on September 26, 2013 at 16:27

Hi Jan,

Disabling an re-enabling does work and produces a fixed reliable delay of around 1ms (see my original post). I don't think this is how the chip designers originally intended it to work so really I'm just after confirmation that this is a necessary and acceptable work around for a little mistake in the chips design. Adam

[Tesla DeLorean]

Posted on September 26, 2013 at 17:50

Not sure anyone here has a gate-level understanding of the design. I'm also not sure that the bit placement with a granularity of the baud clock dividers is a flaw or oversight, but rather just a simple/elegant implementation. If plotted against the baud clock, all output bits would likely appear synchronous, and the placement jitter you observe relates to the phase of the baud divider wrt the writing of DR.

Enabling may cause a synchronous reset of the divider, as might writing the BRR, or manipulating it, perhaps with 0 or 1, or just rewriting the current setting. You'll need to find someone inside ST to talk to about the gate-level design, try your ST or FAE contacts.