--- 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
Honored Contributor
