LPC1549 UART RX with DMA - how to get last received bytes?

[volkeroth]

I'm currently trying to port a DMA based UART driver I wrote for the LPC1768 to a LPC1549.
There are quite a few difference on the UART peripheral but my main issue is with the DMA peripheral.
On the LPC1768, the source and destination addresses were stored in DMA registers, so I could use a link descriptor to set up a circular receive buffer and read the current destination address to know where the last received byte was written. So I could poll the circular receive buffer and knew exactly which byte I already read and which I didn't.

Now with the LPC1549, the initial descriptor is in SRAM and additionally the source destination addresses in the descriptors are end addresses. So I guess there must be internal address (current) registers for each channel, but obviously it's not possible to access these. Since there is also no timeout interrupt or whatever, I have to poll the receive buffer, but without access to the actual destination address, there is no way to determine how many bytes were transferred. Actually this makes the DMA somewhat pointless for receiving but as there is no FIFO either, the performance of the UART peripheral is actually worse than that of a LPC13xx with FIFO.

None of the code examples I found solves this problem. Some note that some kind of timeout DMA flush concept was needed, but don't go into detail how that is supposed to work and how this should not cause any data consistency issues or tell you how many bytes were actually received in the "flushed" buffer.

So in a nutshell: is there any way to get access to the current values of the source/destination addresses of an ongoing DMA transfer?

Or is there any application note or whatever that describes how to set up to implement a robust UART DMA receive concept that allows you at least to poll every received byte instead of waiting endlessly for the DMA transfer of the entire buffer to be completed?

Currently my only idea for a quick'n'dirty workaround would be to overwrite all read data in the receive buffer with an invalid pattern. But letting aside the potential consistency issues this would limit the usable data (i.e. no plain binary transfers) or I had to use 16bit transfers - which I also try to avoid.

[volkeroth]

Or wait: can I read the current transfer count from XFERCFG.XFERCOUNT?

The manual says:

"The DMA controller uses this bit field during transfer to count down.
Hence, it cannot be used by software to read back the size of the transfer, for
instance, in an interrupt handler."

The first sentence sounds like this register contains the information I was looking for.
The next sentence is rather confusing though. I guess it means I can not read back the total size, but I could use it to read back the current size. Else it would contradict the previous statement.

Anyway, I'll try that.

[Carlos_Mendoza]

Hi Volker,

Yes, you can use the XFERCOUNT value to know the current source and destination address taking in consideration the total number of transfers to be performed, data width and the source and destination end addresses.

Hope it helps!

Best Regards,
Carlos Mendoza
Technical Support Engineer

[volkeroth]

Thanks...
Igot it to work shortly after I posted the above comment and in the end it's even a bit more elegant using XFERCOUNT. It's just that everything is completely different to how it was done on the LPC1768.

I also didn't get why exactly I need to configure the RX DMA transfer as SW trigger and then even trigger it explicitly. As the user manual is rather cryptic and even confusing regarding some details, it would be really helpful if there was an application note for DMA transfers and how to use them for the common peripherals like UART and SPI.

Actually I'm pretty sure that there was an application note for the LPC17xx and it was really helpful when I tried to get my first DMA transfers to run on the LCP1768.