Priority between ACPY3 and EDMA3 copy in C6455

From which software package are you accessing ACPY3? I am definitely not well-informed on all the latest software packages, but this is the first time I heard of someone using ACPY3 with the C6455. There is no reason what that would be bad, I am just curious for my own benefit.

It is my understanding that ACPY3 can be considered to be a wrapper around the QDMA functionality of the EDMA3. When you setup an event-driven DMA channel, that also is a part of the EDMA3 module.

In what way does the ACPY3 disturb the displayed image? Are you sure it is the displayed image and not the captured image that is corrupted?

Give us some more details on what you are copying with ACPY3, from where to where, how much...

And also on the image transfers, how much, from where to where, how often...

How do the transfers relate to each other in time? Which one starts first? Is it almost random?

Priority will probably not solve your problem, but it just all depends on what you are doing.

Regards,
RandyP

Hi RandyP

sorry for the late answer, I needed to check thing up before I can answer correctly.

First, we are using framework component 2.26 (on DspBios 5). Previously we configured manually EDMA3 channels to copy data between internal and external memory, and we thought it would be easier with ACPY3. We also integrated algorithm that was designed according to XDAIS guidelines, so we need to change all the copy method to ACPY3\DMAN3. More previously, on C6414 we used the CSL DAT_copy for all the internal to external copies, but on C6455 the CSL DAT_copy doesn't support parallel copies, like start two different copies with unique wait for each one on different part of the code. It only supports one copy with one wait, and then another copy and wait. By the way, why it changes? It works great on C6414.

Anyway, I will describe how we work. We receive image from cmos camera (800*600 YCbCr 4:2:2) on 30 Hz to the external memory using event driven EDMA3 copy, perform some algorithms include memory copy form external to internal memory (and back), and then send back the result image to the firmware using EDMA3 event driven copy. We work with double buffer, so when new incoming image copy in and previous outgoing image is copy out, we perform the processing on the current image.

We saw that when ACPY3 copy occurred, it disturb another event driven EDMA3 copy form external memory to firmware (FPGA) memory. We saw that the firmware memory fills with garbage data, and also it adds delay to the outgoing memory, so the garbage lines on the video "push down" the good image lines. It can be matter of priority on the external memory, but why fill the firmware memory with garbage data?

Maybe if I will avoid using large ACPY3 copies, it will help. Most of the time I copy only few lines of image to the internal memory, process them, and return back to the external memory. But in some cases I copy the whole image using single 2D copy. Maybe breaking the copy to small copies will help.

I hope you come out with new idea,

Regards,

eli

Eli,

Priority issues would only affect when the data is transfered, not the content of the data that gets transfered.

My guesses are only guesses. You will need to CCS to debug the problem. Here are some guesses:

• Resource conflicts between ACPY3 and the event DMA channels, such as re-using the same PaRAM for both or the same TCC number for both.
• Programming error in which the PaRAM is setup wrong periodically.

Suggestions:

• Look at the exact nature of the garbage data.
• When the garbage data is sent, is the right amount of data sent or is extra data (more lines) sent?
• Find out which EDMA3 channels and which PaRAMs and which TCC codes are being used for the DMA and QDMA channels.

Regards,
RandyP

Hi RandyP

I think I find the answer. It was conflict on the DMA Queues. I need to set queue for the ACPY3 copy to different queue number than the EDMA3 copy, using DMAN3_PARAMS.qdmaQueueMap parameter. This parameter doesn't appear in the ACPY3 user's guide or in the ACPY3 examples, but it is part of the DMAN3_PARAMS struct. I think you need to add this struct field to the ACPY3 user's guide.

Regards,

eli