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

MSPM0G1107: TI MSPM0 Errata UART_ERR_08

Max Luc Balen
Prodigy 670 points

Part Number: MSPM0G1107

Tool/software:

I've had a customer recently discovered an issue with UART behavior under certain configurations, which led us to new errata UART_ERR_08:

I have a couple of questions I’d like to clarify:

  1. Will the SDK be updated to implement the proposed workaround? Knowing your plans or timeline for SDK updates would help my customer anticipate compatibility changes and plan accordingly.
  2. How exactly does the errata manifest? In a previous project, we didn’t encounter this issue, even with heavy use of the BUSY bit. In another project, though, we were able to manifest the errata under certain configurations. Could you specify the conditions where the issue is most likely to arise?

Thank you.

  • 0
    Guru 101885 points

    As I read the UART_ERR_08 text [SLAZ742C p. 27], it says that if you disable the UART (CTL0:ENABLE:=0) while the TX FIFO is not empty, STAT:BUSY stays set. Since the UART is disabled, the TXFIFO will never empty so BUSY will never clear. [I'm not quite sure why this is an Erratum, since the description of BUSY in TRM (SLAU846C) Table 23-43 pretty much says this.]

    The workaround would be to either wait for the TX FIFO to empty (STAT:TXFE=1) before disabling the UART or empty the FIFO (CTL0:FEN:=0) after disabling it [Ref TRM Sec 23.3.28]. [I don't speak for TI, but it seems to me that DriverLib should not be doing either of these things on its own.]

  • +1
    TI__Mastermind 27765 points

    Hi Max,

    I replied this in email. 

    B.R.

    Sal