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

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

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

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

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.....

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