From Texas Instruments Wiki
Jump to: navigation, search

This page is no longer maintained and is kept here for reference only! Please go to this link for the most current version.

DSS Generic Loader (loadti)

The DSS Generic Loader (loadti) is a DSS (Debug Server Scripting) JavaScript example that functions as a command-line loader which can load/run an executable *.out file on TI targets. Any C I/O standard output can be sent to the console and scripting logs. It can also perform basic benchmarking of the application. The lack of GUI dependency and ease of use make it an attractive automation tool, useful for quick sanity tests and batch regressions. Unlike other command line loaders like 'load6x', because it leverages DSS, loadti works with any TI target, hardware or simulator, supported by the base Debug Server.

Some basic supported functionality includes:

  • C I/O standard output can be sent to the console and scripting logs
  • Generate detailed executions logs
  • Perform basic application benchmarking (using profile clock)
  • Pass arguments to 'main()'
  • Loading/saving data from host to target memory (and vice versa)
  • Resetting the target

Refer to the loadti 'readme.txt' and console help for a full list of supported features. To quickly see the typical command line params the Readme.txt from loadti in CCSv4.1.2 is attached here.

loadti is delivered with the default installation of DSS. The loadti documentation (readme.txt) is found in the root 'loadti' directory (See the next section for the directory location)

Environment Setup

To enable the ability to run loadti from any location, it is recommended to add the below directory to your system PATH:

set PATH=%PATH%;"<INSTALL PATH>\ccsv[x]\scripting\examples\loadti";

The above can be typed in manually after opening a command window, or stored in a batch file to run when opening a command window, or simply added permanently to the system PATH in Windows.

Once the location of loadti is added to the system PATH, it can be called from anywhere.

Using loadti

Usage: loadti [OPTION]... [OUT_FILE] [ARGUMENT]...

Example: The below command will use loadti to configure the debug server for the target specified in the target configuration file (mytarget.ccxml), load an application (myapp.out), pass two arguments to main (arg1, arg2), run the application to completion, and generate a DSS log file (mylog.xml):

> loadti -c C:\myproject\mytarget.ccxml –x C:\myproject\mylog.xml C:\myproject\myapp.out arg1 arg2

To get a list of all the supported options with loadti, simply bring up the command line help:

> loadti -h

Known Limitations

  • loadti does not fully support multi-core environments. It will automatically try to connect to the first connection and device found. However, loadti can be modified to add this support. See the section called: Customizing loadti
  • Unless the asynchronous run (-a) option used, loadti will wait until program execution is completed (hits the program exit breakpoint) or, if the run timeout option is specified (-t), if the run timeout occurs. If none of these events occur, loadti will not return from execution. Note that is some cases, loadti may not halt even if an exit point is reached ( Using loadti with MSP430)
  • When running loadti with the asynchronous (-a) option, profiling information (cycle counts) will not be collected

Using loadti with MSP430

Unless the asynchronous run (-a) option used, loadti will wait until program execution is completed (hits the program exit breakpoint) or, if the run timeout option is specified (-t), if the run timeout occurs. However there are instances where a breakpoint is not set on the program exit point, often on devices where the program is running from persistent memory like on an MSP430. This is to conserve the limited number of hardware breakpoints available for debug. In these cases, when using loadti, the user may notice that loadti never seems to finish executing when a synchronous run is done without a timeout specified. This is because when the exit point of the application is reached, execution does not halt. To avoid this from occurring, either:

  • Use the '-a' option to do an asynchronous run, keeping in mind that loadti may "finish" before program execution is done. Note that an asynchronous run will not output any profiling (cycle count) information
  • Use the '-t' option to set the run timeout
  • Change the default debugger settings to set a breakpoint at the program exit point
  • Modify loadti to add a breakpoint at the program exit point (can set a breakpoint at the exit point label)

Customizing loadti

loadti is a DSS Javascript example. loadti can be used right out of the box 'as-is' or it can be customized to add more options and functionality. All the files needed to extend loadti functionality is provided within the loadti example folder. The main loadti scripts are straight JavaScript. With a cursory knowledge of Javascript and DSS, customizing loadti will not be difficult. When modifying the loadti scripts, the main files of interest is:

  • getArgs.js: This script has the list of command line options. Add to this script to add additional command-line options.
  • main.js: This script has the main functionality of loadti. Add to this script to add additional functionality to loadti. This includes adding the functionality for the additional command-line options specified in getArgs.js

Please see the Debug Server Scripting topic for more information on DSS and which to find the full DSS API documentation.

Debugging Your Changes to loadti

Because loadti is a DSS JavaScript, the Rhino Debugger delivered with DSS can be used to debug loadti.