Loadti
From Texas Instruments Embedded Processors Wiki
Contents |
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. It can be found in '<INSTALL DIR>\ccsv4\scripting\examples\loadti'. The loadti documentation (readme.txt) is found in this directory.
NOTE: loadti does not support multi-core debug
Environment Setup
To enable the ability to run loadti from any location, it is recommended to add the above directory to your system PATH:
Example (for DOS):
set PATH=%PATH%;"C:\Program Files\Texas Instruments\ccsv4\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.
NOTE: There is a known issue with CCSv4 Beta 5 with the 'loadti.bat' file that will cause an error when running loadti. The workaround is to fix line 26 to look like:
set DEBUGSERVER_ROOT=%~dp0..\..\..\DebugServer
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.xml), 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
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.
- 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.
Leave a CommentComments
Comments on Loadti
Mjb said ...
Alanc said ...
Mjb - done. Attached the readme from CCSv4.1.2 - naturally you should always look at the readme from the corresponding CCS release you are using however we agree that having a quick peek at available options on here makes sense. Thanks.
--Alanc 13:01, 18 April 2010 (CDT)


Need more information about each individual parameter for the Loadti app.
--Mjb 15:11, 16 April 2010 (CDT)