EVM OMAP L137 - accessing McASP with DSP/BIOS app running under Linux

A couple of things come to mind that may be worth investigating

1) I2C used to control the AIC3106 on OMAP-L137 EVM is also used to control ethernet switch and EEPROM; if the ARM-Linux OS is trying to access the I2C bus at the same time as DSP. this may cause problems.

2) I am not too familar with OMAP-L137 environment, but another thing to keep in mind is how the memory map is partitioned between ARM and DSP; does this match GEL?

Hello mtmike,

I am having a similar issue to your description above, but my application seems to be getting hung up in  SIO_create when I attempt to initialize the audio system. Everything else went fine during my integration up to this point, including altering the memory map to accommodate the necessary device drivers and such. I have loaded the necessary device drivers to support the audio pass through example in conjunction with a dsplink application based on the message sample app. Everything works fine until I call audio_configure in main as the sample app does at which point it hangs in SIO_create as I mentioned.

Did you ever resolve this problem? In my case, the audioSample app works fine when loaded from CCS and started with the gel file doing its thing, but hangs in the same place if I bypass gel initialization. I included what I thought were the pertinent parts of the gel file into my userInit routine in DSP/Bios but that didn't fix the problem. Any insights here would be most valuable. Does anyone know if source code is avilable for the SIO module somewhere so I can try to figure out where it's getting stuck and why?

-Richard Bagdazian

Hello Mariana,

Thanks very much for this information. I did as you indicated and that has gotten me to be able to get the audio passthrough working inside of my dsplink based application. I'm optimistic I can get the rest working now.

thanks again!

Richard

Hello again Mariana,

Although my application is functioning as far as its interaction with dsplink and the audio passthrough. I have now found that I am getting different numerical results in my dsp processing algorithm which is in a separate task from the audio passthrough (It receives its input from the gpp side via message passing through dsplink). The dsp processing algorithm uses the DSPLIB for the fft and other vector operations it supports. My question is would there be any issues with using DSPLIB in a multitasking environment where interrupts are active and/or the streaming io associated with the audio transport mechanism is active? As I mentioned, the overall application is working correctly, but I'm getting different numerical results when the audio task is active. If I disable the audio task but leave all of the software intact the original results are obtained. I'm going to investigate further to try and determine the exact failure mechanism.

Thanks for your assistance.

Richard

Richard,

There should not be any inherent trouble with using DSPLIB functions in a multi-threaded application.  These functions are interrupt-tolerant, so any interrupt that occurs during processing is deferred until after that function completes.  If you want to be absolutely sure that interrupts are not interfering with your processing, try explicitly disabling and re-enabling your interrupts using the DSP/BIOS HWI API:

Uint32 old = HWI_disable();
// processing here...
HWI_restore(old);

Hope this helps.

Thanks Joe,

I'll be digging into this today.Thanks for the tip on interrupt handling, though I suspect it is probably something else I inadvertently overlooked on my side.

-Richard

Richard,

Have you disabled the ALSA driver in the Linux kernel? You should do that in order to prevent conflicts with the DSP audio driver...

Hello Mariana,

I'm not sure regarding the ALSA driver, but will look into it to make sure it's disabled in my build. I succeeded in getting everything going just now. It turns out I had insufficient memory set aside for my main heap in SDRAM and a number of memory allocations I was performing before starting my processing phase were failing. With that fixed, I am now simultaneously running the audio passthrough and my algorithm in two separate DSP/BIOS tasks.

Thanks for your help and support!

Richard

Hello Mariana,

I am in the process of debugging and optimizing my application algorithm and have noticed that frequently the audio stream does not seem to startup but in those cases all of my other DSP/BIOS tasks operate normally. I was wondering if the ALSA driver interference would explain this behavior? I haven't yet gotten to the point where I want to drop things in my algorithm development  to rebuild my linux image yet and was wondering if this behavior has been seen before.

Thank you,

-Richard Bagdazian

Richard,

You need to disable the ALSA driver for sure, but if you have sound sometimes you probably already have. I had some similar problems because of the SPI/I2C in Linux conflicting with the audio codec configuration in the beginning of the sound configuration in the DSP. When I had a conflict, by chance in the beginning, the audio would not work because the codec did not work in the beginning.

The pdf attached has the modifications I made in the kernel to make it work. I need more tests to publish this better, but give it a try.

Hi Mariana

I finally got a chance to rebuild my kernel and make the module adjustments you indicated to try in the pdf file you attached and the build process went fine with the indicated changes, but when I ran my application, it turns out that it would not get past the attempt to start the audio stream at all. So I was wondering if you have any additional input on this. I did discover that by inserting a fixed delay in audioSample_io.c of 1 second right after the call to edma3init() the call to createStreams() would succeed about 80% of the time which is much better than when there is no delay at all.

Thanks for your assistance on this.

Richard Bagdazian