Hi Tom,
Fyi, below is some information on ways to debug a prebuilt DSP server
using CCS.
Debugging the DSP in CCS in a CE application
============================================
Procedures
==========
There are two common scenarios when debugging the DSP that require
slightly different approaches to setting up the debug environment:
Codec-level debugging: for example, a new or modified codec is being
used inside the CE framework
Arbitrary DSP code: code that is invoked directly from main() or via
DSP/BIOS static objects
In both cases, the assumption is that the user has a working system -
DSP/BIOS, Link, and Codec Engine are already working - so there is no
need to debug these fundamental components.
Codec Debugging
---------------
In this scenario, you do not need to modify the DSP code to enable
debugging. Build the DSP application (possibly with a debug profile) as
usual. On the ARM side, the application will load and start the DSP when
the Engine_open() method of CE is called. After Engine_open(), the DSP
is running and waiting for requests from the ARM. To debug your codec,
you should attach CCS to the DSP and set breakpoints.
You can ensure that the DSP side waits by putting a "prompt" after
Engine_open() in the ARM-side application code. For example:
Engine_open( .... );
printf("Hit enter to continue: ");
scanf("%s", tmpString);
Alternatively, you could use gdb to set a breakpoint in the ARM
application somewhere after Engine_open() but before any VISA calls.
Once the DSP is loaded and running, you follow the same basic steps in
either scenario:
Open up CCS,
Select Debug->connect,
Select File->load symbols->load symbols only, and choose your dsp server
executable as input file
Set your breakpoints. Open other source files in CCS as needed to
accomplish this.
Run the DSP (F5) to continue execution. Happy debugging!
Once the DSP debugging is running again, return to the ARM side to
either "Hit enter" or continue in gdb.
Arbitrary DSP Code Debugging
----------------------------
First you need to add a spin-loop in the DSP code, so that the DSP can
wait after being started by CE on the ARM side, while giving the user
the time to launch and set up CCS.
An example spin loop you can directly put into main(), located in main.c
of the DSP server code, is: -
volatile Int i=0;
volatile Int j=0;
while (i == 0) {
i = i * j;
}
This loop is complex enough so that the optimizer does not optimize out
the loop and the code immediately after. If you run the application,
Engine_open() will load and run the DSP, and the DSP will be blocked in
main().
One additional detail is that Engine_open() then waits for the DSP's
remote messaging server (RMS) task to respond before returning...
effectively blocking the ARM until the DSP runs this RMS task after
exiting main(). So you should have time to open and setup CCS before
continuing execution on both the ARM and DSP sides.
After adding the spin loop, recompile the DSP server after the change
and run it. Then
Open up CCS,
Select Debug->connect,
Select File->load symbols->load symbols only, and choose your dsp server
executable as input file
Open main.c by selecting File->Open.
Set your breakpoints. Open other source files in CCS as needed to
accomplish this.
Set the program counter to the line immediately after (i.e. outside) the
loop. Use the Debug->Set PC to cursor option from the menu for this.
run the DSP (F5) to continue execution. Happy debugging!
If you are suspecting a problem that occurred before main(), you can
also add the spin-loop code into the DSP/BIOS initialization that
happens before main() by adding a GBL user init function. To do so,
insert the following lines into your DSP server's BIOS configuration
file (typically has extension .tcf):
bios.GBL.CALLUSERINITFXN = true;
bios.GBL.USERINITFXN = prog.extern("myGblInitFxn");
Then in main.c, you can create a function named "myGblInitFxn" with the
spin-loop:
Void myGblInitFxn()
{
volatile Int i=0;
volatile Int j=0;
while (i == 0) {
i = i * j;
}
}
This function will be called early on during BIOS initialization, so you
will get a chance to step through some of that code. Again you can
recompile the DSP server code and follow the procedure outlined above to
launch CCS, load symbols, set breakpoints, run, etc.
Best regards,
Vincent
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of T Ziomek
Sent: Wednesday, November 01, 2006 9:23 AM
To: davinci-linux
Subject: Re: DSP Server debugging on CCS3.2
On Thu Oct 5 11:29:53 CDT 2006 james at eointecsolutions.com wrote:
>
> Can anyone tell me if it is possible to create a DSP sever pjt on
CCS3.2
> with the Framework components, xDM algos, etc . Load it from CCS and
> debug it while the arm app is running. If not is possible to generate
> the DSP server on the linux environment and debug it from CCS.
I haven't seen any response to this on the list; can it be done? If not
then developing DSP-side code is going to be problematic at best...
Thanks, Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
