• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 80 subscribers
  • Views 4186 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.

msp432p401r: msp432 UCTXCPTIFG (eUSCI) doesn't seem to work

Eric Decker
Expert 1420 points

Part Number: msp432p401r

I'm running an eUSCI (A) as a UART sending a stream at 4800 baud (1 byte time is about 2ms).  I send a stream and then want to make sure that all the bytes have gone out before switching baud rates.  According to everyihing I've read in the manuals, datasheets, and on the forum (e2e) I should be able to monitor UCTXCPTIFG and when it goes 1 that says that both the TXBUF and the outgoing shift register should be empty.

But it doesn't seem to work.  Here is the scenerio.....  I'm using the TXIFG interrupt to feed the outgoing stream to the eUSCI TXBUF.  That works perfectly.  When the last byte has been sent to TXBUF, I then busy wait waiting for TXIFG to come back indicating that the TXBUF is empty.  I then busy wait on TXCPTIFG waiting for complete to indicate the shift register is empty.  But it immediately returns.

How do I know that it immediately returns?  Well I'm looking at a 1us ticker that I have running.   And the time from the last char being output to the eUsci to the TXIFG going up is 2156 (~2ms, sounds right, 1 byte time @ 4800 baud), and the TXCPTIFG is already up at that point.  The delta is about 4us which is how long it takes for the instructions to go out and look.

Doesn't look like TXCPTIFG actually works like you say.  Can someone at TI verify this please?

  • 0
    Expert 1420 points
    okay. This is a known problem, documented in USCI42 in the errata.

    Are there any plans to fix this?
  • 0
    TI__Mastermind 26380 points
    Eric,
    You are spot on in your observation. There is no difference between the functioning of TCPTIFG and TXIFG. Unfortunately we do not have plans to fix it in an upcoming revision just yet. Try to follow up TXIFG/TXCPTIFG set, by checking the UCBUSY bit (UCAxSTATW.UCBUSY). I will check into if this is a reasonable workaround with our Design team.

    -Priya
  • 0 in reply to Eric Decker
    Guru 41995 points
    Why not wait 2-3ms?
  • 0 in reply to Keith Barkley
    Expert 1420 points

    Keith Barkley said:
    Why not wait 2-3ms?

    yeah you can do that.  but in my world that is rather a long time.  the whole thing about interrupts is to avoid that kind of thing.  but when they are broken doesn't work so well.

    for what it is worth, that is what we ended up doing.  waiting.  really isn't much of a choice if CPT doesn't work.

  • 0 in reply to Priya Thanigai
    Expert 1420 points

    Priya Thanigai said:
    Eric,
    You are spot on in your observation. There is no difference between the functioning of TCPTIFG and TXIFG. Unfortunately we do not have plans to fix it in an upcoming revision just yet. Try to follow up TXIFG/TXCPTIFG set, by checking the UCBUSY bit (UCAxSTATW.UCBUSY). I will check into if this is a reasonable workaround with our Design team.

    -Priya

    UCBUSY doesn't work.  Back in the 1611 days it did because it was only driven by the TX side.  But at some point someone decided that UCBUSY should also be driven by the RX side.  So UCBUSY will assert if either the TX side is busy or the RX side is busy which is problematic if you are trying to see if the TX finished.

  • 0 in reply to Priya Thanigai
    Expert 1420 points

    Priya Thanigai said:
    Eric,
    You are spot on in your observation. There is no difference between the functioning of TCPTIFG and TXIFG. Unfortunately we do not have plans to fix it in an upcoming revision just yet. Try to follow up TXIFG/TXCPTIFG set, by checking the UCBUSY bit (UCAxSTATW.UCBUSY). I will check into if this is a reasonable workaround with our Design team.

    -Priya

    Actually I suspect there is some differences between TXIFG and TCPTIFG.  TXIFG should go high when the TXBUF is copied into the Shift regsiter and TXCPT goes high when the stop bit is shifted out.  If you start with a cleared out CPT.  Writing the first TXBUF will not effect TXIFG (or it blips, not sure)   one byte time later TXCPT will pop.  

    But if you are observing inside a stream it will look like TXIFG and TXCPT happen at the same time.

    We don't have the visibility to actually observe any of this as it is all buried in the silicon.

  • 0 in reply to Eric Decker
    TI__Mastermind 26380 points

    Justo to clarify, the intent behind setting up two different flags was to indicate the difference between when the shift buffer was loaded and when the data was physically transmitted on the bus. The sequence should work as:
    1. TXIFG set
    2. Data moved TXBUF by user
    3. Data moved from TXBUF to TX shift register on the next bitclk
    4. Data shifted out of the shift register including STP
    5. TXCPTIFG is set provided TXBUF has not been loaded

    However, due to the errata this does not work as the spec intended.

    -Priya

**Attention** This is a public forum