• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 81 subscribers
  • Views 156 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430FR6043: Proposed USCI42 Workaround

lu tan
Prodigy 90 points
Part Number: MSP430FR6043

Hi,

This MCU has an errata USCI42 that has no official workaround provided by TI.

Here is the errata

Reading about this errata on some other threads in this forum, I gathered that this issue really only takes effect if the USCI is asked to function in half-duplex mode (ie: RS485). For full-duplex mode (ie: SPI), this errata is not applicable and can be ignored.

I would like to propose an unofficial workaround for the half-duplex case. Please let me know if it has a possibility of working.

First of all, looking at the block diagram of the USCI module shows that, for transmission, it has two main components: the transmit buffer and the output shift register.  

When transmitting a byte, the byte is first loaded into the TX buffer and then passed on through to the output shift register that actually sends the byte. There are two flags that can be observed during this process, UCTXIFG and UCTXCPTIFG (this latter flag is the one under question by the errata). The UCTXIFG is set each time that a byte has been transferred out of the tx buffer, in other words, when the tx buffer is empty. UCTXCPTIFG is set when the output shift register has transmitted all bits and there is no additional byte to be transferred from the tx buffer, in other words, both the tx buffer and output shift register are empty. My interpretation of the errata is that the UCTXCPTIFG is erroneously being set after each byte is sent, rather than at the moment that both tx buffer and shift registers are empty. This makes its function redundant as that is essentially what the UCTXIFG flag does.

My proposed alternative way is as follows:

First, find how long it takes to transmit a byte, say, 2ms. If we are transmitting 10bytes, that should takes 20ms. Under optimal conditions, after the 10th byte has been sent, UCTXCPTIFG would be sent and the controller can change to RX mode and get ready to receive. An alternative is to set a timer after the 10th bytes has been sent for say, 1ms or however long we feel is long enough to safely feel that the final byte has been sent, and then have controller change to rx mode. Of course, the alternative way is not as exact as the official way, hence why it is less optimal.

 

  • 0
    Guru 17195 points

    Sounds very kludgy and less effective than what I described.

  • 0
    Guru 85260 points

    I'm pretty sure you can use UCBUSY for this; the problem is that you have to poll it (no IFG). 

    If you start polling immediately, you might have to spin for an entire byte time (or even 2 if the pipeline is full), but as you say if you have a good guess (e.g. timer) you can go do something else then start spinning at about the time you expect it to go to 0.

  • 0
    Prodigy 90 points

    Hi David,

    Do you mind sharing the link to your solution? I was not able to find it.

  • 0 in reply to lu tan
    Guru 17195 points

    The simplest (and not my idea) is that if you know how many bytes are being sent, count TXCPT interrupts. Simpler than using a timer and more accurate.

    My idea (in a recent thread on USCI42 even) is to use the behaviour of TXIFG, TXCPTIFG, and the IV register. The short version being that TXIFG should be clear at TXCPT time until the transfer is done. This depends on the transfer from TXBUF happening while stop bits are being sent (not documented), the TXCPT interrupt happening after the stop bits are finished, and reading the IV register clearing the interrupt and flag.

    Or count TXCPT interrupts after you disable transmit interrupts when you run out of data. (Enabling TXCPT interrupts when you clear TXIE would be a race so it might work at low bit rates and fail at higher rates. Or fail randomly if other interrupts are enabled.)

  • 0 in reply to David Schultz
    Prodigy 90 points

    Has lab testing been done on this idea or is it unproven in terms of evaluation? Not saying it won't work, would just like to know how reliable it is. If it has been proven to work, would make me feel a lot better in terms of picking this MCU.

  • 0 in reply to lu tan
    TI__Mastermind 26656 points

    Hi Lu,

    I have a look for your discussion with David.

    You need use TXCPTIFG to check if the last data have been sent out via USRT, but there are a Errata that this flag will be set even the TXBUF not empty.

    Right?

    Maybe you can check TXIFG and if the times of Set, and if this equal with data length you want to sent. Those data should finish sent out.

    Just a idea if I understand correct.

    Thanks!

    Best Regarda

    Johnson 

**Attention** This is a public forum