• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 424 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.

TM4C1294KCPDT: Cannot communicate properly when using UART for high-speed communication

Sh.Sasaki
Guru 13625 points
Part Number: TM4C1294KCPDT


Hi experts,

My customer is unable to communicate properly with the UART at 230,400 bps.

Details are below.
When they send the data "00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F" from PC to the UART of TM4C, the TM4C side can only read the data up to 07.
At this time, the Rx FIFO appears to be empty (RXFE bit = 1 in the UARTFR register).
Also, even if the UARTDR register is Read, no normal data can be read.
Then they send "10 11 12 13" data from PC, TM4C reads "08 09 0A 0B". (It seems that the sent data and received data are shifted by 8Byte)

The data shift is not constant, but with high probability, it shifts by the number of bytes set in RXIFLSEL of UART Interrupt FIFO Level Select (UARTIFLS).

Also, the following has been found.

  • If the Baudrate is lowered or the transmission interval is increased, this problem becomes less likely to occur.
  • They have confirmed with an oscilloscope that there is no problem with the transmitted waveform.
  • No error flag such as overrun error is raised.
  • The error bits such as BE, PE, FE, and the UARTRIS and UARTMIS bits remain 0. There is no error.

Do you know why the error bit is not set even though communication is not working properly?

Do you have any idea what causes this problem?

Best regards,
Sasaki

  • 0
    Guru 56033 points
    Sh.Sasaki said:
    • No error flag such as overrun error is raised.
    • The error bits such as BE, PE, FE, and the UARTRIS and UARTMIS bits remain 0. There is no error.

    How are they testing these flags? Are the RX bytes being buffered and flushed? The FE flag is tricky to deal with the RX interrupt when the FIFO exceeds 16 bytes. Trying to manage 32 byte reads is even more challenging.

    Testing status flags first during the INTRX, INTRT interrupts would be a suggested method.

  • 0
    TI__Guru**** 191906 points

    Hi Sasaki,

     Some questions:

      - Did you enable the RXFIFO by calling UARTFIFOEnable()?

      - What UART FIFO level select did you pick to generate the FIFO interrupt? Which FIFO level gives better result?

      - Can you set up a system ping-pong buffers to make sure all incoming UART data are received. Is it possible that some of the data in the buffer are overwritten as the incoming UART stream is too fast?

  • +1
    Guru 13625 points

    Hi GI-san,Charles-san,

    Thank you for your reply.

    The problem was that the interrupt handler priority setting was missing and the priority remained at 0. Fixing this solved the problem.
    Best regards,
    Sasaki
  • +1 in reply to Charles Tsai
    Guru 56033 points
    Charles Tsai said:
    What UART FIFO level select did you pick to generate the FIFO interrupt?

    That would be a good suspect for the posted problem. Perhaps the issue of global interrupt priority will manifest other areas of contention as more HS mode data enters the FIFO via rapid and reoccurring local interrupt events.