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

TMS320F28377S - TXRDY SCI bit is not automatically cleared as the documentation explains

JFerCep-Ing
Intellectual 330 points

Hello,

I'm working with the uart driverlib (v200) and I'm developing a protocol over the SCI module. All was working as expected until I had to take a closer look to the interrupt management in order to avoid some concurrence issues.

I have seen that the TXRDY is not immediately reset when I write the SCITXBUF register using the UARTPutchar function.

Instead it is cleared when I write a second byte whereas the last byte is still processed, so right now I'm not sure how it works.

My problem is that the TX interrupt is not generated at the end of the first write because the TXRDY flag is not cleared, so I need to write two bytes to start using the interrupts. And this is a little bit dirty for the code.

What is my mistake? How should I use the interrupts properly?

Thank you

  • 0
    TI__Mastermind 42195 points

    Javier,

    just a few clarifications.

    When you say "UARTPutchar" do you mean the "UARTCharPut" function found in the uart.h and uart.c  files?

    If you wait some time before sending the second byte will TXRDY go low?

    Are the any bytes lost, distorted or out of order?

    What is the behavior when you send a 3rd or 4th byte? For example does writing the 3rd char cause the 2nd to be sent or are the bytes grouped into pairs ie. 1st and 2nd bytes send after the second then the 3rd and 4th bytes send after the 4th.

    Regards,

    Cody

  • 0 in reply to Cody Watkins
    Intellectual 330 points

    Hello Cody, 

    Thank you for your answer.

    1. Yes, UARTCharPut from uart.h and uart.c files inside driverlib

    2. When I write the second byte, the TXRDY is reset "immediatly", but with the first byte remains set.

    3. No. Well that was my concurrence problem,  but it came from a bad implementation I did, it is not related to the issue I'm talking about here.

    4. Bytes are sent as expected, when I write the first one, the byte is correctly sent but as the TXRDY flag is not reset, when it is completely transmitted the interrupt is not generated. It looks like (it is an idea)  that when I write the first byte, as the transmission shift register is empty, instead of writing into the SCITXBUF I'm writing directly into the shift register and then the TXRDY flag is not triggered .

    The UARTCharPut  function is writting always into the SCITXBUF  (of course) so it should be something related to the MCU SCI peripheral implementation. I have taken a deep look into the reference manual and everywhere says that with any byte written into the SCITXBUF, the TXRDY flag is reset and when data is transmitted from SCITXBUF to TXSHF, the TXRDY flag is set and the interrupt is generated (if enabled).

    This is a problem for me because I'm filling a buffer and I force the transmission of the first byte and I expect the interrupt to clear the whole buffer. I have fixed this just writing two bytes if the filled buffer size is bigger than 1 byte. However, testing the robustness of the protocol,  if I send a stream of bytes at the maximum PC speed through the COM port, the TX interrupt is "lost" sometimes. That's why I would like to understand how it is supposed to be used the SCI interrupts with this microcontroller.

  • 0 in reply to JFerCep-Ing
    TI__Mastermind 42195 points

    Javier,

    It is required to have a "dummy" write! However, I ran a quick test, I also see that the TXRDY flag remains high until a second message is sent(as expected). From this point I began writing to SCITXBUF as fast as possible, after every write to SCITXBUF I would check if TXRDY = 0 which was always true in my experiments. This seems to work as expected, I did not see any lost TXRDY signals.

    Here is the a snippet of the TRM that shows that it is necessary have a "dummy" write every time you restart the SCI in non-FIFO mode. Do you think this information would be helpful somewhere else in the TRM? If you have suggestions on where this information should go please let me know!

    Regards,
    Cody

  • 0 in reply to Cody Watkins
    Intellectual 330 points

    Thank you Cody! All is clear now.

    Well, for me it is interesting to include this remark in the description of the TXRDY bit, because it also requires the dummy byte before start working as the description explains. And it would be interesting to have a small note inside section 18.10.2 Transmitter signals in communication modes.