DSS Generic Loader (loadti)
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)
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.
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
- 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)
- 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