• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 282 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Lost DMA Events using Chaining on C6415

Ralf Goebel
Genius 3715 points


Hello,

I have a problem of missed EDMA events using the chaining mechanism. I use the following setup:

The first EDMA channel "A" copies one word within L2 memory and then triggers the second EDMA channel "B". In rare cases, a chaining event for EDMA B is missed. It seems that a race condition occurs when two Transfer Requests of EDMA A are queued up in the priority queue. My guess is that the Channel Controller isn't able to send the Transfer Request of EDMA B for the first chaining event to the priority queue fast enough, before the second chaining event of EDMA A occurs.
There should be room in the priority queue to accept the next TR without stalling. The problem seems to go away if the data source for EDMA A is located in a slower memory. This makes sense, because the second event takes longer to arrive at the Channel Controller.

Is there information available on how long it can take for an EDMA channel between arrival of the first event and the time it will accept the next event (with the assumption that the priority queue is not full)? Could we make sure not to loose any event by using slower source or destination memory for the EDMA A?

Any help is appreciated,
Ralf

  • 0
    TI__Guru* 84110 points

    Ralf,

    The detail is not available of cycle counts between one event and the time to be ready for the next event on the same channel. Your case is a slight extension of that, since the issue is the chaining to the next event, but the detail of cycle counts is not available. There are many external issues that will affect this timing.

    In general, you should never be in a position to have a second event being triggered when the first event is not guaranteed to have been completed. Normally, you would consider this for channel "A", but channel "A" seems to be a very quick transfer that then chains to channel "B". So you must also consider the chaining as a triggering event, meaning that channel "A" must not trigger channel "B" before channel "B" is guaranteed to have completed.

    It could help to have more information from you about the timing, clock frequencies, queues, and so on. But the real answer will be throttling the rate of the channel "A" events or finding a way to queue up events in the DSP code, but that would mean using interrupts and DSP MIPS to handle it. Then again, I am only guessing based on what could be going on in your system.

    Regards,
    RandyP 

  • 0 in reply to RandyP
    Genius 3715 points

    Hi RandyP,

    thanks a lot for your reply.

    There is already a delay between events for channel "A" of about 1us. I think the problem is that a longer transfer request for a different DMA channel is already in the priority queue which then causes two events for channel "A" to queue up after each other. As soon as the large transfer completes, the two smaller transfer requests for channel "A" will be processed without any delay and the second chaining event will be missed by the channel controller.

    Using a different data source than L2 SRAM for channel "A" seems to work as a workaround, because it gives the channel controller more time to post the transfer request. The copied data itself is not of interest, the DMA is only used to count the number of events.

    Ralf

  • 0 in reply to Ralf Goebel
    TI__Guru* 84110 points

    Ralf,

    You are giving me only small hints into what you are trying to do. If I make guesses and propose a solution, it is likely wasting your time to consider it and mine to develop and propose it. A fuller description of what you want to do may be the only way to get anything meaningful here, but I will keep trying.

    The 1us delay is obviously not sufficient to avoid the race condition. Depending on what you are doing with channel "A", you may be causing an error condition by triggering a second transfer before the first has completed or even started. Getting different results from different source location implies that the long transfer is not 100% to be the culprit.

    One possible solution is to use different queues for the transfers. Let the long transfer be run on a lower priority queue and let the channels "A" and "B" run on a higher priority queue.

    Another possible solution is to break the long transfer into multiple smaller transfers that would allow the first channel "A" to slip in sooner.

    And another possible solution is to use more than one channel "A" and more than one channel "B", or modify channel "A" to chain to two different channels "B1" and "B2". You can do this with EDMA2 in C6415T but not EDMA3 in the C64x+ and later devices.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Genius 3715 points

    The system setup is very complex and is already working for many years now. The problem suddenly appeared because our customer started using a faster camera.

    I'm also trying to understand how EDMA transfer requests are submitted in general. I found some useful information in spra994, spraa00 and spraa02 about the interaction between the channel controller and transfer controller.

    I don't think that multiple transfer requests in a queue for the same channel would cause an error condition in general. They are simply processed after each other. But in my case, the arbitration at the transfer requester nodes for the chained channel B sometimes takes longer than for the next event to arrive. I understand that it is difficult to get exact numbers for arbitration times at the transfer request bus, because it depends on transfer request submission of all request nodes which depends on the whole system.

    Using a different queue for the long transfer (which takes 1...2us) isn't an option in our application. But I agree that chaing to two different channels B1 and B2 should solve the problem. I will keep that in mind in the case that my simple workaround (using a different data source than L2 RAM) doesn't solve the problem completely.

    Thanks,
    Ralf