TM4C129ENCPDT: UART Transmit Interrupt Not Being Triggered

Hi,
Somehow you need to kick start the UART to generate the interrupt. You will need to start off with some writes to the FIFO (if you are using the FIFO feature) with the desired interrupt FIFO Level Select. For example, you can configure with 1/8 the FIFO level. This means you need to kick start the UART in your main with two data written to the FIFO. Once two data are written to the FIFO, the UART will generate interrupt. In the ISR you can write subsequent data to the FIFO. If you don't do this, you are in a chicken and egg situation. There is no data in the FIFO and hence there is no interrupt.

  There is also an UART interrupt based interrupt in the workshop Lab12.

  Please also make sure have:

  IntMasterEnable(); // enable processor interrupts

Charles Tsai said:

For example, you can configure with 1/8 the FIFO level. This means you need to kick start the UART in your main with two data written to the FIFO. Once two data are written to the FIFO, the UART will generate interrupt

One should be suffient should it not Charles? At least on every UART I've worked with and w/o reviewing I'm pretty sure my current TM4C code does it this way as well. The UART generates an interrupt not only when dropping below the FIFO level but also on FIFO empty.

Robert

Beyond "broken" - that is one of the most tortured writings (yet) presented.
Multiple "gotchas" behind each/every "bend" - just awaiting our (slight) misstep!

While it has been mentioned (just here/now) that there is an, "Interrupt based, UART example w/in "Workshop Lab 12" - can the, "Cry here for a competent, more (i.e. somewhat) publicized/findable, code example" be denied?

Not the fault of those (now) here - yet this should have reached (someone's) "To Do" list.     (Avoidance is not always the "best" option.)

cb1_mobile said:

can the, "Cry here for a competent, more (i.e. somewhat) publicized/findable, code example" be denied?

Indeed, in fact it such an example should be able to describe how to deal with the following situation

• 4 byte FIFO threshold
• Two bytes are written to the FIFO
• Some unknown number of character times later 3 bytes are written to the FIFO
• Questions: will the transmit interrupt ever fire? How do we know?

Robert

At least the receive timeout oddity is simple to deal with.

Unlike every other UART I've ever used TI separated the receive timeout into a separate interrupt distinct from the receive interrupt. All you have to do is treat it as a receive interrupt.

IE


switch (status)

    case receive_timeout:
    case receive:
          ...
          break;

so simple, just unexpected.

I've seen no useful application of that separation, although there has been some attempt at justification.

Robert

Robert Adsett said:

Well, that's broken. Glad you brought it to my attention. There is a bit of a work-around using an EOT trigger.

Indeed it looks like the only way to fix this is to change the transmit interrupt to trigger on end of transmission. Likely to make the traffic a little bursty but at lest you shouldn't miss transmit interrupts and you can still use the receive FIFO.  So far I've not seen anything else with any guarantee of working.

Robert

twelve12pm said:

If there's an additional interrupt that you can get at end of interrupt, then is it possible to enable both interrupts and give them the same treatment, the same way as the "receive oddity"?

Not that I can see. The EOT interrupt replaces the FIFO threshold interrupt. If it was in addition it would solve most of the problem. As it is it's the only thing I can see that will work but there will be a small performance degradation. In many applications that is not likely to matter.

Maybe if I'm overlooking an interrupt?

Robert

Is it somehow true that we "inmates" (appear) to be (somewhat) running the asylum?        Can that prove optimal?      

Dare it be asked, "Wherefore art the, "UART Architecture/Management" experts?"

twelve12pm said:

More importantly, have you used DMA with the UARTs on TM4C?

Nope, given the nature of serial communication I've never seen a case where it made sense (consider what happens if a byte is dropped or added).

twelve12pm said:

But we're getting ready to spin a board with multiple TM4C that communicate with each other through the UARTs. I'm not sure of the exact numbers right now but I think they'll exchange a kilobyte of data with each other 100 times per second, and I'm hoping to run the UARTs at 4 MHz.

What kind of data? And are you sure you can get 4MHz transceivers?

Robert

Charles Tsai said:

When EOT bit is set in the UARTCTL register the transmit interrupt is generated once the FIFO is completely empty and all data including the stop bits have left the shift register.

Yes. All other FIFOed UARTs that I've ever used provide an interrupt that occurs upon FIFO emptying. TI is the exception in not providing such.

Charles Tsai said:

. For EOT interrupt to generate, you still need to first write one data to the FIFO in the main.

Of course, like all other edge triggered UARTS

Charles Tsai said:

But you are right this is another way to continue the interrupt-based re-transmission by using EOT instead of FIFO threshold.

As near as I can tell, it's the only way to do so safely. At least no other safe method has been presented.

Robert

I was thinking more about the type of data and commands and the amount of duplication. That bandwidth more than saturates CAN but if there was enough duplicate traffic it might fit. I've also heard of people using Ethernet for this sort of traffic.

I'd wonder though if the interface to use isn't FIFO's or maybe even shared memory. You should get a lot of bandwidth that way but you do have to pay for the FIFO ICs.

Explains why you are not worried about transceivers although I'd want to check the overhead.

Robert

twelve12pm said:

...datasheet says you can crank up the UARTs to 7.5MHz

Yet - w/out mention of any added "error rate" - or (actual) operating conditions - or data payload - such claim may not prove fully compelling.

Having past served as Engineering Mgr. at a "similar, semi-giant" - it was noted that such, "optimistic findings" resulted when the, "Remote Device was (perfectly) "dialed-in" (i.e. Frequency painstakingly set) - and that scenario will NOT overlap yours.      In addition - in the real-world - might one MCU "run fast" - the other "slow" - what then?     (such frequency errors ARE additive)       

And - the deviations enforced by "PVT" (Process Changes, Voltage, Temperature) and simple aging - must be anticipated - and guard-banded.     All this cries for a (more) conservative approach - and solid test/verification.

At 4MHz we've found board layout to be important - short, direct routes and good "separation" from other potentially impacting signals - all "push you toward success."     Yet "Caution" should sit close by,  data integrity should trump high speed.

Note too - that the (lesser) MCU here (4C123) most always requires a "pull-up R" upon the TX line - which may impact max speed...     (and such need may overflow to your device, as well...)

twelve12pm said:

the UART samples each bit 16 times

May I disagree - I believe (just) 3 such "Voting Samples" are the "chosen ones."      (this topic came up recently (here) - I recalled that "3" number - and such was (finally) agreed upon.)

https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/588322?tisearch=e2e-quicksearch&keymatch=UART%20bits

You "seize upon" pull-up - yet your "Need for speed" - minus well chosen "cautions" - appears to pass w/little concern - that alarms...

As to UART (Async) vs SPI (Sync) I'd vote for clocked data (almost) every time.      Recall in my earlier post - the possibility that one of your interconnected MCUs runs "fast" - the other, "slow!"      How can that increase reliability?       The fact that an "extra" signal line (i.e. the data clock) is tolerated must signal some advantage w/ "SPI" - that being, "Signal Reliability/Robustness!"     

You may glean some insight into the "Value of SPI vs. UART" by surveying the occurrence of "accessory ICs" - servicing each serial format.       SPI - overwhelmingly - Wins!      (so much so that  "Slaughter Rule" is often called...)

I should note that firm/I are "fans" of UART - especially so when the communication flows (beyond) the board - and proper transceivers/level shifters (even radio modules) are deployed.

twelve12pm said:

I don't see any advantage to using the transmit interrupt at all.

Just adding my two cents to this long conversation...

The way we've implemented, and as I understand it, the buffer transmission controller must be aware of:

- Whether there are still bytes to be transmitted (from the buffer to FIFO)

- If there is room to place bytes into the FIFO

So I find no need for an EOT interrupt!

Let's say you have 3 bytes to transmit, and the FIFO is empty. The transmission controller would do something as while(FIFO_HAS_ROOM_AVAILABLE & THERE_ARE_BYTES_TO_BE_SENT);

The three bytes will be sent immediately, end of story. That would work for 1 byte, 16 bytes, whatever. The loop would exit because the buffer was fully transmitted, hence there is nothing more to be worried on the application end, and it can assume "everything has been transmitted". Do you really need to know, here, that the last byte actually left the hardware? The correct transmission requires other approaches, acknowledge protocols and so on.

Now, let's say you have 25 bytes. The first 16 bytes will be sent right away, and you can go back to whatever your MCU needs to do - you will get an interrupt after "some" of those bytes left the FIFO (let's say half of them, on default configuration). When you get that interrupt, you have some time to service it, simply by calling that "controller" again with the very same logic. By the time you start sending the remaining 9 bytes, there's a good chance that one extra byte left the hardware, so all 9 will be gone on the second call. If not, no problems - the last byte will simple be sent on the third call of the controller.

Fine tune the FIFO level for interrupt. If you set the interrupts right after 2 bytes left the FIFO, you will be calling the controller too often. If you set it to interrupt after 14 bytes left, you will have the benefit of "a lot of FIFO space" on your next controller call - but if your code is busy doing something else, maybe you will waste transmission time because the last 2 bytes got sent before you were able to send more.

This is easier to be explained with flowcharts, but I hope the text makes sense. We found that such strategy provides a VERY reliable UART transmission, does not mess with the receiving, and does not demand too much processing.

Bruno

Bruno Saraiva said:

The way we've implemented, and as I understand it, the buffer transmission controller must be aware of:

- Whether there are still bytes to be transmitted (from the buffer to FIFO)

It's this part that I think is, in general very difficult to impossible to do. In fact the only way I can see to do it in general would be to add a timer to count down the time that the characters would stay in the FIFO. relying on probabilities just leaves you with difficult to track bugs.

Bruno Saraiva said:

- If there is room to place bytes into the FIFO

This part is trivial

Bruno Saraiva said:

Let's say you have 3 bytes to transmit, and the FIFO is empty.

First question, how do you know the FIFO is empty?

Bruno Saraiva said:

The three bytes will be sent immediately, end of story

Only the start of the story. Second question when/will an interrupt fire? If you add more characters to the queue do you need to send them to the FIFO or can you rely on the interrupt?

Bruno Saraiva said:

. Do you really need to know, here, that the last byte actually left the hardware? The correct transmission requires other approaches, acknowledge protocols and so on.

How else do you know when to add more bytes to the FIFO?

Bruno Saraiva said:

Now, let's say you have 25 bytes. The first 16 bytes will be sent right away, and you can go back to whatever your MCU needs to do - you will get an interrupt after "some" of those bytes left the FIFO (let's say half of them, on default configuration

Yes

Bruno Saraiva said:

When you get that interrupt, you have some time to service it, simply by calling that "controller" again with the very same logic. By the time you start sending the remaining 9 bytes, there's a good chance that one extra byte left the hardware, so all 9 will be gone on the second call.

Relying on probability does not, in general, lead to robust software.

Bruno Saraiva said:

If not, no problems - the last byte will simple be sent on the third call of the controller.

Good, now what happens if you queue up an additional 3 bytes immediately after the last has left your queue?

What happens if you queue up 3 bytes immediately after the FIFO interrupt fires?

I think I see a way or two clear of this but it'll need some care to prevent race conditions.

Robert

Robert Adsett said:

(- Whether there are still bytes to be transmitted (from the buffer to FIFO)). It's this part that I think is, in general very difficult to impossible to do.

Not at all. You misread. Controller needs to know if there are pending bytes from BUFFER, which need to be placed in FIFO. After they're in FIFO, mission is accomplished. So this is just a matter of buffer pointers.

Robert Adsett said:

First question, how do you know the FIFO is empty?

It was empty by definition for the sake of the example. To know that the FIFO is empty we have this weird thing, which I don't even want to think of re-understanding:

(!(HWREG(Serial_UART[uartid][SERIAL_BASE]+UART_O_FR) & UART_FR_TXFF))

Robert Adsett said:

How else do you know when to add more bytes to the FIFO?

You can add more bytes to the FIFO immediately after you get a TX interrupt! Again, you don't need to know if all bytes are gone through the wire.

Robert Adsett said:

Good, now what happens if you queue up an additional 3 bytes immediately after the last has left your queue?

You never queue 3 bytes, or 8 bytes, or whatever bytes. You queue one by one, while there is room in the FIFO. And you control the pointers of your buffers: one points to what has already been sent to FIFO, the other points to the last BYTE that needs to be sent.

Robert Adsett said:

Relying on probability does not, in general, lead to robust software.

That was a mean comment! You wrote before reading the rest!!! Objection!!!!

Hope these additional comments cleared things a bit!

Bruno

Bruno Saraiva said:

It was empty by definition for the sake of the example. To know that the FIFO is empty we have this weird thing, which I don't even want to think of re-understanding:

(!(HWREG(Serial_UART[uartid][SERIAL_BASE]+UART_O_FR) & UART_FR_TXFF))

Isn't there some nice neat TivaWare function that does that?

Bruno Saraiva said:

It was empty by definition for the sake of the example.

That was rather my point. You must consider both the empty and the non-empty condition. You only considered the empty condition.

Bruno Saraiva said:

To know that the FIFO is empty we have this weird thing, which I don't even want to think of re-understanding:

That's what determines whether or not an interrupt will occur so that condition and its effect absolutely must be considered.

Bruno Saraiva said:

Robert Adsett

Relying on probability does not, in general, lead to robust software.

That was a mean comment! You wrote before reading the rest!!! Objection!!!!

I did.

Bruno Saraiva said:

Robert Adsett

Good, now what happens if you queue up an additional 3 bytes immediately after the last has left your queue?

You never queue 3 bytes, or 8 bytes, or whatever bytes. You queue one by one, while there is room in the FIFO. And you control the pointers of your buffers: one points to what has already been sent to FIFO, the other points to the last BYTE that needs to be sent.

That doesn't answer the question. It sidesteps it w/o addressing it.

I mentioned I thought I saw a way clear and I think I do. It does take some work to avoid races and that increases latency considerably compared to a conventional UART FIFO

First start with the conventional UART

Application code

TransmitByte( char byte)
{

Add byte to queue
if PrimePumpFlag set {
    disable interrupt
    place byte in UART FIFO
    clear PrimePumpFlag
    enable interrupt
    }
}

There are cases where you could dispense with the interrupt protection around the priming. If you want to be safe against future changes though, then even if that case applies now the interrupt protection should still be present. Note that the order of operations is important here.

Interrupt Code

UARTTransmit()
{
    if ! queue_empty {
         copy queue to FIFO until queue empty or FIFO full
         }
    else {
         Set PrimePumpFlag
         }
}

This will not work with the TI UART since in the case where the UART FIFO is not filled past the FIFO threshold there will be no interrupt and the PrimePumpFlag will never be set so transmission is never re-started.

The easy safe way to fix this is to convert the transmit interrupt to an EOT interrupt with some attendant loss of bandwidth. I think I have a better approach though.

Starting with the interrupt code. It actually simplifies since there is no way to set the priming flag.

UARTTransmit()
{
    if ! queue_empty {
         copy queue to FIFO until queue empty or FIFO full
         }
}

The application code now needs additional protection and is at least arguably more complex

TransmitByte( char byte)
{

disable interrupt
if queue is empty  and !FIFO is full {
    place byte in UART FIFO
    }
else {    
    Add byte to queue
    }
enable interrupt
}

The expanded protection period is necessary to prevent race conditions. I don't think I've left any race conditions but it needs review, I've only done a preliminary check on it.

Two side effects of this

1. increased latency
2. increased number of transmit interrupts with nothing to do.

A note on the interrupt protection, as long as the transmit never comes from a higher priority than the transmit interrupt then the disabling only needs to block the transmit interrupt. If not the disable must be more inclusive and additional blocks are needed in the interrupt code as well.

Robert

Bruno Saraiva said:

Because this one is blocking, it has to check for FIFO space

That just needs a FIFO full check. See UARTSpaceAvail. Should boil down to a simple flag check.

Robert

cb1_mobile said:

You "seize upon" pull-up - yet your "Need for speed" - minus well chosen "cautions" - appears to pass w/little concern - that alarms...

As to UART (Async) vs SPI (Sync) I'd vote for clocked data (almost) every time.      Recall in my earlier post - the possibility that one of your interconnected MCUs runs "fast" - the other, "slow!"      How can that increase reliability?       The fact that an "extra" signal line (i.e. the data clock) is tolerated must signal some advantage w/ "SPI" - that being, "Signal Reliability/Robustness!"     

Now I'm nervous!

Point taken about the advantages of synchronous communication. (Incidentally, what do you think of a USART? That can give you framing AND a clock! Too bad TM4C doesn't have that.)

I have to study this further and run some tests...

twelve12pm said:

Incidentally, what do you think of a USART? That can give you framing AND a clock!

Really, got a pointer? All the USARTs I've seen do not provide any framing in synchronous mode (that'd be a bit oxymoronic I think). They were just a way of providing an SPI like interface.

Robert

Bruno, my last reply was a bit flippant. I just figured you had miss-written.

However,  FIFOEmpty and SpaceAvailable are quite different things. In fact you can make the case (true but probably not useful) that Space Available more closely matches SpaceUsed than it does FIFOEmpty. Consider for a 16 byte FIFO

• Space Available 1 to 16 bytes in FIFO are available
• FIFO Empty 16 bytes in FIFO available
• Space used 0 to 15 bytes in FIFO available
• FIFO Full 0 bytes available

and the logical inverse relationships

• Space Available = !FIFO Full
• Space Used = !FIFO Empty

FIFO Full is the flag that's readily available and it's the one you check.

I suspect it's possible to approximate FIFO empty by checking for transmit holding register being empty but I have not verified that flag is available.

Robert