• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 911 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UARTCharPut Send Buffer slowing down

Bruno Saraiva
Guru 13040 points
Other Parts Discussed in Thread: TM4C1294NCPDT

Gentlemen,

I'm working on this project on TM4C1294NCPDT. There is a lot of serial communication involved among 6 uarts. They have all been working well until now.

Suddenly one of the boards became slow. Checking every routine, I found that the code is slowing down on UARTCharPut, specifically while waiting for the output buffer to have room:

while(HWREG(ui32Base + UART_O_FR) & UART_FR_TXFF)

This UART is configured at 921600, and it has been working fine. The exact same code runs well on other boards. I'm not asking where to blame on the Tiva MCU, but rather asking for help to better understand this service on the hardware level. What exactly makes the UART not be available?

I do expect that the UART speed, at 921600, is slower than the system clock, and after a while new bytes that come in via software would have to wait until the uart clock actually ticks all bits out of the port... but is there any "successful transmission verification"? I know the uart engine doesn't even care if the other end of the cable is connected to a receiver or not, but is there something that can cause an abnormal delay on the transmission on the HW level? Could a bad RS422 driver on that line cause such behaviour?

Thanks for your inputs in advance!

  • 0
    Guru 20670 points
    Hi Bruno,

    First I would check with a logic analyzer if there is a problem with the RS422 driver.

    Just some notes on what makes the UART not available:
    What causes the UART to be "not available" is a full FIFO. The UART has a FIFO to hold up to 18 data bytes (basically 18 packets of data even if in 5bit data mode).
    That's a pretty high speed. I think using the DMA would be much better.

    It is also possible to instead use a interrupt. The FIFO can trigger a DMA transfer or an Interrupt when it's 1/8 or less full, 1/4, and some others.

    Other that might help you with code being blocked is using instead UARTCharPutNonBlocking(). Instead of waiting for the FIFO to be have a space available it returns 1 or 0 if it was successful in putting data in the FIFO. So you can try to put something, if it fails the code can go do other thing and then come back to see if it can now send something.
    Note that this will not make the UART transmission faster.
  • 0
    Guru 13040 points
    Luis Afonso,

    I had some backup boards and they are working fine, so for the time being I will continue with the development using what is (hopefully) good. I don't know why it was behaving as FIFO full, but I can't test any further right now. Will post some extra comments later if I have useful info.

    But the failure made me do some tests this morning, and it is indeed an extreme waste of time to use UARTCHarPut! It gets much worse on another uart port of the same board, which is just an RS232 console output to a PC: a message that is 120 characters long naturally takes "forever" and holds the processor meanwhile!

    It was on my to-do-list already, but now it is high on the list: serial transmissions will soon become a DMA task here!

    Saudacoes and thanks for the reply!
  • 0
    Guru 92251 points

    Bruno Saraiva said:
    I know the uart engine doesn't even care if the other end of the cable is connected to a receiver or not, but is there something that can cause an abnormal delay on the transmission on the HW level?

    The UART has an option to enable hardware flow-control. If CTS flow-control is enabled the UART will only transmit if the CTS input is asserted.

    What is the state of the CTSEN bit for the UARTs?