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.

UCD3138064A: Check if UART communication is still working

Part Number: UCD3138064A
Other Parts Discussed in Thread: UCD3138

Hi Team,

One of my customers is using UCD3138 for their projects and they need to run several bootloaders on their system, up to more than 2000 times. There are instances that the UCD3138 will lose it's UART function and not reply with any data to the housekeeping MCU. 

Customer is asking if there is any way to know when the UART has lost it's function? Is there any flag or bit that they can refer to to check? Customer is looking to add a reset UART function when the UART does lose it's function. 

Kindly help advise.

Thanks! 

Best Regards,
Alfred 

  • Hi Alfred,

    There are a few bits in the UARTINTST register that may be used as an indication of error occurred during UART communication.

    Please look at the definition of these bits at page 465 of the technical reference manual:

    https://www.ti.com/lit/pdf/sniu028

    Hope this helps.

    Regards,

  • Hi Yitzhak,

    Below is feedback from customer:

    I try to use the debug when below bits are not 0 (UART Interrupt Status Register (UARTINTST) bit 0,1,3,4,5), the debug pin will toggle once.

    The debug pin does not toggle when the UART with no reply situation happens.

    Is there any other reason to cause UART module lose function?

    Thanks! 

    BR,

    Alfred

  • Hi Alfred,

    Does the UART issue that they are facing happen in room temperature?

    How easy is to reproduce this issue? Does it happen very often?

    Anything specific triggers this issue?

    What is the baud rate of the UART communication?

  • Hi Yitzhak,

    I got feedback from customer and they already resolved this issue. The error seems to be with their housekeeping MCU. When they reflashed the MCU, the error didn't occur anymore. 

    Thanks! 

    Best Regards,

    Alfred

  • Hi Yitzhak,

    Even if customer has resolved the initial issue, I got below question:

    I checked the UART stop response root cause is our UART service routine function conflict.

    The UCD3138 UART module still received byte correctly.

     

    I find a solution to solve our service routine function conflict issue.

    When I add a debug pin before function process UART server routine.

    The UART stop response issue disappear.

    So I think it just need add somedelay to solved this issue.

     

    If I know those code use how many instruction cycle.

    I could use NOP to make the same time delay.

     I just want to know how many instruction cycle as below portion.

     

     

    Thanks! 

    BR,

    Alfred

  • Alfred, changing timing to fix an issue is generally not a real solution, it's just moving things around for the particular test and code configuration.  A different test, or a slight change in the code will make the issue occur again.  Often a timing sensitivity indicates that there's an interaction between something in an interrupt and something in background mode.  If the same variable is written in both places, there can be broken writes.  There are other possibilities.  Sometimes the issue can be figured out by reading the code, but often it's necessary to toggle I/Os to tell what is happening.  Is the debug code above in an interrupt or in background mode?  

  • Alfred, based on other information, I think this issue is solved, so I'm closing this thread.