[OMAP-L137] About changing DSPLink memory map

Diego,

Please see if the below links help:

http://wiki.davincidsp.com/index.php/Troubleshooting_DSPLink_configuration_issues#Problem:_PROC_load_failed_with_DSP_ESIZE_error
http://wiki.davincidsp.com/index.php/Troubleshooting_DSPLink_configuration_issues#Problem:_PROC_start_failed_with_DSP_ERANGE_error

Deepali

Hello Diego,

I am doing something similar in which I wanted to use the streaming audio application and integrate it with an application which I derived from the dsplink message sample app. I was able to successfully modify the memory map from the default and rebuild the message based app and it worked fine. As soon as I integrated the drivers for the audio interface program I got the same error message you got when I attempted to start the program. Did you get the problem resolved? I need to solve the same problem.

Thank you,

Richard Bagdazian

All,

If you share your ARM and DSP side memory map related files, I can verify them for you.

Deepali

Hi Richard and Deepali,

I'm sorry, I wasn't able to solve the problem and I have in hand another project at the moment, but I'm really interested in understanding dsplink functioning.

I'll share soon my project memory files, I hope this can help us.

Thank you, best regards.

Diego

At the moment I am backtracking to get my basic app working again with the default memory map.

Just to summarize, I made what I believed were the appropriate changes to the GPP memory configuration side for DSPLINK. Coincidentally they were exactly the same as Diego indicated in his previous post. I ensured that I also adjusted the boot vector in every place I could find on both GPP and DSP sides. I also followed the documentation that indicated how to adjust memory on the DSP side and make the necessary changes to my project *.tcf file. The documentation that I found about the error indicates that the error code I received from attempting Proc_load with my adjusted DSP module means that the BIOS.args size was insufficient which it was not and which I hadn't changed from the working app. So something else is off the rails.

Once I get back to a point where I can move forward again I will post my memory config files for review.

Are there any examples of using the Audio codec on the OMAP-L137 EVM board in conjunction with DSPLINK to capture streaming data without having to resort to the codec engine which is vastly overkill for my application? From reading the documentation on the codec engine I am not convinced that I could even get it working in a reasonable amount of time if I have to deviate from the canned applications.

-Richard

HI Deepali and Diego,

I spent the day carefully integrating the audioSample app into my message based DSPLINK configuration and succeeded in getting a build that ran my initial unit tests successfully up to, but not including the audio channel initialization and startup. I have all of the support drivers installed and the memory map adjusted successfully for the audio application and the DSP code is loading in successfully from the GPP side as desired and starting normally. The memory maps indicate that the new configuration is working as desired and I now have the working room needed to bring in the audio support drivers and such.

I discovered that I had inadvertently dropped the message.tci include file out of my tcf configuration file and that I believe was responsible for my ESIZE error. One thing which I don't understand is it looks like the GPP side only indicates that it needs an arg size of 4, but the DSP message.tci file sets it to 50. Not clear why this is necessary.

Anyway, I still have a problem which I hope someone can help me with.

I found that when I attempted to enable the audio task at DSP startup, the system hangs inside of SIO_create inside of the audioSample_io.c module and never returns. Since I had control of the DSP at that point, I closed out my project inside of CCS and opened the audioSample project from the edma3 distribution and built it and loaded it. I discovered that it also hung inside of the same routine SIO_create. It dawned on me that there was originally a GEL file that is loaded every time I start code composer which I normally delete before connecting to the DSP, so I exited out and restarted code composer and reloaded the sample audio program leaving the gel file active. When I connected to the remote DSP via the emulator, the gel file did it's intialization thing. I then attempted to run the sample audio program from the start and this time the SIO_create function returned correctly and the audio application ran fine.

So what do I need to include in my project that the Gel file is doing to get the SIo_create function to behave properly, I suspect there is some kind of hardware setup being done by the gel file that isn't being done in my normal startup sequence and which I have to do to get the system to behave. Can someone give me an idea of what might be the cause? It's apparently something that the drivers themselves don't do in their initialization sequence.

Thank you,

Richard

Richard,

I do not know about the need for the gel file  I will not be able to guide you on what updates your initialization sequence need. I will let others on the community help you with this one.

Regarding the DSPLink question,

>>One thing which I don't understand is it looks like the GPP side only indicates that it needs an arg size of 4, but the DSP message.tci file sets it to 50. Not clear why this is >>necessary.

[Deepali]: DSP message.tci file sets it to to 50. This maybe be a bit more than required but definitely a size of 4 is too small.

The .args buffer for Dsp/Bios 5.xx has the form:
      argc,
 +-- argv,
 |    envp
 +-->argv[0], -------+
       argv[1],        |
       ...,              |
       argv[n],        |
       argv 0 string,<-+
       argv 1 string

So you can decide the exact size of .args based on the passed arguments.

Deepali