• State TI Thinks Resolved
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 104 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MSPM0G3107-Q1: TI UART - Error Handling with DMA

Adan Pantoja
Prodigy 150 points
Part Number: MSPM0G3107-Q1


Hello,

I want to preface this with - I am using freeRTOS to manage multiple tasks. I have a dedicated task for communicating with an external IC.

I am working on a project which uses the UART peripheral to communicate with an external IC periodically. I have created a UART driver to use with my application. The driver was created referencing the uart_rx_multibyte_fifo_dma_interrupt example project. With the driver working, I am now trying to ensure any issues with the code can be caught and an appropriate action can be done to handle the issue. 

For example, below is a screenshot of my write function.

image.png

When initiating a write, the software needs to wait for the DMA to move all data bytes into the UART TX FIFO and then it waits for the UART peripheral to finish outputting the data on the bus. These two areas can (in theory) fail. To mitigate this, I have added a timeout to each while loop. I have measured the time it takes for the DMA and TX UART to finish. It takes the chip ~223us to trigger the DMA done and UART done interrupts. Therefore, I have set a timeout of ~3ms. 

So my question is: if somehow the TX DMA never triggers and/or the UART somehow doesn't finish transmitting the data, what should be the corrective action that should occur. Right now, I am just disabling the TX DMA channel. Is this sufficient? Also, is there a way to get the software to trigger these error, so I can fully test the behavior?

On the same note, now on the receiving end, below is a screenshot of the error handling I am doing. 

image.png

For this function, if the RX DMA does not receive it's transfer size within ~30ms I timeout. The corrective action I am doing here is basically disable the RX DMA and clear the RX FIFO. This one seems a bit more straight-forward and I think, for the following events, this is sufficient.

  • No data bytes were received
  • Partial data bytes were received
  • Overrun of bytes were received

So for this one, I just ask if this is good enough.

Thanks,

Adan Pantoja

  • 0
    TI__Prodigy 510 points

    Hello Adan,

    Your checks cover a majority of the issues that you could run into, however here are a few notes:

    - If the DMA doesnt complete or the UART doesnt finish, that means that something has gone wrong and signifies that either of these peripherals are in a bad state. In general, i would say disabling is not enough, and it is best to fully restart the peripheral. If there is a DMA timeout, the recommended action is to abort the DMA transfer by disabling the channel, clearing the interrupt flag, and ensure correct config before re-enabling. Additionally, the UART TX must be disabled, interrupts cleared, and FIFO flushed before re-enabling, as seen in section 23.2.5 of the TRM. This should put both into a fresh state. 

    - For RX DMA and FIFO, the checking looks sufficient, however similarly clearning the interrupts, FIFO, and error flags is suggested. This ensures that when these peripherals restart, they are in a clean state.

    Best Regards,

    Tyler

  • 0 in reply to Tyler Morgan
    Prodigy 150 points

    Tyler,

    Thank you for your response and suggested steps for recovering from these issues. Unfortunately, I've been quite busy and haven't had the time to thoroughly look at your response. I plan on taking a look starting the new year.

    I will come back and report any finding around that time as I am curious about the steps for re-initializing the UART.

    Thanks,

    Adan