Using XDC to build my own rtos code in the EZSDK

What are you trying to build?  A utility library?  A codec for use by Codec Engine?  A full blown executable (that links in other components)?

XDC is a power tool that may/may not be applicable for you, depending on what you're trying to accomplish.

Chris

Lee,
a primary source of RTSC documentation is RTSC-Pedia.
This link: http://rtsc.eclipse.org/docs-tip/RTSC_Packaging_Primer/Lesson_5 contains a detailed description of package.bld, config.bld and the whole build process in RTSC.
Then, there is xdc command documentation http://rtsc.eclipse.org/docs-tip/Command_-_xdc. This command builds packages using the content of package.bld, config.bld and other files.

A short answer to your question is - config.bld defines the compilers you want to use to build a package or packages, package.bld defines which libraries you want to build in a package, and what code should they contain. Each package must have its own package.bld, but they usually share config.bld
The file package.xdc declares the name of a package, and the modules in it, but that file is of concern only for a package producer. If you are only building existing packages, you don't need to care about that file.

I'm continuing along the development of rtos-side, DSP, apps on the C6a8168 using Syslink and IPC.  I already have makefile based development in-place for the linux side, but Syslink remains a bit of a mystery.  Portions of it runs as a module in linux while another portion is configured in the DSP by a .cfg file.  I thought I had it figured out using Code Composer, but as that appears not to be an option, I need to understand the build environment created using xdc, as done in the EZSDK.  I haven't found much in the way of documentation that isn't Ecilpse, aks CCS, specific.  Basically, what I need to understand are the connections between the config.bld file, showing where the tool chain is, and the package.bld file, which actually describes what is to be built.  Take for example Syslink's rtos library which is referred to in the app.cfg file.  What happens by xdc.loadPackage ('ti.syslink.ipc.rtos') in the .cfg file?  More to the point, when I type: xdc all, what sequence of files does xdc look at to produce a .mak file?

Lee Holeva

Ok, I got the rtos-side code development working using xdc on the c6a8168 EVM.  I copied the sample package.xdc, package.bld, and config.bld files and via trial-and-error I figured-out how to get it to build my own code.  The on-line documentation wasn't of much help.

One question remains.  If I cannot build code in Code Composer, is there a way to still use the CCS emulator for debug?  Assuming that I build the app in EXSDK with the debug symbols, is it possible to get this into CCS to do symbolic debug, set break-points and so forth?  With the ARM loading the DSP code there is a coordination issue that I haven't figured-out.  This sounds to be extremely ackward so you guys at TI need to tell us how to develop Syslink/Ipc code in CCS.

Lee Holeva

Lee Holeva said:

The on-line documentation wasn't of much help.

Could you post a link to this documentation?  We are constantly trying to improve documentation and your feedback would be helpful.

Lee Holeva said:

One question remains.  If I cannot build code in Code Composer, is there a way to still use the CCS emulator for debug?  Assuming that I build the app in EXSDK with the debug symbols, is it possible to get this into CCS to do symbolic debug, set break-points and so forth? 

Yes, definitely.  You can use the following procedure to debug an ARM-loaded image using CCS:

1) If you need to control the point at which you start debugging code on the DSP, you should insert some code into your DSP image that spins until you have changed some state in memory via CCS.

   I.e. if you want to debug you application in main() before BIOS_start is called, declare a global volatile variable and loop on this variable until it reaches '0'

volatile int debug = 1;

  :

void main() {

while (debug);

        BIOS_start();

}

2) Connect to the C6A8168 DSP using CCS and Load symbols.  At this point, CCS will have symbolic debugging information contained within your .out file.

3) If you chose to create a spin loop per the instructions in 1), break the loop by changing the value of 'debug' in a CCS memory or watch window.

4) Debug your DSP application as you would have had you loaded the DSP directly onto the core via CCS.

Regards,

Shreyas

Shreyas Prasad said:

Could you post a link to this documentation?  We are constantly trying to improve documentation and your feedback would be helpful.

The only doc that I found showing the form of the package.bld file:

http://rtsc.eclipse.org/docs-tip/RTSC_Packaging_Primer/Lesson_5

now compare with what I actually use:

var Build = xdc.useModule('xdc.bld.BuildEnvironment');
var Pkg = xdc.useModule('xdc.bld.PackageContents');

for each (var targ in Build.targets) {
    Pkg.attrs.profile = "debug" ;
}

var testBld = xdc.loadCapsule("ti/sdo/ipc/build/test.bld");
/*
 *  Export everything necessary to build this package with (almost) no
 *  generated files.  This also exports subdirectories like 'golden'
 *  and 'docs'.
 */
var srcRelease = Pkg.addRelease(Pkg.name + ",src", {exportSrc: true, exportExe : true, exportCfg: true, exportAll: true});

/* 
 *  Export everything necessary to build this package with (almost) no
 *  generated files.  This also exports subdirectories like 'golden'
 *  and 'docs'.
 */
//Pkg.attrs.exportAll = true;

/*
 *  ======== testArray ========
 *  See ti/bios/build/test.bld. Only the test name is required.
 *
 *  Example:
 *    var testArray = [
 *        {name: Test1},
 *        {name: Test2, sources: ["Test"], config: "Test", refOutput: "Test", timeout: "15", buildTargets: ["C64", "C28_large"]}
 *    ];
 */
var testArray = [
    {name: 'DSPtasks_ti81xx',
        sources: ["DSPtasks", "Preprocessing"], config: "./DSPtasks_ti81xx",
        copts: ["-DSYSLINK_PLATFORM_TI81XX"],
        buildTargets: ["C674"],
        buildPlatforms: ["platforms.ti816x.dsp"],
    } ];

arguments[arguments.length++] = "platform=all";

/* clean generated files and folders */
Pkg.generatedFiles.$add("platforms.ti816x.dsp/");

/* Generate the makefile goals. 'arguments' is XDCARGS */
testBld.buildTests(testArray, arguments);


What is going on here?  I have no idea.  As I said, I determined that this will build my rtos app by trial and error, copying from the samples in the EZSDK.

Shreyas Prasad said:

Connect to the C6A8168 DSP using CCS and Load symbols.  At this point, CCS will have symbolic debugging information contained within your .out file.

I need to carefully read over your instructions, but one problem is that the .out file generated by CCS is at the present time, bogus.  With identical code, compilers, targets, and platforms, I should be able to generate identical ELF file outputs from both xdc in Linux, via the EZSDK, and CCS, but at present I cannot.

Lee Holeva