SGDMA descriptor questions

#1 Either the thing emptying the DCFIFO can't keep up or the DCFIFO is too shallow. Yes the SGDMA will stall if the DCFIFO is full since the FIFO will dessert the ST ready signal which will then stop the SGDMA from reading until there is more room available.

# 2 There are different ways. To have predictable memory usage you can carve up a block of memory into descriptors and divide them amungst the SGDMAs. That method allows you to build circular buffers easily as well as makes it much easier to transverse the linked-list (if you know where they are in memory then you don't have to jump through the list).

# 3 Nope the descriptor still remains in memory. When the transfer completes the SGDMA will write the actual_bytes transfer into the descriptor field as well as set "owned by hardware" to 0. So if you want to reuse those descriptors you might be able to just flip the owned by hardware back to 1.

--- Quote Start ---

#1 Either the thing emptying the DCFIFO can't keep up or the DCFIFO is too shallow. Yes the SGDMA will stall if the DCFIFO is full since the FIFO will dessert the ST ready signal which will then stop the SGDMA from reading until there is more room available.

--- Quote End ---

And this will not produce any error?

--- Quote Start ---

# 2 There are different ways. To have predictable memory usage you can carve up a block of memory into descriptors and divide them amungst the SGDMAs. That method allows you to build circular buffers easily as well as makes it much easier to transverse the linked-list (if you know where they are in memory then you don't have to jump through the list).

--- Quote End ---

Right now, i am using a 256bit width RAM with depth of 50, so the total is 1600 bytes RAM to store all the descriptors. It worked out pretty well.

In my experiment, i was moving content in RAM(65K) to another RAM(65K). I created random data in Source_RAM using In-system Memory content editor, and watch the data with it in Destination_RAM after the transfer.

I have 1 question, why can't i fill in ALL the the data in Destination_RAM using DMA? it seems like certain part of my Destination_RAM is write-protected, but i just cant find any settings in Eclipse that is responsible for this.

In the attached picture, the red zeros should not be there if the transfer is successful, all the data above is correct, just the bottom part is messed up. It seems like i cannt even write data manually to these range of memory address . have any idea why?? and the range of "inaccesible" RAM will only shift when some of my code changes, like using usleep(10000000); // delay 10sec .

--- Quote Start ---

# 3 Nope the descriptor still remains in memory. When the transfer completes the SGDMA will write the actual_bytes transfer into the descriptor field as well as set "owned by hardware" to 0. So if you want to reuse those descriptors you might be able to just flip the owned by hardware back to 1.

--- Quote End ---

It works! changing owned by hardware bit back to 1 will allow me to do another asyn transfer. This is how i change it.

for(i=0;i<NUMBER_OF_BUFFERS;i++){

IOWR_32DIRECT(DESC_MEM_BASE,28+32*(i), 0x80000000);

}

But is there a better way of doing this? can i set "park" to 1? so that my owned by hardware bit will not go 0 after transfer??

regards,

Michael

A functional error due to the FIFO becoming full depends on your implementation. Data will not be dropped between the SGDMA and FIFO since both use the streaming valid and ready signals to apply back pressure.

You will need to use two descriptors to move 65kB of memory, descriptors only have a 16-bit length field so that means you can only write up to 65535 bytes total. So it's not that the memory is write protected, the SGDMA just can't write that much data using a single descriptor.

When parked is set then the SGDMA just doesn't flip the owned by hardware bit when the transfer completes. The tricky think is you will not know how many times the same descriptor has been reused by the SGDMA if parked is enabled so that may or may not matter to you.

--- Quote Start ---

You will need to use two descriptors to move 65kB of memory, descriptors only have a 16-bit length field so that means you can only write up to 65535 bytes total. So it's not that the memory is write protected, the SGDMA just can't write that much data using a single descriptor.

--- Quote End ---

I was using a chains of descriptors, not just 1. I know 1 DMA transaction can move 65KB of data, so i used a chains of 4 DMA transaction to move 16384 bytes each time, so i can move 4*16384=65536 Bytes, but still some ranges of memory address in the destination RAM is not writable, as shown in the picture

Michael