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

Using a DMA and UART RX in an open ended data flow system

Brent Rasmussen
Expert 1305 points
Other Parts Discussed in Thread: MSP430F5418A

I am developing a system using a MSP430F5418a as the core part.  In the system, there is a UART connection to an external device.  The data is a string of commands.  There is no way to hold off the data stream so the MSP has to be able to accept whatever data comes.  The commands are variable length and the time between the commands is indeterminate.  Some of the commands cause the flash on the MSP to be erased and written.  Because of that, I am not able to use a simple ISR routine to pull the data from the UART module on the MSP.  Therefore, I have to use the DMA in conjunction with the UART.

My problem is how to handle the DMA.  I plan on setting it up in a repeated single transfer mode with a size of around 512 bytes.  I would then periodically pull the data out of the block the DMA is writing to.  However, at some point, the DMA block needs to be reset to the start of the buffer.  To reset it, I would have to disable the DMA.  If a receive byte happens to arrive during the time it is disabled, when I re-enable the DMA, it would miss that byte and be locked up.  The only way I can think to handle it is to check the UCRXIFG flag after I have re-enabled the DMA.  If it is set, then I would pull the byte from the UART RX buffer and add it to the data I just pulled from the block.

Is this an acceptable solution?  Is there a better way of dealing with this problem?

Thanks,

Brent

  • 0
    Guru 227245 points

    Brent Rasmussen said:
      The only way I can think to handle it is to check the UCRXIFG flag after I have re-enabled the DMA.  If it is set, then I would pull the byte from the UART RX buffer and add it to the data I just pulled from the block.

    It will work. However, it leaves you with a byte which has to be mangled somewhere into the buffer.

    It would be better to setup the DMA for next block, skipping the first byte, then intentionally wait for the next incoming byte (if you can afford waiting, that is), arm the DMA and put it into the saved location as if the DMA had put it there. Don'T try to use the DMA level trigger. It may or may not work, but not always the same :)

  • 0 in reply to Jens-Michael Gross
    Expert 1305 points

    Hi Jens-Michael Gross,

    Thanks for your response.  I am not sure what you mean by "mangled".  I believe you mean managed?  Either way, it isn't too hard for me to deal with the extra byte.  I have to pull the data from the dma buffer and push them into a fifo anyway.  One more byte doesn't hurt anything.  I don't have time to wait for the next incoming byte because I have no idea when it will occur.  My biggest concern is missing data (or getting extra data) or locking up the system.  If checking the UCRXIFG flag after re-enabling the DMA and if it is set, pulling the data out works (meaning I don't lock up the system and get the data I should) then I should be fine.

    Brent

  • 0 in reply to Brent Rasmussen
    Guru 227245 points

    Brent Rasmussen said:
    I believe you mean managed?

    No, but you're right, it wasn't the proper word. 'fiddled' would have been better. But 'managed' fits too :)

    Brent Rasmussen said:
    If checking the UCRXIFG flag after re-enabling the DMA and if it is set, pulling the data out works (meaning I don't lock up the system and get the data I should) then I should be fine.

    Well, if you'r enot fast ebough to setup the DMA before the next byte comes, maybe you're not fast enough before the next two come. But this case can't be handled at all. If you get a receive buffer overflow than you get an overflow. No software can fix it afterwards.
    Besides this, it should work properly. But only thoroughly testing it can tell whether it really works.

**Attention** This is a public forum