CCS/AMIC110: Switch between release and debug versions

Thomas Hecht

Part Number: AMIC110
Other Parts Discussed in Thread: OMAPL138

Tool/software: Code Composer Studio

Hi there,

I'd like to switch between the release and the debug version of the PDK_am335x_1_0_13 library. I created the two versions using gmake all BUILD_PROFILE = debug / release. The CCS continues to use the release version regardless of whether I set the build configuration to debug or release. How can I convince CCS to generate a debug version?

Best regards
Thomas

over 6 years ago

0 Rahul Prabhu over 6 years ago

TI__Guru** 116170 points

Thomas,

Can you please indicate how you are switching between debug and release modes of the driver libraries. If you are just doing this by switching profiles in CCS then this step only changes the profile for building the application code and will leverage the compiler, linker options specified for the application build profile.

To switch the driver libraries, you need to make the switch by making modification to the BIOS configuration script or linker settings depending on how you have included. Every component in the PDK like board library or the LLD contain a RTSC packing script called package.xs that contains the logic for the XDC tools to interpret the BIOS configuration and use the appropriate build profile for the component.

For example, for UART driver, check the libProfiles supported in package.xs located in folder pdk_am335x_1_0_xx\packages\ti\drv\uart

An example to include debug version of USB driver is provided here for your reference:

var Usb = xdc.loadPackage('ti.drv.usb');     

var usbSettings = xdc.useModule('ti.drv.usb.Settings');
usbSettings.socType = "am335x"; 
usbSettings.libProfile="debug";

To include debug profile version of RTOS module libraries refer:

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/FAQ.html#useful-resources (How to include debug version of RTOS and driver code)

Please review the information that I have shared here and let me know if you have any further comments.

Regards,

Rahul

PS: The compiler flags for debug and release profile for PDK components is done through the build file "pdk_am335x_1_0_xx\packages\ti\build\makerules\rules_a8.mk"

0 Thomas Hecht over 6 years ago in reply to Rahul Prabhu

Expert 1080 points

Hi Rahul,

Thanks for anwering,

To generate a debug and a release version, I used the command

'gmake all BUILD_PROFILE = debug / release'.

After doing so I find in the folder:

C:\ti\pdk_am335x_1_0_13\packages\ti\drv\uart\lib\a8

two subfolders one for debug and a second for release, each folder contains two files

ti.drv.uart.aa8fg and ti.drv.uart.profiling.aa8fg.

Now I thought it would be enough to switch between the release and debug by setting the build configuration within the CCS.

what do I miss?

best regards

Thomas

0 Rahul Prabhu over 6 years ago in reply to Thomas Hecht

TI__Guru** 116170 points

Thomas,

Yes, CCS project build profile switch from Debug and Release only switches the application level compiler and linker settings that user has created to easily switch between build profiles. However, the PDK components in your project are being included using a RTSC build that uses XDCtools to parse the .cfg file and link in the correct PDK components. CCS Build profile switch doesn`t change the .cfg script this change needs to be done manually adding Setting.buildProfile to "release" or "debug" as described in my previous post.

Conventionally, if the PDK libraries were being linked using Linker settings in the CCS project as per bare-metal development then the linker settings of the build profiles would be sufficient for switching between debug and release version of components. This would still require one time configuration of the linker settings in debug and release profile though.

With RTOS builds where libraries are linked using RTSC tools and .cfg script, the CCS switch doesn`t automatically force linking of the libraries in the same profile.

Regards,

Rahul

0 Thomas Hecht over 6 years ago in reply to Rahul Prabhu

Expert 1080 points

Hi Rahul,

??? do I have to moditie all the package.xs files?

where do I have to insert the lines you mentioned in your previous mail.

could you please supply some more information in detail.

best regards

Thomas

my package.xs looks like:

/*
* ======== package.xs ========
*
*/

/*
* ======== Package.getLibs ========
* This function is called when a program's configuration files are
* being generated and it returns the name of a library appropriate
* for the program's configuration.
*/

function getLibs(prog)
{
    var suffix = prog.build.target.suffix;
    var name = "";
    var socType = this.Settings.socType;
    var useDma = this.Settings.useDma;
    var profilingTag = "";
    useDma = useDma.toLowerCase();


    socType = socType.toLowerCase();
    /* Replace the last charecter in SoC am#### to am###x */
    if (socType.substring(0, 2) == "am")
    {
        socType = socType.substring(0, socType.length - 1);
        socType = socType.concat("x");
    }

    if (this.Settings.enableProfiling == true)
    {
        profilingTag = ".profiling"
    }
    name = this.$name + profilingTag + ".a" + suffix;

    /* Read LIBDIR variable */
    var lib = java.lang.System.getenv("LIBDIR");

    /* If NULL, default to "lib" folder */
    if (lib == null)
    {
        lib = "./lib";
    } else {
        print ("\tSystem environment LIBDIR variable defined : " + lib);
    }

    var socTypes = [
                     'am571x',
                     'am572x',
                     'am574x',
                     'dra72x',
                     'dra75x',
                     'dra78x',
                     'am335x',
                     'am437x',
                     'k2h',
                     'k2k',
                     'k2e',
                     'k2l',
                     'k2g',
                     'omapl137',
                     'omapl138',
                     'c6678',
                     'c6657',
                     'am65xx'
                   ];

    /* Get the SOC */
    for each (var soc in socTypes)
    {
        if (socType.equals(soc))
        {
            lib = lib + "/" + soc;
            name = this.$name + profilingTag + ".a" + suffix;
            break;
        }
    }

    /* Get the DMA choice */
    if (useDma.equals("true"))
    {
        name = this.$name + profilingTag + ".dma.a" + suffix;
    }

    /* Get target folder, if applicable */
    if ( java.lang.String(suffix).contains('66') )
        lib = lib + "/c66";
    else if (java.lang.String(suffix).contains('674') )
        lib = lib + "/c674";
    else if (java.lang.String(suffix).contains('a15') )
        lib = lib + "/a15";
    else if (java.lang.String(suffix).contains('m4') )
        lib = lib + "/m4";
    else if (java.lang.String(suffix).contains('a9') )
        lib = lib + "/a9";
    else if (java.lang.String(suffix).contains('e9') )
        lib = lib + "/arm9";
    else if (java.lang.String(suffix).contains('a8') )
        lib = lib + "/a8";
    else if (java.lang.String(suffix).contains('a53'))
        lib = lib + "/a53";
   else if (java.lang.String(suffix).contains('r5f'))
        lib = lib + "/r5f";
    else
        throw new Error("\tUnknown target for: " + this.packageBase + lib);

    var libProfiles = ["debug", "release"];
    /* get the configured library profile */
    for each(var profile in libProfiles)
    {
        if (this.Settings.libProfile.equals(profile))
        {
            lib = lib + "/" + profile;
            break;
        }
    }

    /* Get library name with path */
    lib = lib + "/" + name;
    if (java.io.File(this.packageBase + lib).exists()) {
       print ("\tLinking with library " + this.$name + ":" + lib);
       return lib;
    }

    /* Could not find any library, throw exception */
    throw new Error("\tLibrary not found: " + this.packageBase + lib);
}

/*
* ======== package.close ========
*/
function close()
{
    if (xdc.om.$name != 'cfg') {
        return;
    }
}

0 Rahul Prabhu over 6 years ago in reply to Thomas Hecht

TI__Guru** 116170 points

No, you do not need to modify package.xs file. The script already has the required code for library selection.

If you have noticed when your TI RTOS application builds, it shows the libraries linked when the XDC portion of the build is in progress. The XDCTOOLs process your .cfg file (BIOS configuration file). you need to add the test that I shared in the CFG for each of the driver modules so the XDCtools picks the debug version of the library rather than release.

Check the example of the USB module that I provided in the earlier post. That is the syntax used to specify the libProfile to be linked in the application.

Regards,

Rahul

0 Thomas Hecht over 6 years ago in reply to Rahul Prabhu

Expert 1080 points

Hello Rahul,

it looks like it would work at least with the libraries. E.g. an attempt is made to jump into the function "SPI_transfer (spi, & spiTransaction)".

Unfortunately I get the output: "Can not find a source file at" src / SPI_drv.c "
I thought the resource path was known by CCS (C: \ ti \ pdk_am335x_1_0_13 \ packages \ ti \ drv \ spi).

Do I have to re-announce all paths to the CCS Is there an elegant way to define these paths (in a kind of cfg-file)?

best regards

Thomas

0 Rahul Prabhu over 6 years ago in reply to Thomas Hecht

TI__Guru** 116170 points

Thomas,

You just need to point to one source file and the CCS Editor will then locate all paths relative to that file. For the SPI_drv.c, just browse to the folder

pdk_am335x_1_0_xx\packages\ti\drv\spi\src\SPI_drv.c

Once you do that it should be able to locate all the files in PDK. You may need to do that also if you want to debug inside the BIOS kernel. This is required because when the project is built in CCS it knows the location of the source of the application files but since the linked libraries are not built in CCS, it is not aware of the paths.

Hope this clarifies the CCS setup for debugging driver library code.

Regards,

Rahul

0 Thomas Hecht over 6 years ago in reply to Rahul Prabhu

Expert 1080 points

Hallo Rahul,

it works now as I want it. Two more little things:

1) in the the app.cfg file, there are the following lines:

var buildConfig = "release";

var buildConfig = "debug"; // added by me

/* Load the spi package */
var SPI              = xdc.loadPackage('ti.drv.spi');
SPI.Settings.socType = socType;
if (buildConfig == "debug") {                  // added by me
    SPI.Settings.libProfile="debug";       // added by me
}                                                                   // added by me

Question: can I use the the CCS information "Build Configuration" to switch between debug and release version (can the app.cfg file access this information in a way)?

2) as you metioned before

You just need to point to one source file and the CCS Editor will then locate all paths relative to that file. For the SPI_drv.c, just browse to the folder

pdk_am335x_1_0_xx\packages\ti\drv\spi\src\SPI_drv.c

CCS remembers this decision somewhere - where is this information (path) stored? Can I set this manually in advance in CCS?

I still have an additional request, I do not know the tool XDC, are there a few introductory documents / tuorials / videos? maybe you would be so nice to send me a few links.
Otherwise thank you for your help.

best regards

Thomas

0 Rahul Prabhu over 6 years ago in reply to Thomas Hecht

TI__Guru** 116170 points

Thomas,

Thanks for the update and glad to know you have the debug and release versions switching as expected.

Thomas Hecht said:

CCS remembers this decision somewhere - where is this information (path) stored? Can I set this manually in advance in CCS?

I may not the right expert to comment on this question so I will loop in some CCS expert to provide insights. I suspect by searching the source the first time you add the folder to the CCS index for search paths. Based on my understanding of the CCS Editor has source tracking enabled in Windows->Preferences->Code composer Studio->Advanced Tools-> Source Line reference. You can also add source search paths using the following that is described in CCS Help:

XDCtools tools has a long history with TI RTOS and is a fairly old build mechanism. The best collateral that I know that describes the inner workings of this tool are RTSCpedia portal. I have provided a link below:

http://rtsc.eclipse.org/docs-tip/XDCtools_User%27s_Guide

If you refer to the index on the left, the binders has the basic information and the XDC packages has the package specific information for the tool. Please revert back if there are some questions that you are not able to find good answers as the build automation tool is fairly complex and is a mix of JAva and C code to follow.

Regards,

Rahul

0 Thomas Hecht over 6 years ago in reply to Rahul Prabhu

Expert 1080 points

Hello Hahul,
Many thanks for your help. It was really fun with your support to solve the problem. Thanks again.

best regards

Thomas

Processors

Processors forum

CCS/AMIC110: Switch between release and debug versions