memory-to-memory sgdma problem

[Altera_Forum]

Hello,  

I am testing the sgdma core by copy data from one on-chip-memory buffer to the other. However, I met a confusing problem that the actual_transfered_bytes is always zero. Can anybody help? the sopc-builder system i used is as follows:   cpu -----instruction_master -----data_master on-chip memory -----s1 sgdma_0 -----csr -----descriptor_read -----descriptor_write -----m_read -----m_write   descriptor_read, descriptor_read, m_read and m_write are connected to s1 of on-chip memory. csr is connected to data_master of cpu.     the c code is as follows:   alt_u32 tx_buf[10], rx_buf[10]; alt_sgdma_descriptor desc, next; int main() { alt_u32 i; alt_sgdma_dev *sgdma_m2m; alt_u8 status; for(i=0;i<10;i++){ tx_buf = i+0x11111111; rx_buf = 0; }   sgdma_m2m = alt_avalon_sgdma_open ("/dev/sgdma_0");   /* This will create a descriptor that is capable of transmitting data from an Avalon-MM buffer * to a packet enabled Avalon-ST FIFO component */ alt_avalon_sgdma_construct_mem_to_mem_desc( &desc, // descriptor &next, // next descriptor tx_buf, // read buffer location rx_buf, // write buffer location (alt_u16) 10, // length of the buffer 0, // reads are not from a fixed location 0); // writes are not from a fixed location   /* Prime the SGDMA engines with the descriptor lists (first one, it's a linked list) */ status = alt_avalon_sgdma_do_sync_transfer(sgdma_m2m, &desc);   return 0; }   After alt_avalon_sgdma_do_sync_transfer() is called,  status is 0x0C which is as supposed, but desc.actual_transfered_bytes is zero!  The values in rx_buf[] remains the original values, all zeros. Any comments will be appreciated.

[Altera_Forum]

Is it possible to transfer data between two on-chip memory buffers with memory-to-memory sgdma?

[Altera_Forum]

If you have a data cache enabled, it will probably prevent you from reading the updated values. 

You can use alt_remap_uncached() to change a pointer value to something that will force the CPU to bypass the cache.

[Altera_Forum]

And yes it is possible. You can either transfer from and to the same memory, or between two different memories.

[Altera_Forum]

The length of your buffer is 40 (10 words of 4 bytes each). Like others have said make sure the data isn't held in the cache. 

 I can't remember if actual bytes transferred is supposed to update for MM->MM transaction types since there is no need to know it (you tell the DMA how much data to move). The actual bytes transferred field is meant for ST-->MM transactions with packet support enabled since you will not know how much data is arriving.

[Altera_Forum]

I just got the right result after I had taken your advices. 

I used the function alt_remap_uncached() which is described in "Cache and Tightly Coupled memory" to transform the pointers, and the transfer size is indeed 40 instead of 10.   Thanks all, especially Daixiwen.

[Altera_Forum]

I recently made the sgdma work in the setup described in this topic but I'd like now to move data from one second on chip memory to a third one. I tried several ways to connect the sgdma to the memory blocks but it never works. I guess that the main problem is that the connection of the devices in the SOPC builder is not done correctly. Is there any place where I can find the purpose of the csr/descriptor_read/descriptor_write/m_read/m_write I/O of the SGDMA block ?

[Altera_Forum]

The m_read/m_write master ports must be connected to the memories you want to read from/write to. 

The csr slave port must be connected to the CPU data master The descriptor_read/write master ports must be connected to the memory that holds the descriptor (usually the RAM that holds the .data section or the heap memory, depending on your code).

[Altera_Forum]

Hello i didnt understand your code. Could you explain it pls? Where do you select the adress of the memories you want to read/write from and where are you seeing if everything is happening as planned (how are you debuggin?)

[Altera_Forum]

alt_remap_uncached(), how to use this function in the code

[Altera_Forum]

See page 14-47 of http://www.altera.com/literature/hb/nios2/n2sw_nii52010.pdf