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.