This document explains how to load and run programs from the command line using CCES Runner. CCES Runner is a command line utility that can be used to help automate tests. For example, ADI's CrossCore Embedded Studio (CCES) Compiler team runs a suite of automated tests that builds their compiler test programs and then uses CCES runner to run those programs on a target to verify the test results.
Figure 1: Installing CCES Runner
Figure 2: Updating CCES Runner
Or by visiting the "Help" menu, choosing About CrossCore Embedded Studio, Installation Details, click on the feature that you would like to update, and choose "Update...". If any updates are available they will be installed automatically.
Figure 3: Uninstalling CCES Runner
Once CCES Runner has been installed, the Runner executable file, CCES_runner.exe, will be located under the CrossCore Embedded Studio (CCES) directory. CCES Runner can be run from any directory but if run outside the CCES home directory, the command option --cceshome must be used to specify the location of CCES.
To run CCES Runner:
To display the help text containing all valid options and their arguments:
Figure 4: Example --help command
To run a program, at least these four options must be specified: processor, target, platform, and core. To find the values of these options, the --list option (optional combine with --processor) can be used to list all the possible target and platform values to pass as arguments. Or you can also create a launch configuration in CCES IDE and copy the session configurations into the corresponding command.
Figure 5: Launch configuration in CCES IDE
The following is a brief explanation of the purpose of each command:lo
--core "0,EMU|KIT|CLEAR_SYMBOLS|RUN_AFTER_LOAD|SHARC\ldr\ezkitSC589_preload_core0_v01,C:\ workspace\ADSP-SC589_Core0\Debug\ADSP-SC589_Core0"
Use the –list option to view all available targets and platforms. Specify the optional processor string to view all available targets and platforms for a specific processor. The results can then be passed to the --target and --platform commands.
To list all available combination of targets and platforms for ADSP-BF707:
Figure 6: Example --list command
$ CCES_runner.exe --list --processor ADSP-BF707Target: ChipFactory SimulatorPlatform: ADSP-BF707 Functional-SimTarget: Blackfin CS EmulatorPlatform: ADSP-BF707 via ICE-2000Target: Blackfin CS EmulatorPlatform: ADSP-BF707 via ICE-1000
ADSP-SC589 using ICE-2000
$ CCES_runner.exe \ --target "Emulation Debug Target" \ --platform "ADSP-SC589 via ICE-2000" \ --processor ADSP-SC589 \ --core "0,C:\Users\workspace\cces\2.7.0\test_Core0\Debug\test_Core0" \ --core "1,C:\Users\workspace\cces\2.7.0\test_Core1\Debug\test_Core1.dxe" \ --core "2,C:\Users\workspace\cces\2.7.0\test_Core2\Debug\test_Core2.dxe"
ADSP-SC589 using Functional Simulator
$ CCES_runner.exe \ --target "ChipFactory Simulator" \ --platform "ADSP-SC589 Functional-Sim" \ --processor ADSP-SC589 \ --core "1,C:\Users\workspace\cces\2.7.0\test_Core1\Debug\test_Core1.dxe" \ --core "2,C:\Users\workspace\cces\2.7.0\test_Core2\Debug\test_Core2.dxe"
ADSP-SC589 using Cycle-Accurate Simulator
Please note core id starts from zero.
$ CCES_runner.exe \ --target "ChipFactory Simulator" \ --platform "ADSP-SC589 Cycle-Accurate-Sim" \ --processor ADSP-SC589 \ --core "0,C:\Users\workspace\cces\2.7.0\test_Core1\Debug\test_Core1.dxe"
As mentioned in the description of the core command, load prerequisites can be specified to be loaded prior to loading the user program. A load prerequisite consists of a DXE file and possible options for that session. Below is a table containing available load prerequisite options:
To specify a prerequisite program, a path that points to the DXE file relative to the CCES installation directory is necessary.For example, Blackfin\Examples\drivers\flash\BF506F\bf506f_flash.dxe.
If prerequisite options are not explicitly specified when using the core command, CCES Runner will see if default preloads are available and load them automatically.
When running an ADSP-SC589 Core 0 project:
This command would also load the prerequisite program to set up clocks and DMC settings, so that the debugger is able to load the user’s application to external memory, as
--core "0,EMU|KIT|CLEAR_SYMBOLS|RUN_AFTER_LOAD|SHARC\ldr\ezkitSC589_preload_core0_v01, C:\workspace\ADSP-SC589_Core0\Debug\ADSP-SC589_Core0"
The --datafile option can be used to initialize memory from data stored in a file on the host as well as save data from memory back to a host file. The argument to --datafile is a comma separated string with 8 options as follows:
One of two values:
in - to specify that data should be loaded from a file and written to target memory after the application is loaded but before it is executed
out - to specify that data should be read from target memory and written to a file upon termination of the application
binary or binary:le - Specifies a binary file in little-endian format
binary:be - Specifies a binary file in big-endian format
<other> - Specifies a text file format from those listed via the --list-memformats option
This example reads 4096 values of data from a text file called input.dat which contains floating point formatted numbers on each line and writes it to core 0 memory starting at the address specified by stream_input before the application is run.
--datafile "0,in,input.dat,Floating Point 32 bit,stream_input,4096,1"
--datafile "0,in,input.dat,Floating Point 32 bit,0x001c0c4f,4096,1"
This example reads 1024 memory locations on core 0 starting at stream_output and writes it to a binary file called output.dat on the host. The file is written when the applications main() routine terminates.
This example reads 1024 memory locations on core 1 starting at stream_output and writes it to a binary file called output.dat on the host. The file is written when the program runs and hits the specified breakpoint symbol 'BP'.
Since different processor types have different file formats that they understand the list can vary from part to part. To see the list of valid --datafile <format> options you can use the --list-memformats option in conjunction with a chosen target, platform and processor. This option takes a single parameter called <core> which specifies the zero based core in the processor for which to list formats.
$ CCES_Runner.exe \ --target "Sharc Emulators/EZ-KIT Lites" \ --platform "ADSP-21489 via ICE-2000" \ --processor "ADSP-21489" \ --list-memformats 0 32 Bit Hexadecimal Binary Floating Point 32 bit Floating Point 40 bit Hexadecimal Octal Signed Fractional Signed Integer Unsigned Fractional Unsigned Integer
The --breakpoint option can be used to set a breakpoint at the specified. One breakpoint option can be used per core but multiple breakpoints can be set in one breakpoint option.
To set a breakpoint at address 0x001c0c4f, main() and adi_intComponents() for a core 0 program:
The --pgo command can be used to collect PGO output data in a specified file. Simulator only.
To find more information about Profile-Guided Optimization and Code Coverage, visit the help contents in CCES:
CrossCore Embedded Studio 2.7.0 > SHARC Development Tools Documentation > C/C++ Compiler Manual for SHARC Processors > Optimal Performance from C/C++ Source Code > Analyzing Your Application
The --preferences command can be used to set preferences for your CCES Runner debug session. The --preferences command takes a white space delineated list of preferences with optional values.
To increase the JTAG frequency to 46Mhz when loading and running program(s) using an ICE-2000, add the following command to your CCES Runner command line: --preferences "jtagfrequency=46"
The -@ or --config option can be used to specify an input text file containing the CCES Runner options.
For example, add the following to a file called options.txt:
target=ADSP-BF5xx Blackfin Family Simulators
platform=ADSP-BF5xx Single Processor Simulator
And specify -@ options.txt on the CCES Runner command line:$ CCES_Runner.exe -@ options.txt
The --customboard option can be used to specify a custom board support file. A custom board support file can be used to override the default register reset values with custom memory-mapped registers.
For example, --customboard BF527-custom.xml
Hi Richard@31 - just a wee note that the functionality you're after now exists in the CCES Runner.
I am so sorry for the delay in replying to your question. Sadly, it is currently not possible to dump memory and/or restart execution when a breakpoint is hit. It is possible, however, to set a breakpoint and stop the program(s) when the breakpoint(s) are hit using the --breakpoint option. For example, --breakpoint "0,main,adi_initComponents"
We're tracking a work item in our database to enhance the CCES Runner.
Thank you for your valuable feedback.
What does the application and the simulator once stopped on break point ?
can we dump memory and restart execution ? how to do that
Is it possible to script what should be done when the running application stop on break point ?