I've recently battled my way through some interesting DSPLink debugging and I thought I'd share with the community in case anyone else has similar issues.
I'm using an OMAP-L137 on a custom board. I have a SPI ADC connected to SPI1. The SPI ADC signals that data is ready to read via a GPIO line. I programmed the GPIO Bank Interrupt as a falling edge event.
I used two EDMA events: (1) the GPIO Bank event was tied to an EDMA transfer to transmit a single word to the SPI ADC and (2) the SPI1 receive event was tied to an EDMA transfer to receive a large amount of SPI data and store it in memory. The transfer complete interrupt disabled the EDMA events and set a semaphore to signal that the transfer was complete.
The first attempt to get this working was with Codec Engine, but the SPI traffic timing was very erratic. The timing was occasionally so bad that it violated the spec for the SPI ADC's "quiet time". At TI's suggestion, I ported the code to use DSPLink rather than Codec Engine. Everything worked fine, except that DSPLink on the DSP would no longer respond to any notifications after SPI transfers started. A team of engineers at TI helped me figure out what was going wrong.
My DSP code was altering the pinmux on the DSP side (to configure the SPI pins, which may have been used as UART2 up until the DSP was loaded), and the pinmux operation hits the KICK registers. DSPLink is "sensitive" to KICK register usage.
The solution was to move the pinmux changes to the ARM9 before it starts using DSPLink to setup, attach, etc the DSP.
Lastly, because the SPI device didn't work under the Codec Engine as expected, I had been instructed to disable SPI1 in the kernel and power it in the DSP code. It seems that DSPLink may be "sensitive" to playing with the Power Control Registers also.
All is working now and the SPI timing is perfect. Thanks for all the support I got during the effort. Special "huzzahs" to Brad Griffis for helping with the EDMA PaRAM set definitions and to Arnie Reynoso for debugging the DSP notification hangs (and much else of the DSPLink conversion from Codec Engine). Their efforts went "above and beyond".
I received lots of support from other TI personnel also. Thanks to all.