From RTSC-Pedia

Jump to: navigation, search
revision tip
—— LANDSCAPE orientation
[printable version]  [offline version]offline version generated on 04-Aug-2010 21:08 UTC

Trouble Shooting

Frequently encountered problems and their solutions

Contents

Building Packages

xdc loops indefinitely rebuilding the same file

The xdc command is a relatively simple utility that just invokes GNU make with controlled set of command line options and environment. Since GNU make exclusively uses file timestamps to determine if a file needs to be rebuilt, you can run into this problem if you have files with bad time-stamps. Suppose you have a file, say foo.h, whose timestamp is set to a future date (or your workstations time setting is in the past) any file that depends on foo.h will be rebuilt by GNU make until your workstation's time exceeds thefoo.h file's date stamp.
This problem is often seen when exchanging files between developers located in different time zones.

xdc (or xs) fails with an "xdc.services.global.XDCException: ..." error

These types of errors are described in XDCtools Error Codes.

xdc fails with an "Error: Can't find import file: '...' (not found along '...')" error

This error indicates that a required file could not be found in any of the directories listed between the ()'s. In almost all cases, these directories are just the directories that are defined by your package path.
You should review your package path to ensure that the file being searched for does in fact exist in one of the repositories listed on the package path. If the file being looked for is delivered in a package, the directories that appear in file name will match the packages name; e.g., if the file name is "ti/bios/bios.tci", then you should check that the ti.bios package is in one of the repositories listed on your package path. You can review the packages available on your package path via the xdc.tools.path.sg.

On Windows, xdc fails with error: compilation failed: can't find specification file: mypkg.mymod.xdc

This error indicates that a required specification file (i.e., .xdc file) could not be found along the package path. Even on Windows systems, which are have case-insensitive file systems, it is important that the names of your package directories exactly match the names of your packages. For example, a package name declared to be myPkg in your package.xdc must be in a directory named myPkg and can not be in a directory named mypkg, MYPKG, or any other name that differs only in letter case.

The RTSC IDL translator fails with "can't resolve name (...)"

The error indicates that (for some reason) the IDL parser can't figure out whether the name between the ()'s is a package, a module, a configuration parameter of a module, ... In other words, it can't resolve what this identifier is.
Usually this indicates that your package path is not correct; the name between ()'s can't be found along the package path.

tar fails with "file changed as we read it"

Before tar copies a file into an archive it reads the file's time-stamps. After tar copies each file into the archive, it re-reads the file's time-stamps and checks them against the previously read values. If the time-stamps differ, tar (rightly) believes the file was changed and that the contents of the archive are inaccurate; so, it exits with the failure message above.
This failure is also caused by poor network file system configurations that report inaccurate file time-stamps. For example, UNIX-based network file systems that are accessed via a Windows port of tar often exhibit problems. Windows file time-stamps differ from UNIX file time-stamps so network file systems must carefully translate these times.
So how do you fix the problem? The only reliable solution is to fix your network file system to report reliable file time-stamps; otherwise, the time-stamps recorded in the package archive will be inaccurate and, in some cases, result in failures when the packages are used. For example, GNU make may mistakenly believe that the package must be rebuilt.
If you can't fix your build environment's filesystem infrastructure, the only solution is to switch to zip as the package archiver. Each package release can specify which "archiver" to use to create the single file containing all of the package's files; currently, there are only two options: "tar" or "zip". Since zip version 2.3 does not perform the same time-stamp checks that tar does, it's possible to reliably create a zip package release archive.
You can specify which archiver to use on a per-release basis and set the default release archiver for all releases within a package. To set the archive format of a release to be zip, simply set the Release.attrs.archiver attribute to the string "zip":

package.bld
 
Pkg.addRelease(..., {archiver: "zip"});
To set the default to be zip for all releases in a package, set the PackageContents.attrs.archiver attribute to the string "zip":

package.bld
 
Pkg.attrs.archiver = "zip";
Rather than change each package's package.bld script, you can set the default to be zip for all releases of all packages by placing this setting in a config.bld file shared by your packages:

config.bld
 
Pkg.attrs.archiver = "zip";

tar fails with "gid_t value ... too large (max=16777215)"

tar attempts to save and restore all file permissions and ownership IDs and assumes a *nix file permission model which includes a notion of a "group ID". The C type named "gid_t" is used to store group IDs and may vary in size from one host to another. As a result, its maximum value may also vary. In addition, some hosts use distinguished values, such as -1 or -2, to represent special users or groups.
This error can result by using tar files that were produced on a different host operating system (OS) or by modifying a file on one OS and archiving the file on a different host via a network file system. Since Windows does not use the same permission ownership model as *nix, any Windows implementation of tar will have to heuristically map Windows permissions to *nix permissions and these heuristics may result in this error.
If you work in a mixed Windows *nix development environment, it's best to use of zip rather than tar to create package releases. For an example of how to do this, see the previous note.

Configuring Content

Configuration fails with an "Error: Module Xyz does not support static instances" error

For a module to support static instance creation it must:
  1. supply a *.xs" file that implements instance$static$init to initialize the object
  2. define the instance object state in the module's "*.xdc" file in the internal: section
If you continue to get this message you may need to clean and rebuild your package; adding a *.xs after you've already gotten the error above is not enough to trigger a rebuild.

Configuration complains about "incompatible use of package 'x.y.z': imported x.y.z [i,j,k], a.b.c was built with x.y.z [...]"

The package a.b.c was originally produced using a version of x.y.z that is incompatible with the version you are using, [i,j,k]. See Compatibility Keys for more information about how incompatibilities are detected and controlled.
To make this concrete, suppose x.y.z and a.b.c are ti.bios.utils and ti.rtdx, respectively. Your configuration requires both ti.bios.utils and ti.rtdx but your version of ti.rtdx is [i,j,k] and ti.bios.utils was built with an earlier incompatible release of ti.rtdx. So, either your supplier of ti.bios.utils (which could be Codec Engine or DSP/BIOS) needs to update their product to use a more recent version of ti.rtdx, or you need to use an earlier release of the product that supplied ti.rtdx (DSP/BIOS?)
Since a package can be delivered in more than one product bundle, you must locate the repositories containing ti.rtdx and ti.bios.utils and decide which products you'd like to change. Locating the repository is quite easy: 
    xs xdc.tools.path.sg
For the advanced user: you can also use xdc.tools.repoman to build your own repository containing consistent versions of ti.bios.utils and ti.rtdx and place this at the front of your package path.

Configuration fails with an "incompatible use of the target ..." error

When the config step runs, it makes sure the version of the compiler used is "compatible" with the version used to build any prerequisites. This error indicates that you are using a compiler of some version and you are linking libraries built with a version which config believes is incompatible. See Compatibility Keys for more information about what checks are performed.
If the version reported in the error message is "[]", this indicates that when the package.bld script was run, it was not able to determine the version of the compiler. Often this is simply because the target's .rootdir parameter, set in config.bld, was incorrect and the version check failed because the toolchain couldn't be found. The configuration tool assumes that unknown versions are incompatible with any known version of the compiler.
The "right way" to fix this is to ensure that the package.bld script can run without any warnings. However, if you know there is not a problem and you just need to get past this error, it is possible to tell the configuration tool to not check compiler versions (and proceed). For example, to treat compatibility check failures as warnings, you can set the xdc.cfg.check.fatal "environment variable" to false.
If you use the configuro tool this can be done on the command line. 
    xs xdc.tools.configuro -Dxdc.cfg.check.fatal=false ...
If you use the XDCscript build scripts directly (package.bld), you can set xdc.cfg.check.fatal by defining the xsopts attribute when adding an executable to your package.

 
 
 
Pkg.addExecutable("app",targ,targ.platform,{
    xsopts: "-Dxdc.cfg.check.fatal=false"
});

The xsopts attribute replaces the deprecated tcopts attribute of earlier XDCtools releases.

For more information see the xdc.cfg package-level documentation.

Configuration fails with an "xdc.services.global.XDCException: ..." error

These types of errors are described in XDCtools Error Codes.

Compiling and linking

The C compiler fails with "error: package/internal/ModXyz.xdc.h: No such file or directory"

Make sure you've added module ModXyz to the package.xdc file and recompiled the IDL files. Internal headers for modules are only generated if the module has a *.xdc file and it's named in the package.xdc file.

The C compiler fails with a "conflicting types" error; e.g., "error: conflicting types for '..._Instance_init__F'"

The type signature of your module's implementation methods do not match the signature defined in the module's generated headers. Make sure that if you specified the @InstanceInitError attribute that your module's Instance_init() function has the proper signature.

The linker fails with "undefined reference to package_name_Mod_Object__create(void)" or "undefined symbol package_name_Mod_function__E"

You must add xdc.useModule("package.name.Mod") statements to your application's configuration script for each module directly referenced by your application.
The undefined reference is to a function that is only generated by the configuration tool if the the specified module is "used". Unfortunately it is not possible to know what you've referenced in the C code, so you should always add an xdc.useModule() statement for each #include of a module header in your C sources.

The TI C6000 linker fails with "Invalid intermediate file:..." and "Compilation failure"

If you are building with "whole program" optimization (i.e., using the "whole_program" profile), this error indicates that some object files being linked into your application were built with an incompatible version of the C6000 compiler. Version 6.1 of the C6000 compiler is incompatible with all previous releases, for example.
You may be able to work around this issue by rebuilding the C6000 xdc.runtime support package ti.targets.rts6000. See Working with xdc.runtime for more information about how to rebuild this package.

The linker fails because there isn't enough space for .text or .bss, or ...

Your platform does not have sufficient space to hold your program's code (or data). Either you have completely filled physical memory and you need to look for a way to reduce your program's code or data requirements, or you simply need to "remap" the sections of your program to different physical memory regions.
You can perform simple remapping operation using xdc.cfg.Program.sectMap from within you program's configuration script. If on the other hand, adding section placement in your program's configuration file ties it to a particular platform. To avoid this you can instead create a new platform which partitions the memory as necessary and then change your build to use this new platform. See Using Targets and Platforms for information about creating new platform instances.

Runtime Issues

At runtime, the application fails with the error message "ModuleXyz: generic error: create policy error"

Your application tried to create an instance of ModuleXyz at runtime but this module's memory policy was set to STATIC_POLICY; i.e., only configuration time instance can be created.

At runtime, Log events for xdc.runtime modules are not being generated

The modules in the xdc.runtime package are not affected by settings made to xdc.runtime.Defaults.common$.logger or the diagnostics flags xdc.runtime.Defaults.common$.diags_*. In order to enable logging of an xdc.runtime module, you must explicitly set its logger and diagnostics flags. This special treatment is intended to keep the logging overhead of the xdc.runtime to an absolute minimum and prevent unintended logging of the xdc.runtime loggers, for example.
 
 
 
 
 
 
 
var HeapMin = xdc.useModule("xdc.runtime.HeapMin");
var Diags = xdc.useModule("xdc.runtime.Diags");
var Defaults = xdc.useModule("xdc.runtime.Defaults");
Defaults.common$.logger = ...;
/* must explicitly set HeapMin settings to get Log events */
HeapMin.common$.logger = Defaults.common$.logger;
HeapMin.common$.diags_Entry = Diags_RUNTIME_ON;

At runtime, some module's startup functions are not being called

Make sure the module's specification (its .xdc file) has the @ModuleStartup attribute. Without this attribute the module's startup function will not be called.
 
 
 
 
@ModuleStartup /* required to ensure MyMod_Module_startup() is called during startup */
module MyMod {
    ...
}

XDCscript Errors

An XDCscript fails with "TypeError: Cannot read property "..." from undefined."

This error indicates that the statement on the specified line tried to access the property named "..." from a variable that is undefined. This can be because your script has not initialized the variable, your script explicitly set the variable to undefined, or you've tried to access a global variable that has not been defined.
Make sure any global variables you reference are in fact defined. For example, attempts to reference the configuration script object Program from within a build script will result in this kind of error. Scripts can determine which "model" they are running within by checking the xdc.om.$name property. Depending on the model, one or more global variables are pre-defined.

CCS4 Problems

XGCONF cannot open cfg files which are NOT tied to CCS4

XGCONF depends on the project properties for launching itself. For opening configuration files which are not a part of a project any text editor can be used. In CCS4 XGCONF is set as a default editor for all files with the 'cfg' extension. This maybe changed in the CCS4 preferences. Navigate to Window->Preferences->Editors->File Associations and select the *.cfg file type. Then associate this file type with a text editor of your choice. Then make it the default editor by clicking on the Default button. A screenshot is shown below.


[printable version]  [offline version]offline version generated on 04-Aug-2010 21:08 UTC
Copyright © 2008 The Eclipse Foundation. All Rights Reserved
Retrieved from "http://rtsc.eclipse.org/docs-tip/Special:Offline"
Views
Personal tools
package reference