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 the
foo.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
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:
supply a *.xs" file that implements instance$static$init to initialize the object
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 file to a package's base directory is not enough to trigger a rebuild of the package.
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.
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.
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. 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.