This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[OMAP-L137 EMV] Debug DSP side application / get DSP side traces

Other Parts Discussed in Thread: OMAP-L137, OMAP3530

Hello

I have the OMAP-L137 Evaluation Module and I'm writing a small test application for communication between the ARM and the DSP core. I've been browsing wiki.davincidsp.com as well as the manuals provided by TI's SDK but I simply don't understand what I need to do to be able to debug the DSP or at least see the traces generated by the DSP/BIOS LOG_printf () and SYS_printf() calls.

In my *.tci file I have:

var trace = prog.module("LOG").create("trace");
trace.bufLen = 4096 ;

So I think doing LOG_printf (&trace, "..") should work, right? Or do I need to configure anything else?

I've read that TI suggests to use CCS and JTAG to access the DSP traces. I've installed CCS4 (trial version) and the XDS510 JTAG emulation drivers by spectrum digital. In CCS4 I've created a target configuration and when I start a debug session I see 3 nodes:

Spectrum Digital DSK-EVM PLUS onboard USB Emulator_0/C674X_0

Spectrum Digital DSK-EVM PLUS onboard USB Emulator_0/ARM9_0

Spectrum Digital DSK-EVM PLUS onboard USB Emulator_0/ETB11_0

However, I can't connect to either of them...

What I'm wondering is:  my DSP is configured for default boot mode, so the ARM applicaton does PROC_attach/load/start do download the *.out file to the DSP and start the DSP. Do I need to change something in this behaviour in order to connect to the DSP via JTAG emulator? Do I need to alter my code, use another boot mode, set some switches on the board? I have absolute no idea... :-(

Or is there even a method to access the DSP traces using the ARM core? i.e. access them via the shared memory and use the ARM application to print them to stdout?

Any help would be very welcome as it's kinda senseless to write code for the DSP if you have absolutely no clue if it's doing what intended...

Thanks, Dominique

 

 

  • Dominique,

    Have you seen this page?

  • I've seen a similar page for OMAP3xxx and searched for such a site (more OMAP-L137 related) but was unable to find it. This page looks very promising tho. I'll read / work through it and gonna post my results / questions!

    thanks already :-)

  • Ok, I've done the steps stated in the DSP debugging guide and it seems to work! Thanks!

    However, what I still don't know is how I can see the logging traces generated on the DSP by SYS_printf and LOG_printf calls.

    A similar guide would be very helpful ;-)

  • Dominique,

    The log module manages LOG objects, which capture events in real time while the target program executes. You can use system logs or define your own logs. You can view messages in these logs in real time with Code Composer Studio.

    Please refer to CCS tutorial at http://focus.ti.com/lit/ug/spru301c/spru301c.pdf which discuss LOG module and its usage in detail

    Deepali

  • Hello Everyone,

    I have been working on a dsplink application for OMAP3530.  I am unable to see any of the LOG_printf messages from the DSP either through the serial console or through Code Composer Studio. I have the LOG object correctly configured through tci file and tconf. My question is, for a dsplink based application, is it possible to send the LOG messages to the serial console instead. Is there any configuration on the ARM/DSP side that I need to change to make this work? Also, what could be a possible reason for LOG_printf to fail in Code Composer Studio? When I build the dsp-side application from CCS IDE, I can open the ROV from tools after connecting to the dsp. I see the trace object under log, but after running the application for some time and halting, the trace object does not update. Please note: this only happens with my dsplink application. I have other DSP "hello world" "fast fourier transform" and many other DSP-specific applications that display LOG_printf in CCS.

    One more issue: When I cross-compile the dsp-side of the dsplink application in my host computer under Linux (i.e not through CCS), I cannot even open the ROV tool from CCS. In this case, the dsp executable (.out) is loaded by the ARM. I connect to DSP processor after PROC_start and I can single step through the dsp disassembly code. But, I cannot open the ROV to view LOG messages. The ROV tool complains that the XDC path is not set.

    -I hope someone can help me understand what is going on. I can provide more information about my configuration.

    -Thank you in advance for sharing your experience