DSP Wait-in-Reset OMAP-L137

Hi kemeron,

I never tried this for OMAP-L137, but I think you would need to do something similar to what is in this page:

http://wiki.davincidsp.com/index.php?title=Debugging_the_DSP_side_of_a_DSPLink_application_on_OMAP_using_CCS

This was made with the Blackhawk BH-USB-560m emulator and OMAP3 EVM, you can probably do it for OMAP-L137 with the embedded emulator on the board.

Another page that could help you is:

http://wiki.davincidsp.com/index.php?title=Debugging_the_DSP_side_of_a_CE_application_on_DaVinci_using_CCS

Just to complement my answer, you will need DSPlink to do the procedure I mentioned, and this was not part of the EA2, current software release of OMAP-L137. So I think it would be better for you to wait for the next release - should probably be ready in one or two weeks.

Many thanks for your reply.  I tried poking a few things even in the absence of DSPLink, without much success.  I was able to examine the HOST1CFG register from Linux / arm and the content indicated that the DSP is not being held in reset by this register.

Hi,

I am also new with this DSP OMAP L137. The point is that I have setup up the CCStudio and during the first trials I had no problems to connect to the DSP-side. But now (I don't know what I have done....), when I try to connect to the DSP it says "The target is stuck in Wait-in-Reset mode". Don't know what to do, please can you mention to me which steps did you follow when you faced the same problem.

Regards.

Hi Leopoldo,

Check the board switches. You are probably not in emulation mode. Please see page 14 of the document:

http://support.spectrumdigital.com/boards/evmomapl137/revd/files/EVMOMAPL137_TechRef_RevD.pdf

I would bet that you have Linux or at least u-boot running, and that means the arm is holding the DSP in reset mode. In that case you can not connect to the DSP...

Hi Mariana,

Certainly, you win the bet. I just simply know what the Emulation Debug Mode was useful for... So just let me recap what I should do if I want to work properly with OMAP L137. My application will include code development on both processors DSP and ARM, so that if I want to program only the DSP and do some test, then I should use the Emulation Debug Mode, while if I want to program both ARM and DSP then I should use DSP/BIOS Link so that the ARM can load a binary to the DSP and wake it up.

Regards,

Leopoldo.

Mariana,

On the OMAP-L137 the DSP boots first, holding the ARM in reset, opposite of what I believe DaVinci does.  DSP ubl loads ARM ubl and lets it run.  First thing ARM ubl does is put the DSP into reset.  One problem is if switches are set to Emulation Mode neither ubl will run as the source code checks the switch configuration first for boot mode and if not defined (Emulation Mode is not checked), exits.  Thus question becomes how do you debug a DSP application while Linux is running.  I'm looking into hacking the UBL code now to ignore the switches and not put the DSP into reset but not sure if will have problem elsewhere, if you know anything would be useful given programming DSP code that interacts with Linux will be difficult to debug without using CCS & JTAG.  I have a large Linux program and a large DSP program where Linux is doing all the communications.  Could debug as standalone entities but comes a time when you have to make them talk and short of dumping diagnostic messges out a serial port on the DSP I don't see much you can do from a debug perspective?  Any thoughts on best way to proceed in this regard?

Thanks,

Kev

Hi all,

In OMAP-L137, the DSP boots the arm, but once the ARM is booted, it takes control of the DSP and resets it as you said. So you can not connect to the DSP at this point. So to debug a DSP application when Linux is running you would need DSPLink or Codec engine to take the DSP out of reset. There is a wiki page about this for OMAP3. I have not tried for OMAP-L137, but the process should be similar:

http://tiexpressdsp.com/index.php/Debugging_the_DSP_side_of_a_DSPLink_application_on_OMAP_using_CCS

From a debugging perspective that link is rather messy.  Also ignores people who may not want to use DSPLink.  If any code changes looks like you need to load the binary with DSPLink each time and symbols with CCS.  Not sure about restarting, etc.

I'm experimenting but what I have found out is if you modify the arm-ubl as a stand alone project and do the following I have full control of DSP and can debug Linux with gdb:

1.  In the ARM ubl.c comment out DSP disable:  //  DEVICE_disable_DSP(); 

2.  Use the drivers from the spi_flash_writer project (winbond, spi_flash), there is some initialization done I think by the boot rom that now needs to be done in the program, not sure but this works when not booting from DSP.

3.  Remove the malloc calls and use static memory references since only using the functions once anyways. 

4.  Set compiler for (Advanced tab) Generate Long Calls.  Add rts32e.lib to linker library to include just to resolve some symbols if cleaned up code could get rid of it.

4. Set project build for auto initialization.  Set tab in project for BOOT_SPI and not default BOOT_NAND.

With this you have a standalone ARM project that loads uboot and then Linux from CCS debugger.  Can even break execution within Linux with CCS and continue although not recommended. 

Here is the project for anyone interested (assuming I'm attaching this correctly):  2577.armubl.zip

Once Linux is running you can load any standard CCS DSP program with DSP/BIOS and load/run as normal as long as  you don't step on Linux memory.  For now I'm linking at 0xC3000000 with no problem and I am not using DSPLink although do have it built into my Linux distribution (full preemption).  Later I may use DSPLink but for now I'll write a simple driver to communicate through the local dualport memory.

Ran large program with DSP/BIOS tasks (Timer 1) in parallel with Linux with no problem.  Can modify code, build and run again all the time Linux is running as normal.

My bet is a slight modification to DSPLink so it does not load the DSP program (build option) nor reset it and life can get a lot simpler for the DSP programmer.  Will look into that later.

Kev

I adapted the procedure to OMAP-L137:

http://tiexpressdsp.com/index.php/Debugging_the_DSP_side_of_a_DSPLink_application_on_OMAP-L137_using_CCS