Author Topic: UART Tx stalls and incomplete messages  (Read 7321 times)

Offline Raffaele

  • Jr. Member
  • **
  • Posts: 65
    • View Profile
UART Tx stalls and incomplete messages
« on: December 23, 2020, 07:02:58 PM »
Hi,

I'm working with a KL_03 using the UART to transmit (no DMA, just base mode) and I am having issues. Is there anything I need to pay attention to in terms of UART Tx buffer size, baud rate, and transmission duration? Is there a correlation between them, such as a certain buffer size only works with some specific baud rates?

I have a task that runs periodically every few seconds, at each run I print UART messages of different lengths using fnDebugMsg():
1) some messages are cut or not printed completely
2) after some printouts the code stalls (I'm debugging it to understand if the problem is somewhere else or related to UART)
3) I use fnDelayLoop(x) after UART messages, but it looks like that it sometimes helps write more complete messages, other times it doesn't. I don't know how to choose the value for x



Thank you
« Last Edit: December 23, 2020, 07:04:45 PM by Raffaele »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3239
    • View Profile
    • uTasker
Re: UART Tx stalls and incomplete messages
« Reply #1 on: December 23, 2020, 08:07:23 PM »
Hi

When the UART interface is opened an output buffer size is allocated. As you write data to the UART it is first copied to this buffer and then transmitted out via DMA or interrupts. Since the KL03 doesn't support DMA it will always be interrupt driven in your case.

If you write more data than the output buffer can accept the excess date will be dropped.

Before writing data you can check the amount that can be accepted by calling fnWrite() with a zero pointer - see page 9 of https://www.utasker.com/docs/uTasker/uTaskerUART.PDF and if you know that the data wont fit you can choose to wait until there is more space (if it is not basically dimensioned too small) and try again later.

I am not aware of any situation where a UART transmitter has become blocked so you will need to debug to identify whether it is somewhere else in the system or due to some form of corruption.

The use of delays may be giving time for transmission to advance to clear the output buffer so that further data fits but the better method is to have more output buffer space (when the memory allows this) or use SW timer events to delay sending subsequent data.
Note also that a TX_FREE event is available that can be sent when the UART has completed all (or a defined amount) of output data which allows an event driven solution to avoid overflowing the output buffer when its dimension is restricted - see also page 9 of the UART user's manual.

Regards

Mark