TMS320C6678: Maximum size of a single EDMA transfer?

My current working thesis is that copying data via EDMA from PCIe mapped memory does not work for single transfers > 1 MB.
This is why I am setting up a chained transfer using all three EDMA loops now.

I am using the cCnt now, so I also need to set the stride for the scrDstCidx, which is a 16 bit signed integer. This reduces the possible size of the AB-synchronized transfers (which are now partial transfers) to 16 KB (the nearest power of two).
16 KB are easy to reach by the bCnt alone, so I set the aCnt to a very small value of 4 bytes.
aCnt = 0x4;
bCnt = 0x1000;
aCntbCnt = CSL_EDMA3_CNT_MAKE(aCnt, bCnt);
srcDstBidx = CSL_EDMA3_BIDX_MAKE(aCnt, aCnt);
cCnt = 0xFFFF;
srcDstCidx = CSL_EDMA3_BIDX_MAKE(aCnt*bCnt , aCnt*bCnt);

The resulting transfer would be over 1 GB.
For practical reasons I make the bCnt and cCnt adjust to the transfer size. I omit the arithmetic code here.

I adjusted the PaRAM setup:
option = CSL_EDMA3_OPT_MAKE( CSL_EDMA3_ITCCH_EN, CSL_EDMA3_TCCH_DIS,\
CSL_EDMA3_ITCINT_DIS, CSL_EDMA3_TCINT_EN, channelNum, CSL_EDMA3_TCC_NORMAL,\
CSL_EDMA3_FIFOWIDTH_NONE, CSL_EDMA3_STATIC_DIS, CSL_EDMA3_SYNC_AB,\
CSL_EDMA3_ADDRMODE_INCR, CSL_EDMA3_ADDRMODE_INCR );

CSL_EDMA3_ITCCH_EN allows the EDMA controller to signal intermediate transfer completion for every iteration of the C loop.

CSL_EDMA3_STATIC_DIS: It took me some time to find out that it is necessary to have nonstatic addressing at a chained transfer, otherwise the transfer gets stuck after doing one intermediate transfer.
The EDMA Keystone User Guide sprugs5b says about CSL_EDMA3_STATIC_DIS:
"0h = Set is not static. The PaRAM set is updated or linked after a TR is submitted. A value of 0 should be used for DMA channels and for non-final transfers in a linked list of QDMA transfers.
1h = Set is static. The PaRAM set is not updated or linked after a TR is submitted. A value of 1 should be used for isolated QDMA transfers or for the final transfer in a linked list of QDMA transfers."

The result works fine for transfers from DDR3 to DDR3 again, but from PCIe the transfers still get stuck at > 1 MB.

Thank you for any suggestions.

Thank you, Eric.

I guess you are right that the problem of the 1MB transaction limit lies outside of the EDMA. I am investigating this.

I will report as soon as I have found something.

Eric,

comparing my code for PCIe setup with the examples you provided, my attention was drawn to the following lines of code:

From pcie_sample.c:
/* Only required for v0 hw */
obSize.size = pcie_OB_SIZE_8MB;

My code used pcie_OB_SIZE_1MB.

The outbound size is relevant for the C6678, as it has PCIe hardware revision 0:
"There are three revisions of the pcie hardware. The first, v0, in KeyStone devices (C66x, K2x). The second, v1, is in AM57xx devices. The third, v2, is in AM65xx devices." -
software-dl.ti.com/.../Device_Drivers.html

Changing the obSize.size to 8MB solved the problem for me.

While there are actually 32 outbound translation regions of 1MB, the reason why it did not work may be this:
"If a transaction is large enough that it goes past the address translation region, unspecified behavior may occur. [...] So, a memory write, for example, will not automatically go to the next translation region if it starts in the previous one and is bigger than the remaining size in the starting translation region." - sprugs6d PCIe user guide 2.7.1.1

Hello!

Nice to hear you found solution.

Meanwhile I'd like to draw your attention, that according do PCIe spec, transactions are not allowed to cross 4KB boundary. As 1MB translation region has its boundary aligned on 4KB, so no one transaction may cross translation region boundary and point of 2.7.1.1 slips out of my understanding.

Hi rrlagic,

concerning sprugs6d 2.7.1.1, I'm not entirely sure that the word "transaction" always means the same thing throughout the document. EDMA transactions are split up internally, just as Eric wrote. I suppose that the EDMA Transfer Controller's default burst size complies with the 4KB PCIe transaction boundary you mention and it is the sub-transactions' size that is relevant here.

Staying inside an address translation region boundary seems to be an additional obligation to me - and it has different constraints.
As an indication, I did not succeed in splitting up my transaction into separate EDMA transfer calls, such that each of them matched the size of a single translation region. As result, the first call succeeded, while the second call got stuck without signaling the interrupt - with no boundaries crossed. Thus, I don't know if 2.7.1.1 really applies here. pcie_OB_SIZE_8MB did.