• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 917 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.

MSP430FR6989: Design Sequence For Proper Trigger of A1 UART TX ISR/IRQ

John Westmoreland43
Guru 13915 points
Part Number: MSP430FR6989

Hello All,

I have seen some other threads on this - difficulty/confusion on getting the TX IRQ to trigger for the '6989.

I'm using the A1 UART on pins 3.4 and 3.5 - I've noticed the MSP430 Ware also seems to be unreliable for the A1 port; I have to set this up the classic way 
so to speak to get the port to work.

In order to trigger a TX IRQ - I have to first use the RXIRQ - echo the char to TX; then the TX IRQ will work.

I have a string queued up that will then transmit provided the echo took place to kick off the TX IRQ.

It would appear something has to be written to UCA1TXBUF first for the TXIRQ to become active.

I have to wonder if this is the desired behavior of this serial port; if it is - can someone (preferably TI) show the state machine in which a TX IRQ is designed to be entered?

Writing one char and then jumping into the TXIRQ doesn't seem to be the desirable behavior but that is the only way thus far I have got this to work.

I've included about all I can find on the hardware internal to the chip here:

Thanks In Advance, and Happy Holidays!
John W.

  • 0
    TI__Genius 15370 points

    Hi John, 

    Section 24.3.8 of the User's Guide describes how transmits are enabled on this MCU. As you've described above a transmission is only initiated when something is loaded into the UCAxTXBUF. 

    I don't understand the need to echo the the received char to TX, then place the placing the queued up string in TXBUF. Couldn't you place the queued up string in TXBUF when the char is received? Maybe I'm not understanding what you're trying to accomplish. 

    Unfortunately, I can't provide you any further details on the state machine. Again however, it does require something be written to UCAxTXBUF to start a transmit operation. 

    Best regards, 
    Caleb Overbay

  • 0 in reply to Caleb Overbay
    Guru 13915 points
    Hello Caleb,

    It would appear then that a polled TX driver was the intention vs. having the IRQ's for TX xmission. The IRQ's seem to be nothing more than place holders for status.

    So, it would appear RX was/is designed for IRQ operation as expected; but for TX is appears to make more sense to check registers and then just do a polled approach.

    From Figure 24-1 it is hard to glean that.

    I suppose a nonprintable char like STX can be used to kick off a transmission; just want to use this in the constraints of the underlying hardware architecture.

    Thanks and Happy 2017,
    John W.
  • 0 in reply to John Westmoreland43
    TI__Genius 15370 points
    Hi John,

    I wouldn't say a polled TX driver was the intention.Transmission is kicked off by loading a value into the TXBUF. Once this buffer is emptied into the transmit shift register, the TXIFG is set which can trigger an IRQ. Then inside the ISR you would reload a new value into TXBUF.

    If you want to stop transmission and restart it later, you would have to load a value into TXBUF again. This could be done within an RX ISR for example.

    I would consider what I've described above to be an IRQ based approach but maybe we're thinking of two separate applications/scenarios.

    Best regards,
    Caleb Overbay

**Attention** This is a public forum