Code Composer COM interface for CCS 4.0?

Thanks for your response.  We found the symbol lookup information in the API documentation you suggested, but we couldn't find where to get the symbol type information.  Currently the way we use the symbolPackage information that we extract from CCS 3.1 is to learn the address and type of any generic symbol in our code and read the memory over an ethernet interface and then are able to determine the value of any member of the object.  For example, if we have a global object in our code, myObj that has members x1 and x2, we can from the symbolpackage information, know the address and size (from the type).  We then issue an Ethernet command, asking the DSP to output N bytes of data from addess X.  In our .Net development project, we can then extract the values of x1 and x2 from the bytes.  We use this to have remote visibility into DSP variables in a powerful generic way, over an Ethernet connection, using a low priority task in the DSP.   Losing this capability would be a major roadblock in our advancement to CCS 4.0.  It there any way to extract equivalent information from a *.out file using CCS 4.0?

Tara,

I'm a member of the Debugger team for CCS.  I had a few more questions about your environment.

In your environment do you know the names and types of your global variables before the symbol package has the symbol file added, or are they discovered via iterating the CCSymbolPackage's GetGlobalInfo or other such member?  If the variable names and types are known ahead of time there may be some expressions that can be evaluated through DSS' Expression class.

Secondly, I was wondering if you have investigated JavaScript from .NET.  It's my (limited) understanding is that it is not a very straightforward thing to do.

Best regards,

Chris

Chris,

Let me explain a bit more about what we are doing.   We have a .Net application that we have created, called symbol package creator, which uses the CCS COM interface to load symbols from a *.out in CCS.  We then use getNumGlobals to get the number of global symbols.  We iterate through the number of global symbols, and use get getGlobalInfo to extract the address and symbolType information (recursively as needed for compoundtypes).  As we are doing this we are creating a parallel symbol package using our own .net class definitions, so that when we are done, we have a stand alone .net object, that contains all of the symbol information for the code running on the DSP.  Then using a small piece of C-code running on the DSP, along with the Ethernet interface we are able to remotely read/write any variable in our code using just an address, and type field.   Essentially, we have the ability to create our own stand alone Watch Window type interface using only our created .Net Symbol Package Obj.

We are really hoping to be able to create a similair .Net Object through some interface to CCS 4.0.

Tara

Oh, and in response to your second question, I have not investigated JavaScript from .net.

Sorry to barge into your thread , but we have a very similar situation.  We do a similar thing over a serial port and we currently extract all the symbol information from the COFF/STABS outfile created in CCS3.1/CCS3.3.  CCS4 does not support STABS, only DWARF.  We want to avoid having to figure out how to parse the symbol table info from DWARF and use some existing utility.  We've just started looking into the ofd6x.exe utility which creates the xml file, but the symbol table info provided is too basic. For example, a dsp program with a floating point array float floatArray[64], just shows up in the xml file as a symbol 'floatArray' whose address is 0xWHATEVER.  It does not tell us that its type is float and it has 64 elements.  I'll be interested to see what solution is found on this topic.  If we come across anything, I'll post as well.

Tara,

Thanks for the response and explanation.

CCS 4.x's DSS does not currently support the functionality that you desire.  First, DSS does not support the concept of using an offline symbol package, so any symbol package that you attempt to load will attempt to be loaded on the target.  That won't be feasible (or desirable) in your environment.

Secondly, as you've already figured out, there's no easy way to iterate the globals and their respective type structure via DSS.  We can look into adding support for this feature in future revisions of DSS.

Tara and Shawn,

I think the only feasible thing to do if you need to get going in the short term is rely on the output from ofd and to possibly extend the cg_xml scripts that John previously mentioned. 

Starting with ofd, it's important that you specify the -g option when running it.  This will tell ofd to dump the DWARF debug information from your object file in the output.  This debug information contains very rich debug information about your application and is what's processed and interpreted by the debugger to enable debug support for your application.

From the cg_xml side of things, I'd start by taking a look at the global_types_gen.pl script.  Given the XML output of an ofd run it will generate the type information for all the global types in a symbol file.  This isn't a list of all global symbols, but it does provide the types they may have.

Extracting the global symbols will require additional work and an understanding of the debug information structure.  The DWARF debug information will include the address of the symbol.  With the symbol in hand you should be able to either match the type that was output from global_types_gen.pl or walk the DWARF information to extract the type information using your own script/program. 

Needless to say, it's bound to be a fair amount of work.  However, it's about all I can suggest if you need to get going in the short term.

Best regards,

Chris

Thanks Chris,

For the short term, we'll just stick with CCS 3.3.  But what about the long term?  Are there any plans to add back this ability in CCS 4.0?  We would sure use it!

Tara

Tara,

We'll continue to extend the functionality of the DSS APIs in future releases of CCS.  Based on the feedback here, we're planing on extending the Symbol related APIs to include more CCS 3.x symbol and type functionality.  However, at the current time there is no hard schedule for this so I can't provide a specific date for when the new functionality will be available.

Chris

Hi

We've got the same issue but with a different tool. With CCSv3 and Matlab pre 2009, we'd to run our CCS tests and extensively use Matlab's createobj() to get a  variable's address and type. That was working fine until we upgraded from 2008 to Matlab 2009b. Now Matlab has decided not to support createobj(). Arg!

Now after readying Chris's suggestion, I'm overwhelmed on what we have to do to get a similar feature working in CCSv4. TI has got to give us a javascript command that will give us the symbol address and type once the .out is loaded.

It would be great to have a javascript command like "loadVariable variable_name value".

Cheers

Unlike my colleagues above, I have the luxury of being able to load the .out so I should be able to access the symbol information.

From this example C:\Program Files\Texas Instruments\ccsv4\scripting\examples\DebugServerExamples\Quicksort.js,

it looks like I can get access symbols using session.expression. Would it be possible to do this through the scripting console? 

Would something like this would work?

debugSession = ds.openSession(".*");

debugSession.memory.loadProgram("myApp.out");

**** then somehow my javascript function does this*****
long addr = debugSession.symbols.getAddress(my_global);
 
debugSession.memory.fill(addr, 0, the_length, the_value_I_want);

(following the API at C:\Program Files\Texas Instruments\ccsv4\scripting\docs\DS_API\index.html)

I'm not sure how this could become a function that can be loaded via loadJSFile. How would a function access the debug session if its run from the script?

(as you can tell, I'm a MAJOR novice at java scripting)

Cheers

*******************************Quicksort.js****************************************************

/** This is not a test; it is a helper function.  It runs to the end of main and verifies that values were sorted.
@pre N/A
@post Asserts that each value in the array is less than the next value in the array
*/
function verify_execution()
{
    // Run to the end of main (i.e. line 58)
       
    session.breakpoint.add("main.c", 58);
    session.target.run();
   
    // Verify that the elements in the array were sorted
   
    for(var i=0; i<10; ++i)
    {
        // Note: arr is the name of the array in the source file (main.c)
        var value1=session.expression.evaluate("arr[" + i + "]");
        var value2=session.expression.evaluate("arr[" + (i + 1) + "]");
       
        // Assert that the pair of values is in ascending order
        assert(value1<=value2);
    }
}

Eddie,

Yes it is possible to run a DSS script from within the Scripting Console.  You can run them as-is or you can tweak them a bit so that it will detect that it is running within the console and reuse existing variables.  More info here: http://processors.wiki.ti.com/index.php/Scripting_Console#Running_DSS_JavaScript_Files

Regards,

John