Question 1

Start/Stop FLEXnet License Server via Command Line

Accepted Answer

Question: Is there any way to Start/Stop LMTOOLS from command line? 
 Answer: Yes. Start lmgrd as an application from a Windows command shell using the following syntax: C:\flexlm> lmgrd -c license_file_list -L [+]debug_log_path Where, &bull; license_file_list is one or more of the following: - the full path to a single license file - a directory, where all files named *.lic in that directory are used 
 &bull; debug_log_path is the full path to the debug log file Prepending debug_log_path with the + character appends logging entries We recommend referring to the chapter "Starting the License Server Manager on Windows" in the attached FLEXnet Licensing End User Guide. This section provides detailed instructions on how to manually start the license server from the command line. And, the lmdown utility through lmutil.exe allows for the graceful shutdown of selected license daemons (both lmgrd and selected vendor daemons) on all machines. To view the available command-line options, you can run the following command from your LMSERVER installation directory: lmutil.exe lmdown -help 
 PDF

Question 2

MPEG-4 AAC Decoders support on the ADSP-SC573

Accepted Answer

Question: 
 Does the ADSP-SC573 support MPEG-4 AAC decoders (AAC-LC and HE-AAC), and can these decoders be integrated and used in CCES? 
 Answer: 
 Yes, the ADSP21573/ADSPSC573 supports MPEG 4 AAC( AAC-LC and HE-AAC are the subset of MPEG 4 AAC) decoders and the SDK can be used with CCES.

Question 3

Git-Based Version Control System in CCES

Accepted Answer

Q1: What is the Version Control System (VCS) feature in CCES? 
 Git is an open-source, Distributed Version Control System (DVCS). In the DVCS environment, each user has a complete copy of the repository, including its entire history. A user can potentially push changes to or pull changes from any other repository. Although policy may confer special status on one or more repositories; in principle, every repository is a first-class citizen in the DVCS model. This stands in contrast to a centralized version control system, where every individual checks files into and out of an authoritative repository. 
 Q2: How do I clone a repository into CCES? Navigate to File > Import > Git > Projects from Git Choose Clone URI and enter your repository details Follow the prompts to import the project into your workspace 
 Q3: Where can I view Git operations in CCES? Use the Git Perspective: Go to Window > Perspective > Open Perspective > Other > Git This view provides access to Git Repositories, History, Staging, and more For more information, refer the below CCES help for the getting started tutorials, concepts, and reference information. CrossCore&reg; Embedded Studio 3.0.2 > Integrated Development Environment > Eclipse Documentation > EGit User's Guide > EGit User Guide CrossCore&reg; Embedded Studio 3.0.2 > Integrated Development Environment > Using Version Control > Git Graphical User Interface

Question 4

Instrumented Profiling Report in CCES

Accepted Answer

Question: How to generate Instrumented Profiling Report using CCES: Answer: The -p compiler switch enables instrumented profiling in the compiler when compiling C/C++ source into assembly. Enable the -p switch in the IDE via Project > Properties > C/C++ Build > Settings > Tool Settings > Compiler > Processor > Enable compiler instrumented profiling The input data file will be created after debugging and running the application. Note: Do not rebuild the application before generating the report, because the IDE raises an error if the data file is older than the executable file. There are two methods to generate Instrumented profiling reports: the CCES IDE and the command-line tool (Reporter.exe). To generate an instrumented profiling report from CCES IDE: 1.Open the Wizard Go to File > New > Code Analysis Report. 2.Select Profiling Type Choose Instrumented profiling. Click Next. 3. Select the Input and Output files In DXE that produced the data file, brows the application executable file. In Data file, brows the profiling (.prf) data file. In Report document's output file name, enter the name of the new HTML report file. 4.Click Finish. To generate the Code Coverage report and Heap Debugging report, refer to the CCES help documentation located in the following directory: CrossCore® Embedded Studio > Integrated Development Environment > Debugging Executable Files > Generating Code Analysis Reports To generate an instrumented profiling report from the command line: Reporter.exe is the command line utility used to generate reports for Instrumented Profiling. Example: Reporter.exe -dxe Project.dxe -printer:ReporterInstrProf Project.prf -output report.html Where: -dxe - Specifies the Executable file. -printer: - Specifies the report type to be generated and one or more input data files. For Instrumented Profiling, use -printer:ReporterInstrProf. For Code Coverage, use -printer:ReporterPGO. For Heap Debugging, use -printer:ReporterHeap. -output - Specifies the path of the generated report.

Question 5

Build Configuration settings in CCES

Accepted Answer

Question: Why does the project always open in Debug mode upon reopening, even when it was previously set to Release mode? 
 Answer: CrossCore Embedded Studio (CCES) stores the active build configuration (such as Debug or Release) within the workspace metadata, not within the project itself. When a project is opened in a new workspace or if the existing workspace metadata is deleted, the active configuration reverts to the default, which is typically Debug. As a result, the previously selected configuration is not retained unless the same workspace is used consistently.

Question 6

Create ASM project in CCES

Accepted Answer

Question: 
 How to create ASM project in CCES? 
 Answer: 
 Direct creation of ASM projects is not possible, as CCES only support creating C/C++ projects. 
 So, create a new project for C/C++ and delete automatically generated .c/.cpp source files. Then, place the .asm source files in the source folder. 
 Also we can import VisualDSP++ assembly project into CCES, via 'VisualDSP++ Project' option in the Import Wizard.

Question 7

External Configuration tool in CCES

Accepted Answer

Question : 
 Is External Tool configuration tool removed from CCES 2.11.0 or is there any other way to access it? 
 Answer: To make the External Tools configuration visible, please follow these steps: 
 1. Navigate to the menu and select "Run -> External Tools -> External Tools Configurations." 2. Uncheck "Filter checked launch configuration types" icon located in the Launch configurations page. Please refer the attached image 3. Select "Apply and close." 
 
 Now the "Program" should be visible in the "external tools configurations" page.

Question 8

ICE feature comparison Table

Accepted Answer

ICE-1000, ICE-1500 and ICE-2000 Feature comparisons table:

Emulator

Features

Supported Processors

ICE-1000

1. Standard debug 2. 5 MHz JTAG frequency 3. Software controlled target reset 4. Multiple I/O voltages supported 5. USB bus powered

ADSP-2116x, ADSP-2126x, ADSP-213xx, ADSP-214xx ADSP-BF50x, ADSP-BF51x, ADSP-BF52x, ADSP-BF53x, ADSP-BF54x, ADSP-BF561, ADSP-BF592-A, ADSP-BF60x ADSP-SC5xx, ADSP-215xx, ADSP-70x

ICE-1500

1. Standard debug 2. 5 MHz JTAG frequency 3. Software controlled target reset 4. USB bus powered

ADSP-SC5xx, ADSP-215xx, ADSP-70x, 21569 SAM, GL-XP / SHARC-FX SOM baseboard

ICE-2000

1. Standard debug 2. Up to 46 MHz JTAG frequency 3. Software controlled target reset 4. Multiple I/O voltages supported 5. USB bus powered

ADSP-2116x, ADSP-2126x, ADSP-213xx, ADSP-214xx ADSP-BF50x, ADSP-BF51x, ADSP-BF52x, ADSP-BF53x, ADSP-BF54x, ADSP-BF561, ADSP-BF592-A, ADSP-BF60x ADSP-SC5xx, ADSP-215xx, ADSP-70x

Question 9

"DO_CYCLE_COUNTS" macro in CCES

Accepted Answer

Question: While using cycle count program in CCES, it does not print number of cycles. Why? 
 Answer: When running cycle count program, ensure that "DO_CYCLE_COUNTS" macro is specified in the Project Options. This can either be added as "DO_CYCLE_COUNTS" to the 'Preprocessor Definitions' under "Project Options: Compile: Preprocessor", or as "-DDO_CYCLE_COUNTS" to the 'Additional Options' under "Project Options: Compile".

Question 10

CCES_HOME Environment variable

Accepted Answer

1. CCES_HOME Environment variable 
 Question Is it necessary to add CCES_HOME (specific CCES installation directory) in system environmental variable? 
 Answer CCES_HOME can be used to overwrite internal behaviour but is not generally required to be set by the user. If we set the environmental variable CCES_HOME to a directory other than the CCES installation that we are using then, Debug sessions will not operate correctly. Note that, CCES_HOME shouldn't be used and it isn't required. In fact, it's use has been dropped from CCES 2.9.4+ releases.

Question 11

Which versions of CrossCore Embedded Studio (CCES) do I need to install? Audit

Accepted Answer

Q : 
 I am about to start working with CCES for the first time. Do I need to install all versions available on your website or can I just download and install the latest version? 
 
 .............................. 
 
 A : 
 We always recommend using the latest as it has the latest updates, and that old versions can be installed side-by-side. 
 Please note, to be able to download the latest version of CCES you must have an active subscription. For detailed information regarding subscriptions please see the following FAQ: https://ez.analog.com/dsp/software-and-development-tools/cces/w/documents/5300/faq-what-is-the-difference-between-a-license-expiring-and-a-subscription-ending-how-do-i-renew-a-subscription

Question 12

Using CMSIS packs from the command line in CrossCore Embedded Studio

Accepted Answer

Whilst we recommend using the CrossCore Embedded Studio GUI for your development work, there are some occasions where you may find command line access useful such as build automation. This page contains a list of frequently asked questions about command line support for the Cortex-M processor families. 
 How do I install CrossCore Embedded Studio from a command line? 
 Download the latest CCES release from https://www.analog.com/cces 
 Linux (Ubuntu) 
 CCES is officially supported for the 32-bit variants of Ubuntu 14.04 and 16.04. It may also work on other flavours of Debian but will not be officially supported. 
 If you are using an unsupported 64-bit OS you'll need to ensure you have support for the 32-bit architecture with the following commands: 
 $ sudo dpkg --add-architecture i386 $ sudo apt update $ sudo apt install libc6:i386 libstdc++6:i386 
 To install, run the following command to install: 
 $ sudo dpkg -i ${CCES-INSTALLER}.deb 
 CCES will be installed to: 
 /opt/analog/cces/${VERSION}/ 
 You can uninstall CCES using the following commands: 
 $ sudo dpkg -r adi-cces-${VERSION} $ sudo dpkg -P adi-cces-${VERSION} $ sudo rm -rf /opt/analog/cces/${VERSION} 
 Windows 
 On Windows, run the following command to install: 
 > ./ADI_CrossCoreEmbeddedStudio-Rel${VERSION}.exe /S /V"/qn INSTALLDIR=\"${INSTALL_PATH}\"" 
 CCES can be uninstalled via the uninstall link in the start menu, or via the control panel. 
 What CMSIS pack files do I need? 
 There are a few pack files required for development of the Cortex-M series processors. 
 First, to make use of the CMSIS support, you need the core ARM CMSIS support ( ARM.CMSIS.4.5.0 or later). 
 When developing for a processor family, you'll need the device family pack (DFP) for that device family, which contains all of the configurations required to build and debug for that family of processors. For example, if developing for the ADuCM3029, you'll need the ADuCM302x device family pack (AnalogDevices.ADuCM302x_DFP.x.y.z.pack). 
 Additionally, if you are developing using an evaluation platform from ADI (EZ-Kit, COG, CUP) then you'll need the appropriate board support pack (BSP) for the board, which contains examples and drivers for off-chip peripherals provided on the board. For example, if you are using the EV-COG-AD3029LZ evaluation platform, then you'd need the EV-COG-AD3029 BSP ( AnalogDevices.EV-COG-AD3029LZ_BSP.x.y.z.pack). 
 The CMSIS pack files have support for dependencies, so you should be prompted to install any missing pack files. 
 How do I install CMSIS pack files from the web? 
 To install a pack from the web , first identify the pack name by visiting https://www.keil.arm.com/devices and finding the pack you want to install. The pack name is the filename with the .pack extension on the top row of the expanded tab, but without the .pack extension. For example, the pack file for the ADuCM302x Device Family Pack is "AnalogDevices.ADuCM302x_DFP.2.0.0". 
 
 To install directly from the web, use the following command: 
 ${CCES}/Eclipse/cces -nosplash -consoleLog -application com.arm.cmsis.pack.installer -installPack ${PACK_NAME} 
 How do I install a pack file from my local filesystem? 
 To install a locally downloaded pack , use the following command: 
 ${CCES}/Eclipse/cces -nosplash -consoleLog -application com.arm.cmsis.pack.installer -importPack ${PACK_FILE} 
 How do I remove a pack file I have installed? 
 To remove a pack , use the following command: 
 ${CCES}/Eclipse/cces -nosplash -consoleLog -application com.arm.cmsis.pack.installer -deletePack ${PACK_NAME} 
 How do I see what CMSIS packs are installed from a command line? 
 There is no command line support for determining which pack files have been installed , however the pack structures will be installed into 
 ${CCES}/ARM/packs/AnalogDevices/ 
 Where the first level directory is the pack name and the second level is the pack version e.g. 
 ADuCM302x_DFP/2.0.0/ 
 On Linux, you can get a full list of pack and versions in CCES 2.7.0 with the following ls command: 
 $ ls /opt/analog/cces/2.7.0/ARM/packs/AnalogDevices/* /opt/analog/cces/2.7.0/ARM/packs/AnalogDevices/ADuCM302x_DFP: 2.0.0 /opt/analog/cces/2.7.0/ARM/packs/AnalogDevices/EV-COG-AD3029LZ_BSP: 1.0.0 
 On Windows, you can get a full list of pack files (without versions) with the following command: 
 > dir C:\analog\cces\2.7.0\ARM\packs\AnalogDevices\ /ad /b 
 ADuCM302x_DFP EV-COG-AD3029LZ_BSP 
 How do I build an existing project from the command line? 
 To invoke the dependency, makefile generation and build process, you need to invoke the headless builder with the following commands. 
 On Linux: 
 $ /opt/analog/cces/2.7.0/Eclipse/cces -nosplash -consoleLog -application com.analog.crosscore.headlesstools \ -data ~/cces/cmdline/ -project ~/cces/cmdline/MyProject/ -build all 
 On Windows: 
 > C:\analog\cces\2.7.0\Eclipse\ccesc -nosplash -consoleLog -application com.analog.crosscore.headlesstools \ -data C:/path/to/workspace -project C:/path/to/project -build all 
 Where: 
 -data is the path to the workspace you want to build from 
 -project is the path to your project 
 -build identifies the configuration to build, or "all" to build all configurations. Configuration name is case insensitive. 
 When a project has been built, and you haven't changed any settings or added/removed any files, you can invoke the makefiles directly from your build area. To do this, add the code generation tools location to your path 
 You can also use the makefile support generated by a project build to build directly. 
 First, ensure the ARM/gcc-arm-embedded/bin directory in your CCES install is in the PATH environment variable. 
 On Linux, you can use 'export' in your script or .bashrc: 
 $ export PATH=${PATH}:/opt/analog/cces/2.7.0/ARM/gcc-arm-embedded/bin/ 
 On Windows, you can use the 'set' command or the "Advanced System Settings" GUI: 
 > set path "%PATH%;C:\analog\cces\2.7.0\ARM\gcc-arm-embedded\bin" 
 Then cd into your output directory, where you can invoke the following make commands: 
 "make all" to perform a full build of anything that's changed since the previous build. "make clean" to perform a clean, which deletes any temporary/generated files allowing for a full build to be carried out. 
 Note: If you change any project settings or add/remove files, this won't be reflected in the makefiles unless you invoke the headless builder again. You can modify the makefiles directly but they will be overwritten if the headless builder is used. 
 How do I create a new project from the command line? 
 There is currently no support to create a CMSIS project from CCES via the command line. We're looking to add this in the future. 
 Currently your only options are to create the project under the CCES GUI, or to write a makefile based project. 
 How do I debug from the command line? 
 Debugging from the command line involves 2 components: OpenOCD (which handles the connection to the device) and gdb (which provides the debug interface) 
 Invoking OpenOCD 
 The OpenOCD command requires two configuration files (specified with the -f switch) : one for the target (CMSIS-DAP, ICE-2000, etc) found in: 
 ${CCES}/ARM/openocd/share/openocd/scripts/interface/ 
 and one for the target, found in the appropriate Device Family Pack under 
 ${CCES}/ARM/packs/AnalogDevices/${DFP}/${DFP_VERSION}/openocd/scripts/target/. 
 You also need to include both scripts directories (specified with the -s switch) : 
 ${CCES}/ARM/openocd/share/openocd 
 ${CCES}/ARM/packs/AnalogDevices/${DFP}/${DFP_VERSION}/openocd/scripts 
 You then need to invoke OpenOCD with "-c init" and an adapter speed. 
 Your full openocd command will therefore look something like this: 
 On Linux: 
 $ /opt/analog/cces/2.7.0/ARM/openocd/bin/openocd \ -f /opt/analog/cces/2.7.0/ARM/openocd/share/openocd/scripts/interface/cmsis-dap.cfg \ -f /opt/analog/cces/2.7.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/2.0.0/openocd/scripts/target/aducm3029.cfg \ -s /opt/analog/cces/2.7.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/2.0.0/openocd/scripts \ -s /opt/analog/cces/2.7.0/ARM/openocd/share/openocd/scripts \ -c init -c "adapter_khz 1000" 
 On Windows: 
 C:\analog\cces\2.7.0\ARM\openocd.exe \ -f C:\analog\cces\2.7.0 \ARM\openocd\share\openocd\scripts\interface\cmsis-dap.cfg \ -f C:\analog\cces\2.7.0\ARM\packs\AnalogDevices\ADuCM302x_DFP\2.0.0\openocd\scripts	arget\aducm3029.cfg \ -s C:\analog\cces\2.7.0\ARM\packs\AnalogDevices\ADuCM302x_DFP\2.0.0\openocd\scripts \ -s C:\analog\cces\2.7.0\ARM\openocd\share\openocd\scripts \ -c init -c "adapter_khz 1000" 
 Connecting via GDB 
 First, launch gdb. 
 On Linux: 
 /opt/analog/cces/2.7.0/ARM/gcc-arm-embedded/bin/arm-none-eabi-gdb 
 On Windows: 
 C:\analog\cces\2.7.0\ARM\gcc-arm-embedded\bin\arm-none-eabi-gdb.exe 
 Then use the 'target' command to connect to the OpenOCD session 
 (gdb) target remote localhost:3333 
 You can then use the standard gdb commands to manipulate your debug session, such as: 
 'load' command to load your executable 
 (gdb) load /path/to/executable 
 'continue' command to start running your application. 
 (gdb) continue

Question 13

Where can I find details of CrossCore Software and Tools Anomaly Reports? Audit

Accepted Answer

Question 
 Where can I find details of CrossCore Software and Tools Anomaly Reports? ==================================== 
 Answer 
 CrossCore Software and Tools Anomaly Reports are listed on the Software and Tools Anomalies page, here:

Software and Tools Anomalies Search | Design Center | Analog Devices

Question 14

What is the current working directory for the Elfloader in CrossCore Embedded Studio Audit

Accepted Answer

Question 
 I am trying to create a multi-DXE Loader file in CrossCore embedded Studio, using a relative file system path to include additional DXE(s). Using the relative path from the location of the .project and .cproject files does not work, and generates the error: 
 [Error ld0095]: Unable to open file: DualCoreLDR_Core1.dxe. 
 make: *** [DualCoreLDR_Core0.ldr] Error -1 
 What is the current working directory when the Loader is invoked, so that I can use a relative path to the 2 nd DXE? 
 ================================ 
 Answer 
 When the elfloader is invoked, the current working directory is the location of the DXE file produced from building the project, so any relative path should be relative to the output directory of the project being built (for example, the defaults of &ldquo;.\Debug&rdquo; and &ldquo;.\Release&rdquo;).

Question 15

What changes are needed to build a CrossCore Embedded Studio project after moving to another directory? Audit

Accepted Answer

Question 
 I have moved a CrossCore Embedded Studio project to another directory, and it no longer builds. There appears to be a number of resources that it cannot locate, generating the error: 
 make: *** No rule to make target `filename.c', needed by `an_object.doj'. Stop. 
 What do I need to change to build the project? 
 ==================================== 
 Answer 
 When you encounter the &lsquo;No Rule to Make Target&rsquo; error, it indicates that the makefile has a reference to a build file that cannot be located by gmake. Typically a project will use a number of relative paths in its configuration that may become invalid once the project has been moved. These will need to be corrected. 
 The first thing to check in CCES is whether the project uses any Linked Files. These are files that do not exist within the directory structure of the project, and are instead linked into the project from relative paths. Expanding the Project in the Project Explorer window will show an exclamation mark over any Linked Files that cannot be located. To correct the path for these files, you will need to right-click on each one and select &ldquo;Properties&rdquo;. Then, under the &lsquo;Resource&rsquo; tab, click the &ldquo;edit&rdquo; to the right of the &lsquo;Location&rsquo; details and correct the path to the Linked File by providing either a corrected relative path, or an absolute path. 
 Once all of these are resolved, if you are still encountering &lsquo;No rule to make target&rsquo; errors, you need to check the Project Preferences for any linked files. Go to &lsquo;Project: Properties: C/C++ Build: Settings: CrossCore Linker: General&rsquo;, and correct any &ldquo;Library search directories&rdquo; for the project&rsquo;s new location. 
 If the project still fails to build, the next settings to check are the &lsquo;Additional Include Directories&rsquo; for the Assembler, Compiler and Linker. Under &lsquo;Project: Properties: C/C++ Build: Settings&rsquo;, check the &lsquo;Preprocessor&rsquo; tab for each of these three tools and correct any Additional Include Directories for the new project location. 
 Finally, ensure that any referenced paths in any &lsquo;Additional Options&rsquo; for the Compiler, Linker and Assembler are corrected for the new project location. 
 If your project is set to build a Loader File artifact, you will also have to check that the path to the Initialization File - if a relative path - is correct for the project&rsquo;s new location, and ensure that any paths in the &lsquo;Additional Options&rsquo; for the Loader are corrected for the new project location. 
 This should correct most build errors, however you may still encounter problems where your code references files using relative paths that are not valid for the new project location. For example, if you use relative paths in #include or .import commands these may no longer be valid.

Question 16

What are the different types of licenses for CrossCore Embedded Studio? Audit

Accepted Answer

Question: 
 What are the different types of licenses for CrossCore Embedded Studio? 
 
 Answer: 
 There are four types of licenses that are used by CrossCore Embedded Studio: 
 
 Evaluation license 
 Full license 
 EZ-Kit license 
 Add-in license 
 
 Evaluation license: 
 An Evaluation license gives you full access to CrossCore Embedded Studio for 90 days. After 90 days the user cannot use CrossCore Embedded Studio unless they purchase a Full license or use an EZ-Kit license from a qualifying EZ-Kit (see EZ-Kit license). 
 Full license: 
 A Full license gives you full access to CrossCore Embedded Studio. The access does not expire after a given time period. A Full license is subscription based. It has a one year subscription, meaning that for the first year of use the developer can upgrade to a newer version of CrossCore Embedded Studio. After the first year the user can no longer upgrade CrossCore Embedded Studio but they still have full access to the version they have. 
 EZ-Kit license: 
 An EZ-Kit license has all the same features as a Full license except for the following items: 
 
 It is restricted to just the EZ-Kit it came with. No other hardware is supported, custom or otherwise (i.e. a different EZ-Kit). 
 It only works with the emulator shipped with the EZ-Kit, ICE-1000. The Simulator is not licensed via an EZ-Kit. 
 
 An EZ-Kit license is subscription based just like the Full license. 
 The current EZ-Kits that are supported by EZ-Kit licenses are: 
 ADSP-SC598 ADSP-21593 ADSP-SC594 ADSP-21569 ADSP-BF706 ADSP-BF707 ADSP-SC573 ADSP-SC584 ADSP-SC589 ADuCM3029

Question 17

Using Blackfin and SHARC from the command line in CrossCore Embedded Studio

Accepted Answer

Whilst we recommend using the CrossCore Embedded Studio GUI for your development work, there are some occasions where you may find command line access useful such as build automation. This page contains a list of frequently asked questions about command line support for the Blackfin and SHARC processor families. 
 What Operating Systems can I use to develop for Blackfin and SHARC? 
 The Blackfin and SHARC toolchains are only supported under Windows. The following versions of Windows are supported (as of CrossCore Embedded Studio 2.7.0): 
 
 Windows 7 (with Service Pack 1) 
 Windows 8.1 
 Windows 10 
 
 How do I install CrossCore Embedded Studio from a command line? 
 Download the latest CCES release from https://www.analog.com/cces 
 Run the following command to install: 
 > ./ADI_CrossCoreEmbeddedStudio-Rel${VERSION}.exe /S /V"/qn INSTALLDIR=\"${INSTALL_PATH}\"" 
 Uninstallation should be done via the uninstall link in the start menu, or via the control panel. 
 How do I build an existing project from the command line? 
 To invoke the dependency, makefile generation and build process, you need to make use of the headless builder. 
 > C:\analog\cces2.7.0\Eclipse\ccesc -nosplash -consoleLog -application com.analog.crosscore.headlesstools \ -data C:/path/to/workspace -project C:/path/to/project -build all 
 Where: 
 -data is the path to the workspace you want to build from 
 -project is the path to your project 
 -build identifies the configuration to build, or "all" to build all configurations. Configuration name is case insensitive. 
 You can also use the makefile support generated by a project build to build directly. 
 First, ensure that your CCES installation directory is in your PATH environment variable. 
 > set path "%PATH%;C:\analog\cces\2.7.0" 
 Then cd into your output directory, where you can issue the following make commands: 
 "make all" to perform a full build of anything that's changed since the previous build. "make clean" to perform a clean, which deletes any temporary/generated files allowing for a full build to be carried out. 
 Note: If you change any project settings or add/remove files, this won't be reflected in the makefiles unless you invoke the headless builder again. You can modify the makefiles directly but they will be overwritten if the headless builder is used. 
 How do I create a new project from the command line? 
 First, ensure the environment variable CCES_HOME to the root directory of your CCES installation. 
 You can use the headless builder to create a project using the following command: 
 > ${CCES}\Eclipse\ccesc.exe -nosplash -consoleLog -application com.analog.crosscore.headlesstools \ -data c:/path/to/workspace -project ${project_name} -project-name ${project_name} -command projectcreate \ -processor ADSP-BF707 -type Executable -language C++ 
 Where: 
 -data is the path to the workspace you want to create the project in -project and - project-name are the name of the project you want to create (currently these have to match) -type is either "Executable" or "Static Library" -language is either "C" or "C++" 
 Can I build without an Eclipse project from the command line? 
 Yes, but we'd recommend using an Eclipse project since it gives you access to the Add-Ins. 
 With the root directory of CrossCore Embedded Studio in your system path, you can invoke the driver directly (either "ccblkfn.exe" or "cc21k.exe") for all the source files you want to compile. Static .ldf (Linker Description Files) and C Run-Time objects are provided by the library to get you up and running without having to generate them yourselves (we'd recommend doing so for a more optimal configuration), and the System Services & Device Drivers are available in pre-compiled library form if they are being used. 
 You can either build and link everything in a single command : 
 > ccblkfn -proc ADSP-BF707 source1.c source2.c source3.asm -o myoutput.dxe 
 Or you can build and link your files independently (to take advantage of dependency support in makefiles): 
 > ccblkfn -proc ADSP-BF707 source1.c -c -o source1.doj 
 > ccblkfn -proc ADSP-BF707 source2.c -c -o source2.doj 
 > ccblkfn -proc ADSP-BF707 source3.asm -c -o source3.doj 
 > ccblkfn -proc ADSP-BF707 source1.doj source2.doj source3.doj -o myoutput.dxe 
 A full breakdown of the switches is available in the online help, or via the -help switch: 
 > cc21k -help 
 Can I debug from the command line? 
 There is support for running executables in a simulator or hardware session from the command line via CCES Runner , but the support is limited to execution only with no debugging support. To debug applications, you'll need to create and use a debug session under the CCES GUI.

Question 18

System Services and Device Drivers for CrossCore®︎ Embedded Studio Training Videos Audit

Accepted Answer

Two new training videos , " System Services and Device Drivers for CrossCore Embedded Studio " and " System Services and Device Drivers: Migrating from VisualDSP++ to CrossCore Embedded Studio " have been added to the Analog Devices Video Channel, and can be found at: 
 http://videos.analog.com/category/products/processors-dsp/ 
 System Services and Device Drivers for CrossCore Embedded Studio ( YouTube version ) 
 This training module introduces the System Services and Device Drivers 2.0 API for Blackfin in Crosscore Embedded Studio. 
 System Services and Device Drivers: Migrating from VisualDSP++ to CrossCore Embedded Studio ( YouTube version ) 
 This training module will walk you through the steps required for migrating a VisualDSP++ Blackfin project using System Services and Device Drivers 1.0 API to CrossCore Embedded Studio and the Device Drivers and System Services 2.0 API. 
 Find attached the training video slides and example codes. 
 For more information on CrossCore Embedded Studio and related Add-ins, please visit www.analog.com/CCES 
 
 Attachments: 
 
 SSL2_0inCrossCoreEmbeddedStudio.pdf 
 SSL2_0inCrossCoreEmbeddedStudio.zip 
 MigratingfromSSL1_0toSSL2_0.pdf 
 MigratingfromSSL1_0toSSL2_0.zip 
 SwitchSettings.txt.zip

Question 19

Support for Parallel Builds in CrossCore Embedded Studio Audit

Accepted Answer

Question 
 When attempting to use parallel builds with the command-line make tool, using the -j [N] or --jobs [N] switch, the build sporadically fails with errors, such as: 
 [Error ea1184] "command-line":1 The assembler was unable to locate the following .xml file: 
 'C:\Analog Devices\CrossCore Embedded Studio 1.0.2\System\ArchDef\ADSP-21371-compiler.xml'. 
 Or the file might be corrupted. Check the -proc option on the command-line and the contents of the .xml file. 
 Are parallel builds supported? 
 ==================================== 
 Answer 
 Support for parallel builds using the -j/--jobs switch was introduced in CrossCore Embedded Studio 1.0.3. If you are encountering this error you will need to upgrade your CrossCore Embedded Studio installation. The latest release is available on the CrossCore Embedded Studio Product Page . 
 Prior to this release parallel builds were not supported, and an instance of the build tools may lock resources required by other instances, causing them to fail. On these older releases, the error is intermittent, and larger projects will typically build over subsequent attempts. 
 For the VisualDSP++ version of this FAQ, follow this link: 
 FAQ: Support for Parallel Builds in VisualDSP++

Question 20

CrossCore Embedded Studio STDIO is slow, and interrupts processing of real world data Audit

Accepted Answer

Question: 
 When I use STDIO functions, such as printf, the process is slow and incoming data is missed. Why? 
 --------------------------------------------- 
 Answer: 
 The slow stdio operations which you are seeing are due to the manner in which STDIO operations are performed. A typical example is printf(), which performs three operations when it is used: It first does an open, then a read, then a close. 
 At each of these events, the DSP is halted by a hidden breakpoint (at the __primio label), the requested operation is performed, then the DSP is run again. When the DSP is halted, the emulator or debug agent gets a context switch request and, in the case of an Emulator, the context is transferred via JTAG, over USB to the host. Then memory operations are then performed as necessary. When the host is done, context is switched back to the DSP which requires USB traffic again, and the debug agent is set running. Multiply this by 3 times for the three operations (open, read, close) that a printf() does, and this takes time. 
 The context-switches between the DSP and the Host (PC) are performed whenever any STDIO is used, and consume quite a lot of time due to the data transfers necessary to do this. Although the HPUSB-ICE, USB-ICE and the ICE-100B (or EZ-KIT Debug Agent) perform the same switches, it should be quicker using the HPUSB-ICE as the HPUSB-ICE has higher bandwidth availability, and so can perform the context switches much faster. 
 If you are using an emulator and are unhappy with the speed, then you may simply need to scale down the amount of data you are trying to log via printf. Unfortunately, due to the way stdio operations are performed via JTAG, it is slower, and can disrupt the real-time metrics of your application due to the number of halt/run commands. 
 The best way to improve the STDIO performance, though, is to eradicate the context switches by taking the Emulator/Debug agent out of the process, which can be done by redirecting STDIO to a local peripheral, for example UART or USB, which would allow you to pipe data to a terminal application (such as HyperTerminal) via the Serial Port on your PC. 
 Information on how to do this in the System Runtime Documentation within CCES Help (Help->Contents->CrossCore Embedded Studio 2.x.x->System Runtime Documentation->STDIO PrimIO). 
 Also find information within the System Services and Device Drivers User Guide (Help->Contents->CrossCore Embedded Studio 2.x.x->System Runtime Documentation->System Services and Device Drivers->ADSP-BF609 API Reference->Modules->STDIO Service).

Popular Forums

Product Forums

Application Forums

Design Center Forums

Highlighted Webinar

Places

Libraries

Latest Webinars

Challenge Yourself!

What's Brewing

Places

Resources

Highlighted Blogs

Latest Blogs

ADI Blogs

Visit ContentZone

Featured Content

View Content By Industry

View Content By Technology

CrossCore Embedded Studio STDIO: FAQ