DMA-controller doesn't generate an interrupt after changing the transaction type once

[Altera_Forum]

Hello, 

 I realized that the dma-controller doesn't generate an interrupt the first time after I change the transaction type without resetting the core. But the transaction is done normally.  All transaction types I tried are enabled in the SOPC core. The interrupt bit is set in all cases.  The error doesn't occur if I reset the dma-controller every time - but the throughput diminishes. So that's no solution.  I also tried setting the go bit in an extra iowrite32() call - without success.  Does somebody know if I'm making a mistake or is this a bug? The SOPC is running on a Arria II GX on the Arria II GX dev kit.  Thanks in advance.  Regards,    Frederik

[Altera_Forum]

We made similar experiences, but with some differences. 

 In our case everything went well until we manually aborted the DMA-Transfer. It wasn't enough to clear the GO-Bit and reinit the DMA for a new transfer. To change the transaction type we had to do a core reset.  but if the DMA-Transfer was successful, we didn't have to do a reset in order to change the transaction type.   If I got you right, you always have to do a reset, don't you? Even after successfully completed DMA-Transfers?  regards, Philipp

[Altera_Forum]

Hello Pillemann (sounds german to me), 

 I do not check how the transfer ends. I set up the dma controller to end when the length register reaches zero and the driver checks that length is a integer multiple of the transfer type's length in bytes (ie. 4 or 8 in my case).   I watched the length register in signal tap. It always reaches zero even if no interrupt is generated.   I fixed the problem in not changing the transfer type. Every transfer is double word. That doubled the throughput, too.  I normally do not reset the go bit but I tried to - without success. Only a reset before changing the transfer type soluted the problem. But the reset operation reduced the throughput significantly.  My driver generates a timeout if no interrupt occures. I will check the status register after a timeout and post it.  I'm using Quartus 10.0 SP1.  Regards from Hamburg,  Frederik

[Altera_Forum]

I did further tests. 

 Debugging the status register after a timeout of five seconds (!) makes clear that the BUSY bit is still set. The length register reaches zero.  Tha following transfer runs normally without any reset until I change the transfer type.  But the first transfer doesn't finish after changing the transfer type.  Can you confirm this?   Regards,  Frederik

[Altera_Forum]

Good morning Frederik, 

 I can not confirm it for sure. But actually I think it is the same problem or bug.  We are using the DMA in combination with UART. Even if we don't change the transfer type (in our case it is always BYTE), we sometimes aborted the direction of the transfer. Meaning that we clear the GO-bit before transfer is done, changing from RCON to WCON (or vice-versa) and setting up a new transfer, which ends with setting the GO-Bit again.  But this didn't work out. No interrupt was asserted, so we had to reset the DMA by writing the SOFTWARERESET-bit twice. Then it worked, even for aborted transfers. Unfortunately it is some time ago we recognized this problem. So I don't know exactly if the the length register was zero. But I know for sure that the BUSY-bit was still set, but nothing happened. Resulting in no interrupt. And I am pretty sure we set up the DMA right, after aborting the previous transfer.  I assume it's a similar problem/bug. But that's only my assumption....  Regards from NRW, Philipp  P.S. : Yeah, I am german. Don't get my nickname wrong. Got something to do with sports.....

[Altera_Forum]

I just had another Problem. The system froze. That happens because of an dma buffer overflow. This happend after a transfer type change.  

 So I think we can conclude the dma controller doesn't work like the user exspects after reading the user guide.  Not changing the transfer type helps but is not always a solution. Resetting the dma controller works, too but reduces throughput and will not help if that's the bottleneck.  So ALTERA, please fix this issue. Those error produce a lot of idle power.   Regards,  Frederik