McASP Audio example on OMAP L138 doesn't run

Hi Shankari,

I am running the McASP Audio example code on DSP through JTAG debugger.
I do not want to do this additional step of connecting ARM and disconnecting it before running the DSP example code.
I can see from the example code that all initialization wrt to McASP and AIC 3106 are compelte, but still it doesnt run without the ARM connect/disconnect cycle.

Even when i flashed the McASP code example into the flash to run it directly, it could not run.
I need to understand what additional initialization step is missing from the code.

Thanks
Alwyn

Hi,

The below "Note" would explain that we cannot violate the additional step of connecting ARM and disconnecting it before running the DSP example code

Note: While launching CCS debugger, please ensure to connect the ARM core first to make DSP out of reset before running the code and disconnect the ARM core, Then try reconnecting to the DSP core, reload the application image and run the application. You will succeed in hearing the audio output through Line OUT, provided when there is some input stream (mp3, aac etc) feeded through Line IN. This is because, OMAPL138 is an ARM boot device where in which arm boots first with its bootloader code and then it wakes up the DSP core letting it out of reset, so that, we are allowed to connect to the DSP core and run the application on the same.

I would recommend you to ensure the above note is properly executed before running the McASP audio example project and you could succeed running the demo "as-is" with out any modifications in the code

I don't think, there shouldn't be any issues in running the McASP Audio example code on LCDK L138 and it is working from our end without any issues.

Thanks & regards,

Sivaraj K

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question

-------------------------------------------------------------------------------------------------------

Thanks Sivaraj for the reference.

However i am not convinced. Without connecting/ disconnecting the ARM core, i can run other programs without any problem. The Linux is already out of reset and running linux, so there is no question of Linux not being booted up and DSP not out of reset.

What about running the McASP example program from flash, i created an AIS image of the McASP example program with the custom bootloader. After flashing it the program got triggered, but there was no loopback - which is the same behavior as running from a debugger directly w/o ARM connect/disconnect step.

The McASP example program is missing some basic initialize step which i need to understand.
May be PSC register setting - dont know??

Regards
Alwyn

Dear Alwyn,

What about running the McASP example program from flash, i created an AIS image of the McASP example program with the custom bootloader. After flashing it the program got triggered, but there was no loopback - which is the same behavior as running from a debugger directly w/o ARM connect/disconnect step.

The McASP example program is missing some basic initialize step which i need to understand.
May be PSC register setting - dont know??

Are you able to run the McASP code through debugger & CCS ?
You are able to run the code via debugger but not with flash boot mode ?

Please isolate the flash mode & booting Linux, just try to run the DSP McASP code alone via debugger & CCS.

As i have already mentioned in my first query, i am able to run the code after ARM connect/disconnect.
But that is not what i want.
1. I want it to run w/o that additional step - which could be done because of the reasons stated above
2. Once i am able to run it w/o ARM reset via debugger, i should be able to run it with flashing the code and running from DSP

Thanks

Dear Alwyn,
I hope you might have set boot mode to SD card or NAND in your OMAPL138 LCDK board, that's why, you are able to run some of the examples without connecting the ARM.
As Sivaraj mentioned, you have to connect the ARM core first then DSP core since OMAPL138 is ARM boot master device and DSP will be in reset state unless you enable via ARM.

I am trying to run McASP Audio example on LCDK L138.

I see it doesnt run as it is. I have to connect ARM core and disconnect it after first power up.

Then reload the DSP program to make the audio example run.

However this additional step is puzzling since all other DSP example run without this additional step.

I do not want to do this additional step and i think there is something to do with linux running on ARM which hinders normal running on McASP example on DSP through CCS and JTAG emulator.

Can you please set boot mode to UART then do all the things which ever you done earlier ?
You can't see the same behavior now since you might have set boot mode to some other mode where the ARM is enabling the DSP including all the peripherals (through u-boot or linux kernel)

Even, you can't connect the DSP directly through emulator & CCS and  you would get "target is in reset state"

Yes, I agree that we can also connect the DSP directly without connecting ARM (In OMAPL138) but we need to be set into "Emulation boot mode" where ARM & DSP is waken up by RBL code.

PS: OMAPL138 LCDK board doesn't support emulation boot mode since its low cost device & internal emulator support is not available.

I hope this helps.

Thanks Titus.

I am using the NAND boot mode. Given that why doesn't the McASP code run without the ARM connect/disconnect step, since everything has been already intialized by the uboot and Linux.
Even DSP available to be programmed.

Any ideas?

Dear Alwyn,
I suspect that resource conflict between DSP & ARM for audio & EDMA support.
Linux kernel might have used the EDMA channels in linux.

You have to disable the audio & EDMA support and try.

Please refer to this wiki page.
processors.wiki.ti.com/.../OMAP-L137_Audio_Drivers_in_the_DSP_+_Linux

Can you please try as wiki advised and update to us ?

I hope this helps.

Why can't i just stop at uboot and then run the DSP program.
It should have the same effect as disabling the Linux drivers.