MSPM0L1306: interrupt controlled UART-transmission: problems using EOT-DONE-Interrupt

Hi Matthias,

How are you enabling the EOT-DONE interrupt and where in your code do you check if it is set or not?

Hi Dennis,

here is the interrupt function, based on a sdk example.
I do not use fifo.
Rx and Tx interrupt calls are correctly detected and the corresponding handler is called.

void UART0_IRQHandler(void)     // from TI-example
{
switch (DL_UART_Main_getPendingInterrupt(UART_0_INST))
{
  case DL_UART_MAIN_IIDX_RX:
    Irq__vHandlerUartRx();
  break;

  case DL_UART_MAIN_IIDX_TX:
    Irq__vHandlerUartTx();
  break;

  case DL_UART_MAIN_IIDX_EOT_DONE:
    Irq__vHandlerUartEotDone();
  break;

  default:
  break;
}
}

A message sent by a master is correctly received, the transmit-buffer is then correctly set up and the interrupt controlled sending of the buffer also works.
With each TX-interrupt, one byte of the buffer is written into transmit-register.

But since TX-interrupt fires at the begin of the stop bit (then transmit-register is empty for next byte), I need EOT-DONE-interrupt instead for the last byte so that this interrupt is called at the end of the stop-bit of this last byte. Only then, I can control attached hardware correctly.
Using only TX-interrupt would require to insert a delay of one bit-time. This works, but it is not desireable since EOT-DONE is the feature for this.

If the last byte is written into transmit-register, I want to have the next interrupt being EOT-DONE-Irq and not TX-Irq.
The transmit-interrupt is in principle:

void Irq__vHandlerUartTx(void)
{
  DL_UART_Main_transmitData(UART_0_INST, (*Sendbuf++)) ;    // send byte of send buffer and point to next
  ByteCount++;      // increment Count of sent bytes

  if (ByteCount >= BytesToSend)     // Check if it was the last byte which was transferred to TX-Buffer and enable EOT-DONE
  { 
    DL_UART_Main_disableInterrupt(UART_0_INST, DL_UART_MAIN_INTERRUPT_TX);
    DL_UART_Main_enableInterrupt(UART_0_INST, DL_UART_MAIN_INTERRUPT_EOT_DONE);

    // Now next interrupt should be EOT-DONE-Irq and not TX-Irq.
  }
}

This is the EOT-DONE-handler which should be called if the last byte to send is entirely shifted out:
Unfortunately this function is not called from aboce switch/case.

void Irq__vHandlerUartEotDone(void)
{
    DL_UART_Main_disableInterrupt(UART_0_INST, DL_UART_MAIN_INTERRUPT_EOT_DONE);
    Re-EnableReception();
}

May you have an idea what I do wrong when disabling TX-interrupt and enabling EOT-DONE-Interrupt?

Thank you.

Hi Matthias,

My apologies for the delay in my response.  It's not clear in the TRM regarding the usage.  It does say it is generated when last bit leaves the serializer, I'm not sure if this is true for UART or one it's extended modes, LIN, DALI, etc.

I'm setting this up to duplicate what you are seeing.

Hi Matthias,

The behavior of the EOT interrupt does not seem to align with the description in the TRM. I tried 3 different scenarios to see when the EOT interrupt is generated.  Looking at the illustration below, I set then clear and IO pin (make a pulse) in the TXINT and EOT ISR handler to show if, and when I enter that portion of the handler.

In the top trace, I have a large delay between when the TXINT is set and when I transmit the next byte.  I did this on purpose to create long delay.  You'll notice the EOT does occur, but not where I would expect it to.  It appears at the START bit of the next byte.  

I repeat these steps making the delay smaller and smaller, until there is no EOT.

I'm checking with our designers to see why this is.

If it turns out this is the behavior, then yes, you will need to have some type of a delay.  You could use a timer in 'one-shot' mode programmed with the desired delay.  Then when you are sending your last byte you could start the timer timer.  When the timer period is over, the timer can generate an interrupt and you can perform your necessary actions then.

I will let you know what the designers say.

Hi Matthias,

To give you an update on this issue, I am currently discussing this with our design engineers.  I have provided them code examples that demonstrate the problem and now waiting for them to review the internal timings.  They will most likely provide an answer about this on Monday (designers located in India).

Hi Matthias,

I'm still waiting for the design team to verify the UART logic with simulations, but in the mean time, if by chance it turns out that the EOT is generated at the wrong time, or not at all (based on my earlier experimentation), we will need to devise a work around.  My first thought would be to use a timer in one-shot mode to generate an interrupt at the appropriate time.  Since you are loading the TXBUF and not loading the TXFIFO, you know when you are going to send the last byte.  You can start the timer then.  Would this work?

Hi Dennis,

unfortunately we do not have any free timers in the application. Otherwise your suggestion would work, I believe.
When do you expect will TI design team work on this issue?

Hi Matthias,

My last communication was today.  They are trying to figure out why the EOT does not appear to be set when executed in code, but does when they perform a timing analysis on simulations.  I have a call with them tomorrow night (Thur 10/12) to discuss.

Hi Matthias,

Our designers are recommending the following. 

1. Enable both RX and TX (I assume you do since you show a RX handler in your ISR, but just to make sure).  I didn't.  For some reason I had on TX enabled.  For me, enabling both fixes the issue on my side.

2. Enable pull up resistor on RX pin to ensure it is always logic '1'

I verified it works on my code. Let me know if it works for you.

Here is my logic probe timing.  You can see the EOT occurs just after the end of the STOP bit.

Attached is my code for reference.

uart_eot_issue_mspm0l1306.zip