Is there a StarterWare for OMAP-L137 ?

Thank you for the reply Titusrathinaraj Stalin. I have run the example that Sivaraj Kuppuraj mentioned and it works.

Now I´m trying to convert some projects (from the package you suggested) from OMAP-L138 to OMAP-L137. However I cannot find the EMIFB file that you said that needs to be changed.

For instance, so far, I have adapted the following registers for the example "McASPEcho_dspL138" included in "quickStartOMAPL1x_rCSL-2.0-Setup.zip":

- In "syscfg.c" ->  Changed Registers PINMUX0,1 (for McASP0 module) and PINMUX4 (for I2C comms). The rest of registers, SUSPSRC/CFGCHIP1,4/PWRDN, seem to be common for OMAP-L138 and OMAP-L137.

Could you please detail a bit more what else needs to be adapted to migrate projects to OMAP-137? Would be really appreciated.

Thanks

Hi Sivaraj Kuppuraj,

 

First of all, thank you for the modified (for OMAPL137) loopback example. It has been really useful since it has helped us to better understand the EDMA3 data transfers and the McASP configuration parameters. (Thanks also to Titusrathinaraj Stalin for the project conversion suggestions).

We have been trying to adapt the given example in order to make it work with a bit sample resolution of 24bits. However, we were not able to make it run correctly, we hope you (or any other colleague) can shed some light on these:

 

1- Using your example and changing only WORD_SIZE to 24bits and the SLOT_SIZE to 32 bits, the reception buffers (rxBuf0,rxBuf1,rxBuf2) are not showing the empty channel that is not being used in the I2S protocol (currently there is only one channel input by LINE_IN). Note that the empty channel can be correctly seen in the CCS memory browser when both parameters (word/slot size) are set to 16 bits.

2- We suspected that the problem might be because the DMA transfer is really moving 32 bits (width of the FIFO) and we have tried 16 and 32 bits width FIFO sizes in the OPT.FWID field of pARAMs, with no result in spite of many trials.
We suspected that the issue might be related with the data format transfer between the McASP1 Data memory and the rxBuf0,1,2 that is performed by the EDMA3. (I.e. the format registers XFMT and RFMT).

What could be the problem? Any ideas?

 

Thanks!

Nicolas,

Could you provide mode details on the problems?

-For testing the pinmux I would advise to use the pin as GPIO first to make sure that you can first as GPO set a signal and then as GPI see as signal at the input.
Then when you are sure that you look at the right pin then you can use it as McASP pin.

-As far as I know Spectrum digital provide some low level test code for their EVM board:
support.spectrumdigital.com/.../
I think there is a McASP loopback example where a signal is input on the McASP and then ouput.
I don't think it uses EDMA so it could be a good way to test just the McASP portion.

-In term of trainings there used to be some SYSBIOS/DSPBIOS workshop based on the former OMAP-L138 EVM:
processors.wiki.ti.com/.../C6000_Embedded_Design_Workshop
The training material includes some well done slides to explain the OMAP-L13x architecture.
The Rev 1.20 student guide (C6000 Embedded Design Workshop Student Guide (Nov 8, 2013) (262 pages) (17 MB) ) does provide some information on McASP and EDMA architecture:
software-dl.ti.com/.../C6000_Embedded_Design_Workshop_Student_Guide_rev1.20.pdf
Especially lab 11 does use SYSBIOS EDMA McASP driver as an audio pasthrough example and explain the overall architecture.

Also the previous version of the workshop (Student Guide Rev 5.93 (.pdf)) contained some labs to input audio, manage a ping pong buffer scheme, via EDMA, make some DSP processing and output it back (from lab 2 with a simple C base loopback to lab 11 a stand alone fully featured FIR filter app) . Again it was for OMAP-L138 but the same principle applies to OMAP-L137.

A.

Hi Titus,
could you help? It does not seem to be an HW problem (see below the feedback).
Is there something specific with McASP0 that need to be taken into account (as McASP1 works fine)?

AnBer said:

-For testing the pinmux I would advise to use the pin as GPIO first to make sure that you can first as GPO set a signal and then as GPI see as signal at the input.
Then when you are sure that you look at the right pin then you can use it as McASP pin.

It has been done long ago and AXR0(4) runs normally when configured as GPIO as well as the other pins used later for clocks and sync (AHCLKX, AHCLKR, AFSX, AFSR, ACLKX and ACLKR). It is not a HW problem.

AnBer said:

I think there is a McASP loopback example where a signal is input on the McASP and then ouput.
I don't think it uses EDMA so it could be a good way to test just the McASP portion.

This is true, it was also tried and worked fine on McASP1 but failed when trying to output on McASP0. Note that since the EVM board does not allow to generate a signal coming in through McASP0, the test was done keeping the proven configuration for input on McASP1 but there was no signal on AXR0(4).

We feel that the detailed configuration that we indicated in our question contains all what is needed to configure McASP0 and what changes vis à vis McASP1. The fact that the code runs with McASP1 and that almost everything runs with McASP0 shows that there is no big mistake: the clocks are well generated, the EDMA transfer logic is running (the interruptions are coming as they should, as you are easily capable to analyse and is visible “EDMA3 reception and transmission interrupts are coming and the PINMUX and PDIR are correctly configured”). The only question is why is the AXR0(4) line flat (and it was checked at closest point to the DSP, not only on the EVM connector output).

 Moreover we never succeeded in activating the digital loopback, configured by means of the DLBCTL in the Multi-Channel Audio Serial Port (McASP) module. This would also be a good test for the DSP HW and curiously it doesn’t work. That is why we still ask for a running example.

A.