We are working with an EVMC6678. When performing several linked transfers, with the output of one transfer set to be the input of the next, we see incorrect behavior.
We start with a simple 100x100 image consisting of a flat gray background and a single 21x21 white square, as seen in file img0.pgm (viewable with IrfanView or Beyond Compare).
We run three linked transfers, each copying the white square to a new location in the image. The destination of each linked transfer is the source of the next transfer. We expect to see a result with four white squares (img1_expected.pgm) but we see a corrupted result (img1.pgm). Here are the relevant PaRAM sets:
0x02704200: 80000004 00000000 00000000 00000000 00000000 00004220 00000000 000000000x02704220: 80000004 80000B62 00150015 80000B8A 00640064 00004240 00000000 000000010x02704240: 80000004 80000B8A 00150015 80001AFD 00640064 00004260 00000000 000000010x02704260: 8010000C 80001AFD 00150015 80001F08 00640064 00004280 00000000 00000001
Note that the first set is a QDMA channel, the others are link channels. The QDMA is configured as a dummy transfer linked to the second channel. The trigger word is CCNT and the configuration is shown here just before setting CCNT=1 on the first set. Also note that Early Completion is disabled and contrary to our expectations, has no effect on the results.
Obviously we could solve the problem by setting the original white square as the source for all transfers; we still want to know why this is failing and whether this would have an impact on other use cases.
what are you using to trigger these? The next PaRAM entry when linked is automatically loaded as soon as a transfer begins, if you're triggering that next transfer before the previous one has completed then you can get ahead of it (i.e. then 2nd tranfer is reading the data before the 1st transfer has written it.) Which appears to be what's happening here. You have one of two options, 1 make sure whatever your using to trip the event to cause the Xfer to be executed has sufficient time between linked entries, or two you can using chaining, such that the completion of one transfer trips the execution of the next transfer. I'd recommend the 2nd option for this case, and I'd suggest not using early completion when chaining where the source of transfer N is the destination of transfer N-1.
Please click the Verify Answer button on this post if it answers your question.
Your memory printout is missing the 4260 line, but the 4280 line is using the same source as 4240's destination, so it implies a printout gap of some kind, or else a label error.
Your image files are not in a format that I can view, and I am not going to press my IT department for something that could have been supplied in a format compatible with the forum or common web browsers/Windows OS. In lieu of that, please describe the corruption you are seeing.
The concept seems solid for your QDMA-chained transfers. The first one is a throw-away to start the process, so I usually just write the first transfer there after writing 2-N to the later PARAMs. But your method is reasoned and clean, and it leaves all of the transfer PARAMs visible in the printout.
Having Mode=Normal is definitely the right choice, but I am surprised that you had no difference with it either way.
Try making your square 25x25 and see if the corruption changes. This will overfill the 512-byte read buffers in the Transfer Controller. You could also try making the square a lot smaller, like 8x8, but that sounds less interesting.
You may want to study the DDR command ordering information in that User Guide. I cannot picture a way that the EDMA could be causing this corruption from what you have described. And the DDR should not return the Normal completion so early that you would get corruption.
Could it be a memory viewing problem related to cache coherency? How are you viewing the corrupted image?
Search for answers, Ask a question, click Verify when complete, Help others, Learn more.
I believe Chad gave the best explanation for what's going on here: the transfers are not occurring sequentially as expected but the 2nd is reading before the 1st has completed writing. As the EDMA documentation states in sprugs5, section 2.1.3 in the discussion about DSTREGDEPTH, the Transfer Controller's read controller may process several Transfer Requests ahead of the write controller.
Thanks for your help!
Now it makes sense to me, that the triggering happens at the link step and the link step happens when the Transfer Request was sent to the Transfer Controller. I was stuck thinking that the completion flag from the DDR would be starting the next one.
You can do the same process as your QDMA list by chaining to the same DMA channel for each step, but the chain step will not occur until after the transfer has completed. And this is what Chad was telling you in his post in the first place.
This points out that QDMA self-chaining is equivalent to EARLY mode chaining. And we can expect reads to happen before the previous writes have finished, when using EARLY mode completion for triggering.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.