omapl138 large latency when dma reads uart rx

Hi,

Thanks for your post.

Actually on the DMA side since there could be more probability on EDMA CC queue manager to engage in other high priority system tasks scheduled to execute data transfer. Basically, there would be multiple data transfer requests initiated by different peripherals and high priority CPU L1D/L1P & L2 RAM data transfer tasks queued on the EDMA CC and also there exists a typical queue mechanism on EDMA CC to prioritize task requests and based on that, high priority CPU tasks cannot be violated on the queue manager. In general, you will observe more latency on DMA data transfer.

Thanks & regards,
Sivaraj K

-------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.
-------------------------------------------------------------------------------------------------------

thank you for the response.

i am thinking that you are right when you say that the delay is probably in the dma -- if the uart were holding onto the data, it would have overrun the fifo, and the data would have been lost.

that being said, i have to solve this problem somehow, and 2 or 3 msec seems like a looong time for the DMA to wait for access to the L2 RAM.

i am thinking that the transfer controller has the data -- but it is in no hurry to flush it out to the RAM -- that may be because the DMA transfer is set up to accept 64 bytes, and all of them have not arrived yet.

if i configured the parameter set to transfer only one or two bytes, do you expect that the transfer controller would then "flush its internal buffers" when they were received, and the data would appear in the L2 RAM with much less latency?

Hi,

Thanks for your update.

By default, TC's servicing memory to memory transfer would be given lower priority and in this context, you could try transfer only one or two bytes would be a good idea so that DMA don't have to wait for a long time for the data to appear in L2RAM. Yes, it's a good idea to reduce the DMA latency in accessing L2RAM.

Usually, each master peripheral will have an allocated priority level (POR default value) and when multiple masters are trying to access the common shared resources, based on the individual priority value, it will allow the system interconnect to arbitrate requests from different masters. So, please determine your priority assignments in the Master Priority Registers (MSTPRI0-MSTPRI2) in the System Configuration Module and trace the priority values in your application. This can be re programmed based on the applications prioritization requirements and however for this device, the priority control for the transfer controllers (TC's) is controlled by the chip-level registers in the System Configuration Module.

In general, TC's servicing audio data requests from serial ports should be given higher priority when compared to TC's servicing memory to memory (paging/bulk) transfer requests. To know more details on EDMA3 TC prioritization, please check the section 18.2.13 in the omapl138 TRM as referred below:

http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf

So, i would recommend you to program the priority of each TC with respect to other TC's as well with other master peripherals in the system and doing this would be explicitly significant and very essential.

Thanks & regards,

Sivaraj K

-------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.
-------------------------------------------------------------------------------------------------------

didn't help -- i checked the master priority registers, and the DMA was already pretty much the highest priority peripheral (the default value is 0 =highest).  nevertheless, i explicitly set the priority of all three transfer controllers to 0 -- had absolutely no affect on the latency.

the dma uses SYSCLK2, which is currently set to 150 MHz -- that seems prettry fast -- can you think of any mechanism which could possibly slow it down to an effective transfer rate of 7000 bytes per second -- i never get data errors -- i never lose characters -- it is just incredibly slow.

Hi!

1) The UART FIFO reports reception of data upon completion of a programmable number of chars (register IIR/FCR). What is your byte number threshold? Try to lower the threshold.

2) How do you measure the latency?

Best regards

the uart fifo threshold is 1 byte -- i tried other thresholds when i was thrashing around looking for the cause of the latency -- but there was no improvement -- the RXFIFTL bitfield in the FCR register is set to 0.

the mechanism i use to determine latency is implicit in the design of the driver.  the source of the uart characters is "bursty" -- the message format is such that i don't know in advance how many characters i will be receiving -- as a result, i cannot tell the DMA to transfer (say) 14 characters, and send me an interrupt when they have arrived.

instead, i determine the number of characters which have been received by polling the DMA parameter set which is tied to the uart RX.  In the first variant of the driver, i checked the C-INDEX register -- since it incremented by one whenever the DMA transferred a character, i knew how many characters had been transferred.

in the latest incarnation in the driver, each parameter set transfers only one byte -- however the destination register in the parameter set tells me how many bytes have been transferred to date.

in other words, i determine the arrival of characters by polling the DMA -- since i poll in successive timer ticks, i obtain the arrival time of the data with the accuracy of +- 1 timer tick (.3 msec).

thank you for your response.

Hi!

Could you check the latency of the UART without DMA transfer (time between sending the last character and FIFO full flag)? This could possibly help to narrow down the problem?

Best regards

the uart is not to blame.

when i send a 14 character message and receive it via dma, the dma "parcels it out" a few characters at a time, over 5 or 6 of my "timer ticks" (each is 1/3 msec apart).

i removed the dma driver, and polled the status register of the uart directly -- the 14 characters arrive in 1 or 2 timer ticks -- this is what you wouild expect, considering the asynchronous nature of the trransmitter and receiver -- i consistently see 12 or 13 characters arriving in a single burst of enthusiasm from the uart.

Just came accross RDRATE register in EDMA3. Maybe this is some hint...

sadly, i don't think so -- i checked the RDRATE registers for all 3 transfer controllers, and the 3-bit field is 0 -- the default value which corresponds to maximum speed.