McASP Issues

Hi Pratibha

A few observations/feedback

1) Looks like your system will have some complexity , in terms of interrupts from multiple sources (McASP, EDMA, GPIO, SPI). Without OS, I think you will have a long development time writing your own schedulers and interrupt handlers. Esp for EDMA, if you have multiple peripheral sources, you will need a smarter EDMA interrupt handler. This is where TI RTOS/Linux and EDMA3LLDs might be more initial ramp, but might provide a better path for development.  

Prathibha Kadur said:

CPU polling and CPU interrupt for McASP. I have two issues with McASP.

1. As I mentioned McASP works only when it is a stand-alone module. Once I start McBSP communication (Rx only) on EDMA, McASP stops working. I don’t even get McASP interrupts. I have assigned interrupt #4 to McASP and #5 to McBSP EDMA event. I would like McASP interrupt to work with other interrupts.

2) It appears to me from your description that you might be confusing CPU interrupt and EDMA events? The McASP interrupt to CPU (if you are not using EDMA for McASP) is # 54 for ARM INTC and #61 for DSP interrupt controller (Table 6-6 and 6-8 in the datasheet). The McBSP1 "events" to EDMA are 4 and 5 (RX, TX, Table 6-14), the McASP events are higher up.

If you are expecting a completion of McBSP-EDMA transfer to generate an interrupt this will be an EDMA Transfer Completion Interrupt to the ARM or DSP interrupt controller (Table 6-6/6-8 again) and if you have multiple EDMA channels, it will still be single interrupt to the CPU, and the EDMA ISR will need to have the "smarts" to figure out which channel's transfer completed and what needs to be done post completion . 

So I don't understand what the lines highlighted in yellow imply. I would recommend making sure that there is no confusion on EDMA events and CPU interrupts and how they need to be handled by the CPU etc. Additionally the interrupts and events are "hard wired" so the event/interrupt assignment is not software programmable etc. 

Hope this helps some on Q1

Regards

Mukul 

• Hi Mukul,

Thank you for your reply.

1)      Looks like your system will have some complexity , in terms of interrupts from multiple sources (McASP, EDMA, GPIO, SPI). Without OS, I think you will have a long development time writing your own schedulers and interrupt handlers. Esp for EDMA, if you have multiple peripheral sources, you will need a smarter EDMA interrupt handler. This is where TI RTOS/Linux and EDMA3LLDs might be more initial ramp, but might provide a better path for development.

We are planning to have TI RTOS in future, but for now we need to make these peripherals work together in NON-OS environment.

2) It appears to me from your description that you might be confusing CPU interrupt and EDMA events? The McASP interrupt to CPU (if you are not using EDMA for McASP) is # 54 for ARM INTC and #61 for DSP interrupt controller (Table 6-6 and 6-8 in the datasheet). The McBSP1 "events" to EDMA are 4 and 5 (RX, TX, Table 6-14), the McASP events are higher up.

I have been running EDMA TC0 successfully for McBSP0 Receive, EDMA event being #2 (McBSP0 RX, Table 5-14).  This event is mapped to CPU #5 Interrupt (DSP usable Interrupts are 4 to 15). I have EDMA3 dispatcher/interrupt handler in place. There is no confusion there. 

.  For McASP I am mapping #61 (MCASP0_INT) event to CPU interrupt #4. Both peripherals work fine if I run them as stand-alone modules.  Problem starts when I run both McASP and McBSP simultaneously.  McBSP0 peripheral takes over and McASP does not work.  The lines highlighted in yellow imply the following.

            // Interrupt Selector

            //MCASP Interrupt will be sent to CPU Interrupt # 4 (highest priority of available interrupts)

            CSL_FINS(dspintcRegs->INTMUX1, DSPINTC_INTMUX1_INTSEL4, CSL_INTC_EVENTID_MCASP0INT);

            // McBSP0 uses this EDMA

            //EDMA3 0 Channel Controller 0 Region Interrupt #1 will be sent to CPU Interrupt # 5

            CSL_FINS(dspintcRegs->INTMUX1, DSPINTC_INTMUX1_INTSEL5, CSL_INTC_EVENTID_EDMA3_0_CC0_INT1);

For Q2, I am testing McASP EDMA FIFO as stand-alone. This is for only transmit. I am using EDMA event #1 (McASP0 Transmit). This is not working either.

Any help is appreciated.

Thanks,

Prathibha

Hi Prathibha

Thanks for clarifying on your edma, interrupt handling. Good to know that you have this right. Thanks for clarifying that you are using the DSP interrupt controller.

it would appear that you either have a software issue in handling multiple interrupts - in which case i would recommend start looking at the the interrupt source files in Starterware releases to make sure you are handling the dsp interrupt controller register handling correctly ( e.g. not accidentally stomping on the flags set for one interrupt vs the other etc) 

Alternatively, if you are confident that this is working correctly and the interrupt handling should work when you have multiple interrupts, then please investigate further on the frequency of McBSP - EDMA vs McASP interrupts , to ensure that McBSP rate of interrupts is not too frequent that your code never hits the McASP interrupt ISR etc , even though priority wise you have McASP at higher priority interrupt 

On #2 it is unclear what your problem might be, please also make sure you are looking at the McASP tips wiki written by Brad

http://processors.wiki.ti.com/index.php/McASP_Tips

Hope this helps.
Regards

Mukul 

Thanks for updating the thread. Good to hear that you are able to work around the issue.

Was there something specific that was not making your McASP EDMA working in the first place? Any gaps in the documentation that caused this?

Regards

Mukul 

Hi Mukul,

I used McASP Echo example from rCSL library as a reference code for my McASP EDMA project.  I used the same configuration and same data as in Brad/Brian’s post in this forum. It did not work. I found that memory allocated in the linker command file was causing the problem. It was using

L2:                          origin = 0x00800000          length = 0x00040000

When I changed to

L2   o = 0x11800000  l = 0x00040000  // 256kB L2 Shared Internal RAM

it started working.

Thanks,

Prathibha