• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 424 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.

DM365 McBSP DMA transfers stop interrmittently when there are too many event-triggered transfer requests

Rod Burchell
Prodigy 230 points

What I'm seeing is that if my DMA event trigger has extra event triggers (particularly two - 9722) beyone the number of triggers needed for each DMA transfer (my DMA transfer is set up for 9720), that intermittently, the McBSP DMA transfers stop and cannot be restarted, (even though the DMA setup params continue to be set and the DMA start continues to be called). I'm seeing NULL transfers due to the extra event triggers as would be expected...these result in a dma error interrupt where the EMR and SER are cleared.  I've tried manually (non-DMA style) sending out a McBSP double word after the "crash" and still nothing comes out of the McBSP.  The only effective solution for recovery thus far has been power cycling or a hardware reset of the processor.   

Getting the event triggering peripheral to generate the exact number of event triggers has its own challenges and I was trying to avoid that.  

Anyone seen anything like this or know anything about this?

Regards,

Rod

  • 0
    Prodigy 230 points

    I'm also seeing some irregularity spacing in the event triggers during the last half of each transfer.  Typically, its 2.5us between triggers for the first half of the transfer.  During the last half of the transfer, the trigger spacing varies from 2.5us up to as much as 20us between triggers.

    I've been able to catch some transfer failures.  The last DMA transfer is only a partial transfer...and from what I've seen so far, the first half appears to transfer fine and then the stop of transferring occurs somewhat randomly in the last half of the transfer. 

    I can only surmise at this point...maybe there's a coorelation between the failure and the irregular trigger spaceing??

    Rod

  • 0 in reply to Rod Burchell
    Prodigy 230 points

     You can see from this scope capture an example of what's happening when the McBSP dies.  The hardware trigger (rising edge of GPIO6) is going low sooner than it does elsewhere and there is only one response of the FSX to two rising edge hardware triggers.  

    Does that help in narrowing down what would cause the crash?

  • 0 in reply to Rod Burchell
    TI__Mastermind 21285 points

    Hello Team,

    Is there an update available regarding this customer inquiry?

  • 0 in reply to Michael S
    TI__Genius 9775 points

    Hello,

    What is UB_CLK in the plot?  Also, what else is concurrently running when you see this behavior?  What bit clock are you running the McBSP at? 

    Thanks.

  • 0 in reply to Ivan Garcia
    Prodigy 230 points

    Hi Ivan,

    Thanks for the inquery!

    The UB_CLK is a signal that is unrelated to the McBSP transfer.   (I see the glitch on this signal that is occuring right at the time of the failure, but I've captured this problem without this glitch present.) 

    The McBSP clock rate is 17.3MHz.

    There are other DMA transfers going on besides this one.

    A collegue has pointed out that we are requesting a second McBSP transfer (low to high transition) before the first one has fully completed.  His thought is that we should never do this, and I'm inclined to agree.   Would doing this cause the McBSP function to crash?

    What makes this more complex is that the length of time it takes from the McBSP transfer hardware request to when the transfer completes varies.  My guess would be that this is probably due to multiple DMA channels using the same transfer controller.

    Regards,

    Rod