Why is my DMA transfer taking so long?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
ChRe_4711096
Level 4
Level 4
50 replies posted 25 replies posted 25 sign-ins

The attached project uses DMA to retrieve the channel currently handled by SARSEQ. This is done by DMAing SAR_STATUS into a control register on every pulse seen on sdone. The DMA channels always first read SAR_STATUS, and DMA_5 also copies some more data (SAR_RESULT to memory, then split off bytes 1 and byte 3). The purpose of this mockup is to find the latency between sampling and DMA completion.

The datasheet gives some numbers for an optimal DMA transfer, and when I do the math for DMA_5 (two single transfers and one X-loop with two transfers) I end up with 35 slow_clk cycles. However, my scope shows a delay between rising edges of sdone and DMA_5::tr_out of about 0.72 us, or 52 slow_clk cycles (slow_clk = 72 MHz).

Why? Is it because all DMA channels have their descriptors configured in an endless loop? I found no other way to get them to re-trigger on sdone without CPU intervention.

0 Likes
3 Replies
Vasanth
Moderator
Moderator
Moderator
250 sign-ins 500 solutions authored First question asked

Hi Christopher,

Regarding the project, As sdone actually represents the end of the sampling for channel, it might be better to use the eos signal to trigger the DMA which reads result from Result registers. Regarding the clock cycles, could you please let me know the split for the calculation of 35 clock cycles for transfer ?

Best Regards,
Vasanth

0 Likes

I took the following numbers for individual parts of a DMA transfer from the architecture TRM's "DMA Performance" section. As I interpret it, a descriptor chain with two single transfers and a 2-element x-loop should sum up to:

  1. channel preparation: 6 cycles
  2. load descriptor (single transfer): 4
  3. load pointer: 1
  4. transfer: 3
  5. load descriptor (single transfer): 4
  6. load pointer: 1
  7. transfer: 3
  8. load descriptor (x-loop): 5
  9. load pointer: 1
  10. transfer: 3
  11. load pointer: 1
  12. transfer: 3

Sum: 35 cycles

Wait states from SRAM or to control registers should be zero as I understand it.

0 Likes

Re the way of using the ADC in general, I need to handle every sample without excess latency in hardware. Since I want to scan 4 inputs, eos is not suitable for this - it's only issued at the end of the whole scan.

That is why I write the currently busy channel from SAR_STATUS to a control register. If, say, Ch=0 and sdone is issued, this sdone is treated like a pseudo-eos for Ch0. I can the safely copy the result into a 16-bit datapath for post-processing, and again copy the currently busy channel into the control register. sdone is further used downstream to mark the following conversion as valid or invalid, based on other conditions. This works as intended, despite the rather slim interface that the ADC has.

0 Likes