LPC54018 USART DMA prep & start taking a long time

[MRenshaw]

Hi,

I am trying to set up a USART DMA transfer on a LPC54018 and am finding it rather slow to start up the transfer.

I takes a little over 200us from calling USART_TransferSendDMA() to it exiting that function, the actual data transfer begins just before this function exits, about half of this time(100us) is taken up by DMA_SubmitTransfer() being called. We only have 500us between each time this data transfer would need to happen and there are other processes that would need to take place in this time period.

Is this the expected time for this process to take, and is there any way to speed it up?

Thanks,

Michael

[nxf77486]

Hello @MRenshaw ,

In order to understand better the situation can you please help me out with the following questions:

1. How are you measuring the timings, for this functions?
2. How are you configuring your UART baud rate (and basic configuration)?
3. How are you configuring the DMA for this application?
4. Are using and SDK example?

[MRenshaw]

Hi,

We are measuring the timings by toggling a GPIO before the DMA transfer function is called and then toggling it back once control is regained by the main loop then looking at this pin on an oscilloscope side by side with the UARR Tx pin to measure these times.

The UART is configured using the BOARD_InitDebugConsole() function that same is used in the SDK "hello_world" example.

The DMA is being configured as in the usart_dma_transfer SKD example.

The project is primarily made up of parts of SDK examples that have been stitched together.

In addition to this I have carried out similar tests to this using SPI instead of UART and got similar results but even slower, taking around 500us for data to start sending after the initial sendTransfer function call. This was configured the same as the spi_dma_transfer SKD example.

Thanks

Michael

[nxf77486]

Hello @MRenshaw 

Ok, so regarding the information you provide I have the following comments, the toggling of the GPIO generates extra timing that it should be causing the timings to not be accurate.

In the other hand the SDK code is useful and work pretty good, but this doesn't mean that is the more optimized code.

So in this case we recommend if you what an more optimized performance probably crating your own functions (by removing stuff you may not need) will be the best way to achieve this. The SDK example contains extra details that can cause not to be in the best optimized conditions.