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.

McBSP EDMA ISR Help

I am attempting to repeatedly read McBSP packets by EDMA utilizing the example found in "csl\csl_c6455\example\mcbsp\mcbsp_edma." Currently if I do not set the rxintFlag in the ISR routine the DSP will receive every McBSP packet that comes in. However this seems to lock up the DSP, I also have EMAC running and can no longer receive messages over the ethernet socket. I believe this is because the DSP is stuck in an infinite loop: While (!rxintFlag){}. However if I remove this loop (and don't run the code that disables the EDMA) I do not get any McBSP packets. Can anyone offer any tips on how to get this working properly?

Thanks!

  • Tim,

    In order to service the McBSP continuously throughout DSP operation, the channels must be linked to a duplicate PaRAM set in the PaRAM. After all frames have been transferred, the EDMA3 channels reload and continue.

    Please take a look at section 3.4.2 in EDMA user guide:

    http://www.ti.com/lit/ug/spru966c/spru966c.pdf

    Hope that could help.

  • Steven,

    Thank you for the reply. I do have a duplicate set of params and I am able to repeatedly read the EDMA transfer. The problem is related to the:

    while(!rxisrFlag){}

    If my RX ISR does not set this flag I will repeatedly receive EDMA transfers. However this means my DSP is stuck in an endless loop. Setting the flag means I only receive one EDMA transfer. I believe the interrupt flag needs to be turned into a HWI so that I can do other processing until the McBSP is ready again. Unfortunately, I have been unsuccessful in my attempts to create the HWI.

    Is a HWI the recommended path? or is there another way? 

    Thanks,

    Tim

  • Tim,

    If EDMA controller is setup correctly to service the McBSP in normal operations, it services the McBSP automatically upon receiving the XEVT and/or REVT as mentioned in McBSP user guide. There is no need for CPU polling or other CPU interaction for the EDMA servicing McBSP events in the background. The EDMA transfer completion event can generate CPU interrupt only if you need to process those received McBSP data by CPU after each EDMA transfer.

    I think "while(!rxisrFlag){}" in the example is just one way to notify CPU that EDMA transfer is completed and CPU could end this example and exit. In your real application, you do not need to keep this while loop, instead, once the EDMA/McBSP event is configured, you could free up CPU to do other work such as servicing EMAC as you mentioned. Again, you may choose to keep the CPU interrupt for EDMA completion. The CPU might be interrupted by EDMA/McBSP event while it is serving other peripherals. But once ISR exists, the CPU should be able to resume to the previous task. 



     

  • Steven,

    That's very interesting. Currently I am not seeing that behavior, but maybe I have something configured incorrectly. Removing the loop seems to prevent EDMA activity. If I use the exact example code and remove the loop (as well as the channel close after it), I should be able to receive exactly one packet correct?

    Tim

  • Tim,

    I think if you remove the while loop and do not disable EDMA channels after that in the example code, the McBSP and EDMA events will keep being triggered when you have new data received by McBSP. But I do not have C6455 at my  hand and hope you can give a try.

    If you see the EDMA is not being triggered, please check the missed event register (EMR/EMRH) and secondary event register (SER/SERH) to see if the channel bit being set.  The section "A.1 Debug Checklist" in EDMA user guide has one row item discussing the issue of "The Secondary Event Registers bits are set, not allowing additional transfers to occur on a channel.". Hope it could be helpful for your application as well.