• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 601 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.

UCD3138: Reset UART module

Jack Wang
Intellectual 320 points
Part Number: UCD3138


Hi all,

 - How can I reset uart module if polling TX_RDY and it's stuck at 0?

  • 0
    TI__Mastermind 18370 points

    Bit number Seven inside the UARTCTRL3 is called SW_RESET used to reset the UART.

    Regards,

  • 0 in reply to Yitzhak Bolurian
    TI__Genius 17090 points

    The TX_RDY is set when data is copied from the transmit buffer to the shift register to start the transmission. 

    If you look at our init_uart functions in the EVMs, you will see this line:

     Uart1Regs.UARTTXBUF.all = ' '; //put out a byte to get things started.

    This sets TX_RDY.  Without the first byte being sent, it doesn't seem to be set.

    TX_RDY is a better signal to use than TX_EMPTY, because you can use it to load the byte while the previous byte is still being transmitted. 

  • 0 in reply to Yitzhak Bolurian
    Intellectual 320 points

    Hi,

     - Thanks for the reply.

     - Do you mean that I can reset the uart by setting SW_RESET to 1? And it will be clear by UCD itself?

  • 0 in reply to Ian Bower
    Intellectual 320 points

    Hi Ian,

     - Please help to check if this is fine. Thank you.

      if (Uart0Regs.UARTTXST.bit.TX_RDY){
        uart_tx_timeout = 0;

    ...


      }else{
        if (uart_tx_timeout >= UART_TX_TIME){

    ...

          uart_tx_timeout = 0;

          Uart0Regs.UARTCTRL3.bit.SW_RESET = 1; // Add for reset
          Uart0Regs.UARTTXBUF.all = ' '; //put out a byte to get things started.
        }else{

          uart_tx_timeout++;

        }
      }

  • 0 in reply to Jack Wang
    TI__Genius 17090 points
    I would not suggest using the code above. It might put a byte out in the middle of a message, or write a byte when the UART is not ready. And the RESET could stop a byte in the middle of transmit too, not a good thing.

    Instead, I would try looking to see if either TX_RDY, or TX_EMPTY are set. If either of them are set, you can send a byte, if neither of them are set, you should not send a byte.

    However, I'm a little confused about why the write byte is even necessary, because looking at a device, I see the TX_RDY set at power up, and set after a SW_RESET as well. Have you actually seen the chip without a TX_RDY set when it should be? What is the root problem you have?
  • 0 in reply to Ian Bower
    Intellectual 320 points

    I was wondering what can I do if UART module is halt. I know in normal conditions everything is fine. Then how about abnormal conditions, like PMBus module, sometime it would halt and pull CLK low. Then I'll need to reset it.

    So I need a function to check if Uart is halt, and try to reset it.

  • 0 in reply to Jack Wang
    TI__Genius 17090 points

    The UART doesn't have an external clock coming to it.  Once it gets a start bit, it samples the bits at the given baud rate until it gets to the end of the byte, or however many bits you have programmed it to receive.  The only way we've seen to lock it up is to write a lower value to the UARTHBAUD, UARTMBAUD, UARTLBAUD registers at exactly the wrong time.  That will lock it up, but only temporarily.  If you're not changing the baud rate dynamically, you shouldn't be able to lock it up. 

    It is good to have some kind of a timeout on messages to stay synchronized in case a message doesn't complete, and it is a good idea to have at least a byte wide delay between bytes once in a while to permit resynchronization in case a byte is truncated.

    And, of course, it is good to have checksums on messages.

    It is best to have a message back from the other end of the transaction to say the message is accepted.  This is good in part because there is no way for the recipient to stretch the clock, so you need to make sure that you don't send messages too fast.

    But lockup is not an issue, because of the absence of an external clock. 

  • 0 in reply to Ian Bower
    Intellectual 320 points
    Many thanks to your explaination.