USER'S GUIDE Version 6.4 New editions of this guide incorporate all material added or changed since the previous edition. Update packages may be used between editions. The manual printing date changes when a new edition is printed. The contents and format of this manual are subject to change without notice.
Generated: 10/1/2017, 8:10 PM
Rev: cb0043d
Part Number: User's Guide for VectorCAST/C++ RSP v.6.4
VectorCAST is a trademark of Vector Software, Inc.
© Copyright 2017, Vector Software, Inc. All rights reserved. No part of the material protected by this copyright notice may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any informational storage and retrieval system, without written permission from the copyright owner.
U.S. Government Restricted Rights
This computer software and related documentation are provided with Restricted Rights. Use, duplication or disclosure by the Government is subject to restrictions as set forth in the governing Rights in Technical Data and Computer Software clause of
DFARS 252.227-7015 (June 1995) and DFARS 227.7202-3(b).
Manufacturer is Vector Software, Inc. East Greenwich RI 02818, USA.
Vector Software reserves the right to make changes in specifications and other information contained in this document without prior notice. Contact Vector Software to determine whether such changes have been made.
Third-Party copyright notices are contained in the file: 3rdPartyLicenses.txt, located in the VectorCAST installation directory.
2 Table of Contents
INTRODUCTION 10
About This Manual 11 Introduction 11 Overview 11 VectorCAST/RSP Concepts 11 Harness Architecture 11 RSP Communication Overview 12 RSP Communication Details 13 Execute Commands 14
Flags 18
Execution Methods 21
USING VECTORCAST/RSP 22
Introduction 23 Combining Host- and Target-based Testing 23 CLICAST - Command Line VectorCAST 23 QuickStart 23 Command Format 24 The C/C++ Options 26 The Target Options 29 CLICAST-Only Options 41
TARGET REFERENCE 43
Analog Devices VisualDSP 44 Configuration 44 Target Execution 46 ARM RVDS 48 Configuration 48 Target Execution 48 Target Debug Execution 50 Code Composer Studio 52 Configuration 52 Target Execution with Code Composer Studio 4.0 53 Target Execution with Code Composer Studio 3.3 55 Target Execution with Code Composer Studio 2 57 DSP/BIOS support on Code Composer Studio 3.3 and 4.x 61 Configuration 61
3 DSP/BIOS Configuration 61 Code Composer Studio on ezDSP28335 target board 65 Configuration 65 Target Execution with Code Composer Studio 3.3 67 Target Execution with Debug in Code Composer Studio 3.3 68 Code Composer Studio on DSK 6713 target board 69 Configuration 69 DSP/BIOS Configuration 69 Target Execution with Code Composer Studio 3.3 73 Target Execution with Debug in Code Composer Studio 3.3 74 Code Composer Studio on OMAP 35x EVM target board 75 Configuration 75 DSP/BIOS Configuration 75 Running in a Heterogeneous Multi-core environment with Code Composer Studio 3.3 79 Target Execution with Code Composer Studio 3.3 81 Target Execution with Debug in Code Composer Studio 3.3 82 Code Composer Studio v4.2.4 on TI Stellaris EKT-LM3S9B92 EVB 83 Target Configuration 83 Configuration 83 Target Execution with Code Composer Studio 4.2 85 Target Debug Execution in Code Composer Studio 4.x 87 Code Composer Studio v4.2.4 on TI TMS570LS31xHercules USB Stick 91 Target Configuration 91 Configuration 91 Target Execution with CCS 4.2 on the TMS570LS31x USB Stick 94 Target Debug Execution in Code Composer Studio 4.x 96 CodeWarrior DSP56800E 103 Configuration 103 Target Execution 105 Target Debug Execution 106 CodeWarrior StarCore SC140e 108 Configuration 108 Target Execution 109 Target Debug Execution 109 CodeWarrior for HC12 113 Configuration 113 Banked Memory Model 116 Target Execution 117 Target Debug Execution 118 CodeWarrior for HCS08 119 Configuration 119 Target Simulator Execution 123 Target Simulator Debug Execution 124 CodeWarrior for MPC 5554 126 Configuration 126
4 Target Execution 127 Target Debug Execution 128 CodeWarrior for MPC 8315 129 CodeWarrior USB TAP Installation 129 Configuration 133 Target Execution 134 Target Debug Execution 136 CodeWarrior for MPC5121 138 Configuration 138 Target Execution 139 Target Debug Execution 142 Cosmic 68HC12 and HCS12X 143 Configuration for 68HC12 143 Configuration for HCS12X 145 Target Execution 149 Target Debug Execution 151 Cosmic STM8 152 Configuration for Cosmic STM8 on ZAP Simulator 152 Configuration for Cosmic STM8 on STVD Simulator 153 Target Execution 154 Target Debug Execution 155 EVP for VD3204x 156 Configuration 156 Fujitsu Softune for FFMC Chips 159 Configuration 159 Target Execution 160 Target Debug Execution 160 Fujitsu Softune Simulator 161 Configuration 161 Target Execution 162 Target Debug Execution 162 Green Hills Simulator/Bare Target 163 Configuration 163 Configuration for a Target Board 163 Target Execution 164 Target Execution with Green Hills Multi Debugger 164 Improving Target Execution Speed 165 Green Hills INTEGRITY Simulator 167 Configuration 167 Target Execution 167 Target Execution with Green Hills Multi Debugger 168 Improving Target Execution Speed 168 Green Hills INTEGRITY mpserv 169 Configuration 169 Target Execution 171
5 Target Execution with Green Hills Multi Debugger 171 Improving Target Execution Speed 171 Green Hills INTEGRITY rtserv 172 Configuration 172 Target Execution 174 Target Execution with Green Hills Multi Debugger 175 Improving Target Execution Speed 176 HighTec TriCore-gcc 178 Configuration 178 Target Execution 181 Target Debug Execution 182 IAR Embedded Workbench 3.x MSP430 183 Configuration 183 Target Execution 184 Target Debug Execution 185 IAR Embedded Workbench 6.0MSP430X Large Memory Model 5.x 187 Configuration 187 Target Execution 189 Target Debug Execution 189 IAR Embedded Workbench 4.x ARM 9 192 Configuration 192 Target Execution 194 Target Debug Execution 195 IAR Embedded Workbench 5.x ARM 9 198 Configuration 198 Target Execution 200 Target Debug Execution 201 IAR Embedded Workbench v6.3for Amtel SAM3N 204 Configuration 204 Target Execution 206 Target Debug Execution 207 IAR Embedded Workbench for dsPIC 209 Configuration 209 Target Execution 211 Target Debug Execution 212 IAR Embedded Workbench for PIC24 target 214 Configuration 214 Target Execution 215 Target Debug Execution 217 IAR Embedded Workbench 5.x for Amtel AVR 220 Configuration 220 Target Execution 221 Target Debug Execution 222 Keil 224
6 Configuration for the C166 224 Configuration for the C51 227 Target Execution 229 Target Debug Execution 229 Keil for ARM 231 Configuration 231 Target Execution 232 Target Debug Execution 233 Keil for ARM Cortex M3 235 Configuration 235 Instrumentation Trace Macrocell (ITM) Configuration 236 Integration Notes 238 Target Execution 239 Target Debug Execution 239 Lauterbach TRACE32 242 Configuration 242 Target Execution 244 Target Debug Execution 244 Microchip MPLAB dsPIC (PIC30) and PIC24 246 Configuration 246 Target Execution 247 Target Debug Execution 248 Microchip MPLAB C30for PIC24 on Explorer 16 249 Configuration 249 Target Execution 250 Target Debug Execution 253 NEC V850 254 Configuration 254 Target Execution 257 Target Debug Execution 257 Paradigm for 80186 259 Configuration 259 Target Execution 261 Target Debug Execution 262 Paradigm for SC520 264 Configuration 264 Target Connections and Configuration 264 Target Execution 267 Target Debug Execution 268 QNX Neutrino & QNX Momentics 270 Configuration 270 Target Execution 271 Target Debug Execution 271 Renesas HEW – M16C/R8C 273 Configuring for Renesas HEW – M16C/R8C 273
7 Target Execution 273 Target Debug Execution 282 Troubleshooting 283 Compatibility 283 Renesas HEW SuperH (SH) chips 285 Configuration for Renesas HEW - SH 285 Target Execution 286 Target Debug Execution 288 Troubleshooting 288 Compatibility 290 TASKING 56k C Compiler 291 Configuration 291 Target Execution 291 Target Debug Execution 292 TASKING 563xx C Compiler 293 Configuration 293 Target Execution 293 Target Debug Execution 294 TASKING C166 Classic 296 Configuration 296 Target Execution 297 Target Debug Execution 297 TASKING C166 VX 298 Configuration 298 Target Execution 299 Target Debug Execution 299 TASKING TriCore 300 Configuration 300 Target Execution 301 Target Debug Execution 301 Tasking C166 Classic withTRACE32 Simulator on Linux 302 Configuration 302 Target Execution 302 Target Debug Execution 303 TriMedia 305 Configuration 305 Target Execution 307 Target Debug Execution 307 Wind River Diab/SingleStep Simulator 309 Configuration 309 Target Execution 309 Wind River Diab withTRACE32 Simulator on Linux 312 Configuration 312 Target Execution 313 Target Debug Execution 313
8 Wind River vxWorks 315 Overview 315 Starting vxSim in Tornado 315 Setting up the Command Line Tools for Tornado 316 Starting vxSim in Workbench 316 Setting up the Command Line Tools for Workbench 317 Configuration 318 Target Execution 318 Target Execution with vxWorks 653 319 Example Using vxSim 320 Example Using SBC 323 Troubleshooting a vxWorks Target Connection 326 Improving I/O Performance 331 Debugging with Tornado Crosswind on Windows 333
EXECUTION METHODS 336
EXECUTION VIA A REMOTE SHELL 337
Introduction 337 Execution via a Remote Shell 337 Introduction 337 Setting Up NFS 337 Setting Up Anonymous FTP 338 Setting Up scp 339 Setting Up rsh 339 Setting Up ssh 340 VectorCAST Configuration for Remote Shell Execution 342 Target Execution Using a Remote Shell 345 Target Debug Execution 345 Standard I/O 347 Introduction 347 Configuring to Use Stdin and Stdout 347 Target Execution - Stdin/Stdout (Automatic) 349 Target Execution - Stdin/Stdout (Manual) 349 Configuring to Use Stdout Only 350 Target Execution - Stdout (Automatic) 352 Target Execution - Stdout (Manual) 352 VectorCAST Monitor 353
INDEX 354
9 Introduction ABOUT THIS MANUAL 11
About This Manual
This section of the VectorCAST/RSP User's Guide contains information that you will need to use VectorCAST/RSP to test your software on an embedded target processor. This section is formatted with its own table of contents and index. The following topics are covered:
l VectorCAST/RSP concepts
l Creating target environments
l Target reference Introduction
Welcome to VectorCAST/RSP.
Congratulations! You have just taken the first step towards increasing your productivity testing your C/C++ language programs on embedded targets. The VectorCAST/RSP User’s Guide is intended to be a companion to the VectorCAST/C++ User’s Guide. This user guide assumes a familiarity with the VectorCAST product and its features.
This user guide has four sections. The first section, which you are currently reading, introduces the product and RSP concepts. The second section describes creating target environments. The third section contains a target reference, with specific information on configuring and executing tests on each target. Overview
VectorCAST/RSP is an extension of the VectorCAST product. It provides an interface layer that allows you to use the VectorCAST testing techniques and methods on an embedded target processor. The VectorCAST/RSP product will always run on your host platform (the same platform as the compiler). Only the VectorCAST generated test harness will be downloaded to, and executed on, the embedded target.
The VectorCAST/RSP product is always customized to a particular Target CPU, Cross Compiler, and Run-Time environment (or kernel). As such, the information presented here contains sections for several different compiler and kernel combinations. VectorCAST/RSP Concepts
VectorCAST/RSP complements the basic VectorCAST functionality. This section provides a conceptual overview of the VectorCAST/RSP functionality and architecture.
VectorCAST allows for the automation of software testing in a self-host environment. That is, testing of the software by running the VectorCAST Test Harnesses on the software development platform – generally a commercial workstation.
The VectorCAST/RSP package allows you to extend your testing one step further and execute your VectorCAST test cases in an embedded Target Environment. This allows you to easily verify that the test results generated in each environment are the same. It also allows you to test software that cannot be executed in the host environment due to target dependencies. Harness Architecture
The VectorCAST architecture is centered on the executable test harness that is constructed using the VECTORCAST/RSP CONCEPTS 12
VectorCAST environment constructor. The source code for this harness is custom built each time a new version of your application is built. The test harness code is compiled and linked into an executable program using the same cross-compiler and linker that you are using for your application code. The result is a complete executable program that can be downloaded to any target architecture your cross- compilation tools support. There is complete compatibility with whatever processor and board the application is intended to run on. The components of the test harness are illustrated in the following graphic:
RSP Communication Overview
The VectorCAST harness is data driven, which means that no changes are required to the harness source code in order to change how the harness stimulates the code under test. VectorCAST uses ASCII text based test data sets to stimulate the test harness. All data produced by the harness during a test run is likewise ASCII text. All IO that the harness performs is funneled through the VectorCAST IO facility. VECTORCAST/RSP CONCEPTS 13
The VectorCAST architecture allows the VectorCAST application to run on a Host platform while the test harness executable runs on the same host platform, OR on a remote target platform. The architecture of the target is not important, all that matters to VectorCAST is that there is some mechanism to send ASCII test data into the harness and to retrieve ASCII test result data back from the harness. With VectorCAST/RSP this mechanism is the IO link that is used for down-loading the target processor from the host platform, or some other dedicated communications link.
VectorCAST supports a variety of different IO mechanisms. The mechanism that you will use is dependent on the compiler and the RTOS (if any) that you are using.
The version of VectorCAST that you are using has been customized for the real-time operating system (or kernel) that is running on your target, and for the IO link that exists between your host and target. For each compiler that is supported by VectorCAST, there is a default IO mechanism. RSP Communication Details
The IO mechanism is controlled using the “Execute Command” field in the C/C++ tab of the VectorCAST options dialog. This dialog is accessed via the Tools => Options menu choice. VECTORCAST/RSP CONCEPTS 14
There are two types of entries that can be put into this field. One is the actual command sequence that should be used to execute the cross-compiled program; the other is a “flag” command that tells VectorCAST to use one of a series of built-in command sequences to execute the target program.
Execute Commands
The command sequence method is used for Instruction Set Simulators (ISS) which have a shell, or command line interface, that can be used to run target programs. For instance the Green Hills PPC compiler has an ISS for the PowerPC called simppc. The default “Execute Command” field for this compiler is simppc -ppc603 because the way you can run target programs under the simulator is to issue the shell command simppc -ppc603 my_program.exe.
The current list of execute commands is as follows:
Compiler Execute command
ARM C 1.x armsd –E
ARM C 3.x armsd –E
CodeWarrior for Power cmdIDE PC Comm
CodeWarrior StarCore runsim VECTORCAST/RSP CONCEPTS 15
Compiler Execute command
CodeWarrior StarCore runsim –d sc140e SDMA
Diab/rtasim rtasim
EVP VD32040 vrun.bat
EVP VD32041 vrun.bat -tgt vd32041
$(VECTORCAST_DIR)DATA\tricore- HighTec TriCore gcc\simulator.bat
Green Hills 68000 grun s68 68881 -- Simulator
Green Hills ARM simarm Simulator
Green Hills Blackfin grun isimbf –X83 -- INTEGRITY Simulator
Green Hills ColdFire grun sim68 -cpu=cf547x -- Simulator
Green Hills ColdFire grun isimcf -X83 -- INTEGRITY Simulator
Green Hills MIPS simmips Simulator
Green Hills NEC 850 sim850 Simulator
Green Hills PPC INTEGRITY 178B grun isimppc -X83 ppc603 -- Simulator (C Static Link)
Green Hills PPC $(VECTORCAST_DIR)\IO\pty $(VECTORCAST_DIR) INTEGRITY 178B \IO\monitor_stdout grun isimppc -X83 ppc603 Simulator (C Monolith -- Link)
Green Hills PPC grun mpserv -setup W:\TARGET\00-ghs-map- INTEGRITY 178B A400 os\cca-147\cca-147.dbs 192.168.0.21 -- PPC Board VECTORCAST/RSP CONCEPTS 16
Compiler Execute command
Green Hills PPC grun mpserv -setup INTEGRITY MBX860 C:\GHS\int408\mbx800\mbx800_mp.dbs ghprobe mpserv --
Green Hills PPC INTEGRITY MBX860 rtserv -port udp@mbx860 -X8 -X14 rtserv
grun - Green Hills PPC Bare setup=C:\GHS\PPC423\target\ppc\mbx860\ MBX860 mpserv mpserv_standard.mbs mpserv ghprobe --
grun -setup= Green Hills PPC Bare C:\ghs\ppc423\target\ppc\core403\ hpserv_ PPC403 hpserv standard.mbs hpserv hpprobe --
grun mpserv -setup Green Hills PPC Bare C:\GHS\int408\mbx800\mbx800_mp.dbs ghprobe MBX860 mpserv (C++) --
Green Hills PPC INTEGRITY 178B grun isimppc -X83 ppc603 -- Simulator
Green Hills PPC rtserv -loaddir INTEGRITY (FAB-T C++) C:\tftpboot -port udp@fabtsil222 -X8 -X14
Green Hills PPC rtserv -port [email protected] INTEGRITY 82XX rtserv
Green Hills PPC grun isimppc -X83 –- INTEGRITY Simulator
Green Hills PPC $(VECTORCAST_DIR)\IO\pty INTEGRITY Simulator $(VECTORCAST_DIR)\IO\monitor_stdout isimppc (Monolith Link)
Green Hills PPC INTEGRITY Simulator grun isimppc -X83 -- (C++ static link)
Green Hills PPC INTEGRITY Simulator rtserv -port udp@localhost -X8 -X14 (C/C++ dynamic link) VECTORCAST/RSP CONCEPTS 17
Compiler Execute command
Green Hills INTEGRITY grun isimarm -X83 -- ARM Simulator (Static)
Green Hills INTEGRITY ARM Simulator rtserv -port udp@localhost -X8 -X14 (Dynamic)
Green Hills INTEGRITY grun -setup= ARM IMX31 mpserv C:\ghs\int508\imx31litekit\imx31litekit.mbs (C++) mpserv ghprobe --
Green Hills INTEGRITY ARM IMX31 rtserv rtserv -port udp@imx31 -X8 -X14 (C++)
Green Hills PPC simppc Simulator
Green Hills x86 grun simx86 -- Simulator
Green Hills x86 rtserv2 -port [email protected] -X8 -X14 INTEGRITY Safeplex
Mercury Computer PPC runmc –ce 2
MetaWare ARC 4.5 scarc -cl -run
MetaWare ARC 6.5.3 scarc -cl –run
Microchip MPLAB C30 for dsPIC (PIC30) & $(VECTORCAST_DIR)\DATA\pic\pic30_sim_c.bat PIC24 MCU
QNX Windows host on live x86 target
QNX Windows host on live SH target
QNX Windows host on $(VECTORCAST_DIR)\DATA\qnx\qnx_windows.bat live PowerPC target 192.168.2.171 root u: /home/vcast_files
QNX Windows host on live MIPS target
QNX Windows host on live ARM target VECTORCAST/RSP CONCEPTS 18
Compiler Execute command
QNX Linux host on live x86 target
QNX Linux host on live SH target sh $(VECTORCAST_DIR)DATA/qnx/qnx_linux.sh QNX Linux host on live 192.168.2.171 root /mnt/qnx/ /home/vcast_ PowerPC target files QNX Linux host on live MIPS target
QNX Linux host on live ARM target
TriMedia tmsim
Flags
The flag technique is used for more complex mechanisms that require VectorCAST customization. The current list of IO mechanism flags is as follows:
Compiler Flag
CodeWarrior DSP56800E <
CodeWarrior HC12 S12XDT512 <
CodeWarrior HC12 S12E128 <
CodeWarrior HC12 SIM S12XDT512 <
CodeWarrior HC12 S12XDP512 <
CodeWarrior HC12 S12XEP100 EVB <
CodeWarrior HC12 S12XEP100 IVY <
CodeWarrior HC12 SIM S12XDP512 <
CodeWarrior HC12 SIM S12E128 <
<
Cosmic 68HC12 <
Cosmic 68HC12 Paged <
Cosmic 68HC12 ICD <
Compiler Flag
Cosmic 68HC12 ICD Paged <
Cosmic S12X <
Cosmic S12X Simulator <
Diab/Single Step 68K <
Diab/Single Step PPC <
GNU Target PA-Semi <
GNU ARM vxWorks <
GNU MIPS vxWorks <
GNU PPC vxWorks <
GNU 68K vxWorks <
GNU x86 vxWorks <
Green Hills PPC vxWorks <
Green Hills vxSim Win32 <
Green Hills vxSim UNIX <
Green Hills INTEGRITY ARM Civic Board (stdout) <
Green Hills INTEGRITY ARM Civic Board (multi) <
Hard Hat PPC <
IAR 68HC12 1.x <
IAR MSP430 1.x <
IAR for ARM 7 version 3.x <
IAR for ARM 7 version 5.x <
IAR for ARM 9 version 3.x <
IAR for ARM 9 version 4.x <
IAR for ARM 9 version 5.x <
IAR M16C 3.x <
IAR M16C 3.x TGT <
IAR M32C 2.x <
Compiler Flag
IAR M32C 3.x <
IAR MSP430 3.x <
IAR MSP430 4.x <
Microtec/Xray <
Paradigm <
Keil C166 <
Keil C51 <
Keil C51_TGT <
NEC V850 f3359 <
NEC V850 f3378 <
Paradigm C++ <
Paradigm SC520 <
Renesas M16C 3.x <
SCORE Target 2.4 <
SCORE Target <
SCORE c3x4x <
ST ST-20 <
Tasking 56K <
Tasking C166 Classic <
Tasking 68K <
Tasking 8051 <
TI Code Composer 3.3 F2812 DSP ezDSP <
TI Code Composer 3.3 F28XX DSP C2000 <
TI Code Composer 3.3 F2407 DSP <
TI Code Composer 3.3 DSP C55xx <
TI Code Composer 3.3 DSP C64xx <
VisualDSP++ ADSP-21xx <
VisualDSP++ Blackfin <
Compiler Flag
VisualDSP++ TigerSHARC <
Visual DSP++ (2.0) <
vxSim Unix <
vxSim Win32 (Tornado 2.0) <
vxSim Win32 (Tornado 2.20) <
vxSim Win32 (Tornado 2.21) <
vxSim Win32 (Tornado 3.x) <
Diab vxWorks 6.x <
vxSim (Workbench) <
vxSim rtp (Workbench) <
vxSim 653 v1.8 Win32 <
PPC vxWorks 653 v1.8 Win32 <
vxSim 653 v2.1 Win32 <
PPC vxWorks 653 v2.1 Win32 <
PPC vxWorks 653 v2.2 vxSim <
PPC vxWorks 653 v2.2 SBC <
PPC vxWorks PSC v2.2 <
Each compiler that is supported by VectorCAST has a default I/O mechanism. For instance, the Texas Instruments TMS320 compiler uses Code Composer as its default mechanism. You may override this default by choosing a different “Execute Command” from the list of available commands, or typing in the command string that should be used to execute the target program.
Execution Methods
The following execution methods can be used with any compiler:
Execution Method Flag
Execute via Remote Shell <
Execute via Secure Shell <
Execute via Standard IO <
Execute via Standard Out <
Introduction
The VectorCAST/RSP product allows you to use all of the VectorCAST functionality on an embedded target, emulator or simulator. The steps involved in creating a VectorCAST environment for target testing are exactly the same as for host testing. You specify the compiler and target in the Tools => Options dialog. When creating a target environment make sure that the directories entered into the Search List contain cross-compiled code for your target.
After the environment is created, VectorCAST must interact with the target (or simulator) in order to populate a VectorCAST database with target-specific information such as type ranges and sizes of storage units, and information on type ranges on the target and other target specific information. For each compiler and RTOS this is slightly different.
Note: VectorCAST will invoke the target two separate times to retrieve target-specific data.
The speed at which a test case runs on the target is based the amount of processing done by the code under test and on the amount of data that you ask VectorCAST to capture to the test results. A way to decrease the amount of data captured is to turn off the Expand Report Parameters and Expand Report Objects options in the Tools => Options dialog box, Execute tab. Combining Host- and Target-based Testing
If you are doing both Host- and Target-based testing, you should use different directories to store your VectorCAST/C and VectorCAST/RSP directories. All instances of VectorCAST that are started from the same directory will share the same configuration file (CCAST_.CFG). If you run the target product and the host product from the same directory, options saved for the target environments will over-write the options saved from the host environment, which may not be desirable. CLICAST - Command Line VectorCAST QuickStart
The following is a list of useful commands to get online CLICAST help. Each command is preceded by $VECTORCAST_DIR/ (Unix) or %VECTORCAST_DIR%\ (Windows).
To see a list of all commands, type:
clicast -lc help all
To see a list of categories, type:
clicast -lc help
To see a list of commands in a single category, type:
clicast -lc help
where
l ENvironment (or just “EN”)
l EXecute
l Report
l TEst
l TOol
l Option
l Get_option
l Language
l Cover
To see a list of all options, type:
clicast –lc help options all
To see a list of option categories, type:
clicast –lc help options
To see a list of options in a single category, type:
clicast –lc help options
where
l Language
l Builder
l Execute
l Report
l Target
l Coverage
l Prqa
To find out the value of an option, type:
clicast –lc get_option
In this manual, the VectorCAST/RSP User’s Guide, only the Target Options are listed. See the VectorCAST/C++ User’s Guide for a complete description of commands and other options. Command Format
CLICAST is invoked using the following syntax: CLICAST - COMMAND LINE VECTORCAST 25
Unix systems:
$VECTORCAST_DIR/clicast –lc –eenv –uunit –ssub –ttestcase command arguments
Windows systems:
%VECTORCAST_DIR%\clicast /l:C /e:env /u:unit /s:sub /t:testcase command arguments where env is the name of the environment, unit is the name of a unit under test, sub is the name of a subprogram, and testcase is the name of a testcase. If the environment has only one UUT, then -u unit is optional.
Throughout this User Guide, the corresponding CLICAST command is presented after each feature or option available in the VectorCAST application. The CLICAST command uses the following format:
clicast -lc -e
Description of the command, option, and arguments.
The following conventions are used:
l -lc indicates that VectorCAST/C++ should be used. If -lc is not present, CLICAST defaults to VectorCAST/Ada. If the command contains -e
l The vertical bar | stands for “or”, indicating that one of several choices is to be included in the command.
l Square brackets around a parameter indicate that a parameter is optional. For example, -e
l Angle brackets indicate that a source file name or script file name must be substituted. For example,
l Square brackets and angle brackets can be combined to indicate that a substitution is optional. For example, [
l Capital letters in a command name indicate the minimum that needs to be typed to uniquely identify the command. For example, clicast ENvironment Build
To specify <
clicast –lc -e DM6B -s "<
The C/C++ Options
Once VectorCAST is running, you should select the Tools => Options from the main menu to bring up the Options dialog. The C/C++ tab contains options that enable you to configure the interface between VectorCAST and the compiler.
Each compiler and target has a separate entry in the compiler templates list. By pulling down on this list you can select from the available target and host compilers, and the appropriate execute command.
The “Execute Command” option controls how VectorCAST interfaces with your specific compiler and target. This field is set to the correct value for the specific compiler you are using and you should not have to change this setting.
l If you are building an environment with C source code files, choose a template name ending with “C”. Example: GNU Native => 3.3 => C
l If you are building an environment with C++ source files (or a mixture of C++ and C files), choose a template name ending with “C++”. Example: GNU Native => 3.3 => C++
clicast -lc template
Initialize C/C++ Compiler options based on standard values for known C and C++ compilers. Selecting a template automatically sets other options, such as C_COMPILER_NAME, C_COMPILE_CMD, C_EXECUTE_CMD, and any other options that are CLICAST - COMMAND LINE VECTORCAST 27
needed for the compiler chosen.
Note: See the VectorCAST/C++ User’s Guide for information on the template settings for the other C/C++ compiler options.
Compiler Integration Tab
The first four options on the Compiler Integration tab on the C/C++ tab provide default commands for the Compiler Integration Wizard, used to create a build-settings repository. Each option here is set by the compiler template, but can be fine-tuned as desired.
The second group of options provides some startup options for target compilers. These options, too, are set by the compiler template, but may be modified.
Assembler Command
Choose Tools => Options, and click the C/C++ tab. Then click the Compiler Integration tab.
The command and options to call the assembler with the startup file.
clicast –lc option ASSEMBLER_CMD
Precompile Command
Choose Tools => Options, and click the C/C++ tab. Then click the Compiler Integration tab.
The command called before compiling the C/C++ test harness files. This command is only used if your compiler has a two-stage compilation process. After the precompile command is run, a file with the pre- compile extension is produced, and then the compile command is run on that file.
clicast –lc option PRECOMPILE_CMD
Precompile Extension
Choose Tools => Options, and click the C/C++ tab. Then click the Compiler Integration tab.
Extension of files resulting from the precompile command.
clicast –lc option PRECOMPILE_EXT
The files resulting from calling the precompile command have a file extension
Startup File
Choose Tools => Options, and click the C/C++ tab. Then click the Compiler Integration tab. This option specifies the file(s) containing startup code for your target. The default value is set by the compiler template. For some compilers, this option’s value includes several files.
To add a path, click the Add Path button . Browse to the location of the startup file, and click OK. To modify a path, double-click it to make it editable. You can include environment variables in the format $(ENV_VAR) by editing the CCAST_.CFG file. To delete a path, select it and click the Remove
Path button .
clicast –lc option STARTUP_FILE
Misc Tab
Environment Files
Choose Tools => Options, and click the C/C++ tab. Then click the Misc tab. This option specifies the files that need to be copied into the environment directory during environment build. Its default value is set by the compiler template.
To add a path, click the Add Path button . Browse to the location of the startup file, and click OK. To modify a path, double-click it to make it editable. You can include environment variables in the format $(ENV_VAR) by editing the CCAST_.CFG file. To delete a path, select it and click the Remove
Path button .
clicast –lc option VCAST_ENVIRONMENT_FILES
The Target Options
The Target Options are accessed via the Tools => Options dialog, Target tab. CLICAST - COMMAND LINE VECTORCAST 30
Board name: For vxWorks, the board name is the name of the target server. For other targets, the board name is the hostname or the IP address of the target. This option is used for Ethernet type downloads, to tell VectorCAST the name of the target server (vxWorks) or its IP address.
clicast –lc option TARGET_BOARD_NAME
Name of target board.
Harness file prefix: By default, VectorCAST assumes that a run-time environment is set up with a default working directory, and therefore uses an unqualified path name to open and create files from the test harness. However, in some run-time environments, it is necessary to use a fully qualified path name for these files. This option enables you to add a prefix in order to fully qualify the path name. For example, if you set the prefix to “/tgtsvr/”, then the test harness prepends “/tgtsvr/” to all filenames. Therefore, when the test harness tries to open TESTDATA.DAT, it uses the fully qualified path: /tgtsvr/TESTDATA.DAT. This option is useful when testing environments with Wind River vxWorks or Green Hills.
clicast –lc option VCAST_FILE_PREFIX
This text is prepended to any filename the test harness opens.
I/O Directory: This is used for vxWorks targets to select a directory other than the environment directory where all target I/O will take place. If this option is blank, I/O takes place in the environment directory. CLICAST - COMMAND LINE VECTORCAST 31
This option should be used when the target does not have read/write permission for the directory.
clicast –lc option TARGET_IO_DIRECTORY
Directory where Input/Output files for target test execution are stored.
Boot hostname: If this option is not specified, then the network hostname of the host machine is the target’s boot hostname. Otherwise, the name specified is the name the target knows as the boot host. This option is used for vxWorks.
clicast –lc option TARGET_BOOT_HOSTNAME
For vxWorks. This is the name that the target knows the boot host as.
Maximum string length: This option specifies the size of temporary character arrays that VectorCAST creates in the test harness. It also sets the maximum length of a string that can be used as an input value in the parameter tree. If you are running in a target environment with limited heap and stack resources, making this value smaller will reduce the VectorCAST test harness use of heap and stack. Changes to this value take effect after the environment is recompiled.
clicast –lc option VCAST_MAX_STRING_LENGTH
The size of temporary character arrays that VectorCAST creates in the test harness.
Header Options
Compiler lacks limits.h: This option is turned on when your compiler does not have a 'limits.h' header file.
clicast –lc option VCAST_NO_LIMITS True | False
This option should be turned on if your compiler does not have a "limits.h" header file.
Compiler lacks signal.h: This option is turned on when your compiler does not have a 'signal.h' header file. CLICAST - COMMAND LINE VECTORCAST 32
clicast –lc option VCAST_NO_SIGNAL True | False
This option should be turned on if your compiler does not have a "signal.h" header file.
No stdin, stdout, or stderr defined: This option indicates that the standard file handles: STDIN, STDOUT, and STDERR, are not defined for your compiler.
clicast –lc option VCAST_NO_STD_FILES True | False
This option indicates that the standard file handles STDIN, STDOUT, and STDERR, are not defined for the compiler you are using.
Compiler lacks setjmp.h: This option is turned on if your compiler does not have a 'setjmp.h' header file.
clicast –lc option VCAST_NO_SETJMP True | False
This option should be turned on if your compiler does not have a "setjmp.h" header file.
Compiler lacks stdlib.h: This option is turned on if your compiler does not have a 'stdlib.h' header file.
clicast –lc option VCAST_NO_STDLIB True | False
This option should be turned on if your compiler does not have a "stdlib.h" header file. vxWorks Options
Running with vxWorks headers: This option indicates that you are running with the vxWorks RTOS, causing specific compilation switches (-D VCAST_VXWORKS) to be set to allow the test harness to run under vxWorks.
clicast –lc option VCAST_VXWORKS True | False
For running with the vxWorks RTOS.
Execute with windsh.bat: Check this option to force the use of windsh.bat to connect to the target. If this option is not set, VectorCAST will use windsh.exe (if available) and windsh.bat otherwise. CLICAST - COMMAND LINE VECTORCAST 33
clicast –lc option VCAST_USE_WINDSH_DOT_BAT True | False
In stdout mode, to pass .bat files to a tcl-based windsh script, set this option to true.
Use windsh I/O redirection: This option causes VectorCAST to insert TCL commands into the windsh.src file to force vxWorks to use a /vio device for stdout. This option can be helpful when the target stdout is going to the target console, rather than the windsh stdout.
clicast –lc option VCAST_USE_WINDSH_IO_REDIRECTION True | False
Insert TCL commands into the windsh.scr file to force vxWorks to use a /vio device for stdout.
Use the 'cmd-shell' interpreter in windsh scripts: By default VectorCAST uses the 'c-shell' interpreter when creating the windh script that controls download and execution of the test harness. In some cases, the 'c-shell' is not supported, and the 'command-shell' syntax must be used. For example, 64-bit vxSim requires this option to be set.
clicast –lc option VCAST_VXWORKS_NO_CSHELL True | False
By default VectorCAST uses the 'c-shell' interpreter when creating the windh script that controls download and execution of the test harness. In some cases, the 'c-shell' is not supported, and the 'command-shell' syntax must be used. For example, 64-bit vxSim requires this option to be set.
Load executable as a Real-Time Process (RTP): This option runs VxWorks executables as a Real-Time process via the 'rtpSp' command rather than as a standard process via the 'ld' and 'sp' commands.
clicast –lc option VCAST_VXWORKS_RTP_MODE True | False
Set this option to run VxWorks executables as a Real-Time process (via the 'rtpSp' command) rather than as a standard process (via the 'ld' and 'sp' commands.
Create Tornado/Workbench constructor call source file: This option is used to tell VectorCAST to create a constructor call source file. This is only for use with the WindRiver Tornado or Workbench compiler with C++. If this option is not set, global class objects will not be constructed properly.
clicast –lc option VCAST_TORNADO_CONSTRUCTOR_CALL_FILE True | False
This is only for use with the Tornado/Workbench compilers.
Build test harness into a vxWorks PSC partition: This option is only used with the vxWorks Platform for Safety Critical (PSC). This option causes VectorCAST to build a monolithic boot image for the target, with the test harness located in an address space, as opposed to the coreOS.
clicast –lc option VCAST_PSC_USE_ADDRESS_SPACE True | False
This option causes VectorCAST to build a monolithic boot image for the CLICAST - COMMAND LINE VECTORCAST 34
target, with the test harness located in an address space, as opposed to the coreOS.
Use RAM payload: This option is only used with the vxWorks Platform for Safety Critical (PSC), and only if the VectorCAST option: “Build test harness into a vxWorks PSC partition” is also set. This option tells VectorCAST that it should run a test case by rebooting the PSC address space, via the partitionModeSet command. If this option is not set, then VectorCAST will start the partition using the arincSchedSet command to run each test case.
clicast –lc option VCAST_PSC_RAM_PAYLOAD True | False
This option tells VectorCAST that it should run a test case by rebooting the PSC address space, via the partitionModeSet command. If this option is NOT set, then VectorCAST will start the partition using the arincSchedSet command to run each test case.
clicast –lc option VCAST_PSC_RAM_PAYLOAD_REBOOT_CMD
This CLICAST-only option tells VectorCAST what command to issue to reboot the target hardware when it is required to do so. This option is only used with the vxWorks Platform for Safety Critical (PSC), and only if the VectorCAST option VCAST_PSC_USE_ADDRESS_SPACE is also set.
clicast –lc option VCAST_IGNORE_PSC_RAM_PAYLOAD_REBOOT_STATUS True | False
This CLICAST-only option tells VectorCAST to treat a non-zero target reboot status as a warning and to not require user interaction to continue. This option is used only with the vxWorks Platform for Safety Critical (PSC), and only if the VectorCAST options VCAST_PSC_USE_ADDRESS_SPACE and VCAST_PSC_RAM_ PAYLOAD_REBOOT_CMD are also set.
clicast –lc option VCAST_RELINK_PROMPT_FOR_PSC_RAM_PAYLOAD True | False
By default, when the RAM Payload partition flag is set, VectorCAST relinks the environment upon opening to ensure that the target boot image matches the current environment. If this CLICAST-only option is set to True, VectorCAST will prompt the user before performing these steps, offering the user the chance to skip these steps if the target is known to be properly loaded. vxWorks 653 Build directory: This option provides the path to the vxWorks 653 build directory containing the existing partition build. This directory should contain a directory (with the same name as the Target Board option) containing the files necessary to complete an executable build. CLICAST - COMMAND LINE VECTORCAST 35
Input/Output Options
I/O uses stdin/stdout: This option indicates that you are running tests on a target board and do not have file I/O capability. In this case, STDIN and STDOUT will be used to perform I/O. VectorCAST will read all of the input data from STDIN and write all of the output data to STDOUT. The STDIN of the target should be mapped to the file VCAST_STDIN.DAT, and the STDOUT of the target should be mapped to the file VCAST_STDOUT.DAT.
clicast –lc option VCAST_STDIO True | False
This option indicates that you are running tests on a target board and do not have file I/O capability.
Execute using stdin and stdout: This option tells VectorCAST to execute the test harness with standard input mapped to file VCAST_STDIN.DAT, and standard output mapped to VCAST_STDOUT.DAT. The normal Execute Command is still used to execute the test.
clicast –lc option VCAST_EXECUTE_WITH_STDIO True | False
Execute the test harness with standard input mapped to file VCAST_STDIN.DAT, and standard output mapped to VCAST_STDOUT.DAT.
I/O uses stdout only: This option indicates that you are running tests on a target board that does not have a STDIN capability. In this case, VectorCAST will compile and link the test case data into the test harness so that no data has to be “read” by the test harness.
clicast –lc option VCAST_NO_STDIN True | False
For running tests on a target board that does not have "STDIN" capability.
Execute using stdout only: This option tells VectorCAST to compile input test data into the harness, and map standard output to the file VCAST_STDOUT.DAT. The normal Execute Command is still used to execute the test. CLICAST - COMMAND LINE VECTORCAST 36
clicast –lc option VCAST_EXECUTE_WITH_STDOUT True | False
Compile input test data into the harness and map standard output to VCAST_ STDOUT.DAT.
Enable file indexing mode: This option tells VectorCAST to create output lines which use the file index rather than the file name as a prefix for each line. Using this option will reduce the length of each output line by 10 characters, which can help with the size on small memory targets.
clicast –lc option VCAST_FILE_INDEX True | False
Enable this option to cause VectorCAST to use a file indexing mode that significantly reduces the file I/O required for running coverage or unit tests.
Buffer I/O: This option indicates that you are running tests on a target board that does not have STDIN capability and cannot write to files. In this case, VectorCAST compiles and links the test case data into the test harness, so that no data has to be “read” by the test harness. Output data is stored in a buffer in the test harness.
clicast –lc option VCAST_BUFFER_OUTPUT True | False
For running tests on a target board that does not have STDIN capability, and cannot write to files.
Dump Buffer: If this option is set, VectorCAST will dump the test result data using a single printf call at the end of the test execution (or when the buffer is full). On some targets, reducing the output to a single “write” will result in a dramatic speed improvement. Requires “Buffer I/O” to be on.
clicast -lc option VCAST_DUMP_BUFFER True | False
Dump the test result buffer using a single printf call at the end of test execution. Requires VCAST_BUFFER_OUTPUT to be True.
Output buffer size: This option indicates the size of the buffer allocated for test results in the test harness. This value is used if the option Buffer I/O is set.
clicast –lc option VCAST_OUTPUT_BUFFER_SIZE
Size of buffer allocated for test results in the harness.
Read from serial port: Use utility to read from serial port
clicast –lc option COMREADER_ENABLED True | False
Use utility to read data from serial port.
Port name: Name of serial port (for example, 'COM1'). CLICAST - COMMAND LINE VECTORCAST 37
clicast –lc option COMREADER_COMPORT
Name of serial port (e.g. 'COM1').
Baud rate: Serial port baud rate.
clicast –lc option COMREADER_BAUD
Serial port baud rate.
Parity: Communication protocol uses parity bits.
clicast –lc option COMREADER_PARITY Y | N
Communication protocol uses parity bits.
Number of data bits: Number of data bits in communication protocol.
clicast –lc option COMREADER_DATA_BITS number of data bits
Number of data bits in communication protocol.
Number of stop bits: Number of stop bits in communication protocol.
clicast –lc option COMREADER_STOP_BITS number of stop bits
Number of stop bits in communication protocol.
Harness Size Options
Omit User-Globals Unit: This option will omit the User Global Unit from the test harness, which will greatly reduce the test harness size.
clicast –lc option VCAST_FORCE_NO_USERGLOBALS True | False
Omit User Global Unit from the test harness.
Omit code to process bit fields: This option disables type processing for bit-fields in order to reduce the size of the harness. User code is required to set and check values of parameters, returns, and global CLICAST - COMMAND LINE VECTORCAST 38 objects.
clicast –lc option VCAST_DISABLE_TI_BITFIELD True | False
Disable type processing for bit-fields.
Omit code to process 'string' types: This option disables type processing of char* types as 'strings' in order to reduce the size of the harness. You can still use array mode to set the individual characters of a char* type.
clicast –lc option VCAST_DISABLE_TI_STRING True | False
Disable type processing of char* types as 'strings'.
Omit code to process 'float' types: This option disables type processing for 'float' types in order to reduce the size of the harness. User code is required to set and check values of parameters, returns, and global objects.
clicast –lc option VCAST_NO_FLOAT True | False
Disable type processing for 'float' types.
Disable ALL type processing in the harness: This option disables ALL type processing in order to reduce the size of the harness. User code is required to set all data items. Only use on VERY small targets (less than 32k program space / 2k RAM). Setting this option automatically sets the options to omit BitField, String, and Float Types.
clicast –lc option VCAST_NO_TYPE_SUPPORT True | False
Disable all type processing.
Perform minimal test harness termination processing: This option removes most of the clean-up processing normally performed at the end of the test harness 'main()'. Omitted processing includes closing of files, printing status messages and calling of 'exit()'. Omitting this processing will reduce the size of the harness. This option is only honored when using STDIO or STDOUT mode for harness I/O.
clicast –lc option VCAST_MINIMAL_TERMINATION True | False
Remove clean-up processing. Option is only honored when using STDIO or STDOUT mode for harness I/O.
Maximum varied parameters: Maximum number of scalars that can be varied in one test case. Changes to this value will take effect after the environment is rebuilt. Reducing this value to 0 will completely remove list and range processing from the test harness, significantly reducing the size of the harness.
clicast –lc option MAX_VARY_RANGE
Maximum number of scalars that can be varied in one test. Changes to value take effect after environment is rebuilt. CLICAST - COMMAND LINE VECTORCAST 39
Disable the use of syslib 'malloc()': This option removes the harness dependency on syslib 'malloc()'.
clicast –lc option VCAST_NO_MALLOC True | False
Disable use of syslib 'malloc()'.
Maximum size of the VectorCAST Heap: When using the VectorCAST Heap in place of the syslib heap, this value controls the pre-allocated size of the heap.
clicast –lc option VCAST_MAX_HEAP_SIZE
Control the pre-allocated size of the VectorCAST Heap.
Other Options
Use compound test for batch execution: This option enables you to run all of your test cases during a single test driver execution. This is useful if there are many steps involved in running on your target platform. When this option is set, and you select the Test => Batch Execute All menu item, VectorCAST generates a temporary compound test case to execute all of the simple test cases (including <
When this option is set, the Event Limit does not start over at 1 for each test case; instead, the event tally is summed, as for compound test cases. Note that in the execution results report, each test case still has its own result data (starting at Event 1) and coverage data.
clicast –lc option VCAST_USE_COMPOUND_FOR_BATCH True | False
This option allows you to run all of your test cases during a single test driver execution.
Omit code to trap explicit calls to syslib 'exit()': This option disables the trapping of calls by the code under test to the syslib 'exit()' function which will reduce the size of the harness.
clicast –lc option VCAST_NO_EXIT True | False
Disable trapping of calls to the syslib 'exit()' function.
Use 'vcast-main()' in place of 'main ()': This option changes the name of the 'main' function of the VectorCAST test harness from 'main' to 'vcast_main'. This is useful when your target environment requires CLICAST - COMMAND LINE VECTORCAST 40 some startup processing prior to the start of the test. If you set this option, then you must provide your own 'main()' that calls 'vcast_main()' as part of its processing.
clicast –lc option VCAST_MAIN True | False
Change the name of the 'main' function of the VectorCAST test harness to 'vcast_main'. When this option is set, you must provide your own 'main()' that calls 'vcast_main()' as part of its processing.
Post-run delay: This option causes a delay, in seconds, after test execution completes and before result processing begins. For use with <
clicast –lc option VCAST_POST_RUN_DELAY
Delay in seconds between test execution and result processing.
Testcase timeout: This option sets the maximum amount of time, in seconds, to wait before VectorCAST terminates a test execution. The default value is 0, which means wait 'forever'.
clicast –lc option TEST_CASE_TIMEOUT
Set the maximum amount of time in seconds to wait before VectorCAST terminates a text execution. Default value is 0, meaning to wait 'forever'.
Maximum target files: This option limits the total number of files that the test harness is allowed to open while running a test. If set too low, test execution for that test does not start. This option is used for compound tests with more than 12 slots; it automatically sets the VCAST_MAX_FILE macro in the harness. Environment must be recompiled for changes to take effect.
clicast –lc option VCAST_MAX_TARGET_FILES
Maximum number of files that the test harness is allowed to open while running a test. Used for compound tests with more than 12 slots. Environment must be recompiled for changes to take effect.
Pre-test execution command: When set, this command causes VectorCAST to execute the OS command, script file, or batch file before the test harness is called for each test case execution. This option is useful for cycling power to your target, for example.
When specifying the path to a script file or batch file, a full or relative (to the environment directory) can be used. If a relative path to this command is used, it should be relative to the environment directory.
clicast -lc option VCAST_PRE_EXECUTE_CMD
When set, this command causes VectorCAST to execute the OS command, script file, or batch file before the test harness is called for each test case execution.
TFTP boot directory: For Green Hills rtserv only. This is the directory to which the executable files are copied so that the target can be booted via tftp. CLICAST - COMMAND LINE VECTORCAST 41
clicast –lc option TARGET_TFTP_DIR
Directory to which the executable files are copied so that the target can be booted via tftp.
CLICAST-Only Options
These options cannot be enabled or disabled in the Tools => Options dialog, on the Target tab. They are currently available only as CLICAST options.
clicast –lc option SCORE_DEBUG_CMD
Command used to debug on a SCORE target. This option is not available in the Options dialog.
clicast –lc option SCORE_EXECUTE_CMD
Command used to execute on a SCORE target. This option is not available in the Options dialog.
clicast –lc option SUBSTITUTE_CODE_FOR_C_FILE This option is for certain target debuggers that cannot handle #included .c files. When set, this option causes VectorCAST to copy the #included .c files and user code directly into the S000009.c and I000009.c files so that they are visible to the debugger. This option is not available in the Options dialog. clicast –lc option TARGET_SIM_CMD Command used to execute on the target or simulator. clicast –lc option VCAST_ENVIRONMENT_FILES These files will be copied into the environment directory during an environment build or rebuild. clicast –lc option VCAST_FAR_STDIN_DATA True | False This option should be used when executing on small-memory targets if your compiler supports the __far segment modifier. clicast –lc option VCAST_GH_INTEX_CMD When set, VectorCAST will invoke the Green Hills intex utility with this command immediately after linking the test harness. Refer to the VCAST_GH_ INT_FILE environment variable for information on how to specify a custom integrate file. Example: intex -kernel=C:\GHS\int408\sim800\kernel - bspdir=C:\GHS\int408\sim800 -target=C:\GHS\int408\sim800\default.bsp CLICAST - COMMAND LINE VECTORCAST 42 vcast.int clicast –lc option VCAST_GH_INT_FILE This is the custom integrate file passed to the Green Hills 'intex' command. This file should follow the general format of the default file found in the VectorCAST installation directory, which means it should contain a 'Filename' line with the text VCAST_FILE (to be replaced with the VectorCAST executable name) and a 'Starit' line with the value 'true' clicast –lc option VCAST_MONITOR True | False This option indicates that the VectorCAST host-based monitor utility is being used to control the I/O to the target. clicast –lc option VCAST_NO_FFLUSH True | False This option indicates that the stdio.h function fflush, is not defined for the compiler you are using. Target Reference ANALOG DEVICES VISUALDSP 44 Analog Devices VisualDSP Configuration This section provides details about configuring VectorCAST to run with Analog Devices’ VisualDSP. First, on the Tools => Options dialog, C/C++ tab, choose Compilers => Analog Devices => VisualDSP, and then one of the three choices: ADSP21xx, Blackfin, or TigerSHARC. The picture below shows the compiler settings for the VisualDSP ADSP-21060. If you are testing on another DSP processor from the ADSP 21K family, edit the preprocessor, compiler and linker commands to specify the specific processor you are using as shown in the example below for the ADSP-21363. Change the preprocessor command to: cc21k -E -C -proc ADSP-21363 and the compiler command to be: cc21k -c -w -O1 -Ov100 -g -double-size-32 -proc ADSP-21363 Then, switch to the Linker tab, and change the Linker command to: cc21k -g -proc ADSP-21363 Second, ensure that the directories containing the VisualDSP binaries are included in your PATH environment variable. These are most likely C:\Program Files\Analog Devices\VisualDSP 4.0 and C:\Program Files\Analog Devices\VisualDSP 4.0\System, ANALOG DEVICES VISUALDSP 45 but may be slightly different on your particular system. The first path puts the compiler on your PATH; the second puts idde.exe on your PATH, which VectorCAST calls. If your source code contains static initialization, set the Coverage I/O Type to “Buffered” on the Coverage tab. For example: #ifndef _MY_EXAMPLE_HPP #define _MY_EXAMPLE_HPP class Example { public: Example(); ~Example(); }; #endif #include "MyExample.hpp" Example g_example; // Example *g_example; ` // and you don't have to use buffered coverage Example::Example() { } Example::~Example() { } ANALOG DEVICES VISUALDSP 46 Target Execution There are two execution methods available. The default mode is < dspload visualdsp.exe dsprun dspwaitforhalt exit A template version of the VisualDSP script is saved in a file called “visualdsp.tmp”. If you need to customize the VisualDSP script that VectorCAST is using, you can make changes to the template script file. Upon the next execution of the target program, VectorCAST will use the modified template file. As long as you maintain the four commands shown above, you may add any legal VisualDSP scripting commands to the template script. In this mode, you will see the VisualDSP GUI pop up during the test, and then go away after the test is run. The VisualDSP GUI will look similar to the following: ANALOG DEVICES VISUALDSP 47 If you do not want to see the GUI during test execution, use the < Set session = app.CreateSession(@ "VectorCAST Session", @ "ADSP-BF5xx Blackfin Family Simulators", @ "ADSP-BF535 Simulator", @ "ADSP-BF535" ) to use your processor and platform. For example, if you are using the SHARC simulator with a single ADSP-21065L processor, you would use: Set session = app.CreateSession(@ "VectorCAST Session", @ "ADSP-2106x Family Simulator", @ "ADSP-2106x Simulator", @ "ADSP-21065L" ) You can run cscript $VECTORCAST_DIR/util/targ_list.vbs from the command line to get a list of targets and platforms available for your installation. Unless there is an existing copy of the visualdsp.vbs script in your environment directory, the script is copied there prior to test execution. Since this is a VBScript file, it is run with the cscript command. Make sure that cscript is available in your PATH environment variable. It is typically in c:/WINDOWS/system32. ARM RVDS 48 ARM RVDS Configuration This section provides details about configuring VectorCAST to integrate with the ARM RealView Development Suite (RVDS). The default configuration for all versions of this compiler will support execution on a simulator. In the case of ARM RVDS 4.0, execution on a board is also supported. In VectorCAST, select the appropriate template from the Compilers menu. It should be noted that upon installing the compiler under Windows, a number of environment variables were set up automatically, so there is no need for compiler setup before using VectorCAST. Please consult your ARM RVDS documentation for more details about how to set up your compiler if you have questions about this. Target Execution ARM Version 3.x and earlier Under version 3.x and all previous versions, only the simulator is supported. During environment build or execution, VectorCAST will launch armsd, which is a utility of ARM RVDS, to execute on the simulator. For board support, please contact your VectorCAST representative. ARM Version 4.x Under version 4.x, the default integration provided uses the simulator for ARM7TDMI. However, it is possible to execute under simulator and board for all ARM chips that are supported by the ARM RealView Debugger. The following explains how to adapt the template to run under different chips. First, the compile command may need to be amended. Under Options, in the C/C++ sub-tab, locate the ARM RVDS 49 compile command. Replace the CPU entry (currently ARM7TDMI) by the chip of your choice. To determine what should be the entry, go to a DOS shell and type armcc –cpu list to obtain the list of supported chips. You may also find out that information by compiling code within ARM RVDS – the information will appear among the messages posted during build operations. Second, if you are attempting to execute on target, there is a possibility that you will need some startup code. If it is the case, input the files for the startup code under options in the Compiler Integration sub- tab. Execution on the simulator does not require any startup code not automatically provided by the compiler. Third, any path to user library files that need to be linked must be listed in Options under the Linker tab. The command line must be amended in this fashion: armlink –userlibpath PATH_TO_USER_LIBRARIES Fourth, the execution script must be amended to reflect the chip being used. Open the file $(VECTORCAST_DIR)\DATA\arm\script.txt with a flat text file editor. The lines for CONNECT and DISCONNECT must be amended. By default, their values are: CONNECT @ARM7TDMI@RVISS DISCONNECT @ARM7TDMI@RVISS The string after the first @ sign represents the chip being targeted. The string after the second @ reflects ARM RVDS 50 the category under which that simulator or target template is listed in ARM RealView Debugger. To learn what should be the values, launch ARM RealView Debugger and select Target => Connect to Target. The following menu appears: Here, to execute on the ARM926 simulator, the value for the entire string should be @ARM926EJ- S@RVISS_1. If you want to use the ARM_Cortex template to execute on a physical target, then the right string value is @ARM_Cortex-A8_0@ISSM. It should be noted that a similar amendment must be made to the file debug.txt, also located under $(VECTORCAST_DIR)\DATA\arm\, to set VectorCAST to run test cases with the ARM RealView Debugger. Target Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. Launching a debug execution of the test harness under ARM 4.x will launch the ARM RealView Debugger. You will thereafter be able to run a test case under the control of the debugger . Test case data will be saved automatically, so you need only close the instance of the debugger to return to VectorCAST. Please note that if the test harness is not allowed to run until the end, incomplete results ARM RVDS 51 will be sent to VectorCAST, resulting in an error. Under previous versions of ARM RVDS, upon executing a test case with debug, VectorCAST will launch axd, another utility of ARM RVDS, to execute the test case. Please consult documentation to learn how to use this facility to execute test cases with VectorCAST. CODE COMPOSER STUDIO 52 Code Composer Studio Configuration This section provides details about configuring VectorCAST to integrate with TI Code Composer. If you are using Code Composer Studio 4.0, set the environment variable VCAST_CCS_INSTALL_DIR to your Code Composer installation directory. Usually Code Composer is installed in C:\Progra~1\TexasI~1\ccsv4, but it may be different for your system. Add the directory containing the binary for the compiler to your PATH environment variable. For example, if you are using Code Composer Studio 4.0 with the 55xx chip, add $VCAST_CCS_INSTALL_ DIR\tools\compiler\c5500\bin to your PATH. If you are using Code Composer Studio 3.1 or 3.3 with the < In VectorCAST, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for the version of Code Composer that you are using. In the following figure Code Composer 6x is selected: Special Configuration for Code Composer version 4.1 If you are using the Code Composer C3x version 4.1 simulator with VectorCAST you need to change the CODE COMPOSER STUDIO 53 default composer.cmd file that is delivered with VectorCAST. Edit the composer.cmd file located in VectorCAST's installation DATA directory (%VECTORCAST_ DIR\DATA%\composer.cmd). By default, the line you want to change is: EXTRAM : org = 0x900000, len = 0x40000 Change this to read: EXTRAM : org = 0x800000, len = 0x40000 In addition, you must configure the memory map in the Code Composer Simulator to enable the same range of memory. To do this, open the Code Composer application, and select the “Option” menu, “Memory Map…” choice. This will bring up a dialog similar to the following: Use this dialog to allocate a memory section using the following steps: 1. Enable Memory Mapping, using the check box 2. Select the Starting Address to be 0x800000 3. Select the Length to be 0x40000 4. Select the Attributes to be RAM - Read and Write 5. Click Add to add this memory section to the simulator 6. Click Done to close the dialog. Once this is accomplished, you will be able link and run VectorCAST test cases with the Code Composer C3x simulator. Target Execution with Code Composer Studio 4.0 Code Composer Studio version 4.0 uses the script found at $VCAST_CCS_INSTALL_ CODE COMPOSER STUDIO 54 DIR\scripting\examples\loadti\loadti.bat to run tests. You can specify a different chip by creating a ccxml file for it. Inside Code Composer Studio 4.0, go to Target => New Target Configuration to select your processor and save that to a file. In VectorCAST, go to Tools => Options dialog, C/C++ tab, and change the Execute Command to specify that file along with the path to it. So instead of: $(VCAST_CCS_INSTALL_DIR)\scripting\examples\loadti\loadti.bat -c $(VCAST_CCS_INSTALL_DIR)\scripting\examples\C64\tisim_c64xple.ccxml use $(VCAST_CCS_INSTALL_DIR)\scripting\examples\loadti\loadti.bat -c C:\your_dir\your_ file.ccxml Note that the loadti.bat script cannot read a .ccxml file over a network drive. You can either copy the file to your machine or specify the file with the VCAST_ENVIRONMENT_FILES configuration option so it gets copied automatically into your environment. Special Considerations for Some CCS v4.0 Targets Some of the VectorCAST templates for Code Composer v4.0 targets require using the VectorCAST- supplied loadti.bat file and main.js JavaScript instead of those provided in the Texas Instruments release. CODE COMPOSER STUDIO 55 The VectorCAST CCS templates that do require this will copy all the required script files and JavaScripts from the $(VECTORCAST_DIR/DATA/code_composer directory into your test environment directory and will reference these versions as opposed to the TI versions. An example of such a case is the for Spectrum Digital DSK-EVM-eZdsp F28335 (TI Code Composer 4.0 F28335 DSP C2000) which requires that gel scripts get run at the appropriate time to disable the WatchDog timer and enable the external RAM, from which the harness code gets loaded and executed. See the main.js JavaScript in the $(VECTORCAST_DIR/DATA/code_composer directory for details regarding any target-specific processing that occurs inside this script. When using the VectorCAST-supplied loadti.bat file with some CCS v4.0 targets, you must set the following environment variables before creating a test environment: VCAST_CCS_INSTALL_DIR, PATH, and DEBUGSERVER_ROOT. Note that the DEBUGSERVER_ROOT environment variable must be set here because the TI release version of the loadti.bat file sets this using relative paths, which will not work because VectorCAST will change the location of the loadti.bat file. Also be sure that you do not have the TI release location (%VCAST_CCS_INSTALL_DIR%\scripting\examples\loadti) on your PATH, as it will cause you to use the wrong loadti.bat file. set VCAST_CCS_INSTALL_DIR=C:\Progra~1\TexasI~1\ccsv4 set PATH=%VCAST_CCS_INSTALL_DIR%\tools\compiler\c2000\bin; c:\perl\bin;%PATH% set DEBUGSERVER_ROOT=C:\Progra~1\TexasI~1\ccsv4\DebugServer Target Execution with Code Composer Studio 3.3 Code Composer Studio versions 3.1 and 3.3 require some configuration for test case execution in VectorCAST. From the start menu, run Programs => Texas Instruments => Code Composer Studio v3.3 => Setup Code Composer Studio v3.3. In the System Configuration column, right click on the CPU name beneath the board specification and select Properties. Remove the default GEL file and leave the field blank. CODE COMPOSER STUDIO 56 Click OK. Removing the GEL file allows VectorCAST to invoke cc_app with your own StartUp() function in a GEL script. No data is lost since the default GEL script had an empty StartUp() function. VectorCAST invokes cc_app with a GEL script when executing tests with debug. The default execution method is < StartUp() { GEL_Reset(); GEL_Load("C:/BASIC_TUTORIAL/vcast.out"); GEL_Run(); } If you would like completely automated test execution, you can change your Execute Command in the VectorCAST Tool => Options dialog, C/C++ tab to < The < More recent versions of ActivePerl do not work with CCS Scripting so please check that you have ActivePerl v5.8. Before you can use the Perl execution method, follow these steps: 1. Add the location of the Perl utilities to your PATH environment variable. This is usually C:\Perl\bin but may be different for your system. set PATH=C:\Perl\bin;%PATH% 2. Obtain the patch for CCS Scripting v1.5 by starting up Code Composer Studio and selecting Help => Update Advisor => Check for Updates. CODE COMPOSER STUDIO 57 3. Add the CCStudio Scripting libraries to your PATH environment variable. This is usually C:\CCStudio_v3.1\bin\utilities\ccs_scripting. set PATH=C:\CCStudio_v3.1\bin\utilities\ccs_scripting;%PATH% 4. Finally, set a new environment variable, PERL5LIB, to the same directory as mentioned in the previous step. set PERL5LIB=C:\CCStudio_v3.1\bin\utilities\ccs_scripting The < The < The previous incarnation of the Code Composer product is Code Composer Studio 2. This is the integrated product that combines the TI compiler with Code Composer. If you are using the pre-studio version of Code Composer, see the section “Target Execution with Stand-Alone Versions of Code Composer” on page 58. The execution technique described in this section, is controlled by selecting: < For Code Composer Studio, VectorCAST starts Code Composer Studio (if it is not running) or connects to it (if it is already running). When VectorCAST is ready to run an executable, it puts up a dialog similar to the following: The dialog details the manual steps involved in test execution. After you click OK in this dialog, the Code Composer application is activated, and the test driver is loaded. You will need to select Run from the Debug, menu. When the test execution has finished, you will see the message: “VCAST is Done!” in the standard output window in Code Composer. To force control back to VectorCAST, you should select: Halt and then Reset CPU from the Debug menu of Code Composer. You do not need to exit from Code CODE COMPOSER STUDIO 58 Composer. The following screen shot shows the Code Composer Application with the debug menu pulled down and with the “VCAST is Done!” message in the standard out window. Target Execution with Stand-Alone Versions of Code Composer For older version of the stand-alone Code Composer, VectorCAST automatically creates a Code Composer GEL script and start the Code Composer application. VectorCAST will then “hang” waiting for Code Composer to terminate. This execution technique is controlled by selecting < The GEL script automatically loads and runs the test program. When the test program is done it prints a “VCAST is Done!” message to the standard output window in Code Composer. At this point you must quit Code Composer to have VectorCAST release off its “hang” and continue processing. Before VectorCAST starts Code Composer, it puts up a dialog similar to the following: CODE COMPOSER STUDIO 59 After you click OK, VectorCAST will start Code Composer and put up a second acknowledgment dialog similar to the following: When the target execution is complete, quit code composer and then click OK on the above dialog. The Default Memory Map VectorCAST is delivered with a “stock” linker command file that is used to build VectorCAST test environments. This memory map is located in the VectorCAST installation directory and is called composer.cmd. You should ensure that this file is consistent with your target hardware before testing. You may make changes to this file in the VectorCAST installation directory, and those changes will be reflected in any environments built subsequent to the change. If you need to control the memory map for each environment separately, you may edit the composer.cmd file that exists in the environment and then do a VectorCAST Environment => Relink command. CODE COMPOSER STUDIO 60 Debugging with Code Composer If you wish to debug with code composer, simply use Code Composer to halt the DSP, and then restart the execution using the standard Code Composer controls. DSP/BIOS SUPPORT ON CODE COMPOSER STUDIO 3.3 AND 4.X 61 DSP/BIOS support on Code Composer Studio 3.3 and 4.x Configuration This section provides details about how VectorCAST provides DSP/BIOS support for customers that require DSP/BIOS support running on either target boards or simulators. Currently this integration is supported for Code Composer Studio version 3.3 and 4.x DSP/BIOS Configuration VectorCAST relies on the installation and setup of DSP/BIOS on the system on which you will be creating your test environments. The environment variable BIOS_INSTALL_DIR is used by Code Composer Studio and VectorCAST to determine which version of DSP/BIOS is being used and its install location on your system. You must set up this environment variable accordingly as the example below shows. set BIOS_INSTALL_DIR=C:\CCStudio_v3.3\bios_5_33_06 Note: You may have multiple versions of DSP BIOS installed on your machine, be sure that the BIOS_INSTALL_DIR environment variable points to the version you want to be using. As with any CCS v3.3 environment, you must run CCS Setup to configure the appropriate target/simulator you wish to use. The sample screenshot below shows configuration for the C64xx simulator, which we will use throughout this chapter as an example. If you are using CCS v4.x or later, you do not need to run the CCS Setup as the target configuration in CCS versions after 4.0 are handled through the use of target configuration files (*.ccxml files). By default, VectorCAST will build new unit test environments with DSP/BIOS support disabled for all CCS targets that a user can select through the compiler pull down menu in VectorCAST. You should build a simple unit test environment without DSP/BIOS support to be sure that all other compiler settings and environment variables are properly configured, then turn on DSP/BIOS support in VectorCAST as described below. To determine if VectorCAST currently provides support for DSP/BIOS on the particular CCS target you DSP/BIOS SUPPORT ON CODE COMPOSER STUDIO 3.3 AND 4.X 62 have selected, select Tools => Options dialog, C/C++ tab, and the new Code Composer Options sub-tab is displayed. (This tab exists only when a TI Code Composer compiler has been selected in the compiler pull-down menu.) VectorCAST sets the environment variable VCAST_CCS_INSTALL_DIR to the default install path based on the compiler template you have selected and it is displayed on the Code Composer tab as shown below. For CCS v3.3 templates, the default install directory is “C:\CCStudio_v3.3”. If you have installed Code Composer Studio in a different location then you specify the path by editing it in the “CCS Installation Directory” edit box or use the directory browser button to select the correct install directory. If the checkbox named “DSP/BIOS” is available (not greyed out), then this means that VectorCAST has built-in support for DSP/BIOS for the selected compiler template. You can enable this DSP/BIOS for the test environment, by checking this box. If the checkbox is greyed out, then VectorCAST does not currently support DSP/BIOS on the target you have selected and you should contact VectorCAST support [email protected] for help in adding DSP/BIOS support. Customization of the DSP/BIOS support for your particular target or simulator is handled by pointing to a TCF file. Starting with v3.3, CCS uses TCF files to describe the resources and memory allocation details related to your target application. Details about the CCS graphical configuration tool are beyond the scope of this document, so please refer to your TI documentation for details about the graphical DSP/BIOS configuration tool, which will produce a TCF file as output. (DSP/BIOS 5.40 Textual Configuration (Tconf) User’s Guide http://www.ti.com/lit/ug/spru007i/spru007i.pdf) Here is a small excerpt from that TI documentation that describes the DSP/BIOS configuration tool: Typically, you use the graphical DSP/BIOS Configuration Tool to create your initial configuration. This tool acts as a macro recorder for Tconf scripts (TCF files). You see the script change in the right pane of the tool as you change the configuration graphically. Later, you can edit the Tconf script generated by the DSP/BIOS Configuration Tool with a text editor. (p. 1-4) Tconf scripts are now the source files for DSP/BIOS configurations. The CDB files previously used as configuration source files can now only be opened in read-only mode or converted to TCF files. (p. 1- 3) Users will typically have developed such a TCF file for their project and desired target in the CCS DSP/BIOS SUPPORT ON CODE COMPOSER STUDIO 3.3 AND 4.X 63 application environment, and now you must simply point to that TCF file inside VectorCAST to allow VectorCAST to generate the necessary supporting files based on the TCF file contents. VectorCAST provides a default TCF file as part of the RSP for the selected target which can be used or modified by the user in lieu of providing their own TCF configuration file. After selecting the TCF file the user should click the “Apply” button to initialize the VectorCAST environment data with the selected TCF file. This action will also cause the “Generate DSP BIOS Files” button to become enabled as shown in the figure below. You can now click the “Generate DSP BIOS Files…” button, which causes VectorCAST to generate the necessary DSP/BIOS files based on the selected TCF file, compile those files, and relink with the current environment. VectorCAST runs a .bat file (vcast_cc_tconf.bat) to execute the necessary operations. You will see a “processing…” status box during that execution phase as shown below. Other fields of interest on the Code Composer Options tab include the following: CCS Installation Directory is the installation directory for Code Composer Studio. You may edit the default path to point to the location of where CCS is installed on your system. BIOS_INSTALL_DIR option displays the current version setting for DSP BIOS. You should confirm it is properly set. Because the CCS tools and the VectorCAST tools both use this variable, you must exit VectorCAST to change this variable at the Operating System level, and then restart VectorCAST. DSP/BIOS SUPPORT ON CODE COMPOSER STUDIO 3.3 AND 4.X 64 TI CC DSP BIOS Linker Options contains the DSP BIOS-specific linker options that are automatically generated by VectorCAST based on the TCF filename and the contents of the TI Code Composer template provided by VectorCAST (TI_CC_TEMPLATES.DAT). You can edit these options if you need to add additional linker options. TI CC normal (non-DSP BIOS) Linker Options displays the linker options that are used if DSP BIOS support is turned off by unchecking the DSP/BIOS checkbox. Linker Command Preview is a read-only Linker Command Preview box that allows you to see the completely constructed linker command that will be executed to build the target/simulator image. This pane changes when the DSP/BIOS checkbox is selected or unselected. If the DSP/BIOS or normal linker options change, this pane will update in real-time to reflect those changes. CODE COMPOSER STUDIO ON EZDSP28335 TARGET BOARD 65 Code Composer Studio on ezDSP28335 target board Configuration This section provides details about configuring VectorCAST to integrate with TI Code Composer v3.3 on the Spectrum Digital ezDSP 28335 development board. You should install the latest drivers for the ezDSP 28335 from the Spectrum Digital website that are designed to work with Code Composer v3.3. Code Composer Setup The hardware connection method used for this RSP support is a direct USB connection to the onboard JTAG connection on the ezDSP 28335 development board; i.e., no external Spectrum Digital emulator is used. Prior to running VectorCAST, you need to run Setup Code Composer Studio. Set the board to F28335 ezDSP. It should display the driver location as C:\CCStudio_v3.3\drivers\sdgo28xxeZdspusb.dvr and the gel script at C:\CCStudio_v3.3\cc\gel\f28335.gel based on the default location for CCStudio v3.3 install directory. Note: The f28335.gel file must be modified to enable external memory before the program load occurs by making call to the XINTF_Enable() gel function in the OnPreFileLoaded() function. If you fail to make this change you will get a data verification error when VectorCAST tries to load the program on the 28335 like the one shown below. See the screen shots below to confirm that you are properly setup for the ezDSP 28335 board. CODE COMPOSER STUDIO ON EZDSP28335 TARGET BOARD 66 Specifying the CCS and Perl install directory paths: There are several environment variables you need to set that will define the path for the directories where your Code Composer Studio compiler is installed and where your Perl version 5.8 is installed. Note: This RSP relies on version 5.8 of Perl and will not work with version 5.10, (the most recent Perl version at this date). These environment variables are VCAST_CCS_INSTALL_DIR for the path where your CCS v3.3 compiler is installed and PERL5LIB for the path where your Perl version 5.8 is installed, and they must be set accordingly. Also be sure that the CCS compiler, and perl are included in your PATH, For example: set VCAST_CCS_INSTALL_DIR=C:\CCStudio_v3.3\ set PERL5LIB=C:\CCStudio_v3.3\bin\utilities\ccs_scripting set path=%VCAST_CCS_INSTALL_DIR%\cc\bin;%path% set path=%VCAST_CCS_INSTALL_DIR%\C2000\cgtools\bin;%path% set path=c:\perl\bin;%path% Now you can run VectorCAST to setup your test environment. First, select Tools => Options from the main toolbar an choose the C/C++ tab to select the entry for the version of Code Composer that you are using. In the following figure Code Composer 3.3 ezDSP 28335 is selected: CODE COMPOSER STUDIO ON EZDSP28335 TARGET BOARD 67 Target Execution with Code Composer Studio 3.3 If you would like completely automated test execution, you can select the Execute Command by right clicking on the desired test case or clicking the Execute test case button from the toolbar. This execution method uses CCStudio Scripting so you should only select it if you can install this feature. CCStudio Scripting allows VectorCAST to start Code Composer Studio, load the executable, run it, and then exit Code Composer Studio when the executable has finished. The < The < If you wish to abort the Perl script you may do so by selecting the Abort button, which will exit the perl script processing and typically make your test case fail as you have exited prior to test case execution CODE COMPOSER STUDIO ON EZDSP28335 TARGET BOARD 68 completion. You can change the Perl script file (composer.pl) if necessary. If you would like the changes to apply to all future environments, change the template for the file in $VECTORCAST_DIR/DATA/composer.pl or $VECTORCAST_DIR/DATA/composer_debug.pl if you which to change the behavior of the debug script. Note that when you execute a test case, it is normal for Code Composer Studio to start with an initial status of “HALTED” displayed in the bottom left hand corner. Just wait a few seconds, and after the application is loaded you will see the status switch to “RUNNING.” Target Execution with Debug in Code Composer Studio 3.3 If you select Execute With Debug command, then VectorCAST automatically calls the composer_ debug.pl Perl script, which will load the application but won’t automatically run so as to give you the opportunity to set breakpoints, single step and debug in the typical fashion when using the CCS IDE debugger. Before VectorCAST starts Code Composer, it puts up a dialog similar to the following: When the test program is done it prints a “VCAST is Done!” message to the standard output window in Code Composer. At this point you must quit Code Composer to have VectorCAST release off its “hang” and continue processing. After completing your debug session and quitting out of Code Composer, then click OK on the above dialog and control will be passed back to VectorCAST to display your test results. CODE COMPOSER STUDIO ON DSK 6713 TARGET BOARD 69 Code Composer Studio on DSK 6713 target board Configuration This section provides details about configuring VectorCAST to integrate with TI Code Composer v3.3 on the Spectrum Digital 6713 DSK (DSP Starter Kit) development board. This particular example describes an application example that utilizes the DSP/BIOS features. You should install the latest drivers for the 6713 DSK from the Spectrum Digital website that are designed to work with Code Composer v3.3. Other C6713 based targets can also use this template to configure a unit test environment, provided the required changes are made to accommodate the connection method specified in Code Composer Setup, including what type of emulator you are connecting to and target specific GEL files, also specified in the Code Composer Setup. In addition the user may have to provide their own TCF file to configure the DSP BIOS options according to their desired link configuration. See more details regarding the TCF file in the following sections. DSP/BIOS Configuration The RSP (Run-Time Support Package) that supports this particular board also provides DSP/BIOS support. The CCS 6713 compiler template will reference a TCF file used to enable and create the appropriate DSP BIOS support. The default TCF file will get copied to your test environment directory and will be used as the default TCF file when building your test environment with DSP BIOS support turned on. This TCF file can be used or a customer provided TCF file may be used in its place. See the chapter on DSP/BIOS configuration for Code Composer v3.3 for more details on how VectorCAST provides DSP/BIOS support. VectorCAST relies on the installation and setup of DSP/BIOS on the system you will be creating your test environments. The environment variable BIOS_INSTALL_DIR is used by Code Composer Studio and VectorCAST to determine which version of DSP/BIOS is being used and its install location on your system. The user must setup this environment variable accordingly as the example below shows. set BIOS_INSTALL_DIR=C:\CCStudio_v3.3\bios_5_33_06 Note: You may have multiple versions of DSP_BIOS installed on your machine, be sure that the BIOS_INSTALL_DIR environment variable points to the version you want to be using. You should also check the Component Manager and confirm that you have selected the appropriate version of BIOS for this DSP family (TMS32067xx). See the screen shot below. CODE COMPOSER STUDIO ON DSK 6713 TARGET BOARD 70 Code Composer Setup Prior to running VectorCAST, you need to run Setup Code Composer Studio. Set the board to C6713 DSK. It should display the driver location as C:\CCStudio_v3.3\drivers\sdgo6713dsk.dvr based on the default location for CCStudio v3.3 install directory. See the screen shots below to confirm that you are properly setup for the DSK 6713 board. Note: The GEL file specified in the CCS Setup for the C6713DSK made be modified by the user CODE COMPOSER STUDIO ON DSK 6713 TARGET BOARD 71 to specify a target specific set of GEL functions and actions that customizes the behavior of your target hardware. You can point to a different GEL file by clicking the “Modify Properties” button and navigating to the desired GEL file and saving that setup. Specifying the CCS, DSP/BIOS, and Perl install directory paths: There are several environment variables you need to set that will define the path for the directories where your Code Composer Studio compiler is installed and where your Perl version 5.8 is installed. Note: This RSP relies on version 5.8 of Perl and will not work with version 5.10, (the most recent Perl version at this date). These environment variables are VCAST_CCS_INSTALL_DIR for the path where your CCS v3.3 compiler is installed, BIOS_INSTALL_DIR for the path where your version of DSP/BIOS is installed, and PERL5LIB for the path where your Perl version 5.8 is installed, and they must be set accordingly. For example: set VCAST_CCS_INSTALL_DIR=C:\CCStudio_v3.3\ set BIOS_INSTALL_DIR=C:\CCStudio_v3.3\bios_5_33_06 set PERL5LIB=C:\CCStudio_v3.3\bin\utilities\ccs_scripting Also be sure that the CCS compiler, BIOS xdctools and perl are included in your PATH. For example: set path=%BIOS_INSTALL_DIR%\xdctools\; C:/CCStudio_v3.3/cc/bin;C:/CCStudio_ v3.3/C6000/cgtools/bin;c:/perl/bin;%path% Now you can run VectorCAST to setup your test environment. First, select Tools => Options from the main toolbar an choose the C/C++ tab to select the entry for the version of Code Composer that you are using. In the following figure Code Composer 3.3 DSK 6713 is selected: CODE COMPOSER STUDIO ON DSK 6713 TARGET BOARD 72 To enable DSP/BIOS support for this target you must check the DSP/BIOS checkbox on the Code Composer Options tab as shown below. By default the VectorCAST 6713 tempalte will point to the TCF file for the 6713 simulator (vcast_cc_ 6713_sim.tcf). To enable running on the 6713 DSK target you must select the target version of the TCF file. This file is available in the VectorCAST installation area (e.g. DATA\code_composer\64xx). You can either navigate to this file using the “navigate” button, or simply edit the field and change “sim” to “tgt”. You may also select an alternate TCF file that you have created for your project and custom hardware configuration. After selecting the desired TCF file, click the “Apply” button to save it as the current TCF file, which will store it in your VectorCAST environment data and then click the “Generate” button to have VectorCAST create the necessary DSP BIOS files, and compile and link them into the test harness. You will see a progress dialog box come up indicating that VectorCAST is running the internal bat file it uses to perform these DSP BIOS operations, as shown below. CODE COMPOSER STUDIO ON DSK 6713 TARGET BOARD 73 After that bat file completes successfully you are now ready to create your test cases and execute them with DSP BIOS support. Target Execution with Code Composer Studio 3.3 If you would like completely automated test execution, you can select the Execute Command by right clicking on the desired test case or clicking the Execute test case button from the toolbar. This execution method uses CCStudio Scripting so you should only select it if you can install this feature. CCStudio Scripting allows VectorCAST to start Code Composer Studio, load the executable, run it, and then exit Code Composer Studio when the executable has finished. The < The < If you wish to abort the Perl script you may do so by selecting the Abort button, which will exit the Perl script processing and typically make your test case fail as you have exited prior to test case execution CODE COMPOSER STUDIO ON DSK 6713 TARGET BOARD 74 completion. You can change the Perl script file (composer.pl) if necessary. If you would like the changes to apply to all future environments, change the template for the file in $VECTORCAST_DIR/DATA/composer.pl or $VECTORCAST_DIR/DATA/composer_debug.pl if you which to change the behavior of the debug script. Note that when you execute a test case, it is normal for Code Composer Studio to start with an initial status of “HALTED” displayed in the bottom left hand corner. Just wait a few seconds, and after the application is loaded you will see the status switch to “RUNNING.” Target Execution with Debug in Code Composer Studio 3.3 If you select the Execute With Debug command, then VectorCAST automatically calls the composer_ debug.pl Perl script, which will load the application but won’t automatically run so as to give you the opportunity to set breakpoints, single step and debug in the typical fashion when using the CCS IDE debugger. Before VectorCAST starts Code Composer, it puts up a dialog similar to the following: When the test program is done it prints a “VCAST is Done!” message to the standard output window in Code Composer. At this point you must quit Code Composer to have VectorCAST release off its “hang” and continue processing. After completing your debug session and quitting out of Code Composer, then click OK on the above dialog and control will be passed back to VectorCAST to display your test results. CODE COMPOSER STUDIO ON OMAP 35X EVM TARGET BOARD 75 Code Composer Studio on OMAP 35x EVM target board Configuration This section provides details about configuring VectorCAST to integrate with TI Code Composer v3.3 on the TI/Mistral OMAP 35x EVM development board. This particular example describes an application that is configured to utilize the DSP/BIOS features. This target configuration requires the use of a Spectrum Digital XDS560R emulator to connect from the host PC to the target EVM. You should install the latest drivers from the Spectrum Digital website that are designed to work with Code Composer v3.3. DSP/BIOS Configuration The RSP (Run-Time Support Package) that supports this particular board also provides DSP/BIOS support. The CCS OMAP 35x compiler template will reference a TCF file used to enable and create the appropriate DSP BIOS support. The default TCF files will get copied to your test environment directory and will be used as the default TCF file when building your test environment with DSP BIOS support turned on. This TCF file can be used or a customer provided TCF file may be used in its place. See the chapter on DSP/BIOS configuration for Code Composer v3.3 for more details on how VectorCAST provides DSP/BIOS support. VectorCAST relies on the installation and setup of DSP/BIOS on the system you will be creating your test environments. The environment variable BIOS_INSTALL_DIR is used by Code Composer Studio and VectorCAST to determine which version of DSP/BIOS is being used and its install location on your system. The user must setup this environment variable accordingly as the example below shows. set BIOS_INSTALL_DIR=C:\CCStudio_v3.3\bios_5_33_06 Note: You may have multiple versions of DSP_BIOS installed on your machine, be sure that the BIOS_INSTALL_DIR environment variable points to the version you want to be using. You should also click the Component Manager button and confirm that you have selected the appropriate version of BIOS for this DSP family (TMS32064xx). See the screen shot below. CODE COMPOSER STUDIO ON OMAP 35X EVM TARGET BOARD 76 Code Composer Setup Prior to running VectorCAST, you need to run Setup Code Composer Studio. Select the board and emulator configuration that matches your setup. Here we have selected the omap3530_SDXDS560R as shown below. Take time to configure the appropriate gel file for each of the processors on the omap 35x. You can change the specified gel file by selecting the processor, right-clicking and edit the gel file accordingly. The default gel files will work fine for this example. They are: C:\CCStudio_v3.3\cc\gel\omap3430_c64plus.gel C:\CCStudio_v3.3\cc\gel\omap3530_cortexA.gel CODE COMPOSER STUDIO ON OMAP 35X EVM TARGET BOARD 77 Specifying the CCS, DSP/BIOS, and Perl install directory paths: There are several environment variables you need to set that will define the path for the directories where your Code Composer Studio compiler is installed and where your Perl version 5.8 is installed. Note: This RSP relies on version 5.8 of Perl and will not work with version 5.10, (the most recent Perl version at this date). These environment variables are VCAST_CCS_INSTALL_DIR for the path where your CCS v3.3 compiler is installed, BIOS_INSTALL_DIR for the path where your version of DSP/BIOS is installed, and PERL5LIB for the path where your Perl version 5.8 is installed, and they must be set accordingly. For example: set VCAST_CCS_INSTALL_DIR=C:\CCStudio_v3.3\ set BIOS_INSTALL_DIR=C:\CCStudio_v3.3\bios_5_33_06 set PERL5LIB=C:\CCStudio_v3.3\bin\utilities\ccs_scripting Also be sure that the CCS compiler, BIOS xdctools and perl are included in your PATH. For example: set path=%BIOS_INSTALL_DIR%\xdctools\; C:/CCStudio_v3.3/cc/bin;C:/CCStudio_ v3.3/C6000/cgtools/bin;c:/perl/bin;%path% Now you can run VectorCAST to setup your test environment. First, select Tools => Options from the main toolbar an choose the C/C++ tab to select the entry for the version of Code Composer that you are using. In the following figure Code Composer 3.3 OMAP35x C64x+ is selected: CODE COMPOSER STUDIO ON OMAP 35X EVM TARGET BOARD 78 To enable DSP/BIOS support for this target you must check the DSP/BIOS checkbox on the Code Composer Options tab as shown below. By default the VectorCAST omap35x template will point to the TCF file for the 64x+ simulator (vcast_ cc_64Pxx_sim.tcf). To enable running on the omap 35x EVM target you must select the target version of the TCF file. This file is available in the VectorCAST installation area (e.g. DATA\code_ composer\64xx). You can either navigate to this file using the “navigate” button, or simply edit the field and change “sim” to “tgt”. You may also select an alternate TCF file that you have created for your project. After selecting the desired TCF file, click the “Apply” button to save it as the current TCF file, which will store it in your VectorCAST environment data and then click the “Generate” button to have VectorCAST create the necessary files and compile and link them into the test harness. You will see a CODE COMPOSER STUDIO ON OMAP 35X EVM TARGET BOARD 79 progress dialog box come up indicating that VectorCAST is running the internal bat file it uses to perform these DSP BIOS operations, as shown below. After that bat file completes successfully you are now ready to create your test cases and execute them with DSP BIOS support. Running in a Heterogeneous Multi-core environment with Code Composer Studio 3.3 The OMAP 35x EVM board is a multi-core board that contains a master CortexA8 ARM processor and a C6400+ DSP processor. The VectorCAST RSP is designed to build and test UUT code that is targeted to execute on the C6400+ DSP. To prepare your test environment to connect to, download and run the executable, you must first perform a few manual steps to ensure that the C64x+ DSP has been released from reset by the master ARM processor. The steps required to do so are as follows: 1. After setting up the omap 35x in the Code Composer Setup as described above, start up Code Composer Studio, which will bring up the Parallel Debug Manager, as shown below. 2. Connect to the CortexA_0 ARM processor be selecting, right-clicking and choosing “Connect device…”, then right-clicking again and choosing “Open…” Note: If you have trouble connecting to the CortexA_0 ARM processor you may have to reboot the omap35x target and Spectrum Digital emulator. It is helpful to have a serial port CODE COMPOSER STUDIO ON OMAP 35X EVM TARGET BOARD 80 connection from the omap35x serial port uart 1 connected to the host PC HyperTerminal app so you can see boot up debug messaging appear in the HyperTerminal window. Note that this board comes with a Linux kernel installed and while that kernel is booting up you may experience problems trying to connect to the ARM with the emulator. If you type “reboot” at the linux console prompt you will have better luck getting the connection to the ARM processor. You will also notice that when you disconnect from the ARM processor in CCS, the linux kernel will take control and auto boot. 3. Note that the C6400+ DSP is held in reset by the ARM processor. You must release the c64x+ from reset by selecting GEL => IVA2200_Startup => IVA22_GEM_Startup from the GEL pull down menu as shown below. 4. You should see the Output window appear and a message displayed indicating that the C64x+ has been released from reset, as below. 5. You are now ready to run test cases from your test environment. The perl script that gets run, (composer.pl), when each test case is executed will open a connection to the C64x+ DSP, load the CODE COMPOSER STUDIO ON OMAP 35X EVM TARGET BOARD 81 image to it, and run the executable. You must maintain the connection to the CortexA_0 ARM processor during all test case executions and be certain that the ARM is not holding the C64x+ in reset, which will cause the perl script to fail and subsequently the test case you were running. Note: The perl script has been written to check against the board name to determine if you are running in a multi-core environment. If the board name you have configured in Setup Code Composer is different than the default name, “OMAP3530_SDXDS560R”, for the OMAP 35x, then please contact Vector Software support to assist you in modifying the script accordingly. Target Execution with Code Composer Studio 3.3 If you would like a completely automated test execution, you can select the Execute Command by right clicking on the desired test case or clicking the Execute test case button from the toolbar. This execution method uses the CCStudio Scripting API so you should only select it if you have installed this feature. CCStudio Scripting allows VectorCAST to start Code Composer Studio, load the executable, and run it. In the multi-core test environment, VectorCAST will not exit Code Composer Studio when the executable has finished so as to maintain the connection and debug state of the master ARM processor which allows the C64x+ processor to get loaded and run without having to release it from reset for each test case execution. When you have completed running all the test cases you wish to run for a session, then the user can manually close Code Composer Studio. The user will have to manually setup the C64x+ connection as described earlier, for subsequent test case executions sessions. The < The < If you wish to abort the perl script you may do so by selecting the Abort button, which will exit the perl script processing and typically make your test case fail as you have exited prior to test case execution completion. You can change the Perl script file (composer.pl) if necessary. If you would like the changes to apply to all future environments, change the template for the file in $(VECTORCAST_DIR)/DATA/composer.pl or $(VECTORCAST_DIR)/DATA/composer_debug.pl if you which to change the behavior of the debug script. Note that when you execute a test case, it is normal for Code Composer Studio to start with an initial status of “HALTED” displayed in the bottom left hand corner. Just wait a few seconds, and after the application is loaded you will see the status switch to “RUNNING.” CODE COMPOSER STUDIO ON OMAP 35X EVM TARGET BOARD 82 Target Execution with Debug in Code Composer Studio 3.3 If you select Execute With Debug command, then VectorCAST automatically calls the composer_ debug.pl Perl script, which will load the application but won’t automatically run so as to give you the opportunity to set breakpoints, single step and debug in the typical fashion when using the CCS IDE debugger. Before VectorCAST starts Code Composer, it puts up a dialog similar to the following: When the test program is done it prints a “VCAST is Done!” message to the standard output window in Code Composer. At this point you must quit Code Composer to have VectorCAST release off its “hang” and continue processing. After completing your debug session and quitting out of Code Composer, then click OK on the above dialog and control will be passed back to VectorCAST to display your test results. CODE COMPOSER STUDIO V4.2.4 ON TI STELLARIS EKT-LM3S9B92 EVB 83 Code Composer Studio v4.2.4 on TI Stellaris EKT-LM3S9B92 EVB Target Configuration The RSP described in this section is designed to interface to the Stellaris EKT-LM3S9B92 evaluation kit which includes a BD-ICDI-B debug board. Refer to the TI instructions for connecting the target and debug board to each other with the two supplied flat ribbon cables and then connecting the USB cable to the host PC. This procedure will install the proper drivers for the evb/debug board combination. Upon completion of the driver install, check the Device Manager of your PC to see that the Stellaris ICDI com port, Stellaris ICDI Board A and Stellaris ICDI Board B appear as in the screen shot below. Configuration This section provides details about configuring VectorCAST to integrate with TI Code Composer Studio (CCS) v4.2.4 and the LM3S9B92 evaluation board. If you are using Code Composer Studio 4.2, set the environment variable VCAST_CCS_INSTALL_DIR to your Code Composer Studio installation directory. By default, Code Composer is installed in C:\Progra~1\TexasI~1\ccsv4, but it may be different for your system. VectorCAST will set the VCAST_ CCS_INSTALL_DIR environment variable for any TI CCS version 4.x target to C:\Progra~1\TexasI~1\ccsv4 by default. This default location can be modified by the user inside VectorCAST on the Tools => Options dialog, C/C++ tab, Code Composer Options sub-tab as shown below when first creating your unit test environment. CODE COMPOSER STUDIO V4.2.4 ON TI STELLARIS EKT-LM3S9B92 EVB 84 Add the directory containing the binary for the compiler to your PATH environment variable. Here are the environment variables that should be set for integrating with the CCS v4.2.4 tool chain for an ARM LM3S9B92 target processor. Note: In this example the CCS v4.2.4 was installed in the directory C:\CCS_v4.2.4\ccsv4. Also be sure to set the DEBUGSERVER_ROOT environment variable, as the base install directory for the DebugServer may vary in different versions of CCS. set VCAST_CCS_INSTALL_DIR=C:\CCS_v4.2.4\ccsv4 set path=%VCAST_CCS_INSTALL_DIR%\scripting\examples\loadti;%path% set path=%VCAST_CCS_INSTALL_DIR%\tools\compiler\tms470\bin;%windir%\system32;%path% set DEBUGSERVER_ROOT=C:\CCS_v4.2.4\ccsv4\DebugServer In VectorCAST, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for the version of Code Composer that you are using. In the following figure TI Code Composer v4.2 ARM LM3S9B92 EVB (C) is selected: CODE COMPOSER STUDIO V4.2.4 ON TI STELLARIS EKT-LM3S9B92 EVB 85 Target Execution with Code Composer Studio 4.2 Code Composer Studio version 4.2 uses the script found at %VCAST_CCS_INSTALL_ DIR%\scripting\examples\loadti\loadti.bat to run the target executable. VectorCAST uses this same loadti.bat file to execute test cases and passes a target configuration file as a parameter to the loadti.bat command. VectorCAST provides the appropriate target config file (lm3s9b92_evb.ccxml) for the LM3S9B92 evaluation board as part of the VectorCAST release and is copied to your test environment directory during test environment creation time. You can specify a different target by creating a new ccxml file for it. Inside Code Composer Studio 4.2, go to Target => New Target Configuration to select your processor and save that to a file. CODE COMPOSER STUDIO V4.2.4 ON TI STELLARIS EKT-LM3S9B92 EVB 86 Note that the loadti.bat script cannot read a .ccxml file over a network drive. During test case execution you will see the following progress dialog box displayed while the harness is running on the target. Target execution can take on the order of minutes in some cases depending on the complexity of the test case and UUT code, prematurely selecting the “Abort” button will cause the test case to fail. CODE COMPOSER STUDIO V4.2.4 ON TI STELLARIS EKT-LM3S9B92 EVB 87 Special Considerations for Some CCS v4.x Targets Some of the VectorCAST templates for Code Composer v4.x targets require using the VectorCAST- supplied loadti.bat file and main.js JavaScript instead of those provided in the Texas Instruments release. The VectorCAST CCS templates that do require these files will copy all the required script files and JavaScripts from the $(VECTORCAST_DIR/DATA/code_composer directory into your test environment directory and will reference these versions as opposed to the TI versions. This is not required for the LM3S9B92 EVB target template. Target Debug Execution in Code Composer Studio 4.x Code Composer Studio 4.x uses the Eclipse framework to support its debugging environment. When you execute a test with debug by right-clicking a selected test case and choosing “Execute With Debug,” VectorCAST will automatically pop up a dialog box with instructions for how to download and run the harness on your target using Eclipse. Below is the dialog box you will see the first time you run a test with debug; subsequent debug test case executions in the same unit test environment will not show this dialog box. The following screen shots itemize the sequence of the events described above. First you will be prompted to select a workspace. CODE COMPOSER STUDIO V4.2.4 ON TI STELLARIS EKT-LM3S9B92 EVB 88 On your first invocation of the Eclipse debugger environment you will need to create a NewTargetConfiguration by selecting Target => NewTargetConfiguration… from the pull-down menu inside the debugger environment, where you will define the Connection and Device type as shown in the screen shot below. Save this target configuration and on subsequent debug sessions you will simply select this target debug configuration that you have already created from the Debug history pull-down icon as shown below for the LM3S9B92 Stellaris In-Circuit Debug Interface_0. Next you must connect to the target by selecting Target => Connect Target and then Target => Load Program… to download the image to the target which will prompt you to point to the program file you want to download. Navigate to your test environment directory and select the UUT_INTE.out image file as shown in the example below. CODE COMPOSER STUDIO V4.2.4 ON TI STELLARIS EKT-LM3S9B92 EVB 89 Upon completion of the program load you will see the first line of main() displayed in the debugger window as shown below, since the debugger is configured by default to run to main() after program load. At this point you may begin single stepping, setting breakpoints, examining variables and memory as you would in any normal debug session. When you have run to completion of the harness executable you will see the “VCAST is Done!” message displayed in the console window as shown below. Now you can simply exit the debugger and control will be released back to VectorCAST where you will see your test results displayed. CODE COMPOSER STUDIO V4.2.4 ON TI STELLARIS EKT-LM3S9B92 EVB 90 CODE COMPOSER STUDIO V4.2.4 ON TI TMS570LS31XHERCULES USB STICK 91 Code Composer Studio v4.2.4 on TI TMS570LS31x Hercules USB Stick Target Configuration The RSP described in this section is designed to interface to the TMS570LS31x Hercules USB Development kit. This TMS570LS31x development board has dual Cortex-R4F ARM CPU's running in lockstep, 3MB of on-chip Flash, 256KB of RAM, and an enhanced set of peripheral modules. Refer to the TI documentation for more detailed information on the development kit itself, including the installation of the appropriate drivers for the board, which should be installed automatically upon plugging in the USB connection for the board. Upon completion of the driver install, check the Device Manager of your PC to see that your system displays the TI XDS100 USB Channel A and Channel B as in the screen shot below. Configuration This section provides details about configuring VectorCAST to integrate with TI TMS570LS31x Hercules USB Development Stick. If you are using Code Composer Studio 4.2, set the environment variable VCAST_CCS_INSTALL_DIR to your Code Composer Studio installation directory. By default, Code Composer is installed in C:\Progra~1\TexasI~1\ccsv4, but it may be different for your system. VectorCAST will set the VCAST_ CCS_INSTALL_DIR environment variable for any TI CCS version 4.x target to C:\Progra~1\TexasI~1\ccsv4 by default. This default location can be modified by the user inside VectorCAST on the Tools => Options dialog, C/C++ tab, Code Composer Options sub-tab as shown below when first creating your unit test environment. CODE COMPOSER STUDIO V4.2.4 ON TI TMS570LS31XHERCULES USB STICK 92 Add the directory containing the binary for the compiler to your PATH environment variable. Here are the environment variables that should be set for integrating with the CCS v4.2.4 tool chain for the TMS570LS31x target processor. Note: In this example the CCS v4.2.4 was installed in the default directory, C:\PROGRA~1\TEXASI~1\ccsv4. Also be sure to set the DEBUGSERVER_ROOT environment variable, as the base install directory for the DebugServer may vary in different versions of CCS. set VCAST_CCS_INSTALL_DIR=C:\PROGRA~1\TEXASI~1\ccsv4 set path=%VCAST_CCS_INSTALL_DIR%\scripting\examples\loadti;%path% set path=%VCAST_CCS_INSTALL_DIR%\tools\compiler\tms470\bin;%path% set DEBUGSERVER_ROOT=%VCAST_CCS_INSTALL_DIR%\DebugServer In VectorCAST, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for the version of Code Composer that you are using. In the following figure TI Code Composer v4.2 ARM TMS570LS31X (C) is selected: CODE COMPOSER STUDIO V4.2.4 ON TI TMS570LS31XHERCULES USB STICK 93 Note that this template contains startup files that were generated with TI’s Halcogen code generation tool. The startup code included represent the minimum initialization required to configure the processor registers, memory, stack, etc to allow the user to then jump to and execute the application main(). You will find the list of these startup files on the Tools => Options=> C/C++ Compiler integration tab. If you have generated a more extensive list of startup files to initialize other peripherals/components of ARM Cortex R4F processor for their application, then you should specify any extra startup files in VectorCAST on the compiler tab. CODE COMPOSER STUDIO V4.2.4 ON TI TMS570LS31XHERCULES USB STICK 94 Target Execution with CCS 4.2 on the TMS570LS31x USB Stick Code Composer Studio version 4.2 uses the script found at %VCAST_CCS_INSTALL_ DIR%\scripting\examples\loadti\loadti.bat to run the target executable. VectorCAST uses this same loadti.bat file to execute test cases and passes a target configuration file as a parameter to the loadti.bat command. VectorCAST provides the appropriate target configuration file (tms570LS31x_tgt.ccxml) for the TMS570LS31x USB stick as part of the VectorCAST release and it is copied to your test environment directory during unit test environment creation time. You can specify a different target by creating a new ccxml file for it. Inside Code Composer Studio 4.2, go to Target => New Target Configuration to select your processor and save that to a file. CODE COMPOSER STUDIO V4.2.4 ON TI TMS570LS31XHERCULES USB STICK 95 Note: The loadti.bat script cannot read a .ccxml file over a network drive. Also note that test case execution on the TMS570LS31X USB development stick requires downloading the target executable and burning into flash, which can take minutes. If the time required to execute your first test case seems excessive it is recommended you execute the test case in debug mode to verify that you are at least connecting to the target, burning the image into flash, and executing the startup code and getting to main(). The user should have a good idea of the length of time required to successfully burn an image into flash on the device from working with their own application outside of VectorCAST and interfacing directly through your CCS development environment. During normal test case execution you will see the following progress dialog box displayed while the harness is running on the target. CODE COMPOSER STUDIO V4.2.4 ON TI TMS570LS31XHERCULES USB STICK 96 Occasionally the target loading will fail on the hardware, and VectorCAST will exit out of the loadti.bat file and the test case will obviously fail as a result. The user can get debug information from VectorCAST by selecting Environment => View => Target Output after such failures. See the output below as an example of the case where the download and Flash burning fails. The recommended action for such cases involves rebooting the target and retrying the program download. If the failure persists, be sure that you can connect from inside CCS, while not running VectorCAST, to determine if you have target connection or hardware problems. Special Considerations for Some CCS v4.x Targets Some of the VectorCAST templates for Code Composer v4.x targets require using the VectorCAST- supplied loadti.bat file and main.js JavaScript instead of those provided in the Texas Instruments release. The VectorCAST CCS templates that do require these files will copy all the required script files and JavaScripts from the $(VECTORCAST_DIR/DATA/code_composer directory into your test environment directory and will reference these versions as opposed to the TI versions. This is not required for the TMS570LS31X USB target template. Target Debug Execution in Code Composer Studio 4.x Code Composer Studio 4.x uses the Eclipse framework to support its debugging environment. When you execute a test with debug by right-clicking a selected test case and choosing “Execute With Debug,” VectorCAST will automatically popup a dialog box with instructions for how to download and run the harness on your target using Eclipse. Below is the dialog box you will see the first time you run a test with debug; subsequent debug test case executions in the same unit test environment will not show this dialog box. CODE COMPOSER STUDIO V4.2.4 ON TI TMS570LS31XHERCULES USB STICK 97 The following screen shots itemize the sequence of the events described above. First you will be prompted to select a workspace. On your first invocation of the Eclipse debugger environment you will need to create a NewTargetConfiguration by selecting Target => NewTargetConfiguration… from the pull-down menu inside the debugger environment, where you will define the Connection and Device type as shown in the screen shot below. Be sure to select the TMS570LS3137 as the target device. CODE COMPOSER STUDIO V4.2.4 ON TI TMS570LS31XHERCULES USB STICK 98 Save this target configuration and on subsequent debug sessions you will simply select this target debug configuration that you have already created from the Debug history pull-down menu. There are other target configuration options that you can modify to customize the target debug session, which you can access by selecting Target->Debug… from inside Eclipse development environment. Recommended debug options include specifying “Fast verification”, programming only the necessary flash sectors instead of the entire flash, and deselecting any Auto Run Options which usually defaults to running to main() on program load or restart. This will allow you to debug the startup code if necessary. You can see a sample of these debug options in the screenshots below for the TI XDS100v2 USB Emulator embedded on this target. CODE COMPOSER STUDIO V4.2.4 ON TI TMS570LS31XHERCULES USB STICK 99 This particular target configuration specifies automatically connecting to the target upon launching the debugger. After successfully connecting to the target you should see the following screen in the debug session. CODE COMPOSER STUDIO V4.2.4 ON TI TMS570LS31XHERCULES USB STICK 100 Next you must download the executable and burn it into flash on the target by selecting Target => Load Program. Navigate to your test environment directory and select the UUT_INTE.out image file as shown in the example below. This can take a few minutes, if you expand the Loading dialog window by clicking the “Details>>” button you can see the progress on the flash erase and reprogramming as it occurs with the percentage complete displayed in the lower right corner of the debug window. CODE COMPOSER STUDIO V4.2.4 ON TI TMS570LS31XHERCULES USB STICK 101 Assuming you have deselected the Auto Run Options for this debug session, then upon completion of the program load you will see the first line of _c_int00() displayed in the debugger window as shown below. At this point you may begin single stepping, setting breakpoints, examining variables and memory as you would in any normal debug session and verify the startup code before jumping to main at the end of the _c_int00() routine. When you have run to completion of the harness executable you will see the “VCAST is Done!” message displayed in the console window and the main thread has reached the loader_exit() function as shown below. Now you can simply exit the debugger by selecting “Terminate All” button in the debugger, closing the debugger window and control will be released back to VectorCAST where you will see your test results displayed. CODE COMPOSER STUDIO V4.2.4 ON TI TMS570LS31XHERCULES USB STICK 102 CODEWARRIOR DSP56800E 103 CodeWarrior DSP56800E Configuration This section provides details about configuring VectorCAST to integrate with Freescale’s CodeWarrior C compiler and debugger/simulator for Motorola’s DSP56800E. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “CodeWarrior DSP56800e” under the “Compiler” drop-down menu, as shown here: Second, ensure that the directories containing the CodeWarrior binaries are included in your PATH environment variable. These are most commonly C:\Program Files\Freescale\CodeWarrior\DSP56800x_ EABI_Tools\command_line_tools and C:\Program Files\Freescale\CodeWarrior\bin, but may be slightly different on your particular system. Note: The default CodeWarrior installation adds only the first of these directories to your system %PATH% variable - you must add the second one manually. To specify a different CodeWarrior installation directory: 1. On the Preprocessor/Compiler tab, change the Library Include Directory entry to match the location of the “M56800E Support” directory on your system. Use DOS formatted short-paths (8.3/no spaces). CODEWARRIOR DSP56800E 104 2. On the Linker tab, change the Linker Options entry to match the location of the “M56800E Support” directory on your system. Use DOS formatted short-paths (8.3/no spaces). 3. Click Apply to save the changes. The default command settings should be sufficient to run the Tutorial example in the VectorCAST/C User’s Guide, and it is strongly recommended that you do so before trying to test your application code. It is your responsibility to customize these settings for your particular device and development environment. This potentially includes modifying or specifying an alternative linker command file. The default mwcw_56800e_sim_linker.cmd file is located in VectorCAST’s installation DATA directory (most commonly C:\VCAST\DATA). Whichever command file is used must accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note: The size of the test harness is not static – it is dependent on the size and composition of the specific code under test. Refer to the CodeWarrior documentation for more information on customizing linker command files. To specify a linker command file other than the default, edit the Linker Options field on the Linker tab. Use DOS formatted short-paths (8.3/no spaces). CODEWARRIOR DSP56800E 105 The “Preprocessor/Compiler” tab contains the compiler commands and options that will be used to compile the test harness. The “Linker” tab contains the linker commands and options that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. Specific details and discussion of the options that mwcc56800e.exe and mwld56800e.exe accept is outside the scope of this document. Refer to CodeWarrior’s compiler and linker documentation for more information on this topic. Lastly, click OK to save the settings and close the options dialog. Target Execution For execution with the CodeWarrior IDE simulator/debugger, VectorCAST will create a Tcl control script in the environment directory, and will automatically execute the “Debugger Command” that is set in the VectorCAST Compiler Options dialog. The script file that VectorCAST creates is called “mwcw_ execute.tcl” and is similar to the following: cd C:/vcast_tutorial/DEMO/ if { ![file exists UUT_INTE.elf.mcp] } { project -o UUT_INTE.elf } debug UUT_INTE.elf.mcp bp all off source mwcw_user_exe.tcl go kill project -c quitIDE The above script runs the harness executable UUT_INTE.elf in the CodeWarrior IDE debugger. It is loaded upon startup of the IDE, first setting the working directory to the current environment directory. Next it checks for the existence of a .mcp project file associated with the executable to be run – if the CODEWARRIOR DSP56800E 106 check fails, the script will create a new project based on the executable and you’ll be prompted to choose a debugger: To run on the 56800E Simulator, choose that option and click OK. CodeWarrior will then build a new project based around UUT_INTE.elf, open a debug session for it (named UUT_INTE.elf.mcp), and clear any breakpoints that might exist from previous invocations. The script will then load a second Tcl script, named mwcw_user_exe.tcl. This file is initially empty and provides you with an opportunity to customize the target execution process. If necessary, add Tcl and/or CodeWarrior commands to this file and they will get run just after the executable is loaded. Finally, the debugger will run the executable, kill the debug session when it halts, close the project and exit the IDE. All test result data is automatically passed back to VectorCAST, which will display the results of the executed test. You will have to make a debugger selection via the Choose Debugger dialog for each of the three VectorCAST harness executables that need to run: DATA_IF_.elf (during the build new environment process), UUT_INTE.elf (normal test case execution) and UUT_INST.elf (test case execution when coverage is enabled). Once each of these executables has a project associated with it, target execution is completely automatic, requiring no user interaction. Target Debug Execution Test Execution with Debug functions similarly to normal execution, except the “go” command to execute the downloaded executable is never issued. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. The Tcl script used to execute with debug is named mwcw_user_dbg.tcl. You can customize this script to store frequently used breakpoints/debugging commands conveniently for repeated debugging sessions. CODEWARRIOR DSP56800E 107 To stop debugging, kill the debug thread and exit CodeWarrior. If you allow the execution to reach the end of the driver main program, all VectorCAST execution results will be generated when you exit CodeWarrior. CODEWARRIOR STARCORE SC140E 108 CodeWarrior StarCore SC140e Configuration This section provides details about configuring VectorCAST to integrate with Freescale’s CodeWarrior compiler and debugger/simulator for StarCore SC140e. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “CodeWarrior StarCore SDMA” or “CodeWarrior StarCore SDMA (C++)” under the “Compiler” drop- down menu, as shown here: Second, ensure that the directory containing the CodeWarrior binaries is included in your PATH environment variable. This is most likely C:\Program Files\Freescale\CodeWarrior for StarCore And SDMA 1.2\StarCore_Support\compiler\bin, but may be slightly different on your particular system. Third, set your SCTOOLS_HOME and SC100_HOME environment variables to your StarCore installation directory. This is most likely C:\Program Files\Freescale\CodeWarrior for StarCore And SDMA 1.2\StarCore_Support\compiler, but again may be slightly different on your particular system. To specify a different CodeWarrior installation directory: 1. On the Preprocessor/Compiler tab, change the Library Include directories entry to match the location of the “StarCore_Support\compiler\include” directory on your system. Use DOS formatted short- paths (8.3/no spaces). CODEWARRIOR STARCORE SC140E 109 2. Click Apply to save the changes. The default command settings should be sufficient to run the Tutorial example in the VectorCAST/C++ User’s Guide, and it is strongly recommended that you do so before trying to test your application code. It is your responsibility to customize these settings for your particular device and development environment. The “Preprocessor/Compiler” tab contains the compiler commands and options that will be used to compile the test harness. The “Linker” tab contains the linker commands and options that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. Specific details and discussion of the options that scc.exe accepts is outside the scope of this document. Refer to CodeWarrior’s compiler and linker documentation for more information on this topic. Lastly, click OK to save the settings and close the options dialog. Target Execution For execution with the CodeWarrior IDE simulator/debugger, VectorCAST runs the execute command specified in the Tools => Options dialog, C/C++ tab. By default, the execute command is: runsim -d sc140e If different options are needed for the command line simulator, make a change to the Execute command. Target Debug Execution For execution with the CodeWarrior IDE simulator/debugger, VectorCAST will create a Tcl control script in the environment directory, and will automatically execute the “Debugger Command” that is set in the Tools => Options dialog, C/C++ tab, Debug sub-tab. The script file that VectorCAST creates is called “mwcw_debug.tcl” and is similar to the following: CODEWARRIOR STARCORE SC140E 110 cd C:/vcast_tutorial/DEMO/ if { ![file exists UUT_INTE.EXE.mcp] } { project -o UUT_INTE.EXE } debug UUT_INTE.EXE.mcp bp all off source mwcw_user_dbg.tcl The above script runs the harness executable UUT_INTE.EXE in the CodeWarrior IDE debugger. It is loaded upon startup of the IDE, first setting the working directory to the current environment directory. Next it checks for the existence of a .mcp project file associated with the executable to be run – if the check fails, the script will create a new project based on the executable and you’ll be prompted to choose a debugger: To run on the SC100 Simulator, choose that option and click OK. Next you will get a dialog asking you to find the startup__startup_.asm file. CODEWARRIOR STARCORE SC140E 111 Click Cancel. On the File Not Found dialog, select “Ignore all unknown files” and click OK. CodeWarrior will then build a new project based around UUT_INTE.EXE, open a debug session for it (named UUT_INTE.EXE.mcp), and clear any breakpoints that might exist from previous invocations. The script will then load a second Tcl script named mwcw_user_dbg.tcl. This file is initially empty and provides you with an opportunity to customize the target execution process. If necessary, add Tcl and/or CodeWarrior commands to this file and they will get run just after the executable is loaded. To stop debugging, kill the debug thread and exit CodeWarrior. If you allow the execution to reach the end of the driver main program, all VectorCAST execution results will be generated when you exit CodeWarrior. When the "STDIO: Shared Console" window displays “VCAST is Done!”, the driver has finished. You will have to make a debugger selection via the Choose Debugger dialog for each of the two VectorCAST harness executables that need to run: l UUT_INTE.EXE (normal test case execution) CODEWARRIOR STARCORE SC140E 112 l UUT_INST.EXE (test case execution when coverage is enabled). Once each of these executables has a project associated with it, target execution is completely automatic, requiring no user interaction. CODEWARRIOR FOR HC12 113 CodeWarrior for HC12 Configuration This section provides details about configuring VectorCAST to integrate with Freescale’s CodeWarrior C/C++ compiler and debugger for targets or simulators of the HC12(X) family of processors. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “CodeWarrior HC12” under the “Compiler” drop-down menu, as shown here: Second, ensure that the directory containing the CodeWarrior binaries is included in your PATH environment variable. This is most commonly C:\Program Files\Freescale\Codewarrior for HC12 V4.6\Prog, but may be slightly different on your particular system. To specify a different CodeWarrior installation directory: 1. On the Preprocessor/Compiler tab, change the Default search list for Wizard entry to match the location of the lib\hc12c\include directory on your system. Use DOS formatted short-paths (8.3/no spaces). CODEWARRIOR FOR HC12 114 2. On the Linker tab, change the Linker Options entry to match the location of the lib/hc12c/lib directory on your system. Use DOS formatted short-paths (8.3/no spaces). 3. On the Compiler Integration tab, change the “Startup file” entry to match the location of the startup files listed. (e.g. start12.c, mc9s12xdt512.c, termio.c, and datapage.c) CODEWARRIOR FOR HC12 115 4. Click Apply to save the changes. The default command settings should be sufficient to run the Tutorial example in the VectorCAST Interactive Tutorials, and it is strongly recommended that you do so before trying to test your application code. It is your responsibility to customize these settings for your particular device and development environment. This potentially includes modifying the linker command file. The default hc12_link.prm file and hc12_link_cpp.prm file for C++ are located in VectorCAST’s installation DATA\codewarrior directory (most commonly C:\VCAST\DATA\codewarrior). Based on the target or simulator selected, the appropriate linker file (*.prm), debugger command files (*.cmd), and project file (project.ini) will get copied to your test environment directory as you create the new environment from within VectorCAST. The linker settings used must accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note: The size of the test harness is not static – it is dependent on the size and composition of the specific code under test. Refer to the CodeWarrior documentation for more information on customizing linker command files. If you change your compile options, you need to make the corresponding changes to the Parser flags section of the Misc tab. Each compiler option must also be specified with the --active_option flag. For example, if you add –Or to your compile command, add --active_option =-Or to your parser flags. CODEWARRIOR FOR HC12 116 The CodeWarrior project file may also need customization. The templates for this file are in $VECTORCAST_DIR\DATA\codewarrior, and are named to indicate the target type and whether or not it is a simulation. (e.g. hc12_s12xdp_project.ini, hc12_s12xdp_sim_project.ini, hc12_s12xep_project.ini ) The appropriate file is copied to the environment directory and renamed project.ini. The “Preprocessor/Compiler” tab contains the compiler commands and options that will be used to compile the test harness. The “Linker” tab contains the linker commands and options that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. Specific details and discussion of the options that chc12.exe and linker.exe accept is outside the scope of this document. Refer to CodeWarrior’s compiler and linker documentation for more information on this topic. Lastly, click OK to save the settings and close the options dialog. Banked Memory Model There are a few things to be aware of when configuring your HC12 test environment using the banked memory model. The CodeWarrior HC12 S12XEP100 PROTECH compiler template was developed for a custom RSP on a customer board (Protech) that utilizes the banked memory model and is a good example of the settings required to enable the use of the banked memory model. In order to enable VectorCAST to support the banked memory model the user must set an environment variable named VCAST_ CUSTOM_QUALIFIERS and add a #define variable of the same name that will insert a pointer qualifier in the declaration of pointers that ensures that objects allocated in RAM pages to be properly addressed. Adding the following #define in the Tools => Options dialog, C/C++ tab, Preprocess/Compiler tab, “Defined variables” is an example of such: VCAST_CUSTOM_QUALIFIERS=__far Other configuration related to the use of the banked memory model includes the following items: CODEWARRIOR FOR HC12 117 1. set the “-Mb” compiler switch to compile for the banked memory model 2. select the appropriate lib in the .prm file to link into your application. Code Warrior provides a list and description of the libraries available and how they were built in the It is also very important to note that default RAM, as defined in the .prm file, cannot get mapped into RAM pages. The following example entries from the .prm file show a valid mapping and the aforementioned illegal mapping for DEFAULT_RAM. If you make this illegal mapping, it will compile and link successfully, but fail in unpredictable fashion at run time. /* non-paged RAM */ RAM = READ_WRITE 0x2000 TO 0x3FFF; /* paged RAM: 0x1000 TO 0x1FFF; addressed through RPAGE */ RAM_F0 = READ_WRITE 0xF01000 TO 0xF01FFF; RAM_F1 = READ_WRITE 0xF11000 TO 0xF11FFF; VALID => DEFAULT_RAM INTO RAM; NOT VALID => DEFAULT_RAM INTO RAM, RAM_F0, RAM_F1; Note that if you get an “out of allocation space” for RAM linker error, you must relocate some of the objects that are being allocated into default RAM by the linker into RAM pages to allow the application to link properly. This can be done by identifying large data objects and using #pragmas to direct them to get stored into RAM pages instead of non-paged RAM. See the example below. #pragma DATA_SEG __RPAGE_SEG PAGED_RAM unsigned int LargeDataArray[1000]; #pragma DATA_SEG DEFAULT Target Execution Because the HC12 board uses a COM port connection, the $VECTORCAST_DIR\IO\comreader.exe executable is used to record the results of target execution. The default settings are port "COM1", baud 9600, no parity, 8 data bits, and 1 stop bit. If you need other settings, you can specify a configuration file with the VCAST_SERIAL_CFG environment variable. The file specified by VCAST_SERIAL_CFG should have each option on a separate line. For example, to use the COM2 port, you could use these settings: COM2 9600 N 8 1 The comreader is started before test execution and stops when the debugger exits. Remember to close any other applications, such as HyperTerminal, that are reading from the same port, before executing tests. For execution with the CodeWarrior IDE debugger, VectorCAST will create a control script in the environment directory, and will automatically execute the “Debugger Command” that is set in the VectorCAST Compiler Options dialog. The script file that VectorCAST creates is called hc12_exec.cm” CODEWARRIOR FOR HC12 118 and is similar to the following: load "hc12.abs" AUTOERASEANDFLASH bs vCAST_END g wait ;s exit The above script runs the harness executable hc12.abs in the CodeWarrior IDE debugger. It is loaded upon startup of the IDE. The debugger will start the executable, wait for execution to complete, and exit the IDE. The template for the script is in $VECTORCAST_DIR\DATA\codewarrior. If you change the template, any new environments you build will use the modified version. Note that the script must use Windows line terminations. All test result data is automatically passed back to VectorCAST, which will display the results of the executed test. Target Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. The script used to execute with debug is named hc12_debug.cmd. You can customize this script to store frequently used breakpoints/debugging commands conveniently for repeated debugging sessions. The template for the script is in $VECTORCAST_DIR\DATA\codewarrior. If you change the template, any new environments you build will use the modified version. Note that the script must use Windows line terminations. To stop debugging, kill the debug thread and exit CodeWarrior. If you allow the execution to reach the end of the driver main program, all VectorCAST execution results will be generated when you exit CodeWarrior. CODEWARRIOR FOR HCS08 119 CodeWarrior for HCS08 Configuration This section provides details about configuring VectorCAST to integrate with Freescale’s CodeWarrior C/C++ compiler and debugger for targets or simulators of the HCS08 family of processors. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “CodeWarrior HCS08 SIM 9S08AC128” under the “Compiler” drop-down menu, as shown below. Second, ensure that the directory containing the CodeWarrior binaries is included in your PATH environment variable. This is most commonly C:\Program Files\Freescale\CodeWarrior for Microcontrollers V6.2\prog, but may be slightly different on your particular system. To specify a different CodeWarrior installation directory: 1. On the Preprocessor/Compiler tab, change the Default search list for Wizard entry to match the location of the \lib\hc08c\include directory on your system. Use DOS formatted short-paths (8.3/no spaces). CODEWARRIOR FOR HCS08 120 2. On the Linker tab, change the Linker Options entry to match the location of the lib/hc08c/lib directory on your system. Use DOS formatted short-paths (8.3/no spaces). 3. On the Compiler Integration tab, change the “Startup file” entry to match the location of the startup files listed. (e.g. start08.c, mc9s08ac128.c, and termio.c) CODEWARRIOR FOR HCS08 121 The text for the Startup file by default reads: $(VECTORCAST_DIR)\DATA\codewarrior\start08.c C:\PROGRA~1\FREESC~1\CODEWA~1.2\lib\hc08c\device\src\mc9s08ac128.c $(VECTORCAST_ DIR)\DATA\codewarrior\termio.c 4. Click Apply to save the changes. The default command settings should be sufficient to run the Tutorial example in the VectorCAST Interactive Tutorials, and it is strongly recommended that you do so before trying to test your application code. It is your responsibility to customize these settings for your particular device and development environment. This potentially includes modifying the linker command file. The default hc08_link.prm file is located in VectorCAST’s installation DATA\codewarrior directory (most commonly C:\VCAST\DATA\codewarrior). Based on the target or simulator selected, the appropriate linker file (*.prm), debugger command files (*.cmd), and project file (project.ini) will get copied to your test environment directory as you create the new environment from within VectorCAST. The linker settings used must accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note: The size of the test harness is not static – it is dependent on the size and composition of the specific code under test. Refer to the CodeWarrior documentation for more information on customizing linker command files. If you change your compile options, you need to make the corresponding changes to the Parser flags section of the Misc tab. Each compiler option must also be specified with the --active_option flag. For example, if you add –Or to your compile command, add --active_option =-Or to your parser flags. CODEWARRIOR FOR HCS08 122 The text for the Parser flags by default reads: -w --c --code_warrior --code_warrior_version=hcs08 --unsigned_chars --define_macro=__HIWARE__ --define_macro=__MWERKS__=1 --define_macro=__BIG_ENDIAN__ --define_macro=__PRODUCT_HICROSS_PLUS__ --define_macro=__VERSION__=5025 --define_macro=__SIZE_T_IS_UINT__ --define_macro=__PTRDIFF_T_IS_INT__ --define_macro=__WCHAR_T_IS_UCHAR__ --define_macro=__ELF_OBJECT_FILE_FORMAT__ --define_macro=__BITFIELD_LSBIT_FIRST__ --define_macro=__BITFIELD_MSBYTE_FIRST__ --define_macro=__BITFIELD_MSWORD_FIRST__ --define_macro=__BITFIELD_TYPE_SIZE_REDUCTION__ --define_macro=__PLAIN_BITFIELD_IS_SIGNED__ --define_macro=__CHAR_IS_UNSIGNED__ --define_macro=__CHAR_IS_8BIT__ --define_macro=__SHORT_IS_16BIT__ --define_macro=__INT_IS_16BIT__ --define_macro=__ENUM_IS_16BIT__ --define_macro=__ENUM_IS_SIGNED__ --define_macro=__LONG_IS_32BIT__ --define_macro=__LONG_LONG_IS_32BIT__ --define_macro=__FLOAT_IS_IEEE32__ --define_macro=__DOUBLE_IS_IEEE64__ --define_macro=__LONG_DOUBLE_IS_IEEE64__ CODEWARRIOR FOR HCS08 123 --define_macro=__LONG_LONG_DOUBLE_IS_IEEE64__ --define_macro=__VTAB_DELTA_IS_16BIT__ --define_macro=__PTRMBR_OFFSET_IS_16BIT__ --define_macro=__HC08__ --define_macro=__HCS08__ --define_macro=__BANKED__ --define_macro=__MMU__ The CodeWarrior project file may also need customization. The templates for this file are in $VECTORCAST_DIR\DATA\codewarrior, and are named to indicate the target type and whether or not it is configured for a simulator connection, such as hcs08_9s08ac128_sim_project.ini. The appropriate file is copied to the environment directory and renamed project.ini. The “Preprocessor/Compiler” tab contains the compiler commands and options that will be used to compile the test harness. The “Linker” tab contains the linker commands and options that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. Specific details and discussion of the options that chc08.exe and linker.exe accept is outside the scope of this document. Refer to CodeWarrior’s compiler and linker documentation for more information on this topic. Lastly, click OK to save the settings and close the options dialog. Target Simulator Execution VectorCAST supports the hcs08 simulator and execution of a test case on the simulator is performed by right-clicking on the desired test case and selecting “Execute.” This will cause VectorCAST to invoke the debugger (hiwave.exe). Note: Because Freescale does not support the Terminal component of the debugger for the hcs08 family, VectorCAST must capture the test data using the buffered I/O mode and then write the captured buffer data out to a file that VectorCAST will then examine for the expected results. The buffered I/O mode is automatically selected when you select the HCS08 target template. You can confirm that this mode is properly selected by examining the Target tab under the Options page as shown below. CODEWARRIOR FOR HCS08 124 The writing of the buffered test data is performed through the use of special commands inside the debugger cmd files. The necessary command files are provided by VectorCAST and copied to your test environment, such as hcs08_sim_debug.cmd, hcs08_sim_exec.cmd, and hcs08_fcs_postload.cmd. The appropriate command file is passed to the debugger when it is invoked through the “Execute” or “Execute with Debug” methods. No special action is required on the part of the user. Target Simulator Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. The script used to execute with debug is named hcs08_sim_debug.cmd. You can customize this script to store frequently used breakpoints/debugging commands conveniently for repeated debugging sessions. The template for the script is in $VECTORCAST_DIR\DATA\codewarrior. If you change the template, any new environments you build will use the modified version. Note that the script must use Windows line terminations. You will notice that when the debugger is opened, that there is a wait loop cycling in the command window. This is required for VectorCAST to know when to write out the buffered data, whereby it waits for a flag to be set in the harness code that indicates that all the required test data has been captured, and it can write out to the file. The command window data will look like that shown below. CODEWARRIOR FOR HCS08 125 When you have successfully reached the end of test case execution which is indicated by reaching the vCAST_END breakpoint, then the command window loop will end and display the following: To stop debugging, kill the debug thread and exit CodeWarrior. If you allow the execution to reach the end of the driver main program, all VectorCAST execution results will be generated when you exit CodeWarrior. CODEWARRIOR FOR MPC 5554 126 CodeWarrior for MPC 5554 Configuration This section provides details about configuring VectorCAST to integrate with Freescale’s CodeWarrior compiler for MPC chips. During the last revision of this text, the only chip supported is the MPC5554 through Lauterbach TRACE32 debugger. However, integration with other chips (MPC555x, MPC55xx, MPC8xx and others), either through the TRACE32 debugger or CodeWarrior’s integrated debugger, is quite possible. To inquire about the latest chips supported or to arrange for other physical targets to be supported, please contact your VectorCAST representative. VectorCAST uses the command line interface of Code Warrior to compile the test harness. To enable it, a number of environment variables must be set properly. An example of a DOS script setting these variables could look like this. set PATH=C:\Program Files\Freescale\CodeWarrior for MPC55xx V2.4\PowerPC_EABI_ Tools\Command_Line_Tools;%PATH% REM This must link to the compiler’s header files set MWCIncludes=C:\Program Files\Freescale\CodeWarrior for MPC55xx V2.4\PowerPC_EABI_ Support\MSL\MSL_C\PPC_EABI\Include; set MWCIncludes=C:\Program Files\Freescale\CodeWarrior for MPC55xx V2.4\PowerPC_EABI_ Support\MSL\MSL_C\MSL_Common\Include;%MWCIncludes% set MWCIncludes=C:\Program Files\Freescale\CodeWarrior for MPC55xx V2.4\PowerPC_EABI_ Support\MSL\MSL_C\MSL_Common_Embedded\Include;%MWCIncludes% set MWCIncludes=C:\Program Files\Freescale\CodeWarrior for MPC55xx V2.4\PowerPC_EABI_ Support\Runtime\Include;%MWCIncludes% REM This must link to the libraries and library files associated with the headers set MWLibraries=C:\Program Files\Freescale\CodeWarrior for MPC55xx V2.4\PowerPC_EABI_ Support\Runtime\Lib set MWLibraries=C:\Program Files\Freescale\CodeWarrior for MPC55xx V2.4\PowerPC_EABI_ Support\MSL\MSL_C\PPC_EABI\Lib;%MWLibraries% set MWLibraryFiles=C:\Program Files\Freescale\CodeWarrior for MPC55xx V2.4\PowerPC_EABI_ Support\Runtime\Lib\Runtime.PPCEABI.S.UC.a set MWLibraryFiles=C:\Program Files\Freescale\CodeWarrior for MPC55xx V2.4\PowerPC_EABI_ Support\MSL\MSL_C\PPC_EABI\Lib\MSL_C.PPCEABI.bare.S.UC.a;%MWLibraryFiles% In addition, if your code includes assembly code, other environment variables must be set. Please consult your CodeWarrior documentation to learn how. Also, if you are using Lauterbach TRACE32 to execute the test harness on the board, the path to Lauterbach TRACE32 must become part of the PATH environment variable as follows: set PATH=C:\T32;%PATH% You should remember to either (1) set these environment variables permanently in your OS or (2) set these temporarily in an OS shell. In the latter case, remember to launch VectorCAST from within that shell. Thereafter, select the appropriate template from VectorCAST/C++. CODEWARRIOR FOR MPC 5554 127 In VectorCAST, just select the appropriate compiler template (Compilers => CodeWarrior => MPC). Please note that depending on your installation, the template may need amendments. Particularly, the library includes (all three of them) and the link to certain startup files will need to be changed if you are using any other version of the compiler except 2.4 and/or if you installed the compiler in a different directory than the default one. It is your responsibility to customize these settings for your particular device and development environment. Please note that these changes will be saved as long as you will be using the same working directory. For more information about this, please contact your Vector Software representative. Target Execution At this point in time, the only template provided by default will execute the harness using the TRACE32 debugger. Integration to CodeWarrior’s integrated debugger is also possible. Please contact your Vector Software representative to learn more. Upon successful compilation and linkage, VectorCAST will automatically launch (1) comreader.exe (a part of VectorCAST), and (2) the TRACE32 debugger interface. It will execute the program automatically, and then shut down TRACE32. The comreader program will capture any data sent to the host’s serial port and make it available to VectorCAST. Thus, a serial cable must be connected between the board and the host. If the host does not have a serial port, a serial-to-USB cable can be used. Because this integration uses a COM port connection, the $VECTORCAST_DIR\IO\comreader.exe CODEWARRIOR FOR MPC 5554 128 executable is used to record the results of target execution. The default settings are port "COM1", baud 9600, no parity, 8 data bits, and 1 stop bit. If you need other settings, you can specify a configuration file with the VCAST_SERIAL_CFG environment variable. The file specified by VCAST_SERIAL_CFG should have each option on a separate line. For example, to use the COM2 port, you could use these settings: COM2 9600 N 8 1 The comreader is started before test execution and stops when the debugger exits. Remember to close any other applications, such as HyperTerminal, that are reading from the same port, before executing tests. Target Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. Launching a debug execution of the test harness under CodeWarrior will launch the TRACE32 interface. A breakpoint is already set at the end of the test harness for your convenience. Once finished, merely close the instance of TRACE32 that VectorCAST launched and the results of the test will be read automatically by VectorCAST. If the test harness is not allowed to run until the end, an error may occur. CODEWARRIOR FOR MPC 8315 129 CodeWarrior for MPC 8315 This section provides details about configuring VectorCAST to integrate with Freescale’s CodeWarrior compiler for the EPPC MPC8315E chip. This particular RSP is designed to support interfacing with the Freescale MPC8315 RDB evaluation board using a CodeWarrior USB CodeTAP for a connection to the target board. The Freescale compiler version required is the Freescale CodeWarrior for Power Architecture v8.8. In addition the user must install and run the v8.8.5 patch from Freescale. The downloaded compiler and patch executable names are provided below. CW_Power_Architecture_V8.8_Build_80229.exe PA_8.8.5_110607.exe It is important to install the patch, otherwise you will likely have problems connecting to the target. There were several versions of the drivers for the CodeWarrior USB CodeTAP available, not all of which worked, so details about the driver install and verification are provided in the following section to help ensure proper driver installation. CodeWarrior USB TAP Installation Note: This installation was tested on a Windows XP machine; other platforms and OSs may require a slightly different driver install procedure. 1. Install CodeWarrior for Power Architecture v8.8 from Freescale. 2. Run the v8.8.5 patch update (PA_8.8.5_110607.exe). 3. Now run the setup.bat from C:\Program Files\Freescale\CodeWarrior PA V8.8\ccs\drivers\usb directory. See the results of that operation in the DOS screenshot below. This operation results in the “Device Driver Installation Wizard” getting run to install the LibUSB driver. Now you can plug in the CodeWarrior USB TAP into an available USB port on the host PC and plug the other end into the target board with target power applied. See the Freescale user guide for information on properly connecting the flat ribbon connector to the target. CODEWARRIOR FOR MPC 8315 130 The Windows XP machine used for testing recognized the device being plugged in and invoked the “Found New Hardware Wizard” as shown in the screenshots below. Do not install software automatically, but rather manually point to the driver install directory. After clicking Next, choose “Don’t search. I will choose the driver to install.” Click Next again, and choose “Have Disk...”: Point to the C:\Program Files\Freescale\CodeWarrior PA V8.8\ccs\drivers\usb\x32 directory which contains the usbtap.inf file needed and the driver install will begin as shown below. CODEWARRIOR FOR MPC 8315 131 Now you can bring up the device manager and you should see the CodeWarrior USB TAP appear under “LibUSB-Win32 Devices.” At this point you have successfully installed the drivers for the CodeWarrior USB TAP. CODEWARRIOR FOR MPC 8315 132 Troubleshooting When VectorCAST attempts to execute a test case, it must connect to the target through the USB TAP, download the harness executable, and then run that executable. If VectorCAST has any trouble connecting to the target during this process you may see an error dialog box displayed like the one shown below. To resolve such connectivity issues try pressing the power button on the target to power cycle the board. After a minute or so you can try to rerun the test case and VectorCAST will attempt to reconnect to the target. To monitor the reboot progress of the board, you can temporarily bring up the HyperTerminal windows application to display the serial port output from the target. Wait for the board to boot up and get to the “freescale login:” prompt. Note: This won’t work when just pressing the “reset” button on the target; you have to power cycle the board by pressing the “power” button in the back of the 8315 RDB unit. Once the board has rebooted and displayed the “freescale login:” prompt, you must disconnect the HyperTerminal connection so that VectorCAST can connect to the serial port of the board during test case execution. Now try rerunning the test case. Below is a snapshot of the serial port output from the board after power cycling the board and the default Linux kernel installed on the evaluation board reboots. CODEWARRIOR FOR MPC 8315 133 Note: Don’t forget to disconnect this HyperTerminal connection after you have demonstrated you can successfully connect to the target. VectorCAST uses this serial port to collect test result data via another comreader.exe application that VectorCAST automatically invokes during test case execution. If there is another application, such as HyperTerminal, connected to the serial port at the time of test case execution, then your test case will fail. To inquire about the latest chips supported or to arrange for other physical targets to be supported, please contact your VectorCAST sales representative. Configuration VectorCAST uses the command line interface of Code Warrior to compile and link the test harness. To enable it, a number of environment variables must be set properly. An example of a DOS script setting these environment variables is shown in the figure below. set VCAST_SERIAL_CFG=C:\serial_cfg.txt set VCAST_CW_INSTALL_DIR=C:\PROGRA~1\FREESC~1\CODEWA~1.8 set path=%VCAST_CW_INSTALL_DIR%\bin;%PATH% set PATH=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Tools\Command_Line_Tools;%PATH% set PATH=C:\Tcl\bin;%PATH% set MWCIncludes=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\MSL\MSL_C\PPC_EABI\Include; set MWCIncludes=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\MSL\MSL_C\MSL_ Common\Include;%MWCIncludes% set MWCIncludes=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\MSL\MSL_C\MSL_Common_ Embedded\Include;%MWCIncludes% set MWCIncludes=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\Runtime\Include;%MWCIncludes% set MWLibraries=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\Runtime\Lib;%MWLibraries% set MWLibraries=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\MSL\MSL_C\PPC_ EABI\Lib;%MWLibraries% CODEWARRIOR FOR MPC 8315 134 set MWLibraryFiles=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_ Support\Runtime\Lib\Runtime.PPCEABI.H.UC.a;%MWLibraryFiles% set MWLibraryFiles=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\MSL\MSL_C\PPC_EABI\Lib\MSL_ C.PPCEABI.bare.H.UC.a;%MWLibraryFiles% set MWLibraryFiles=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_ Tools\CodeWarriorTRK\Transport\processor\ppc\serial\8315_RDB_serial\Bin\UART1_8315_ RDB.UC.a;%MWLibraryFiles% You should either set these environment variables permanently in your operating system or set these temporarily in a system shell. In the latter case, remember to launch VectorCAST from within that shell. After starting VectorCAST, select the appropriate template from VectorCAST/C++. For a unit test environment for the CodeWarrior MPC8315 RDB evaluation board, go to the Tools => Options dialog, C/C++ tab. Select Compilers => CodeWarrior => EPPC => MPC8315 => C. Note: Depending on your installation, the template may need amendments to default paths. Particularly, the library includes and the link to certain startup files will need to be changed if you installed your Freescale CodeWarrior PA v8.8 somewhere other than the default directory as shown below. It is your responsibility to customize these settings for your particular device and development environment. Please note that these changes will be saved as long as you will be using the same working directory. For more information about this, please contact your Vector Software representative. Target Execution The test harness image will be downloaded and executed on the target using the CodeWarrior debugger. CODEWARRIOR FOR MPC 8315 135 Upon successful compilation and linkage, VectorCAST will automatically launch the comreader.exe program during test case execution. The comreader.exe program will capture any data sent to the host’s serial port and make it available to VectorCAST. A serial cable must be connected between the board and the host. If the host does not have a serial port, a serial-to-USB cable can be used. Connect the provided serial port cable to the DB15 connector on the back of the MPC8315 RDB unit labeled “RS-232-1”. Because this integration uses a COM port connection, the $VECTORCAST_DIR\IO\comreader.exe executable is used to record the results of target execution. The default settings are port "COM1", baud 9600, no parity, 8 data bits, and 1 stop bit. The specific settings required for the MPC8315 RDB board should be specified in a configuration file that is pointed to by the VCAST_SERIAL_CFG environment variable. The file specified by VCAST_ SERIAL_CFG should have each option on a separate line. For example, to use the COM8 port and 57600 baud, the settings for receiving serial port data from the MPC8315 RDB serial port are as follows: COM8 57600 N 8 1 The comreader is started before test execution and stops when the debugger exits. Remember to close any other applications, such as HyperTerminal, that are reading from the same port, before executing tests. Note that if you have a test case with abnormal termination, you may have to manually kill the comreader.exe process if the harness did not run to completion. You can use the Windows Task manager to do so and select the comreader.exe from the process list and kill the process. VectorCAST uses a codewarrior target project file (vcast_tgt.elf.mcp) to define the debugger configuration and connection type to the target. You can examine the debugger configuration inside the project settings of the CodeWarrior IDE. The debugger connection settings should match the configuration below and should not require any user modifications. CODEWARRIOR FOR MPC 8315 136 Target Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. Launching a debug execution of the test harness will launch the CodeWarrior debugger interface and automatically download the target image. CODEWARRIOR FOR MPC 8315 137 You can begin the debug session by single stepping, setting breakpoints, and examining variables and memory as you would in any normal debug session. Once you have run to the completion of the test harness you will see the following line in the command window of the debugger. thread exit: Running, 0x0, 0x0, cpuPowerPCBig, vcast_tgt.elf (state, tid, pid, cpu, target) Now, merely exit out of the CodeWarrior debugger and the results of the test will be read automatically by VectorCAST. If the test harness is not allowed to run until the end, an error may occur. CODEWARRIOR FOR MPC5121 138 CodeWarrior for MPC5121 This section provides details about configuring VectorCAST to integrate with Freescale’s CodeWarrior compiler for the EPPC MPC5121 chip. This particular RSP is designed to support interfacing to custom hardware referred to throughout this section as the FHW. The interface connection between the host PC and the target board is via the CodeWarrior USB CodeTAP. The Freescale compiler version required for this RSP is the Freescale CodeWarrior for MobileGT V9.2. There were several versions of the drivers for the CodeWarrior USB CodeTAP available, not all of which worked, so see details in the CodeWarrior for MPC8315 section of this document about the driver install if you are having any trouble connecting to the target through the CodeWarrior USB CodeTAP. Configuration VectorCAST uses the command line interface of Code Warrior to compile and link the test harness. To enable it, a number of environment variables must be set properly. The FHW uses a custom built UART library that the user must point to via the MWCLIBRARIES environment variable. The serial port baud rate and other configuration parameters should be contained in a serial configuration file that is pointed to by the VCAST_SERIAL_CFG environment variable. The serial port configuration for this target is BAUD=57600 PARITY=N DATA=8 STOP=1, so the contents of the serial cfg file should be as follows assuming you were connected to COM port 8 on the host PC. COM8 57600 N 8 1 An additional environment variable, FHW_INCLUDE_DIR, was added to temporarily point to a library include directory that points to header files needed for the target startup files to get compiled. An example of a DOS script setting all the required environment variables is shown below. Note: Depending on your installation, the template may need amendments to default paths. Particularly, the library includes and the link to certain startup files will need to be changed if you installed your Freescale CodeWarrior for MobileGT V9.2 somewhere other than the default directory as shown below. set VCAST_CW_INSTALL_DIR=C:\PROGRA~1\FREESC~1\CODEWA~3.2 set VCAST_SERIAL_CFG=C:\FHW_serial_cfg.txt set FHW_INCLUDE_DIR=C:\FHW_include set PATH=%VCAST_CW_INSTALL_DIR%\bin;%PATH% set PATH=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Tools\Command_Line_Tools;%PATH% set PATH=C:\Tcl\bin;%PATH% set MWCIncludes=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\MSL\MSL_C\PPC_EABI\Include; set MWCIncludes=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\MSL\MSL_C\MSL_ Common\Include;%MWCIncludes% CODEWARRIOR FOR MPC5121 139 set MWCIncludes=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\MSL\MSL_C\MSL_Common_ Embedded\Include;%MWCIncludes% set MWCIncludes=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\Runtime\Include;%MWCIncludes% set MWLibraries=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\Runtime\Lib;%MWLibraries% set MWLibraries=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\MSL\MSL_C\PPC_ EABI\Lib;%MWLibraries% set MWLibraryFiles=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_ Support\Runtime\Lib\Runtime.PPCEABI.H.UC.a;%MWLibraryFiles% set MWLibraryFiles=%VCAST_CW_INSTALL_DIR%\PowerPC_EABI_Support\MSL\MSL_C\PPC_EABI\Lib\MSL_ C.PPCEABI.bare.H.UC.a;%MWLibraryFiles% set MWLibraryFiles=%VECTORCAST_DIR%\DATA\codewarrior\EPPC\FHW\UART1_5121_ ADS.UC.a;%MWLibraryFiles% You should either set these environment variables permanently in your operating system or set these temporarily in a system shell. In the latter case, remember to launch VectorCAST from within that shell. After starting VectorCAST, select the appropriate template from VectorCAST/C++. For a unit test environment for the CodeWarrior MPC5121 FHW board, go to the Tools => Options dialog, C/C++ tab. Select Compilers => CodeWarrior => EPPC => MPC5121 => FHW => C. It is your responsibility to customize these settings for your particular device and development environment. Please note that these changes will be saved as long as you will be using the same working directory. For more information about this, please contact your Vector Software representative. Target Execution The test harness image will be downloaded and executed on the target using the CodeWarrior debugger. Upon successful compilation and linkage, VectorCAST will automatically launch the comreader.exe CODEWARRIOR FOR MPC5121 140 program during test case execution. The comreader.exe program will capture any data sent to the host’s serial port and make it available to VectorCAST. A serial cable must be connected between the board and the host. If the host does not have a serial port, a serial-to-USB cable can be used. Because this integration uses a COM port connection, the $VECTORCAST_DIR\IO\comreader.exe executable is used to record the results of target execution. The default settings are port "COM1", baud 9600, no parity, 8 data bits, and 1 stop bit. The specific settings required for the FHW board should be specified in a configuration file that is pointed to by the VCAST_SERIAL_CFG environment variable. The file specified by VCAST_SERIAL_ CFG should have each option on a separate line. For example, to use the COM8 port and 57600 baud, the settings for receiving serial port data from the FHW serial port are as follows: COM8 57600 N 8 1 The comreader is started before test execution and stops when the debugger exits. Remember to close any other applications, such as HyperTerminal, that are reading from the same port, before executing tests. Note that if you have a test case with abnormal termination, you may have to manually kill the comreader.exe process if the harness did not run to completion. You can use the Windows Task manager to do so and select the comreader.exe from the process list and kill the process. VectorCAST uses a CodeWarrior target project file (vcast_tgt.elf.mcp) to define the debugger configuration and connection type to the target. You can examine the debugger configuration inside the project settings of the CodeWarrior IDE. The debugger connection settings should match the configuration below and should not require any user modifications. CODEWARRIOR FOR MPC5121 141 Also be sure that the debugger settings indicates using the Target Initialization File FHW_int.cfg, which VectorCAST will automatically copy to you test environment directory during test environment creation time. To check this is set in the project settings, select the Debugger->EPPC Debugger Settings inside the CodeWarrior IDE as shown below. CODEWARRIOR FOR MPC5121 142 Target Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. Launching a debug execution of the test harness will launch the CodeWarrior debugger interface and automatically download the target image. You can begin the debug session by single stepping, setting breakpoints, and examining variables and memory as you would in any normal debug session. Once you have run to the completion of the test harness you will see the following line in the command window of the debugger. thread exit: Running, 0x0, 0x0, cpuPowerPCBig, vcast_tgt.elf (state, tid, pid, cpu, target) Now, simply exit out of the CodeWarrior debugger and the results of the test case will be read and displayed automatically by VectorCAST. If the test harness is not allowed to run to completion, an error may occur. COSMIC 68HC12 AND HCS12X 143 Cosmic 68HC12 and HCS12X Configuration for 68HC12 This section provides details about configuring VectorCAST to integrate with Cosmic Software’s C Cross Compiler for Motorola MC68HC12 and ZAP Simulator or ICD. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “Cosmic 68HC12” under the “Compiler” drop-down menu, as shown here: Note: If you are planning on utilizing banked memory or the ZAP debugger to download to actual target hardware, you’ll need to choose one of the other Cosmic Compiler Template entries. The specifics of these alternative choices are discussed briefly at the end of this section. Second, check the version of the ZAP Debugger you’ll be running. If it is version 3.72e or greater, you’ll want to ensure the Execute Command is set to < Third, ensure that the directories containing the Cosmic binaries are included in your PATH environment variable. These are most commonly C:\COSMIC\CX12 and C:\COSMIC\zapicd12 or C:\COSMIC\zapsim12 (depending on which debugger version you’d like to use), but may be slightly different on your particular system. COSMIC 68HC12 AND HCS12X 144 To specify a different Cosmic installation directory: 1. Using a text editor open cosmic.cmd and cosmicp.cmd, located in the VectorCAST DATA directory (most commonly C:\VCAST\DATA). 2. Replace all occurrences of C:\COSMIC with the DOS-formatted path to your specific Cosmic installation (no spaces). 3. Save the files and exit the text editor. These default settings should be sufficient to run the Tutorial example in the VectorCAST/C User’s Guide, and it is strongly recommended that you do so before trying to test your application code. The preprocess, compile, and link options are initially set to match the examples provided in Cosmic’s documentation. It is your responsibility to customize these settings for your particular device and development environment. This potentially includes modifying the cosmic.cmd and/or cosmicp.cmd (paged) linker command file templates (most commonly located in C:\VCAST\DATA\cosmic) to accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note: The size of the test harness is not static – it is dependent on the size and composition of the specific code under test. Refer to the Cosmic documentation for more information on customizing linker command files. The “Preprocessor/Compiler” tab contains the compiler options that will be used to compile the test harness. The “Linker” tab contains the linker options that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. Specific details and discussion of the options that cx6812.exe and clnk.exe accept is outside the scope of this document. Refer to Cosmic’s compiler and linker documentation for more information on this topic. Customizing Linker Command File Templates If you encounter problems when VectorCAST attempts to link the harness executable, the first thing to investigate is the linker command file. VectorCAST builds two command files that are used to link the executables needed to invoke the test harness: uut.lkf and inst.lkf. They are based on one of two template files located in the VectorCAST installation DATA directory (cosmicp.cmd is used if a “Paged” Compiler Template is selected, otherwise cosmic.cmd is used). The most common cause for a link failure is a segment overflow – this is because the default VectorCAST command files allocate enough space for our tutorial program and is not intended to be a general purpose command file. Best results are achieved by adapting the command file used for your application to the VectorCAST test harness, as it has most likely been customized to fit your specific source code. For example, assume you are building an environment with the “Cosmic 68HC12” Compiler Template (no banked memory, simulated target). If UUT_INTE.EXE fails to link, you would want to edit the linker command file template “cosmic.cmd” that exists in the local environment directory. To handle the code and data that is required by your particular application, plus additional space required by the VectorCAST test harness wrapper code, you’ll most likely want to replace the default segment definitions at the top of the file. The segments that your actual code requires is a good place to start to attempt linking the VectorCAST harness code. Be sure to leave the “#VECTORCAST OBJECT FILES” tag alone, COSMIC 68HC12 AND HCS12X 145 as this gets replaced with the object files for the test. Once you’ve modified the cosmic.cmd file, run the Environment => Relink command. A new and uut.lkf file will be created from the cosmic.cmd template and the linker command will be executed again. Continue tweaking the linker file template until all executables link successfully. If you have Coverage initialized, the inst.lkf file will be used to link UUT_INST.EXE. Once an appropriate linker command file template has been built, it is possible to copy this file into the VectorCAST installation’s DATA\cosmic directory so that all future new environments will use this new template. It is strongly recommended that you back up the existing template file. Alternative Compiler Templates There are three templates other than “Cosmic 68HC12” that are built into VectorCAST. If the code under test uses banked memory, you’ll need to select one of the “Paged” templates. If you’re planning on using the ZAP Debugger with physical target hardware, you’ll need to select one of the “ICD” templates. The following table summarizes these settings: Compiler Template Banked Memory Target Debugger Command Cosmic 68HC12 No Simulated zaps12.exe Cosmic 68HC12 Paged Yes Simulated zaps12p.exe Cosmic 68HC12 ICD No Physical zapbg12.exe Cosmic 68HC12 ICD Paged Yes Physical zapbg12p.exe Configuration for HCS12X This section provides details about configuring VectorCAST to integrate with Cosmic Software’s C Cross Compiler for Freescale HCS12X. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “Cosmic S12X” if you are running on hardware or “Cosmic S12X Simulator” if you are using the simulator. This is located under the “Compiler” drop-down menu, as shown here: COSMIC 68HC12 AND HCS12X 146 Second, check the version of the ZAP Debugger you’ll be running. If it is version 3.72e or greater, you’ll want to ensure the Execute Command is set to < Third, ensure that the directories containing the Cosmic binaries are included in your PATH environment variable. These are most commonly C:\Program Files\COSMIC\CXS12X and C:\Program Files\COSMIC\ZAPSIMS12X, but may be slightly different on your particular system. To specify a different Cosmic installation directory: 1. Using a text editor open s12x\cosmic.cmd and s12x_sim\cosmic.cmd, located in the VectorCAST Cosmic DATA directory (most commonly C:\VCAST\DATA\cosmic). 2. Replace all occurrences of C:\Program Files\COSMIC with the path to your specific Cosmic installation. 3. Save the files and exit the text editor. In VectorCAST, select Tools => Options from the main toolbar. Choose the C/C++ tab. On the Preprocessor/Compiler tab, change the “Library Include directories” entry to match the location of the “CXS12X\Hs12x” directory on your system. COSMIC 68HC12 AND HCS12X 147 Fourth, if you are running on hardware, specify the file containing your start up code. On the Compiler Integration tab, go to the Target Compiler Options group and navigate to the file you want to use by the Startup file option. COSMIC 68HC12 AND HCS12X 148 These default settings should be sufficient to run the Tutorial example in the VectorCAST/C User’s Guide, and it is strongly recommended that you do so before trying to test your application code. The preprocess, compile and link options are initially set to match the examples provided in Cosmic’s documentation. It is your responsibility to customize these settings for your particular device and development environment. This potentially includes modifying the s12x\cosmic.cmd and/or s12x_sim\cosmic.cmd (simulator) linker command file templates (most commonly located in C:\VCAST\DATA\cosmic) to accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note: The size of the test harness is not static – it is dependent on the size and composition of the specific code under test. Refer to the Cosmic documentation for more information on customizing linker command files. The “Preprocessor/Compiler” tab contains the compiler options that will be used to compile the test harness. The “Linker” tab contains the linker options that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. Specific details and discussion of the options that cxs12x.exe and clnk.exe accept is outside the scope of this document. Refer to Cosmic’s compiler and linker documentation for more information on this topic. Customizing Linker Command File Templates If you encounter problems when VectorCAST attempts to link the harness executable, the first thing to investigate is the linker command file. VectorCAST builds two command files that are used to link the executables needed to invoke the test harness: uut.lkf and inst.lkf. They are based on one of two template files located in the VectorCAST installation DATA directory (cosmic_s12x.lkf is used if a Cosmic S12X is selected, otherwise cosmic_s12x_sim.lkf is used). The most common cause for a link failure is a segment overflow – this is because the default VectorCAST command files allocate enough space for our tutorial program and is not intended to be a general purpose command file. Best results are achieved by adapting the command file used for your application to the VectorCAST test harness, as it has most likely been customized to fit your specific source code. For example, assume you are building an environment using Cosmic S12X. If UUT_INTE.EXE fails to link, you would want to edit the linker command file template “cosmic.cmd” that exists in the local environment directory. To handle the code and data that is required by your particular application, plus additional space required by the VectorCAST test harness wrapper code, you’ll most likely want to replace the default segment definitions at the top of the file. The segments that your actual code requires is a good place to start to attempt linking the VectorCAST harness code. Be sure to leave the “#VECTORCAST OBJECT FILES” tag alone, as this gets replaced with the object files for the test. Once you’ve modified the cosmic.cmd file, run the Environment => Relink command. A new uut.lkf file will be created from the cosmic.cmd template and the linker command will be executed again. Continue tweaking the linker file template until all executables link successfully. If you have Coverage initialized, the inst.lkf file will be used to link UUT_INST.EXE. Once an appropriate linker command file template has been built, it is possible to copy this file into the cosmic_s12x.lkf file in the VectorCAST installation’s DATA directory so that all future new environments will use this new template. It is strongly recommended that you back up the existing template file. COSMIC 68HC12 AND HCS12X 149 Target Execution For the Cosmic Software ZAP Debugger, VectorCAST will copy a control script into the environment directory, and will automatically execute the “Debugger Command” that is set in the VectorCAST Compiler Options dialog. The default script file that VectorCAST uses is $VECTORCAST_ DIR\DATA\cosmic\cosmic.scr and is similar to the following: load cosmic.h12 fopen /c:1 VCAST_STDIN.DAT fopen /c:2 VCAST_STDOUT.DAT watch getchar():VCAST_INCH { fread /c:1 "%c"input } watch putchar():VCAST_OUTCH { fwrite /c:2 "%c"character } break main():VCAST_END_MAIN go fclose /c:1 fclose /c:2 quit If you need to customize this script, you may add any legal Cosmic scripting commands to the template script, as long as the commands shown above are maintained. To ensure that ZAP is configured correctly and has the correct target and/or communication settings, run it at least once on its own. Choose the appropriate configuration options, then exit. All settings will be saved and restored the next time it is started by VectorCAST. Automatic Execution If you are using ZAP 3.72e or later, choose the < Manual Execution Versions of ZAP previous to 3.72e do not have the ability to load a command file automatically. For these versions, it is necessary for you to load the cosmic.scr command file into the debugger manually using ZAP’s “Command” window. To set this method of execution, choose the < When VectorCAST is ready to run on the target, it will put up a dialog describing the execution sequence. COSMIC 68HC12 AND HCS12X 150 When you select “OK” VectorCAST will start ZAP, using the VectorCAST “Debugger Command” option. Once ZAP comes up, you must use the “Command” window to load the command script which will control the execution of the test. If it is not visible, select the “Show” menu, and check the “Command” item to display the window. To load the script file, use the “File” menu in the command window, and select “File Input”, then navigate to the environment directory, and choose the file “cosmic.scr.” Alternatively you can type the command “input cosmic.scr” at the Zap> prompt. COSMIC 68HC12 AND HCS12X 151 The script will cause the program to be loaded and execution to begin. When finished, all data files will be closed, ZAP will terminate and VectorCAST will display the results of the executed test case. Target Debug Execution Test Execution with Debug functions similarly to normal execution, except the “go” command to execute the downloaded executable is never issued. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. To stop debugging, VectorCAST has built a convenient script to close the I/O files and quit ZAP with one command. To load this script, use the “File” menu in the command window, and select “File Input,” then navigate to the environment directory, and choose the file “cosmic.quit.” Alternatively you can type the command “input cosmic.quit” at the Zap> prompt. Manual Execution with Debug Versions of ZAP previous to 3.72e (or any version using the < Cosmic STM8 Configuration for Cosmic STM8 on ZAP Simulator This section provides details about configuring VectorCAST to integrate with Cosmic Software’s C Cross Compiler for STM8 on ZAP Simulator and STVD Simulator. First, before launching VectorCAST, the compiler must be put on the path. The way to do this depends on the specifics of your Cosmic installation, however it could look like the following: set PATH=C:\Program Files\COSMIC\CXSTM8;%PATH% To put the ZAP debugger on your path, the ZAP executable also needs to be put on the path environment variable: set PATH=C:\Program Files\COSMIC\ZAPSIMSTM8;%PATH% Second, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “Cosmic STM8 on ZAP Simulator” (or Cosmic STM8 on STVD Simulator) under the “Compiler” drop- down menu, as shown here: It is your responsibility to customize these settings for your particular device and development environment. COSMIC STM8 153 Note: The linker files used for this integration apportion a larger section to RAM data and the stack that what would usually be found on a board (but runs correctly on the compiler). Reducing the size of these sections is inadvisable, as typical RAM space on STM8 targets is insufficient to host the VectorCAST unit test harness, even in minimal configuration. Likewise, this integration will only work on simulator. Configuration for Cosmic STM8 on STVD Simulator This section provides details about configuring VectorCAST to integrate with Cosmic Software’s C Cross Compiler for STM8 on ST Visual Develop (STVD) Simulator. First, before launching VectorCAST, the compiler must be put on the path. The way to do this depends on the specifics of your Cosmic installation. However, it could look like the following: set PATH=C:\Program Files\COSMIC\CXSTM8;%PATH% set PATH= C:\Program Files\STMicroelectronics\st_toolset\stvd\sim;%PATH% The first line puts the compiler executable files on the path. The second further puts the simulator executable files on the path. Second, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “Cosmic STM8 on STVD Simulator” under the “Compiler” drop-down menu, as shown here: It is your responsibility to customize these settings for your particular device and development environment. COSMIC STM8 154 Note: The linker files used for this integration apportion a larger section to RAM data and the stack that what would usually be found on a board (but runs correctly on the compiler). Reducing the size of these sections is inadvisable, as typical RAM space on STM8 targets is insufficient to host the VectorCAST unit test harness, even in minimal configuration. Likewise, this integration will only work on simulator. Customizing Linker Command File Templates If you are using custom libraries, you will need to add the name of the libraries to the two linker files, which you will find in $(VECTORCAST)/DATA/cosmic/stm8. The name of the two files is uut.lkf and inst.lkf, respectively, and the libraries must be added to both files. Please consult your Cosmic documentation for more information regarding linker files. Please note that at this time, the RSP integration does not support integration testing (i.e. putting two or more units under test). This is because the name of the files that make up the test harness is hard-coded into the uut.lkf and inst.lkf files. If you need to do integration testing, please contact your Vector Software Representative. Create a Simulator Entry for STM8VectorCAST Virtual Chip Prior to using Cosmic STM8 on the STVD simulator, you must edit the simstm8.cnf file (located inside the STVD simulator) and create a simulator entry for a virtual chip called STM8VectorCAST. This is accomplished by doing the following: 1. Navigate to the simstm8.cnf configuration file located inside the STVD simulator and open the file in any text editor. 2. Open a second instance of the text editor and open the configuration file located on the following path: %VECTORCAST_DIR%/DATA/st/stm8/simstm8.cnf. Copy the contents of this file. 3. Paste the contents of %VECTORCAST_DIR%/DATA/st/stm8/simstm8.cnf at the end of the first configuration file (simstm8.cnf) and save. That will create an entry for a virtual MCU called STM8VectorCAST. Note: Failure to follow these steps will result in a message printed in the execution output that the MCU name is unknown to the simulator. Target Execution For the Cosmic Software ZAP Debugger, VectorCAST will copy a control script into the environment directory, and will automatically execute the “Debugger Command” that is set in the VectorCAST Compiler Options dialog. The script is automatically generated during execution and saved in a file named cosmic.scr, which you may find in your work directory. It is similar to the following: b vCAST_END() fopen /c:1 stdout.txt watch VCAST_OUTCH { fwrite /c:1 "%c"VCAST_OUTCH } watch change { fwrite /c:1 "%c"VCAST_OUTCH } go COSMIC STM8 155 fclose /c:1 reset quit On STVD, a similar process will occur and generate a file called gdbscript.txt as shown below: file PATH_TO_HARNESS\harness.elf target gdi -dll sim\st7sim.dll -config_file simstm8.cnf –mcuname STM8VectorCAST -no_port_logfile load PATH_TO_HARNESS%\harness.elf watch vcast_exit run printf "%%s",vcast_output_buffer quit Target Debug Execution Test Execution with Debug functions similarly to normal execution, except the “go” command to execute the downloaded executable is never issued. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. To stop debugging, you simply need to close the result file by typing fclose /c:1, and then typing quit at the ZAP command line. Please note that if the test harness was not allowed to run to its completion, the results will be partial. To ensure that the test case runs to its completion, please make sure that the test harness runs to vCAST_END() function (or the value on vcast_exit variable changes, which happens only at the end of the test harness in the STVD integration). EVP FOR VD3204X 156 EVP for VD3204x Configuration This section provides details about configuring VectorCAST to integrate with NXP’s EVP C compiler and debugger for VD3204x and the Adelante Software Development Kit. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the template for “EVP” under the “Compiler” drop-down menu, as shown here: Specify either VD32040 or VD32041 depending on your core. The compiler template for the EVP compiler uses the environment variable EVP_INSTALL_BASE, which points to the EVP compiler’s installation directory. You must set this environment variable outside of VectorCAST to point to the appropriate directory. For example: set EVP_INSTALL_BASE “C:\adelante_sdk\vd3204x\r11b1_ixn”. Second, ensure that the directory containing the EVP binaries is included in your PATH environment variable. This is most commonly C:\adelante_sdk\vd3204x\r11b1_ixn\bin, but may be slightly different on your particular system. EVP FOR VD3204X 157 To specify a different EVP installation directory: 1. On the Preprocessor/Compiler tab, change the Default source directories for Wizard entry to match the location of the “adelante_sdk\vd3204x\r11b1_ixn\include” directory on your system. If you have set the environment variable EVP_INSTALL_BASE correctly, this path will resolve itself when the Options dialog is opened, and therefore will be correct. 2. On the Linker tab, change the Linker Options entry to match the location of the $(EVP_ INSTALL_BASE)/lib/vcom_vd32040 directory if you are using VD32040 or the $(EVP_ INSTALL_BASE)/lib/vcom_vd32041 directory if you are using VD32041. Use DOS formatted short-paths (8.3/no spaces). EVP FOR VD3204X 158 3. Click Apply to save the changes. It is your responsibility to customize these settings for your particular device and development environment. The “Preprocessor/Compiler” tab contains the compiler commands and options that will be used to compile the test harness. The “Linker” tab contains the linker commands and options that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. Specific details and discussion of the options that vcom.bat accepts is outside the scope of this document. Refer to NXP’s compiler and linker documentation for more information on this topic. Lastly, click OK to save the settings and close the options dialog. The default command settings should be sufficient to run the Tutorial example in the VectorCAST/C++ User’s Guide, and it is strongly recommended that you do so before trying to test your application code. Be sure to use the code in $(VECTORCAST_DIR)\examples\alternate_tutorial_versions\c_tutorial_no_floating_point since the code in $(VECTORCAST_DIR)\tutorial uses the float type. FUJITSU SOFTUNE FOR FFMC CHIPS 159 Fujitsu Softune for FFMC Chips Configuration This section provides details about configuring VectorCAST to integrate with the Fujitsu Softune IDE. First, before launching VectorCAST, the compiler must be put on the path. The way to do this depends on the specifics of your Fujitsu Softune installation, however it could look like the following: set PATH=C:\Softune\BIN;%PATH% set FETOOL=C:\Softune set INC907=C:\Softune\LIB\907\INCLUDE set LIB907=C:\Softune\LIB\907 set FELANG=ASCII set OPT907=C:\Softune\LIB\907 set OPT=C:\Softune\LIB set TMP=C:\Temp Note: All of these environment variables must be set before VectorCAST/C++ can use them. You can make these environment variables permanently part of the Windows operating system, or you can launch VectorCAST from a batch file that first sets these environment variables correctly. FELANG indicates the encoding that is used by the code files on your computer. The value is likely to FUJITSU SOFTUNE FOR FFMC CHIPS 160 be different if your code base is saved using another encoding, such as Shift-JIS (for Japanese). For more details, please consult your Fujitsu Softune documentation. It is your responsibility to customize these settings for your particular device and development environment. Target Execution The Fujitsu Softune environment has a command line interface to the compiler and linker. However, it does not provide a command line interface to the debugger. The VectorCAST/RSP integration to Fujitsu Softune interfaces directly with the Windows API to automate the unit testing process. Because of this, users are advised not to interact with the Softune window spawned by VectorCAST unless the execution does not complete after several seconds. A typical execution time for this integration may range up to 10 seconds. Likewise, it is recommended not to keep any instance of Fujitsu Softune open during execution with VectorCAST, as the execution program may lock on to the existing Fujitsu Softune instance to run the test harness, which may have unpredictable results. A script file is created containing all the commands that should be issued to the debugger for successful execution. VectorCAST will then launch a Softune template and attempt to execute the script there. Result data can be captured in either of two ways – through a UART/Serial port (in the case of boards) and an OUTPORT, which is a designated variable whose value is saved to a file by the simulator. The mechanism is automatically implemented during template selection. Target Debug Execution When executing under the control of the debugger, VectorCAST will open the Fujitsu Softune IDE template and advance execution to the entry of the main function. From there, you will be able to execute the test harness manually, using your usual debugger command. For your convenience, VectorCAST will also automatically put a break point at the end of the test harness. However, you will need to manually load the file you wish to debug by clicking File => Open, and then, in the working directory, open s0000003.c (for the main function) or the file of your choice. You should refrain from interacting with the debugger until the SCRIPT command has been issued and processed by Fujitsu Softune. FUJITSU SOFTUNE SIMULATOR 161 Fujitsu Softune Simulator Configuration This section provides details about configuring VectorCAST to integrate with the Fujitsu Softune IDE. First, before launching VectorCAST, the compiler must be put on the path. The way to do this depends on the specifics of your Fujitsu Softune installation, however it could look like the following: set PATH=C:\Softune\BIN;%PATH% set FETOOL=C:\Softune set INC911=C:\Softune\LIB\911\INCLUDE set LIB911=C:\Softune\LIB\911 set FELANG=ASCII set OPT911=C:\Softune\LIB\911 set OPT=C:\Softune\LIB set TMP=C:\Temp Note: All of these environment variables must be set before VectorCAST/C++ can use them. You can make these environment variables permanently part of the Windows operating system, or you can launch VectorCAST from a batch file that first sets these environment variables correctly. FELANG indicates the encoding that is used by the code files on your computer. The value is likely to FUJITSU SOFTUNE SIMULATOR 162 be different if your code base is saved using another encoding, such as Shift-JIS (for Japanese). For more details, please consult your Fujitsu Softune documentation. It is your responsibility to customize these settings for your particular device and development environment. Target Execution The Fujitsu Softune environment has a command line interface to the compiler and linker. However, it does not provide a command line interface to the debugger. The VectorCAST/RSP integration to Fujitsu Softune interfaces directly with the Windows API to automate the unit testing process. Because of this, users are advised not to interact with the Softune window spawned by VectorCAST unless the execution does not complete after several seconds. A typical execution time for this integration may range up to 10 seconds. Likewise, it is recommended not to keep any instance of Fujitsu Softune open during execution with VectorCAST, as the execution program may lock on to the existing Fujitsu Softune instance to run the test harness, which may have unpredictable results. A script file is created containing all the commands that should be issued to the debugger for successful execution. VectorCAST will then launch a Softune template and attempt to execute the script there. Result data can be captured in either of two ways – through a UART/Serial port (in the case of boards) and an OUTPORT, which is a designated variable whose value is saved to a file by the simulator. The mechanism is automatically implemented during template selection. When executing on the simulator, the buffer location may differ between executions, therefore the linker map is always analyzed. The linker map format also varies between versions of Softune. Both Version 3 (for FFMC-16 and Version 6 (FR) have been successfully integrated with VectorCAST. To integrate with a different version of Softune, please contact your VectorCAST representative. Target Debug Execution When executing under the control of the debugger, VectorCAST will open the Fujitsu Softune IDE template and advance execution to the entry of the main function. From there, you will be able to execute the test harness manually, using your usual debugger command. For your convenience, VectorCAST will also automatically put a break point at the end of the test harness. However, you will need to manually load the file you wish to debug by clicking File => Open, and then, in the working directory, open s0000003.c (for the main function) or the file of your choice. You should refrain from interacting with the debugger until the SCRIPT command has been issued and processed by Fujitsu Softune. GREEN HILLS SIMULATOR/BARE TARGET 163 Green Hills Simulator/Bare Target Configuration This section provides details about configuring VectorCAST to work with the Green Hills compiler running with a Green Hills Simulator or bare target board (the board is not running a RTOS). Select Tools => Options from the Main Menu. Choose the C/C++ tab to select the correct entry for your compiler. There are templates available for several different Green Hills simulators, including: PowerPC, x86, ARM, and 68k. Additional templates are added as customers request them. The templates that end with (C++) should be used when the code under test is C++ code. In the following example we have chosen the template for the Green Hills PPC Simulator (C++): In this case, by default, the Execute command defaults to: simppc. Configuration for a Target Board In cases where you want to use a live target board rather than the simulator, you should first choose the correct simulator template for the chip you are using, and then change the Compiler command and the Execute command options to reflect the target board you are using. For example, to run on an MBX860 board using the Green Hills probe (mpserv), you would add the cpu GREEN HILLS SIMULATOR/BARE TARGET 164 flag: "-cpu=ppc860" to the compile command, and set the Execute command to something similar to the following: grun mpserv -mode=download -setup=C:\GHS\PPC402\target\ppc\mbx860\mpserv_standard.mbs ghprobe –- The format required for this command is the name of the Green Hills grun utility followed by the remote target connection string, followed by double dashes. In this command string, the -setup option should be the setup script that is appropriate for your board, and the ghprobe option should be replaced with the name of your target board or its IP address. The easiest way to determine the correct target execution command is to connect to your target using the Multi GUI. The command string you use to establish a remote connection in Multi should be used to configure the VectorCAST Execute Command. Target Execution When running a test with a Green Hills simulator or bare target, the VectorCAST will issue the command specified in the Execute command option. VectorCAST interfaces with the target at two different times: The first time that an environment is opened after it is created (this is to build the VectorCAST range databases); and when VectorCAST interfaces with the target to run a test case. Note: For the target I/O to work between the test harness and the host system, the Green Hills -setup script (mpserv_standard.mbs) must contain the option: "syscalls on" Target Execution with Green Hills Multi Debugger When you choose Execute with Debug for a VectorCAST test, VectorCAST will launch the Multi debugger, using the Debugger Command option that has been set in the Misc sub-tab of the C/C++ tab of the Tool => Options dialog. When the Multi GUI comes up, you should use the “Remote” or “Target” menu in Multi (the menu title is different in different versions of Multi) to connect to your target. Enter your target connection command, or select a previously used command from the list. For example: enter simppc for the simulator. GREEN HILLS SIMULATOR/BARE TARGET 165 Once the target connection has been established, you can use the debug features of Multi as you normally would. When the VectorCAST test harness has completed, the Multi debugger will display the status: ‘Name_of_Executable’ has terminated normally. At this point, you can quit from Multi, and VectorCAST will build its test execution report. Improving Target Execution Speed For Green Hills targets, the VectorCAST test harness uses file I/O to read stimulus data, and to write the results data. The Green Hills run time uses a "syscall" mechanism to service I/O operations from the target. Depending on the target connection and board that you are using, this syscall mechanism can result in slow test case execution. GREEN HILLS SIMULATOR/BARE TARGET 166 If your test cases are running slowly, please see the section "Standard I/O" on page 347, particularly the section that describes how to configure the test harness to use standard output only for test execution "Configuring to Use Stdout Only" on page 350). GREEN HILLS INTEGRITY SIMULATOR 167 Green Hills INTEGRITY Simulator Configuration You can configure VectorCAST to work with a live board, or with the INTEGRITY simulator. Choose the Tool => Options dialog, and select the C/C++ tab. VectorCAST has several compiler templates for INTEGRITY. In the following screen shot, we have chosen the template for PPC INTEGRITY Simulator C++. This is for version 4.x of INTEGRITY. By default, the template has all of the options set that are required to build a test environment and run a test case using the INTEGRITY simulator. This template will build a kernel space application where the INTEGRITY operating system and the test harness code will be linked into the kernel address space. This is also called a statically-linked executable. We suggest that you run VectorCAST in this default configuration at least once to become familiar with the tool before attempting a more complex simulator or target board configuration. Target Execution Target execution with the INTEGRITY simulator is exactly the same as with any of the other simulators or bare Green Hills targets. See the previous section on page 164 for details. GREEN HILLS INTEGRITY SIMULATOR 168 Target Execution with Green Hills Multi Debugger Execution with the Multi debugger is the same as described in the previous section on page 164. Simply create a target connection to the "isim" simulator. The only additional option required for isim for use with VectorCAST is the "-X83" option. This option enables I/O to work with the simulator. Improving Target Execution Speed For Green Hills targets, the VectorCAST test harness uses file I/O to read stimulus data, and to write the results data. The Green Hills run time uses a "syscall" mechanism to service I/O operations from the target. Depending on the target connection and board that you are using, this syscall mechanism can result in slow test case execution. If your test cases are running slowly, please see the section “"Standard I/O" on page 347”, particularly the section that describes how to configure the test harness to use standard output only for test execution. GREEN HILLS INTEGRITY MPSERV 169 Green Hills INTEGRITY mpserv Configuration This section describes how to configure VectorCAST for target board execution, using the Green Hills probe and mpserv. The particular example that we present here makes use of an MBX860 board and version 4.0.8 of INTEGRITY. It should be easy for you to extend the example presented for a different version of INTEGRITY, or for different target hardware. Also, for this example we are building a monolithic kernel space application (i.e. the INTEGRITY OS kernel and the test harness application are linked into one kernel space application. VectorCAST has a built in compiler template for the combination used in this example as shown in the following screen capture: Some modification of the default template options will be required, to match your particular hardware. Compile command The Compile command is located on the C/C++ tab of the Tool Options dialog, as shown in the following screen capture: GREEN HILLS INTEGRITY MPSERV 170 The default Compile command is: ccppc -c -G -w -cpu=ppc860 :cx_option=exceptions You should change the -cpu=option to reflect the CPU on your board. Linker command The Linker command is located on the Linker sub-tab of the C/C++ tab of the Tool Options dialog, as shown in the following screen capture: The default Link command is: build -driver mbx800 :integrity_option=kernel -ldebug :language=cxx :cx_lib=sce You should change "mbx800" to the correct value for your BSP. Execute command The Execute command is located on the C/C++ tab of the Tool Options dialog, as shown in the following screen capture: GREEN HILLS INTEGRITY MPSERV 171 The default Execute command is: grun mpserv -setup C:\GHS\int408\mbx800\mbx800_mp.dbs ghprobe –- The execute command should always start with grun, and end with "two dashes". These two strings delimit the target connection string that is used to connect to your target. The connection string is the same one that you would use in the Multi debugger to connect to your target. The -setup option provides a full path to the board initialization file for your board. "ghprobe" should be replaced with the hostname of your target board or its IP address. Target Execution Target execution with the Green Hills probe is completely automatic. VectorCAST will automatically invoke "mpserv" using the Execute command that you have configured, with no manual intervention required. Note: For the target I/O to work between the test harness and the host system, the Green Hills -setup script mbx800_mp.dbs) must contain the option: "syscalls on" Target Execution with Green Hills Multi Debugger Execution with the Multi debugger is the same as described in the previous section on page 164. Simply create a target connection using the correct mpserv command sequence. Improving Target Execution Speed For Green Hills targets, the VectorCAST test harness uses file I/O to read stimulus data, and to write the results data. The Green Hills run time uses a "syscall" mechanism to service I/O operations from the target. Depending on the target connection and board that you are using, this syscall mechanism can result in slow test case execution. If your test cases are running slowly, please see the section “Standard I/O” on page 347, particularly the section that describes how to configure the test harness to use standard output only for test execution (page 350). GREEN HILLS INTEGRITY RTSERV 172 Green Hills INTEGRITY rtserv Configuration This section describes how to configure VectorCAST for target board execution, with the test harness running in a separate address space from the kernel and being dynamically downloaded using rtserv. The particular example that we present here makes use of an MBX860 board and version 4.0.8 of INTEGRITY. It should be easy for you to extend the example presented for a different version of INTEGRITY or for different target hardware. VectorCAST has a built in compiler template for the combination used in this example as shown in the following screen capture: Some modification of the default template options will be required, to match your particular hardware. Compile command The Compile command is located on the C/C++ tab of the Tool Options dialog, as shown in the following screen capture: GREEN HILLS INTEGRITY RTSERV 173 The default Compile command is: ccppc -c -G -w -cpu=ppc860 :cx_option=exceptions You should change the -cpu=option to reflect the CPU on your board. Linker command The Linker command is located on the Linker sub-tab of the C/C++ tab of the Tool Options dialog, as shown in the following screen capture: The default Link command is: cxppc -bspname=mbx800 -non_shared -G -dynamic -integrate -intfile=vcast.int :language=cxx :cx_lib=sce You should change "mbx800" to the correct value for your BSP. By default, VectorCAST provides an integrate file called vcast.int in the VectorCAST installation directory, sub-directory: DATA. When a test environment is built, VectorCAST will copy this integrate file template into the environment directory. The default integrate file contains the following commands: Kernel Filename DynamicDownload GREEN HILLS INTEGRITY RTSERV 174 EndKernel AddressSpace FilenameVCAST_FILE MemoryPoolSize0x30000 LanguageC++ Task Initial StackLength0x8000 StartIt false EndTask EndAddressSpace There are two ways to customize the integrate file that is used. One way is to edit the vcast.int file that is delivered with VectorCAST, in the install area. Subsequent environment builds will then use this file. The second, and more flexible way is to provide the full path to a custom integrate file using the environment variable: VCAST_GH_INT_FILE. For example, if you set the value of this environment variable to be c:\my_project\my_integrate_file.int, VectorCAST will copy this file into the environment directory, name it vcast.int, and use it when linking the test harness. The only requirement of a custom integrate file, is that it have an address space for the test harness, and the Filename line for this address space, must be VCAST_FILE. At link time, VectorCAST will replace VCAST_FILE with the actual filename of the VectorCAST test harness. All integrate file commands required for your application should be added to the VectorCAST integrate file, especially commands related to the creation of needed kernel space data objects and devices. Execute command The Execute command is located on the C/C++ tab of the Tool Options dialog, as shown in the following screen capture: The default Execute command is: rtserv -port udp@mbx860 -X8 -X14 The execute command should always start with rtserv. The connection string is the same one that you would use in the Multi debugger to connect to your target. The udp@mbx860 should be replaced with the correct name for your board. Target Execution Target execution of a dynamic download application with rtserv requires some manual steps. The most important requirement is that the target board be booted with a running INTEGRITY kernel before any test cases are executed. GREEN HILLS INTEGRITY RTSERV 175 Once the board is booted, each VectorCAST test execution will create an rtserv connection to the target. This will cause the download and execution of the test harness address space. Test execution occurs with no manual intervention. Common ways to boot the target are using tftp or mpserv. The Green Hills INTEGRITY documentation has complete information on booting targets with an INTEGRITY kernel. Target Execution with Green Hills Multi Debugger Execution with the Multi debugger is similar to what is described in the previous section on page 164. However, you must manually load the test harness executable to the target after creating your rtserv connection. The following series of screen captures demonstrate a nominal sequence. When you select Execute with debug, VectorCAST will put up a dialog similar to the following: The dialog tells you the complete path to the executable file that should be loaded on to the target. When you select OK, VectorCAST will start the Multi debugger. After the Multi debugger starts, create an rtserv connection to your board. When the connection is made, you will get a task window showing the kernel running on the board. GREEN HILLS INTEGRITY RTSERV 176 Using the Target menu, Load command, load the VectorCAST test harness executable file that was named in the VectorCAST pop-up. In this case, we will load the file: C:\test\c\mbx860\rtserv\TEST\UUT_ INST.mod as indicated. Note: It is important that you load the .mod file, as this is the "Integrated" application. There will also be an .exe file with the same name, this file will not run on the target. After the program is loaded, the task window, will show the VectorCAST task: To debug the program, double click on the "Initial" task under UUT_INST.EXE. Doing this will result in a new Multi debug window being displayed. Use this window to debug your test case. When you’re done, close the debugger, and VectorCAST will create the test execution report. Improving Target Execution Speed For Green Hills targets, the VectorCAST test harness uses file I/O to read stimulus data, and to write the GREEN HILLS INTEGRITY RTSERV 177 results data. The Green Hills run time uses a "syscall" mechanism to service I/O operations from the target. Depending on the target connection and board that you are using, this syscall mechanism can result in slow test case execution. If your test cases are running slowly, please see the section “Standard I/O” on page 347, particularly the section that describes how to configure the test harness to use standard output only for test execution (page 350). HIGHTEC TRICORE-GCC 178 HighTec TriCore-gcc Configuration This section provides details about configuring VectorCAST to integrate with TriCore-gcc compiler and debugger for the TriCore simulator or JTAG server. First, the compiler must be on the path. If it is not already done, the following directory (HighTec compiler directory)\TriCore\bin must be put on the PATH environment variable before VectorCAST is launched. Second, the simulator or JTAG server (in the case of a physical target) needs to be launched. Under Windows, this can be done by accessing Start => PXROS TriCore System Development Platform. Both the simulator and JTAG server can be activated by clicking the appropriate selection. For instance, after selecting the simulator, the following DOS prompt will appear. This window must stay open for as long as VectorCAST is executing test cases. Please note the port number provided to you (usually 6785) and your host ID, which you can obtain by typing ipconfig in a DOS prompt. Then, open the following file in an editor: $(VECTORCAST_DIR) /DATA/tricore-gcc/simulator.bat @echo target tricore-remote 6785@localhost > script.txt @echo load %1 >> script.txt @TYPE %VECTORCAST_DIR%\DATA\tricore-gcc\simulator_commands.txt >> script.txt @tricore-gdb --quiet --silent --command=script.txt On the first line, modify the text 6785@localhost with the port number@host name that are pertinent to your host. Then save the file. Then within VectorCAST select the appropriate template you wish to use (either C or C++). HIGHTEC TRICORE-GCC 179 TriCore installation and target customizations: The integration for this compiler was originally designed on a simulator for the TriCore 1775. To change this for your target, modify the following options: 1. On the Preprocessor/Compiler tab, the –mcpu option on the preprocessor and compile commands, and on the Linker tab, the Linker command refers to the 1775. The –mcpu needs to be changed to your target. 2. To obtain the correct values, launch the compiler IDE (called Code::Blocks) and build your project. Take a look at the build log, which will report the value used for the -mcpu option. Modify your VectorCAST template accordingly. HIGHTEC TRICORE-GCC 180 3. Likewise, the defined variable TRIBOARD_TC1775 must be changed with the macro related to your target. This information can also be obtained in Code::Blocks as shown above. If your project relies on any startup code, these files must be specified in VectorCAST’s Tools => Options dialog, C/C++ tab, Compiler Integration sub-tab, in the option “Startup file.” HIGHTEC TRICORE-GCC 181 Please note that this integration uses the virtual I/O capability of the environment to communicate test harness data. Use of Serial I/O is also possible, but not supported at this time. Please contact your Vector Software representative if your needs include the use of Serial I/O. Target Execution Target execution in the TriCore-gcc environment is straightforward. The only prerequisite to environment building and test case execution is to launch either the JTAG-server or TriCore version 1.x Simulator programs. These programs are available, under Windows, by clicking Start => All Programs => PXROS. These programs can also be launched from the command line. Under Windows default installation, the JTAG server can be accessed at: C:\HighTec\TriCore\bin\tricore-jtagsrv.exe and the simulator at: C:\HighTec\TriCore\bin\tricore-tsimd.exe These two programs will open a port (by default, port 6785) to listen for incoming requests from programs to execute TriCore-compatible programs on a board or a simulator. VectorCAST uses these facilities for target execution. You must therefore ensure that one of them is launched before generating an environment or running a test case. HIGHTEC TRICORE-GCC 182 Target Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. tricore-gcc uses a port of gdb for debug capabilities. Running a test case with the debugger will invoke tricore-insight and charge the test harness. If you prefer to use gdb, go to Tools => Options dialog, C/C++ tab, Debug sub-tab, and replace tricore-insight with tricore-gdb. Please consult the compiler’s manual to learn how to use the debugger. IAR EMBEDDED WORKBENCH 3.X MSP430 183 IAR Embedded Workbench 3.x MSP430 Configuration This section provides details about configuring VectorCAST to integrate with IAR’s Embedded Workbench version 3.10A and C-SPY debugger for Texas Instruments’ MSP430. (Future releases of Embedded Workbench might require slight configuration changes.) First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “IAR MSP430 3.x” under the “Compiler” drop-down menu, as shown here: Second, ensure that the directories containing the IAR binaries are included in your PATH environment variable. These are most commonly c:\Progra~1\IARSys~1\Embedd~1\common\bin and C:\Progra~1\IARSys~1\Embedd~1\430\bin but may be slightly different on your particular system. To specify a different IAR installation directory: 1. Ensure that the “Preprocessor/Compiler” tab is selected. 2. The “Include Dirs” text box contains the installation path in two places. All occurrences of C:\PROGRA~1\IARSYS~1\EMBEDD~1 should be replaced with the DOS-formatted path to your IAR installation (no spaces). 3. Click the “Linker” tab. IAR EMBEDDED WORKBENCH 3.X MSP430 184 4. The “Linker Options” text box contains the installation path in three places. All occurrences of C:\PROGRA~1\IARSYS~1\EMBEDD~1 should be replaced with the DOS-formatted path to your IAR installation (no spaces). These default settings should be sufficient to run the Tutorial example in the VectorCAST/C User’s Guide, and it is strongly recommended that you do so before trying to test your application code. The compile and link options are initially set to match the defaults provided by IAR’s Embedded Workbench when you create a new project, selecting “Generic Device” as your target. It is your responsibility to customize these settings for your particular device, including modifying a linker file that will accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note: The size of the test harness is not static – it is dependent on the size and composition of the code under test. Refer to IAR’s documentation for more information on customizing linker files. The “Preprocessor/Compiler” tab contains the compiler options that will be used to compile the test harness. The “Linker” tab contains the linker options, libraries to be linked, linker file specification, heap and stack size that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. For example, if you are using the F149 target device, you would change the “Linker Options” entry to reference “C:\PROGRA~1\IARSYS~1\EMBEDD~1\430\config\lnk430F149.xcl” instead of the default “C:\PROGRA~1\IARSYS~1\EMBEDD~1\430\config\lnk430.xcl.” If you find that the test harness isn’t linking properly and plan on modifying lnk430F149.xcl, it is strongly recommended that you make a copy of lnk430F149.xcl and name it something unique, like “lnk430F149_vcast.xcl.” Don’t forget to change the Linker Options to reference lnk430F149_vcast.xcl instead of the original. Specific details and discussion of the options that icc430.exe and xlink.exe accept is outside the scope of this document. Refer to IAR’s compiler and linker documentation for more information on this topic. Target Execution Before executing tests with IAR Embedded Workbench version 3.10A, you must specify the IAR Compiler and Execute Command through the Options dialog. Also, ensure that the IAR binary directories (most commonly C:\Progra~1\IARSys~1\Embedd~1\common\bin and C:\Progra~1\IARSys~1\Embedd~1\430\bin) are included in the host platform’s PATH environment variable. See the previous section for detailed instructions on these requirements. VectorCAST utilizes the IAR application “cspybat.exe” to execute the test harness on the C-Spy simulator. This application allows target simulation and execution to occur without the requirement of starting IAR Embedded Workbench IDE or C-Spy debugger. The execution occurs automatically and requires no input from the user. When executing a test case (for example, PLACE_ORDER.001 in the User’s Guide Tutorial) you should see the following output in the Message tab across the bottom of VectorCAST: Running C-SPY Debugger to Execute Program... Building Execution History Data for Event: 1 IAR EMBEDDED WORKBENCH 3.X MSP430 185 Building Execution History Data for Event: 2 Building Execution History Data for Event: 3 Building Execution History Data for Event: 4 Test Execution Complete If an abort message appears, or an error dialog pops up saying “Could Not Build Test History,” then test execution has failed. Select Tools => Options, C/C++ tab, Debug tab, and note the entry for “Debugger Command.” This is the actual command that is run when a test case is executed. Just before executing this command, VectorCAST copies the executable UUT_INTE.EXE to a file named vcast_harness.d43. From a DOS shell, you can navigate to the environment directory and run the exact Debugger Command. The cspybat.exe will provide you with some indication as to why the simulator execution is failing. Refer to IAR’s documentation for more information on the cspybat.exe application. Note, VectorCAST runs the Debugger Command as is, but redirects its output to VCAST_STDOUT.DAT with the redirection (‘>’) shell operator. Target Debug Execution Test Execution with Debug for IAR 3.10A initially requires several manual steps by the user. These steps are outlined in detail in a dialog that pops up when you select Execute with Debug: The above instructions will be different for your particular environment, specifically the names of the files given in steps 3, 7 and 9. IAR EMBEDDED WORKBENCH 3.X MSP430 186 The C-Spy simulator is built-in to IAR’s Embedded Workbench 3.10A. To debug an executable with C- Spy, you need to setup an Embedded Workbench Project, configure the project settings, and add the file you want to debug to this project. It is recommended that you save the IAR Workspace in the current environment directory as “vector_ debug” because VectorCAST looks for this file on future debug executions. To report the results of a debugged test case back to VectorCAST, you must enable Terminal I/O logging once the debugger has started. If you’d like to see these results in realtime, you can select “View | Terminal I/O” and an additional window will open in C-Spy. You can now debug the test harness using the functionality that C-Spy provides. When you are finished debugging, allow the application to run to completion and select “Stop Debugging” to ensure that the I/O log file gets written to disk. If the message “Test case execution aborted” appears in VectorCAST’s Message tab, it is most likely because the I/O log file was never written. Once you have set up an IAR Project and Workspace for debugging and saved them in the current environment directory, VectorCAST will recognize this and prompt you with a smaller set of instructions: The above instructions will be different for your particular environment, specifically the name of the file given in step 2. In fact, if you plan on debugging several test cases, you do not need to close Embedded Workbench. Each time you Execute with Debug, simply switch back to IAR and select “Project | Debug.” The I/O logging will already be set up, so you can immediately start debugging. IAR EMBEDDED WORKBENCH 6.0MSP430X LARGE MEMORY MODEL 5.X 187 IAR Embedded Workbench 6.0 MSP430X Large Memory Model 5.x Configuration This section provides details about configuring VectorCAST to integrate with IAR’s Embedded Workbench version 6.0, MSP430 compiler version 5.1, and C-SPY debugger for Texas Instruments’ MSP430. This RSP was designed to utilize the IAR simulator and Large memory model. (Future releases of Embedded Workbench might require slight configuration changes.) Specifying the IAR install directory paths: The user must set an environment variable that defines the path to where your IAR compiler is installed on your host. This variable is named VCAST_IAR_INSTALL_DIR and must be set accordingly. For example: set VCAST_IAR_INSTALL_DIR=C:\PROGRA~1\IARSYS~1\EMBEDD~2.0\430 Also ensure that the directories containing the IAR binaries are included in your PATH environment variable. These are most commonly located at … C:\Program Files\IAR Systems\Embedded Workbench 6.0\common\bin C:\Program Files\IAR Systems\Embedded Workbench 6.0\430\bin but may be slightly different on your particular system so set the PATH environment variable accordingly. First select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “IAR => MSP430 5.1 => LargeMem => C” under the “Compiler” drop-down menu, as shown here: IAR EMBEDDED WORKBENCH 6.0MSP430X LARGE MEMORY MODEL 5.X 188 These default settings should be sufficient to run the Tutorial example in the VectorCAST/C++ User’s Guide, and it is strongly recommended that you do so before trying to test your application code. The compile and link options are initially set to match the defaults provided by IAR’s Embedded Workbench when you create a new project, selecting the MSP430X processor as your target and specifying the large memory model. It is your responsibility to customize these settings for your particular device, including modifying a linker file that will accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note: The size of the test harness is not static – it is dependent on the size and composition of the code under test. Refer to IAR’s documentation for more information on customizing linker files. The default linker command file used for the MSP430X template is the lnk430x.xcl which is located at $(VCAST_IAR_INSTALL_DIR)\config\lnk430x.xcl. The “Preprocessor/Compiler” tab contains the compiler options that will be used to compile the UUT code and test harness. The target processor core and memory model are specified on the compile command with the following compiler switches --data_model=large --core=430X The “Linker/Debug” tab contains the linker options, libraries to be linked, linker file specification, heap and stack size that will be used to link the test harness. When you are ready to begin testing your IAR EMBEDDED WORKBENCH 6.0MSP430X LARGE MEMORY MODEL 5.X 189 application code you may choose to modify some of these settings. We recommend using the default values provided in the MSP430X template and only modify as needed. Depending on the size and complexity of your UUT code, it may be necessary to increase the default stack and heap sizes, which you will find specified on the linker options, as shown below: -D_STACK_SIZE=1024 -D_HEAP_SIZE=3072 -D_DATA16_HEAP_SIZE=500 -D_DATA20_HEAP_SIZE=500 Specific details and discussion of the options that the IAR compiler and linker will accept are outside the scope of this document. Refer to IAR’s compiler and linker documentation for more information on this topic. Target Execution VectorCAST utilizes the IAR application “cspybat.exe” to execute the test harness on the C-Spy simulator. This application allows target simulation and execution to occur without the requirement of starting IAR Embedded Workbench IDE or C-Spy debugger. The execution occurs automatically and requires no input from the user. The default cspy command that is executed to run a test case on the 430 simulator can be found on the Tools => Options => C/C++ tab in the Debugger command edit box: cspybat.exe 430proc.dll 430sim.dll vcast_debug.out --plugin 430bat.dll --backend -B --core=430X When executing a test case (for example, PLACE_ORDER.001 in the User’s Guide Tutorial) you should see the following output in the Message tab across the bottom of VectorCAST: Preparing Test Data Running Test Case Compiling and Linking Input Data File... Compiling file Test Case Data Linking Environment Running C-SPY Debugger to execute program Building Execution Report Created Execution Report Test Execution Complete If an abort message appears, or an error dialog pops up saying “Could Not Build Test History,” then test execution has failed. Select Tools => Options, C/C++ tab, Debug tab, and note the entry for “Debugger Command.” This is the actual command that is run when a test case is executed. Just before executing this command, VectorCAST copies the executable UUT_INTE.EXE to a file named vcast_debug.out. From a DOS shell, you can navigate to the environment directory and run the exact Debugger Command. The cspybat.exe will provide you with some indication as to why the simulator execution is failing. Refer to IAR’s documentation for more information on the cspybat.exe application. Note, VectorCAST runs the Debugger Command as is, but redirects its output to VCAST_STDOUT.DAT with the redirection (‘>’) shell operator. Target Debug Execution Test case Execution with Debug can be performed by right-clicking on a particular test case and selecting IAR EMBEDDED WORKBENCH 6.0MSP430X LARGE MEMORY MODEL 5.X 190 “Execute with Debug”. VectorCAST will automatically invoke the IAR Embedded Workbench IDE with a default project and workspace setup. In addition, on the first time the user Executes With Debug, an Information dialog box will pop up (shown below) that describes what VectorCAST will be doing on the user’s behalf and the user’s required actions, which basically involves clicking the Download & Debug button to initiate the debug session. Click OK in the Information dialog box and VectorCAST will then bring up the IAR IDE by running the IarIdePm.exe and you will see a “Processing… Abort “ progress box also appear with the IDE as shown below. At this point you can just click the Download & Debug button and begin your debug session. You can IAR EMBEDDED WORKBENCH 6.0MSP430X LARGE MEMORY MODEL 5.X 191 now debug the test harness and UUT code using the functionality that C-Spy provides. When you are finished debugging, allow the application to run to completion and select “Stop Debugging” to ensure that the I/O log file gets written to disk. Upon exiting the debug session and returning control to VectorCAST, if the message “Test case execution aborted” appears in VectorCAST’s Message tab, it is most likely because the I/O log file was never written. Upon successful completion of the test case you should see the follow messages appear in VectorCAST’s Message tab. Preparing Test Data Running Test Case Compiling and Linking Input Data File... Compiling file Test Case Data Linking Environment Running IAR IDE to execute program Building Execution Report Created Execution Report Test Execution Complete IAR EMBEDDED WORKBENCH 4.X ARM 9 192 IAR Embedded Workbench 4.x ARM 9 Configuration This section provides details about configuring VectorCAST to integrate with IAR’s Embedded Workbench version 4.42A and C-SPY debugger for the ARM 9 processor. (Future releases of Embedded Workbench may require slightly different configuration changes.) Note that this RSP is designed to support a particular ARM 9 target board that supports a JTAG interface. Minor customizations will be required for other ARM 9 targets including any modified macros to support your hardware and the linker command file. The example here is for an ARM 9 target SBC (single board computer) from Technologic, referred to as “TS-7300”, which is based on the Cirrus EP9302 ARM9 CPU. Specifying the IAR configuration and install directory paths: There are two the environment variables you need to set that will define the path for the directories where your IAR compiler is installed and where you are storing any necessary configuration files for your target. These are VCAST_IAR_INSTALL_DIR for the path where your version of the IAR compiler is installed, and VCAST_IAR_CONFIG_DIR for the path to the configuration files, and they must be set accordingly. For example: set VCAST_IAR_CONFIG_DIR=C:\IAR_Config_Files set VCAST_IAR_INSTALL_DIR=C:\PROGRA~1\IARSYS~1\EMBEDD~2.0\ARM First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “IAR => ARM9 4.x => TS7300 => C ” under the “Compiler” drop-down menu, as shown here: IAR EMBEDDED WORKBENCH 4.X ARM 9 193 IAR installation and target customizations: 1. Click the “Linker” tab. 2. The “Linker Options” text box contains references to all the startup objects required for your target. $(VCAST_IAR_CONFIG_DIR)\UIC_Debug.r79 $(VCAST_IAR_CONFIG_DIR)\TS7300_cstartup.r79 $(VCAST_IAR_CONFIG_DIR)\EP9302.r79 $(VCAST_IAR_CONFIG_DIR)\TS7300.r79 -l UIC_LDR.map -xmsn -IC:\PROGRA~1\IARSYS~1\EMBEDD~2.0\ARM\LIB\ -f $(VCAST_IAR_CONFIG_DIR)\UIC_Debug.xcl -HFF -h(CODE)ROMSTART-ROMEND -J4,crc32,1,__checksum, CHECKSUM,1,0=ROMSTART-ROMEND -e_PrintfSmall=_Printf -e_ScanfSmall=_Scanf -rt $(VCAST_IAR_INSTALL_DIR) \LIB\dl4tptinl8n.r79 -e__write_buffered=__write The startup objects for your target should be compiled outside of VectorCAST and the resultant .r79 object files should be placed in the VCAST_IAR_CONFIG_DIR you set up earlier. Replace the startup objects for the TS7300 with the appropriate startup objects required for your target. Also in the Linker Options text box, replace the UIC_Debug.xcl linker file for the TS7300 with your target .xcl file in the VCAST_IAR_CONFIG_DIR. 3. Click the “Debug” tab. 4. In the “Debugger command:” edit box, replace the –cpu ARM920T argument with the ARM9 IAR EMBEDDED WORKBENCH 4.X ARM 9 194 CPU type for your target, as well as the appropriate processor device description file in place of the default ioep9302.ddf specified for the TS7300: cspybat armproc.dll armjlink.dll vcast_debug.out --plugin armbat.dll --backend -B --endian little --cpu ARM920T --fpu None --proc_device_desc_file ioep9302.ddf --proc_driver jlink --jlink_connection USB:0 --jlink_reset_strategy "1000,0" --jlink_initial_speed 32 --jlink_catch_exceptions 0x000 --jlink_update_breakpoints main These default settings should be sufficient to run the Tutorial example in the VectorCAST/C++ User’s Guide, and it is strongly recommended that you do so before trying to test your application code. The compile and link options are initially set to match the defaults provided by IAR’s Embedded Workbench when you create a new project, selecting EP9302 as your target. It is your responsibility to customize these settings for your particular device, including modifying a linker file that will accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note that the size of the test harness is not static – it is dependent on the size and composition of the code under test. Refer to IAR’s documentation for more information on customizing linker files. The “Preprocessor/Compiler” tab contains the compiler options that will be used to compile the test harness. The “Linker” tab contains the linker options, libraries to be linked, linker file specification, heap and stack size that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. For example, if you are not using the E9302 target device, you would change the “Linker Options” entry to reference your particular target .xcl file instead of the default UIC_Debug.xcl. Specific details and discussion of the options that the iccarm.exe compiler and the xlink.exe linker accept are outside the scope of this document. Refer to IAR’s compiler and linker documentation for more information on this topic. Target Execution VectorCAST utilizes the IAR application “cspybat.exe” to execute the test harness on the target through the J-Link interface. This application allows target execution to occur without the requirement of starting IAR Embedded Workbench IDE or C-Spy debugger. The execution occurs automatically and requires no input from the user. This test case execution is invoked using the command specified in the Debugger Command that is found in the Tools => Options, C/C++ tab, Debug tab, edit box “Debugger Command.” The default command specifies using a J-Link connection to the target, as well as other J-Link option specific to your target. Review these options shown below and change as appropriate for your target. Refer to IAR documentation for more information regarding the command line options for running cspybat.exe. IAR EMBEDDED WORKBENCH 4.X ARM 9 195 When executing a test case (for example, PLACE_ORDER.001 in the User’s Guide Tutorial) you should see the following output in the Message tab in VectorCAST’s main window: Running C-SPY Debugger to execute program Building Execution Report Created Execution Report Updating Coverage Data Test Execution Complete Just prior to test case execution, VectorCAST copies the test harness executable, UUT_INTE.EXE or the UUT_INST.EXE, depending on whether you have coverage enabled, to a file named vcast_debug.out. In cases of failed test case execution, one can possibly get more information as to the nature of the failure by running this command from a DOS shell. To do so, navigate to the environment directory and run the exact same Debugger Command that is found in the Tools => Options, C/C++ tab, Debug tab, edit box “Debugger Command.” The cspybat.exe will provide you with some indication as to why the target execution is failing. Refer to IAR’s documentation for more information on the cspybat.exe application. Note: VectorCAST runs the Debugger Command as is, but redirects its output to VCAST_ STDOUT.DAT with the redirection (‘>’) shell operator. Target Debug Execution Test case Execution with Debug can be performed by right-clicking on a particular test case and selecting IAR EMBEDDED WORKBENCH 4.X ARM 9 196 “Execute with Debug”. VectorCAST will automatically invoke the IAR Embedded Workbench IDE with a default project and workspace setup. In addition, on the first time the user Executes With Debug, an Information dialog box will pop up (shown below) that describes what VectorCAST will be doing on the user’s behalf and the user’s required actions, which basically involves clicking the Download & Debug button to initiate the debug session. Click OK in the Information dialog box and VectorCAST will then bring up the IAR IDE by running the IarIdePm.exe and you will see a “Processing… Abort “ progress box also appear with the IDE as shown below. At this point you can just click the Download & Debug button and begin your debug session. You can IAR EMBEDDED WORKBENCH 4.X ARM 9 197 now debug the test harness and UUT code using the functionality that C-Spy provides. When you are finished debugging, allow the application to run to completion and select “Stop Debugging” to ensure that the I/O log file gets written to disk. Upon exiting the debug session and returning control to VectorCAST, if the message “Test case execution aborted” appears in VectorCAST’s Message tab, it is most likely because the I/O log file was never written. Upon successful completion of the test case you should see the follow messages appear in VectorCAST’s Message tab. Preparing Test Data Running Test Case Compiling and Linking Input Data File... Compiling file Test Case Data Linking Environment Running IAR IDE to execute program Building Execution Report Created Execution Report Test Execution Complete IAR EMBEDDED WORKBENCH 5.X ARM 9 198 IAR Embedded Workbench 5.x ARM 9 Configuration This section provides details about configuring VectorCAST to integrate with IAR’s Embedded Workbench version 5.2 and C-SPY debugger for the ARM 9 processor. (Future releases of Embedded Workbench might require slight configuration changes.) Note that this RSP is designed to support a particular ARM 9 target board that supports a JTAG interface. Minor customizations will be required for other ARM 9 targets including modifications to the macro that supports your hardware and the linker command file. The example here is for a target referred to as “Madison” that has the ARM926EJ-S CPU on board. Specifying the IAR configuration and install directory paths: There are two the environment variables you need to set that will define the path for the directories where your IAR compiler is installed and where you are storing any necessary configuration files for your target. These are VCAST_IAR_INSTALL_DIR for the path where your version of the IAR compiler is installed, and VCAST_IAR_CONFIG_DIR for the path to the configuration files, and they must be set accordingly. For example: set VCAST_IAR_CONFIG_DIR=C:\IAR_Config_Files set VCAST_IAR_INSTALL_DIR=C:\PROGRA~1\IARSYS~1\EMBEDD~1.0\ARM First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “IAR => ARM9 5.x => Madison => C” under the “Compiler” drop-down menu, as shown here: IAR EMBEDDED WORKBENCH 5.X ARM 9 199 IAR installation and target customizations: 1. Click the “Linker” tab. 2. The “Linker Options” text box contains a reference to the linker .icf file. Replace the AT91SAM9261_iRAM.icf linker file with the appropriate .icf file for your particular target. --config $(VCAST_IAR_CONFIG_DIR)\AT91SAM9261_iRAM.icf --semihosting --entry __iar_program_start 3. Click the “Debug” tab. 4. In the “Debugger command:” edit box, replace the optional AT91SAM9261_iRAM.mac macro file with the appropriate macro for your particular target. cspybat armproc.dll armjlink.dll vcast_debug.out --plugin armbat.dll --macro $(VCAST_IAR_CONFIG_DIR)\AT91SAM9261_iRAM.mac --backend -d jlink -B These default settings should be sufficient to run the Tutorial example in the VectorCAST/C++ User’s Guide, and it is strongly recommended that you do so before trying to test your application code. The IAR EMBEDDED WORKBENCH 5.X ARM 9 200 compile and link options are initially set to match the defaults provided by IAR’s Embedded Workbench when you create a new project, selecting “ARM926EJ-S” as your target. It is your responsibility to customize these settings for your particular device, including changing the – cpu compiler switch to match your target CPU, and modifying a linker file that will accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note: The size of the test harness is not static – it is dependent on the size and composition of the code under test. Refer to IAR’s documentation for more information on customizing linker files. The “Preprocessor/Compiler” tab contains the compiler options that will be used to compile the test harness. The “Linker” tab contains the linker options, libraries to be linked, linker file specification, heap and stack size that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. For example, if you are using a target other than the default ARM926EJ-S target device, you would change the “Linker Options” entry to reference the appropriate .icf linker file instead of the default “AT91SAM9261_iRAM.icf .” If you find that the test harness isn’t linking properly and plan on modifying AT91SAM9261_iRAM.icf, it is strongly recommended that you make a copy of AT91SAM9261_iRAM.icf and name it something unique, like “AT91SAM9261_iRAM.icf.save.” Specific details and discussion of the options that ilinkarm.exe accept are outside the scope of this document. Refer to IAR’s compiler and linker documentation for more information on this topic. Target Execution VectorCAST utilizes the IAR application “cspybat.exe” to execute the test harness on the target. This application allows target execution to occur without the requirement of starting IAR Embedded Workbench IDE or C-Spy debugger. The execution occurs automatically and requires no input from the user. This test case execution is invoked using the command specified in the Debugger command: edit box which can be found in the Tools->Options dialog box, selecting the C/C++ Debug tab. The default command specifies using a J-Link connection to the target and a startup macro “AT91SAM9261_ iRAM.mac” that you may need to replace with a macro customized for your target. See the view below: When executing a test case (for example, PLACE_ORDER.001 in the User’s Guide Tutorial) you should see a progress bar indicating the test case is being downloaded and executed on the target. IAR EMBEDDED WORKBENCH 5.X ARM 9 201 Also, upon completion of the test case, you should see the following output in the Message tab across the bottom of VectorCAST: Running C-SPY Debugger to execute program Building Execution Report Created Execution Report Updating Coverage Data Test Execution Complete Just prior to test case execution, VectorCAST copies the test harness executable, UUT_INTE.EXE or the UUT_INST.EXE, depending on whether you have coverage enabled, to a file named vcast_debug.out. In cases of failed test case execution, one can possibly get more information as to the nature of the failure by running this command from a DOS shell. To do so, navigate to the environment directory and run the exact same Debugger Command that is found in the Tools => Options, C/C++ tab, Debug tab, edit box “Debugger Command.” The cspybat.exe will provide you with some indication as to why the target execution is failing. Refer to IAR’s documentation for more information on the cspybat.exe application. Note: VectorCAST runs the Debugger Command as is, but redirects its output to VCAST_ STDOUT.DAT with the redirection (‘>’) shell operator. Target Debug Execution Test case Execution with Debug can be performed by right-clicking on a particular test case and selecting “Execute with Debug”. VectorCAST will automatically invoke the IAR Embedded Workbench IDE with a default project and workspace setup. In addition, on the first time the user Executes With Debug, an Information dialog box will pop up (shown below) that describes what VectorCAST will be doing on the user’s behalf and the user’s required actions, which basically involves clicking the Download & Debug IAR EMBEDDED WORKBENCH 5.X ARM 9 202 button to initiate the debug session. Click OK in the Information dialog box and VectorCAST will then bring up the IAR IDE by running the IarIdePm.exe and you will see a “Processing… Abort “ progress box also appear with the IDE as shown below. At this point you can just click the Download & Debug button and begin your debug session. You can now debug the test harness and UUT code using the functionality that C-Spy provides. When you are finished debugging, allow the application to run to completion and select “Stop Debugging” to ensure that the I/O log file gets written to disk. Upon exiting the debug session and returning control to VectorCAST, if the message “Test case execution aborted” appears in VectorCAST’s Message tab, it is most likely because the I/O log file was never written. Upon successful completion of the test case you should see the follow messages appear in VectorCAST’s Message tab. IAR EMBEDDED WORKBENCH 5.X ARM 9 203 Preparing Test Data Running Test Case Compiling and Linking Input Data File... Compiling file Test Case Data Linking Environment Running IAR IDE to execute program Building Execution Report Created Execution Report Test Execution Complete IAR EMBEDDED WORKBENCH V6.3FOR AMTEL SAM3N 204 IAR Embedded Workbench v6.3 for Amtel SAM3N Configuration This section provides details about configuring VectorCAST to integrate with IAR’s Embedded Workbench version 5.5 or v6.3 and C-SPY debugger for the Atmel SAM3N processor. (Other releases of Embedded Workbench might require slight configuration changes.) Note that this RSP is designed specifically to support the Atmel sam3n_ek evaluation board, referred to as the SAM3N-EK, with the Atmel SAM3N processor and JTAG interface. Minor customizations will be required for other target processors including, but not limited to, modifications to the macro that supports your hardware and the linker command file. Specifying the IAR configuration and install directory paths: There are two the environment variables you need to set that will define the path for the directories where your IAR compiler is installed and where you are storing any necessary configuration files for your target. These are VCAST_IAR_INSTALL_DIR, for the path where your version of the IAR compiler is installed, and VCAST_SERIAL_CFG, for the path to the serial port configuration file. This RSP receives test result data via the serial port connection from the target back to the host PC. See below for examples of setting these environment variables: set VCAST_SERIAL_CFG=C:\sam3n_ek_serial_cfg.txt set VCAST_IAR_INSTALL_DIR=C:\PROGRA~1\IARSYS~1\EMBEDD~1.0\ARM IAR Embedded Workbench v6.3/v5.5 standard library configuration: Note: You can modify this template to also work with the older IAR EW v5.5 simply by changing the location of the Dlib config file referenced on the compiler options. This location has changed between IAR EW v5.5 and v6.3. For IAR EW v6.3, you can leave the Dlib config file location as the default setup in the template, which is --dlib_config $(VCAST_IAR_INSTALL_DIR)\inc\c\DLib_Config_Full.h For IAR EW v 5.5 the location is as follows: --dlib_config $(VCAST_IAR_INSTALL_DIR)\inc\DLib_Config_Full.h The two libraries that are included in the linker options for this target are the board and chip libraries (libboard_sam3n_ek_ewarm_dbg.a libchip_sam3n4_ewarm_dbg.a respectively ) that were built in the example projects provided for the sam3n-ek board for IAR for ARM EW v5.5. No example projects were provided for v6.3 at the time of this writing, but the v5.5 libs worked fine with the VectorCAST and IAR EW v6.3 integration. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “IAR => ARM CORTEX-M3 6.3 => SAM3N-EK => C” under the “Compiler” drop-down menu, as shown here: IAR EMBEDDED WORKBENCH V6.3FOR AMTEL SAM3N 205 IAR installation and target customizations: The default compiler and linker settings in the template for the SAM3N-EK should work as is for most test cases. Occasionally the user may need to customize these settings for their particular target and source code under test. Additionally, the cspybat command that is used to download the harness executable image onto the target may need to be modified. Details related to modifying these default settings are described below. 1. Select Tools => Options and Click the “Linker” tab. 2. The “Linker Options” text box contains all the linker options used during the link process invoked by VectorCAST. The linker options, includes a reference to the linker .icf file and libraries for the board and chip you are using. Replace the sam3n_ek_flash.icf linker file with the appropriate .icf file for your particular target and the board/chip libraries as needed. libboard_sam3n_ek_ewarm_dbg.a libchip_sam3n4_ewarm_dbg.a --config sam3n_ek_flash.icf 3. Open the ExecCspyJlinkCortex.bat file that has been copied to your test environment directory and edit the cspybat.exe command line as needed. Entries in bold on the command line below are likely candidates for modifications by the user. Note that the device description file is passed in as parameter %1 and the executable is parameter %2 cspybat.exe armproc.dll armjlink.dll %2 --plugin armbat.dll --macro sam3n-ek- flash.mac --flash_loader sam3n4-flash.board --backend -B "--endian=little" "-- cpu=Cortex-M3" "--fpu=None" "-p" %1 "--drv_verify_download" "--semihosting=none" "--device=SAM3N4" "--drv_communication=USB0" "--jlink_speed=adaptive" "--jlink_ reset_strategy=0,0" "--drv_catch_exceptions=0x000" It is your responsibility to customize these settings for your particular device, including changing the – IAR EMBEDDED WORKBENCH V6.3FOR AMTEL SAM3N 206 cpu compiler switch to match your target CPU, and modifying a linker file that will accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note: The size of the test harness is not static – it is dependent on the size and composition of the code under test. Refer to IAR’s documentation for more information on customizing linker files. Specific details and discussion of the options that ilinkarm.exe accept are outside the scope of this document. Refer to IAR’s compiler and linker documentation for more information on this topic. Target Execution VectorCAST utilizes the IAR application “cspybat.exe” to execute the test harness on the target. This application allows target execution to occur without the requirement of starting IAR Embedded Workbench IDE or C-Spy debugger. The execution occurs automatically and requires no input from the user. The SAM3N_EK board uses a COM port connection to deliver test result data and VectorCAST will automatically start the $VECTORCAST_DIR\IO\comreader.exe executable on the host to capture the results of target execution. The default serial port settings for the comreader are port "COM1", baud 9600, no parity, 8 data bits, and 1 stop bit. If you need other settings, you can specify a configuration file with the VCAST_SERIAL_CFG environment variable as mentioned above in the configuration section. The contents of the file specified by VCAST_SERIAL_CFG should have each option on a separate line. For example, to use the COM2 port, and the default BAUD rate settings for the SAM3N-EK board you could use these settings: COM2 115200 N 8 1 The comreader is started before test execution and stops when the debugger exits. Remember to close any other applications, such as HyperTerminal, that are reading from the same port, before executing tests. Test case execution is invoked using the ExecCspyJlinkCortex.bat file specified in the “execute command:” on the Tools->Options C/C++ tab. The default command specifies using a J-Link connection to the target and a startup macro “sam3n-ek-flash.mac” that you may need to replace with a macro customized for your target. When executing a test case (for example, PLACE_ORDER.001 in the User’s Guide Tutorial) you should see a progress bar indicating the test case is being downloaded and executed on the target by running the ExecCspyJlinkCortex.bat file. IAR EMBEDDED WORKBENCH V6.3FOR AMTEL SAM3N 207 Also, upon successful completion of the test case, you should see the following output in the Message tab across the bottom of VectorCAST: Running Test Case Compiling file Test Case Data Linking Environment Running ExecCspyJlinkCortex.bat C:\PROGRA~2\IARSYS~1\EMBEDD~1.0\ARM\config\debugger\Atmel\iosam3n.ddf C:\bub\vcast\iar_ arm_63_gambro_01_cpp\T1\UUT_INTE.out to execute program Building Execution Report Created Execution Report Test Execution Complete Target Debug Execution Test case Execution with Debug can be performed by right-clicking on a particular test case and selecting “Execute with Debug”. VectorCAST will automatically invoke the IAR Embedded Workbench IDE with a default project and workspace setup. In addition, an Information dialog box will pop up (shown below) that describes what VectorCAST will be doing on the user’s behalf and the user’s required actions. This basically involves configuring the JTAG connection and clicking the Download & Debug button to initiate the debug session. Click OK in the Information dialog box and VectorCAST will then bring up the IAR IDE by running the IarIdePm.exe and you will see a “Processing… Abort “ progress box also appear with the IDE as shown IAR EMBEDDED WORKBENCH V6.3FOR AMTEL SAM3N 208 below. After you have properly configured the JTAG debug connection to the target described in the debug instructions dialog box, you can just click the Download & Debug button and begin your debug session. You can now debug the test harness and UUT code using the functionality that the C-Spy debugger provides. When you are finished debugging, allow the application to run to completion and select “Stop Debugging”. Upon successful completion of the test case you should see the follow messages appear in VectorCAST’s Message tab. Preparing Test Data Running Test Case Compiling file Test Case Data Linking Environment Running IarIdePm_Serial.bat UUT_INTE.out to execute program Building Execution Report Created Execution Report Test Execution Complete IAR EMBEDDED WORKBENCH FOR DSPIC 209 IAR Embedded Workbench for dsPIC Configuration This section provides details about configuring VectorCAST to integrate with IAR’s C/C++ compiler version 1.4 for dsPIC, the IAR Embedded Workbench version 5.0 IDE, and the C-SPY debugger for the dsPIC processor. (Note that future releases of IAR’s Embedded Workbench, C/C++ compiler for dsPIC, or C-SPY debugger may or may not require slight configuration changes.) Note that this RSP is designed to support the dsPIC simulator interface. Minor customizations will be required for other dsPIC targets including modifications to the macro that supports your hardware and the linker command file as needed. Specifying the IAR install directory paths: The user must set an environment variable that defines the path to where your IAR compiler is installed on your host. This variable is named VCAST_IAR_INSTALL_DIR and must be set accordingly. For example: set VCAST_IAR_INSTALL_DIR=C:\PROGRA~1\IARSYS~1\EMBEDD~1.0\dsPIC First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “IAR => dsPIC 1.x => SIM => C” under the “Compiler” drop-down menu, as shown here: IAR EMBEDDED WORKBENCH FOR DSPIC 210 IAR installation and target customizations: 1. Click the “Linker/Debug” tab. 2. The “Linker Options” text box contains a reference to the linker .xcl file. Replace the iar_ lnkdspic_16kRAM.xcl linker file with the appropriate .xcl file for your particular simulator configuration. Note that the default .xcl file provided specifies 16K of RAM, which is the minimum required to support VectorCAST with this compiler. -B -l vcast_debug.map –xmsnio $(VCAST_IAR_INSTALL_DIR)\LIB\clib\cldspic2lf.r59 -I$(VCAST_IAR_INSTALL_DIR)\LIB\ -f iar_lnkdspic_16kRAM.xcl -D_HEAP_SIZE=800 -D_STACK_SIZE=600 -rt -s __program_start 3. You may also adjust the HEAP and STACK size in the same “Linker Options” text box. 4. Modify the device description file as needed in the “Debugger command:” text box. Note that by default it is set to $(VCAST_IAR_INSTALL_DIR)\Config\io24hj256gp610.ddf. cspybat dspicproc.dll dspicsim.dll vcast_debug.out --plugin dspicbat.dll --backend -B -p $(VCAST_IAR_INSTALL_DIR)\Config\io24hj256gp610.ddf -d sim --sim_guard_stacks These default settings should be sufficient to run the Tutorial example in the VectorCAST/C++ User’s Guide, and it is strongly recommended that you do so before trying to test your application code. The compile and link options are initially set to match the defaults provided by IAR’s Embedded Workbench when you create a new project, selecting dsPIC as your target. It is your responsibility to customize these settings for your particular device, including changing the – cpu compiler switch to match your target CPU, and modifying a linker file that will accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note: The size of the test harness is not static – it is dependent on the size and composition of the code under test. Refer to IAR’s documentation for more information on customizing linker files. The “Preprocessor/Compiler” tab contains the compiler options that will be used to compile the test harness. The “Linker” tab contains the linker options, libraries to be linked, linker file specification, heap and stack size that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. For example, if you are using a target other than the default pic24 target device, you would need to change the --cpu= option and possibly the –-data model= option on the “Compile Command:” text box. Specific details and discussion of the options that iccdspic.exe accepts are outside the scope of this document. Refer to IAR’s compiler and linker documentation for more information on this topic. IAR EMBEDDED WORKBENCH FOR DSPIC 211 Target Execution VectorCAST utilizes the IAR application “cspybat.exe” to execute the test harness on the simulator. This application allows simulator execution to occur without the requirement of manually starting up the IAR Embedded Workbench IDE. The execution occurs automatically and requires no input from the user. This test case execution is invoked using the command specified in the “Debugger command” edit box which can be found in the Tools => Options dialog box, selecting the C/C++ tab, then the Linker/Debug tab. The default command specifies using the simulator connection by virtue of specifying the dspicsim.dll and passing the –d sim argument. cspybat dspicproc.dll dspicsim.dll vcast_debug.out --plugin dspicbat.dll --backend -B -p $(VCAST_IAR_INSTALL_DIR)\Config\io24hj256gp610.ddf -d sim --sim_guard_stacks After executing a test case on the C-SPY simulator, you see the results displayed in the execution report window. Also, upon completion of the test case, you should also see the following output in the Message tab across the bottom of VectorCAST: Running C-SPY Debugger to execute program Building Execution Report Created Execution Report Updating Coverage Data Test Execution Complete Just prior to test case execution, VectorCAST copies the test harness executable to a file named vcast_ debug.out. The test case executable is UUT_INTE.EXE if you don’t have coverage enabled or UUT_ INST.EXE if coverage is enabled. In cases of failed test case execution, the user can possibly get more information as to the nature of the failure by running the debugger command from a DOS shell. To do so, navigate to the environment directory and run the exact same Debugger Command that is found in the Tools => Options, C/C++ tab, Linker/Debug tab, edit box “Debugger Command.” The cspybat.exe will provide you with some indication as to why the target execution is failing. Refer to IAR’s documentation for more information on the cspybat.exe application. IAR EMBEDDED WORKBENCH FOR DSPIC 212 Note: VectorCAST runs the Debugger Command as is, but redirects its output to VCAST_ STDOUT.DAT with the redirection (‘>’) shell operator. Target Debug Execution Test case Execution with Debug can be performed by right-clicking on a particular test case and selecting “Execute with Debug”. VectorCAST will automatically invoke the IAR Embedded Workbench IDE with a default project and workspace setup. In addition, on the first time the user Executes With Debug, an Information dialog box will pop up (shown below) that describes what VectorCAST will be doing on the user’s behalf and the user’s required actions, which basically involves clicking the Download & Debug button to initiate the debug session. Click OK in the Information dialog box and VectorCAST will then bring up the IAR IDE by running the IarIdePm.exe and you will see a “Processing… Abort “ progress box also appear with the IDE as shown below. IAR EMBEDDED WORKBENCH FOR DSPIC 213 At this point you can just click the Download & Debug button and begin your debug session. You can now debug the test harness and UUT code using the functionality that C-Spy provides. When you are finished debugging, allow the application to run to completion and select “Stop Debugging” to ensure that the I/O log file gets written to disk. Upon exiting the debug session and returning control to VectorCAST, if the message “Test case execution aborted” appears in VectorCAST’s Message tab, it is most likely because the I/O log file was never written. Upon successful completion of the test case you should see the follow messages appear in VectorCAST’s Message tab. Preparing Test Data Running Test Case Compiling and Linking Input Data File... Compiling file Test Case Data Linking Environment Running IAR IDE to execute program Building Execution Report Created Execution Report Test Execution Complete IAR EMBEDDED WORKBENCH FOR PIC24 TARGET 214 IAR Embedded Workbench for PIC24 target Configuration This section provides details about configuring VectorCAST to integrate with IAR’s C/C++ compiler version 1.4 for dsPIC, the IAR Embedded Workbench version 5.0 IDE, and the C-SPY debugger for the dsPIC processor. (Note that future releases of IAR’s Embedded Workbench, C/C++ compiler for dsPIC, or C-SPY debugger may or may not require slight configuration changes.) Note that this RSP is designed to support the dsPIC PIC24 target interface to a custom target prototype (LMCOTGT). Minor customizations will be required for other PIC24 targets including modifications to the macro that supports your hardware and the linker command file as needed. Specifying the IAR install directory paths: The user must set an environment variable that defines the path to where your IAR compiler is installed on your host. This variable is named VCAST_IAR_INSTALL_DIR and must be set accordingly. For example: set VCAST_IAR_INSTALL_DIR=C:\PROGRA~1\IARSYS~1\EMBEDD~1.0\dsPIC First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “IAR => dsPIC 1.x => LMCOTGT => C” under the “Compiler” drop-down menu, as shown here: IAR EMBEDDED WORKBENCH FOR PIC24 TARGET 215 IAR installation and target customizations: 1. Click the “Linker/Debug” tab. 2. The “Linker Options” text box contains a reference to the linker .xcl file. Replace the iar_ pic24_lnkdspic.xcl linker file with the appropriate .xcl file for your particular target configuration. Note that the default .xcl file provided specifies 16K of RAM, which is the minimum required to support VectorCAST with this compiler. The linker option default settings are shown below. -B -l vcast_debug.map -xmsnio -I$(VCAST_IAR_INSTALL_DIR)\LIB\ -f $(VECTORCAST_ DIR)\DATA\iar\dspic\tgt\iar_pic24_lnkdspic.xcl $(VCAST_IAR_INSTALL_DIR)\LIB\dlib\dldspic2lf.r59 -e_ScanfSmall=_Scanf -D_HEAP_ SIZE=800 -D_STACK_SIZE=800 -rt -Ocoff=vcast_debug.cof -s __program_start 3. You may also adjust the HEAP and STACK size in the same “Linker Options” text box. 4. Modify the device description file as needed in the “Debugger command:” text box. Note that by default it is set to $(VCAST_IAR_INSTALL_DIR)\Config\io24hj256gp610.ddf. cspybat dspicproc.dll dspicemu_ri.dll vcast_debug.out --plugin dspicbat.dll -- backend -B -p $(VECTORCAST_DIR)\DATA\iar\dspic\tgt\io24fj256gb110.ddf -d "emuRealIce" These default settings should be sufficient to run the Tutorial example in the VectorCAST/C++ User’s Guide, and it is strongly recommended that you do so before trying to test your application code. The compile and link options are initially set to match the defaults provided by IAR’s Embedded Workbench when you create a new project, selecting dsPIC as your target. It is your responsibility to customize these settings for your particular device, including changing the – cpu compiler switch to match your target CPU, and modifying a linker file that will accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note: The size of the test harness is not static – it is dependent on the size and composition of the code under test. Refer to IAR’s documentation for more information on customizing linker files. The “Preprocessor/Compiler” tab contains the compiler options that will be used to compile the test harness. The “Linker” tab contains the linker options, libraries to be linked, linker file specification, heap and stack size that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. For example, if you are using a target other than the default pic24 target device, you would need to change the -cpu= option and possibly the –data model= option on the “Compile Command:” text box. Specific details and discussion of the options that iccdspic.exe accepts are outside the scope of this document. Refer to IAR’s compiler and linker documentation for more information on this topic. Target Execution The warning dialog shown below is displayed the first time you execute a test case on the target to warn IAR EMBEDDED WORKBENCH FOR PIC24 TARGET 216 the user about the slow I/O mechanism utilized through the JTAG interface on this target. VectorCAST utilizes the IAR application “cspybat.exe” to execute the test harness on the target. Note that the connection to the target in this case was through a Microchip MPLAB Real-ICE emulator. This application allows target execution to occur without the requirement of manually starting up the IAR Embedded Workbench IDE. The execution occurs automatically and requires no input from the user. This test case execution is invoked using the command specified in the “Debugger command” edit box which can be found in the Tools => Options dialog box, selecting the C/C++ tab, then the Linker/Debug tab. The default command specifies using the target emulator connection by virtue of specifying the dspicemu_ri.dll and passing the –d "emuRealIce" argument. cspybat dspicproc.dll dspicemu_ri.dll vcast_debug.out --plugin dspicbat.dll --backend -B - p $(VECTORCAST_DIR)\DATA\iar\dspic\tgt\io24fj256gb110.ddf -d "emuRealIce" After executing a test case you see the results displayed in the execution report window. Also, upon completion of the test case, you should also see the following output in the Message tab across the bottom of VectorCAST: Running C-SPY Debugger to execute program IAR EMBEDDED WORKBENCH FOR PIC24 TARGET 217 Building Execution Report Created Execution Report Updating Coverage Data Test Execution Complete Just prior to test case execution, VectorCAST copies the test harness executable to a file named vcast_ debug.out. The test case executable is UUT_INTE.EXE if you don’t have coverage enabled or UUT_ INST.EXE if coverage is enabled. In cases of failed test case execution, the user can possibly get more information as to the nature of the failure by running the debugger command from a DOS shell. To do so, navigate to the environment directory and run the exact same Debugger Command that is found in the Tools => Options, C/C++ tab, Linker/Debug tab, edit box “Debugger Command.” The cspybat.exe will provide you with some indication as to why the target execution is failing. Refer to IAR’s documentation for more information on the cspybat.exe application. Note: VectorCAST runs the Debugger Command as is, but redirects its output to VCAST_ STDOUT.DAT with the redirection (‘>’) shell operator. Target Debug Execution The warning dialog shown below is displayed the first time you execute a test case on the target to warn the user about the slow I/O mechanism utilized through the JTAG interface on this target. Test case Execution with Debug can be performed by right-clicking on a particular test case and selecting “Execute with Debug”. VectorCAST will automatically invoke the IAR Embedded Workbench IDE with a default project and workspace setup. In addition, on the first time the user Executes With Debug, an Information dialog box will pop up (shown below) that describes what VectorCAST will be doing on the user’s behalf and the user’s required actions, which basically involves clicking the Download & Debug button to initiate the debug session. IAR EMBEDDED WORKBENCH FOR PIC24 TARGET 218 Click OK in the Information dialog box and VectorCAST will then bring up the IAR IDE by running the IarIdePm.exe and you will see a “Processing… Abort “ progress box also appear with the IDE as shown below. At this point you can just click the Download & Debug button and begin your debug session. You can now debug the test harness and UUT code using the functionality that C-Spy provides. When you are finished debugging, allow the application to run to completion and select “Stop Debugging” to ensure that the I/O log file gets written to disk. Upon exiting the debug session and returning control to VectorCAST, if the message “Test case execution aborted” appears in VectorCAST’s Message tab, it is most likely because the I/O log file was never written. Upon successful completion of the test case you should see the follow messages appear in VectorCAST’s Message tab. IAR EMBEDDED WORKBENCH FOR PIC24 TARGET 219 Preparing Test Data Running Test Case Compiling and Linking Input Data File... Compiling file Test Case Data Linking Environment Running IAR IDE to execute program Building Execution Report Created Execution Report Test Execution Complete IAR EMBEDDED WORKBENCH 5.X FOR AMTEL AVR 220 IAR Embedded Workbench 5.x for Amtel AVR Configuration This section provides details about configuring VectorCAST to integrate with IAR’s Embedded Workbench version 5.51 and C-SPY debugger for the Amtel AVR family of microcontrollers. (Future releases of Embedded Workbench might require slight configuration changes.) Note that this RSP is designed to support the simulator for the generic –v3 enhanced core version of the AVR processor family. Minor customizations will be required for other AVR target simulations including modifications to the macro that supports your hardware and the linker command file. Specifying the IAR install directory paths: The user must set an environment variable, VCAST_IAR_INSTALL_DIR, that defines the directory where your version of the IAR compiler is installed. The user must also be sure that the compiler and linker commands are on your path as shown in the example below. Adjust the path as needed for the install location on your machine. set VCAST_IAR_INSTALL_DIR=C:\PROGRA~1\IARSYS~1\EMBEDD~1.4\ set path=C:\PROGRA~1\IARSYS~1\EMBEDD~1.4\avr\bin;%path% set path=C:\PROGRA~1\IARSYS~1\EMBEDD~1.4\common\bin;%path% First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “IAR => AMTEL AVR 5.51 => C” under the “Compiler” drop-down menu, as shown here: These default settings should be sufficient to run the Tutorial example in the VectorCAST/C++ User’s Guide, and it is strongly recommended that you do so before trying to test your application code. The compile and link options are initially set to match the defaults provided by IAR’s Embedded Workbench when you create a new project, selecting “-v3 –enhanced_core” as your processor configuration. IAR EMBEDDED WORKBENCH 5.X FOR AMTEL AVR 221 It is your responsibility to customize these settings for your particular device, including changing the – cpu compiler switch or the generic processor switch setting –v4 to match your target processor, and modifying a linker file that will accommodate the size of the code under test plus the VectorCAST test harness that is used to drive the code under test. Note: The size of the test harness is not static – it is dependent on the size and composition of the code under test. Refer to IAR’s C/C++ Compiler Reference Guide documentation for more information on customizing linker files, the desired memory model, and the C runtime environment. After determining what the appropriate settings are for your desired processor target, then you can make the changes required in VectorCAST on the compiler and linker command lines which you can get to by selecting Tools=>Options=>C/C++ tab and editing in the “Preprocessor/Compiler” and “Linker/Debug” tabs. As an example of such a processor customization, to change the default settings to –v4 processor and large memory model, the user would change the following settings in on the compiler and linker command lines. The user must also modify the ExecCspySimAvr.bat file to specify the desired processor type. l Change -v3 to -v4 on the compiler command l Change lnk3s.xcl to lnk4l.xcl on the linker command l Change -v3 to -v4 in the ExecCspySimAvr.bat file Target Execution VectorCAST utilizes the IAR application “cspybat.exe” to execute the test harness on the simulator. This application allows target simulator execution to occur without the requirement of starting IAR Embedded Workbench IDE or C-Spy debugger. The execution occurs automatically and requires no input from the user. The test case execution is invoked using the bat file, ExecCspySimAvr.bat, which is specified in the execution method for this compiler template. The default ExecCspySimAvr.bat specifies using a simulator connection to the –v3 processor target. The contents of the ExecCspySimAvr.bat are shown below that you may need to customize for your target. @echo off cspybat.exe avrproc.dll avrsim.dll %1 --plugin avrlibsupportbat.dll --backend -B "-v3" "-- enhanced_core" "--disable_internal_eeprom" "-d" "sim" Upon completion of the test case, you should see the following output in the Message tab across the bottom of VectorCAST: Running ExecCspySimAvr.bat C:\bub\vcast\iar_avr_5x_sim03\S1\UUT_INTE.EXE > VCAST_ STDOUT.DAT to execute program Building Execution Report Created Execution Report Test Execution Complete IAR EMBEDDED WORKBENCH 5.X FOR AMTEL AVR 222 Target Debug Execution Test case Execution with Debug can be performed by right-clicking on a particular test case and selecting “Execute with Debug”. VectorCAST will automatically run the debugger bat file, IarIdePm.bat, which invokes the IAR Embedded Workbench IDE with a default project and workspace setup. In addition, on the first time the user Executes With Debug, VectorCAST will display a text file that describes what VectorCAST will be doing on the user’s behalf and the user’s required actions to initiate the debug session. VectorCAST will then bring up the IAR IDE by running the IarIdePm.exe and you will see a “Processing… Abort “ progress box also appear with the IDE as shown below. Follow the instructions described in the text file to configure the terminal I/O, and download and debug the executable. IAR EMBEDDED WORKBENCH 5.X FOR AMTEL AVR 223 You can now debug the test harness and UUT code using the functionality that C-Spy provides. When you are finished debugging, allow the application to run to completion and select “Stop Debugging” to ensure that the I/O log file gets written to disk. Upon exiting the debug session and returning control to VectorCAST, if the message “Test case execution aborted” appears in VectorCAST’s Message tab, it is most likely because the I/O log file was never written. Upon successful completion of the test case you should see the follow messages appear in VectorCAST’s Message tab. Preparing Test Data Running Test Case Compiling file Test Case Data Linking Environment Running IarIdePm.bat C:\bub\vcast\iar_avr_5x_sim03\S1\UUT_INTE.EXE > VCAST_STDOUT.DAT to execute program Building Execution Report Created Execution Report Test Execution Complete KEIL 224 Keil Configuration for the C166 This section provides details about configuring VectorCAST to integrate with the Keil C166 C/C++ compiler. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “Keil C166” under the “Compiler” drop-down menu, as shown here: Second, ensure that the directories containing the Keil binaries are included in your PATH environment variable. These are most likely C:\Keil\C166\bin and C:\Keil\UV3, but may be slightly different on your particular system. Third, ensure that the C166INC and C166LIB environment variables are set. If your Keil installation directory is C:\Keil, then these should be C:\Keil\C166\inc and C:\Keil\C166\lib, respectively. To specify a different Keil installation directory: 1. On the Preprocessor/Compiler tab, change the Default source directories for wizard entry to match the location of the c166\inc directory on your system. 2. On the Compiler Integration tab, change the Startup file entry to match the location of the Start_ v2.a66 file on your system. KEIL 225 3. Click Apply to save the changes. The default command settings should be sufficient to run the Tutorial example in the VectorCAST/C++ User’s Guide, and it is strongly recommended that you do so before trying to test your application code. It is your responsibility to customize these settings for your particular device and development environment. The “Preprocessor/Compiler” and “Compiler Integration” tabs contain the compiler commands and options that will be used to compile the test harness. The startup file on the Compiler Integration tab is copied into the environment directory as start.a6. The assembler command on the Compiler Integration tab is used to assemble the startup file. The size of the memory pool is controlled by the defined variable VCAST_MEM_POOL_SIZE. It is set to 0x800 by default. The memory pool and some configuration flags are set up in the vcast_keil_setup function in the vcast_keil_setup.h file in the environment directory. The template of the vcast_keil_setup.h file is in the DATA directory of your VectorCAST installation. If you change this version of the setup file, all future environments will be affected. If you are using C++, the Pre-compile command on the Compiler Integration tab specifies the command for the EC166 compiler. The Pre-compile extension specifies the file extension of the intermediate file generated by the EC166 Compiler. After that file is generated, the Compile command from the Preprocessor/Compiler tab is invoked to obtain an object file. KEIL 226 The “Linker” tab contains the linker commands and options that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. Specific details and discussion of the options that c166.exe and ec166.exe accept is outside the scope of this document. Refer to Keil Software’s compiler and linker documentation for more information on this topic. KEIL 227 Lastly, click OK to save the settings and close the options dialog. Configuration for the C51 This section provides details about configuring VectorCAST to integrate with the Keil C51 C/C++ compiler. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “Keil C51” under the “Compiler” drop-down menu, as shown here: Second, ensure that the directories containing the Keil binaries are included in your PATH environment variable. These are most likely C:\Keil\C51\bin and C:\Keil\UV3, but may be slightly different on your particular system. To specify a different Keil installation directory: 1. On the Preprocessor/Compiler tab, change the Default source directories for wizard entry to match the location of the c51\inc directory on your system. 2. On the Compiler Integration tab, change the Startup file entry to match the location of the STARTUP.A51 file on your system. KEIL 228 3. Click Apply to save the changes. The default command settings should be sufficient to run the Tutorial example in the VectorCAST/C++ User’s Guide, and it is strongly recommended that you do so before trying to test your application code. It is your responsibility to customize these settings for your particular device and development environment. The “Preprocessor/Compiler” and “Compiler Integration” tabs contain the compiler commands and options that will be used to compile the test harness. The startup file on the Compiler Integration tab is copied into the environment directory. The assembler command on the Compiler Integration tab is used to assemble the startup file. The size of the memory pool is controlled by the defined variable VCAST_ MEM_POOL_SIZE. It is set to 0x950 by default. The memory pool and some configuration flags are set up in the vcast_keil_setup function in the vcast_keil_setup.h file in the environment directory. The template of the vcast_keil_setup.h file is in the DATA directory of your VectorCAST installation. If you change this version of the setup file, all future environments will be affected. The “Linker” tab contains the linker commands and options that will be used to link the test harness. KEIL 229 When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. Specific details and discussion of the options that c51.exe and lx51.exe accept is outside the scope of this document. Refer to Keil Software’s compiler and linker documentation for more information on this topic. Lastly, click OK to save the settings and close the options dialog. Target Execution For execution with the Keil mvision debugger, VectorCAST copies the executable to a file called keil.exe. Then it will automatically invoke the mvision debugger with the project file keil.uv2 if you are using the C166 or keil_c51.uv2 for the C51. The project file invokes a script file called keil_execute.ini which is similar to the following: reset load keil.exe slog > VCAST_STDOUT.DAT bs vCAST_END g slog off bk * reset reset map exit The script loads the executable, sends output to a file, runs the executable, and exits the debugger. The template for the keil_execute.ini script is in the DATA\keil directory of your VectorCAST installation. If you change this version of the script, all future environments will be affected. The template for the keil.uv2 file is also in the DATA directory. Target Debug Execution For debugging with the Keil mvision debugger, VectorCAST copies the executable to a file called keil.exe. Then it will automatically invoke the mvision debugger with the project file keil_debug.uv2 for the C166 or keil_c51_debug.uv2 for the C51. The project file invokes a script file called keil_debug.ini which is similar to the following: reset load keil.exe slog > VCAST_STDOUT.DAT bs vCAST_END bs vCAST_END__Fv The script loads the executable, starts sending output to a file, and sets a breakpoint at the end of the program. The template for the keil_debug.ini script is in the DATA directory of your VectorCAST installation. If you change this version of the script, all future environments will be affected. The templates for the keil_debug.uv2 file and the keil_c51_debug.uv2 file are also in the DATA directory. If you allow the execution to reach the end of the driver main program, you can get the execution results by calling KEIL 230 slog off in the debugger to close the output file before exiting. The first time you execute with debug, you will get a reminder of how to do this: KEIL FOR ARM 231 Keil for ARM Configuration This section provides details about configuring VectorCAST to integrate with the Keil compiler for ARM chips. Two types of chips are supported out-of-the-box on a simulator: the LPC2106 from Phillips and the LM3S6911 from Luminary Micro (now Texas Instruments). Support for additional chips from the same or other families of chips can also be arranged. For support for other targets, please contact your VectorCAST representative. Before launching VectorCAST, please ensure that Keil for ARM is correctly set. When using Keil for ARM with VectorCAST, this is not done automatically. There are a total of three different directories that need to become part of your PATH environment variable. An example script under DOS could look like the following: set RVCT31INC=C:\Keil\ARM\RV31\INC set RVCT31LIB=C:\Keil\ARM\RV31\lib set PATH=C:\Keil\ARM\BIN31;C:\Keil\UV3;%PATH% You should remember to either (1) set these directories permanently in your PATH environment variable or (2) set these temporarily in an OS shell. In the latter case, please remember to launch VectorCAST from within that shell. Thereafter, please select the appropriate template from VectorCAST/C++. KEIL FOR ARM 232 In VectorCAST, just select the appropriate compiler template (Keil => ARM). Please note that depending on your installation, the template may need amendments. For instance, the Assembler command (located on the Compiler Integration subtab) lists an include directory (for instance, -I "C:\Keil\ARM\INC\Luminary"). This needs to be changed if this directory does not exist in your environment. Likewise, the following steps are or may be required in the case of the following types of boards: Luminary Micro boards (such as the LM3S6911) The integration requires that the StellarisWare is downloaded and installed on your host. This free download from https://www.luminarymicro.com/ (search for “StellarisWare”) contains additional libraries that make it possible, among other things, to communicate through UART. VectorCAST leverages these libraries. It is therefore important they are installed. Depending on where the StellarisWare libraries are installed, the linker command (Linker/Debug sub-tab) may also need to be amended (please find --userlibpath "C:\StellarisWare\driverlib\rvmdk" within the linker command and amend the path as needed). For C++ on versions of Keil before 3.4 It was found on version 3.2 that the Assembler command is incorrect, and will cause a failure in code startup sequence. Please use this assembler command, which does not specify MICROLIB. armasm --device DLM -g --apcs=interwork -I "C:\Keil\ARM\INC\Luminary" –xref For C++ on Keil 3.4 For version 3.4 of the compiler, the full Assembler command line should be: armasm --device DLM -g --apcs=interwork --pd "__MICROLIB SETA 1" -I "C:\Keil\ARM\INC\Luminary" –xref Please note that not specifying MICROLIB under version 3.4 will cause a failure in code startup. It is your responsibility to customize these settings for your particular device and development environment. Please note that these changes will be saved as long as you will be using the same working directory. For more information about this, please contact your Vector Software representative. Target Execution Upon successful compilation and linkage, VectorCAST will automatically launch Keil microVision IDE to execute the test harness on a board or simulator. KEIL FOR ARM 233 Unless there is an error, there is no need for you to close Keil – it should close automatically. If the execution fails, you may need to forcefully close Keil for ARM by pressing the red stop button in the upper left corner of the Keil debugger interface. If all else fails, press Ctrl-Alt-Del (under Windows) and shut down the Uv3.exe process. If the execution fails, you may consider trying to run a test case from the debugger (next section). Target Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. Launching a debug execution of the test harness under Keil will launch the Keil IDE. You can therefore execute using the execute button at the top right (highlighted in red). A breakpoint is already set at the end of the test harness for your convenience. Once finished, merely close the instance of the Keil IDE VectorCAST launched and the results of the test will be read automatically by VectorCAST. If the test harness is not allowed to run until the end, an error may occur. KEIL FOR ARM 234 KEIL FOR ARM CORTEX M3 235 Keil for ARM Cortex M3 Configuration This section provides details about configuring VectorCAST to integrate with the Keil for ARM Cortex M3 compiler. This chapter describes the RSP implementation for a custom target with a STM32f103ZE processor on board. Support for additional chips from the same or other families of chips can also be arranged. This RSP was implemented using the Keil uVision4 IDE. (Version:µVision V4.21.0.0). For support on other targets, or other versions of the Keil IDE, please contact your VectorCAST representative. Before launching VectorCAST, you must ensure that Keil for ARM configuration is correctly set. When using Keil for ARM with VectorCAST, this is not done automatically. The user should set the following environment variables according to the installation location of Keil on your host PC before running VectorCAST. set RVCT31INC=C:\Keil\ARM\RV31\INC set RVCT31LIB=C:\Keil\ARM\RV31\lib set PATH=C:\Keil\ARM\BIN40;C:\Keil\UV4;%PATH% set VCAST_KEIL_ARM_INSTALL_DIR=C:\Keil\ You should remember to either (1) set these directories permanently in your PATH environment variable or (2) set these temporarily in an OS shell. In the latter case, please remember to launch VectorCAST from within that shell. Thereafter, please select the appropriate template from VectorCAST/C++ when building your new test environment. KEIL FOR ARM CORTEX M3 236 In VectorCAST, select the appropriate compiler template (Keil => ARM => STM32F10x => uVision4 => 4.2 => HwTgt => C). Please note that depending on your installation, the template may need amendments. Instrumentation Trace Macrocell (ITM) Configuration The ARM Cortex M3 processor core provides several system debug components. One of those system debug components is the Instrumentation Trace Macocell (ITM). The ITM allows for application-driven trace source that supports printf style debugging. Debug control and data access occurs through the Advanced High-performanceBus-Access Port (AHB-AP) interface. This interface is driven by either the Serial Wire Debug Port (SW-DP) or Serial Wire JTAG Debug Port (SWJ-DP) components. This RSP integration utilizes the capabilities of the ITM to capture test result data from the target. The configuration of the ITM stimulus ports and the Flash programming algorithm for this target is provided inside the Keil uVision project file that is copied to your test environment directory automatically by VectorCAST during the test environment creation process. The project file name is STM32_tgt.uvproj. The relevant project settings with respect to the target connection and ITM configuration are shown in the series of screen shots below. The specific settings displayed here may have to be modified to support your specific target clock speeds and selected debugger probe. It is your responsibility to customize these settings for your particular device and development environment. Please note that these changes will be saved as long as you will be using the same working directory. For more information about this, please contact your Vector Software representative. The following dialog is accessed from the Project => Options Menu. KEIL FOR ARM CORTEX M3 237 If you switch to the Utilities tab and then click “Settings” button, you will get the following view, which allows you to set up the Debug connection: Trace: KEIL FOR ARM CORTEX M3 238 and Flash Download Parameters: Integration Notes This RSP integration involved using the Keil Ulink Pro debugger probe to connect to the target board. This probe receives power from the USB connection to the host PC. Note that if you experience difficulties connecting to the target, try removing other USB connections from your host PC, and be sure that you are not going through a USB hub. On some host PC’s the USB connections in the front of the machine may go through an internal USB hub, and you may have better luck trying the USB connections in the back of the machine that may go directly to the USB interfaces on the motherboard. Note that two of the environment files that are included in the default template for this RSP, itm.h and config.h, are included so that a sample tutorial build will work to demonstrate the RSP functionality. Occasionally the user may choose to delete these files and point to their own configuration including KEIL FOR ARM CORTEX M3 239 something other than the default itm.h and config.h which were derived from the base install directory of the keil compiler tool chain. Target Execution Upon successful compilation and linkage, VectorCAST will automatically launch the Keil uVision IDE to execute the test harness on the board. VectorCAST uses a bat file to control both the “Execute” and the “Execute with Debug” methods. The bat file accepts several parameters, the first for the Keil project file that will be used when VectorCAST invokes the uVision IDE, and the second, a flag to indicate if you are executing in EXECUTE or DEBUG mode. The command for the execute mode is keil_stm32_execute.bat STM32_tgt.uvproj EXECUTE VectorCAST will automatically invoke the uVision IDE, download/program the harness executable into target Flash, run the executable, and exit the IDE upon successful completion of the harness. VectorCAST will automatically copy the appropriate execute .ini file (keil_stm32_tgt_exec.ini) to the project ini file (keil_stm32_tgt.ini) to enable the execute capability. Unless there is an error, there is no need for you to close Keil – it should close automatically. If the execution fails, you may need to forcibly close Keil for ARM by pressing the red stop button in the upper left corner of the Keil debugger interface. If all else fails, press Ctrl-Alt-Del (under Windows) and shut down the Uv4.exe process. If the execution fails, you may consider trying to run a test case from the debugger (next section). Target Debug Execution Test Execution with Debug functions similarly to normal execution, except VectorCAST will not run the executable automatically. The “Execute with Debug” command that gets executed is the following: keil_stm32_execute.bat STM32_tgt.uvproj DEBUG KEIL FOR ARM CORTEX M3 240 VectorCAST will automatically copy the appropriate debug .ini file (keil_stm32_tgt_debug.ini) to the project ini file (keil_stm32_tgt.ini) to enable the debug capability. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. Launching a debug execution of the test harness under Keil will launch the Keil IDE and you can execute using the execute button at the top right (highlighted in red). A breakpoint is already set at the end of the test harness for your convenience. Once finished, merely close the instance of the Keil IDE that VectorCAST launched and the results of the test will be read automatically by VectorCAST. If the test harness is not allowed to run until the end, an error may occur. While debugging, the user can view test result data that is getting transmitted back to the host via the ITM stimulus ports by selecting the “View => Serial Windows => Debug (printf) Viewer” in the uVision IDE as shown below. KEIL FOR ARM CORTEX M3 241 When you reach the end of the harness execution, i.e. reached the vCAST_END breakpoint that was set for this debug environment, you can simply exit out of the debugger and control will be switched back to VectorCAST to display your test results. LAUTERBACH TRACE32 242 Lauterbach TRACE32 Configuration This section provides details about configuring VectorCAST to integrate with Lauterbach TRACE32 debuggers and simulators. The templates included in the “Compilers” drop-down menu are only a few examples of integrations using TRACE32. Since TRACE32 replaces the default debugger provided with compilers, you can use VectorCAST with TRACE32 with a number of development environments, as long as VectorCAST already has a template for your specific compiler and board. Changes to be made to the template are described below. Before you can use VectorCAST with TRACE32, both the compiler and TRACE32 must be set on your PATH environment variable. This is not done by default during TRACE32 installation, so you must either (a) set these variables permanently in the operating system, or (b) set them temporarily from the shell, and then launch VectorCAST from within that shell. In a regular DOS shell, setting the compiler on your path may look like this: SET PATH=C:\T32;Path_for_your_compiler%PATH% Then, simply select the appropriate template from VectorCAST/C++, as shown below: If you are using TRACE32 with a compiler for which we do not provide a TRACE32 template, replace the compiler template’s execute command with the following: Execute command for emulator/board: $(VECTORCAST_DIR)\DATA\trace32\execute.bat mode executable file.cmm directory Execute command for simulator: LAUTERBACH TRACE32 243 $(VECTORCAST_DIR)\DATA\trace32\simulator.bat executable chip directory where: mode is SERIAL | NON_SERIAL If a serial port is available on your board and that you have the necessary code to initialize the serial port, replace mode with SERIAL. In addition, in Options => Target tab, both “Execute using stdout only” and “I/O uses stdout only” should be turned on. If a serial port is not available, replace mode with NON_SERIAL. In addition, in Options =>Target tab, turn on both “Execute using stdout only” and “Buffer I/O.” executable: The name of the executable to be used to invoke TRACE32. This depends on your chip. For instance, the name of the executable to be used with PPC/MPC chip is t32mppc.exe, so you can pass in t32mppc. To learn which executable should be used, select the Start menu entry you usually use to launch TRACE32, right-click on the entry and note the name of the executable. file.cmm: The name of the .cmm script file to be used. To generate this, you must (1) look at the .cmm file you are using during regular development, (2) copy any parts prior to the download of the image, and (3) copy from MPC5554.cmm (which is installed in %VECTORCAST_DIR%\DATA\trace32 directory) the last parts, from the download of the data to the end of the file. Then, provide the name of your file in the execute command. chip: The name of the chip that is to be simulated. This information can be retrieved from the .cmm file associated with the simulator. directory: The path to the TRACE32 installation, usually C:\T32. An example of a valid execute command would look like this: Example command for the emulator/board: $(VECTORCAST_DIR)\DATA\trace32\execute.bat SERIAL t32mppc mpc5554.cmm C:\T32 Example command for the simulator: $(VECTORCAST_DIR)\DATA\trace32\simulator.bat t32mppc mpc5554 C:\T32 In addition, you should also make similar modifications to the debug command, which can be retrieved from the Options => C/C++ => Linker/Debug tab: Debugger command for emulator/board: $(VECTORCAST_DIR)\DATA\trace32\execute.bat mode executable file.cmm directory However, the file.cmm file that is passed in should be another file which includes (1) the parts used for environment initialization, which come from the .cmm file used for ordinary development and (2) the latest part from MPC5554_debug.cmm (which is installed in %VECTORCAST_DIR%\DATA\trace32 directory), from the download of the target to the end of the file. Debugger command for simulator: $(VECTORCAST_DIR)\DATA\trace32\simulator_debug.bat executable chip directory LAUTERBACH TRACE32 244 Note that you must use simulator_debug.bat, not simulator.bat. The arguments are the same as above. In addition, in the case of emulators and boards, you must copy the .cmm file in your environment. Go to Options => C/C++ => Misc and select both the regular and debug version of the .cmm files described above. Finally, some compiler templates need some tune-in to work with TRACE32. For instance, Wind River Compiler (ex-Diab) requires the user to pass in the –Xelf argument to the linker command to generate an ELF executable file. Refer to your compiler manual to learn how to guarantee your compiler will generate an ELF or another file format compatible with TRACE32. It is your responsibility to customize these settings for your particular device and development environment. Please note that these changes will be saved as long as you will be using the same working directory. For more information about this, please contact your Vector Software representative. Target Execution In SERIAL mode, the $VECTORCAST_DIR\IO\comreader.exe executable is used to record the results of target execution. The default settings are port "COM1", baud 9600, no parity, 8 data bits, and 1 stop bit. If you need other settings, you can specify a configuration file with the VCAST_SERIAL_CFG environment variable. The file specified by VCAST_SERIAL_CFG should have each option on a separate line. For example, to use the COM2 port, you could use these settings: COM2 9600 8 N 1 The comreader is started before test execution and stops when the debugger exits. Remember to close any other applications, such as HyperTerminal, that are reading from the same port, before executing tests. Regular target execution will open a TRACE32 window, execute the code, save the data and automatically close the TRACE32 window upon harness termination. In the case of a problem, TRACE32 will generate an error and interrupt script execution. This will help you (or VectorCAST Technical Support) to troubleshoot the situation. However, in order to return to VectorCAST you must close the TRACE32 instance that was open during execution. In addition, if using TRACE32 on a board using the SERIAL mode, another executable called comreader.exe will be launched. In case of problems, comreader.exe will wait for data to come from the serial port. However, the data may never come. Use the Windows Task Manager to kill this process. Also, keep in mind that in the SERIAL mode, comreader.exe will use the default settings for serial port monitoring. The test harness will execute on the TASKING Script Debugger entirely automatically. The Script Debugger’s interface will not be launched. Target Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the LAUTERBACH TRACE32 245 main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. Launching a debug execution of the test harness under TRACE32 will launch the TRACE32 debugger. You will have access to the very same functionalities as in any TRACE32 environment. The execution will be stopped at the main function. If you need to get the results obtained during the execution under the control of the debugger, you must ensure that the test harness is enabled to run to its conclusion. For your convenience, a breakpoint is set at vCAST_END, which indicates the end of execution. If you are using the SERIAL mode, there is nothing more to do than to shut down the instance of TRACE32 that was spawned by VectorCAST. This will return control to VectorCAST. In this mode, if you close the TRACE32 window before test harness completion, shut down the DOS window associated with comreader.exe. If you are using the NON_SERIAL mode, the data will not be captured automatically. The data is saved to memory, so after a successful execution you must save the data by typing the following script in TRACE32: d.save.binary path_to_working_directory\stdout.txt y.range(vcast_output_buffer) This will save the data contained in vcast_output_buffer (the buffer containing the results of the test case (s)) to a file called stdout.txt which will be sent to the host’s stdout. That, in turn, will make the results available to VectorCAST/C++. MICROCHIP MPLAB DSPIC (PIC30) AND PIC24 246 Microchip MPLAB dsPIC (PIC30) and PIC24 Configuration This section provides details about configuring VectorCAST to integrate with Microchip MPLAB C30 for dsPIC DSCs and PIC24 MCUs. Specifying the Microchip install directory path: The user must configure an environment variable that will define the path for the directory where your Microchip compiler is installed. This environment variable is named VCAST_MICROCHIP_INSTALL_ DIR, and should be set accordingly. For example: set VCAST_MICROCHIP_INSTALL_DIR=C:\PROGRA~1\MICROC~1\MPLABC~1 Inside VectorCAST/C++, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “Microchip MPLAB C30” under the “Compiler” drop-down menu, as shown here: Microchip target customizations: 1. Select Tools => Options from the main toolbar and choose the C/C++. 2. Click the “Preprocessor/Compiler” tab. MICROCHIP MPLAB DSPIC (PIC30) AND PIC24 247 3. The “Compile command:” text box contains the compiler switch settings for your target. Replace the -mcpu=24HJ256GP610 setting with the appropriate cpu device for your target, and modify the designated memory model accordingly (e.g. -mlarge-data). Refer to the Microchip documentation for descriptions on the available devices, memory models, and their respective switch settings. 4. Select the “Linker/Debug” tab and modify the default linker command and linker options to suit the desired linker options for the target you wish to simulate. It is your responsibility to customize these settings for your particular device and development environment. Target Execution The Microchip RSP executes the code using the command-line simulator (called sim30). An RSP that executes on a particular target board is also possible. For more information, please contact a Vector Software representative. After inserting a test case and initializing the parameters, the user can execute the test case in the usual manner. You should see the following messages appear in the Message window indicating that the test data has been compiled and executed on the simulator. Preparing Test Data Running Test Case Compiling and Linking Input Data File... Compiling file Test Case Data Linking Environment Running MPLAB Simulator Debugger to execute program Building Execution Report During test case execution, the sim30 simulator is invoked by VectorCAST and passed a command script named vcast_pic30_exec.txt, which has been created and copied to your test environment directory. You may modify this command script to perform other operations supported by the sim30 command line simulator, or create your own script. If you choose to create your own script, you should use the same name, but put your custom script at another location. You can then point to this location by editing the path for this script file which can be found on the Tools => Options dialog, C/C++ tab, Misc sub-tab. Double-click on the desired file in the “Environment files:” area of the dialog box, and edit the path, as shown below: MICROCHIP MPLAB DSPIC (PIC30) AND PIC24 248 Target Debug Execution Currently, VectorCAST does not support the Test Execution with Debug feature for the Microchip RSP. Contact Vector Software for updated status on this. MICROCHIP MPLAB C30FOR PIC24 ON EXPLORER 16 249 Microchip MPLAB C30 for PIC24 on Explorer 16 Configuration This section provides details about configuring VectorCAST to integrate with Microchip MPLAB C30 for PIC24 on the Explorer 16 development board using the PICkit 3 emulator for the target connection. The default target type of pic24FJ128GA010 is used for this RSP, which is the target that the Explorer 16 comes configured with by default. Specifying the Microchip install directory path: You must configure an environment variable that will define the path for the directory where your Microchip compiler is installed as well as include the location of the compiler tool chain on your path. The environment variable is named VCAST_MICROCHIP_INSTALL_DIR, and should be set accordingly, see example below. set VCAST_MICROCHIP_INSTALL_DIR=C:\PROGRA~1\MICROC~1\MPLABC~2 set path=C:\PROGRA~1\MICROC~1\MPLABC~2\bin;%PATH% set path=C:\PROGRA~1\MICROC~1\MPLABI~2\Core;%PATH% Specifying the serial port configuration: This target uses an RS232 serial port to pass back test data results to VectorCAST running on the host. VectorCAST runs a comreader.exe application that will capture the serial port data from the target. You must configure an environment variable, VCAST_SERIAL_CFG, to point to a serial port configuration file which VectorCAST uses to properly initialize the UART device on the target board. Be sure that you have the right COM port number and baud rate specified in this file. The formatting of this data is shown in the example contents below, with a single entry per line. set VCAST_SERIAL_CFG=C:\vcast\serial_cfg.txt The contents of the serial port config file should be formatted as follows. COM8 19200 N 8 1 Inside VectorCAST/C++, select Tools => Options from the main toolbar and select the entry for “Microchip MPLAB C30 => PIC24 => Explorer 16 => C” under the “Compiler” drop-down menu, as shown here: MICROCHIP MPLAB C30FOR PIC24 ON EXPLORER 16 250 Microchip target customizations: 1. Select Tools => Options from the main toolbar and choose the C/C++ tab. 2. Click the “Preprocessor/Compiler” sub-tab. 3. The Compile command: text box contains the compiler switch settings for your target. Replace the -mcpu=24FJ128GA010 setting with the appropriate cpu device for your target, and modify the designated memory model accordingly (e.g. -mlarge-data). Refer to the Microchip documentation for descriptions on the available devices, memory models, and their respective switch settings. 4. Select the “Linker/Debug” sub-tab and modify the default linker command and linker options to suit the desired linker options for the target you wish to simulate. It is your responsibility to customize these settings for your particular device and development environment. Note that selecting processor variants with insufficient on-chip RAM resources may cause linker errors due to insufficient RAM to fit the image and RAM variables. Target Execution The Microchip RSP executes the code by downloading and programming the executable harness image on the development board. Microchip’s MPLAB IDE does not currently support any scripting feature to automate this process so the user must manually select that target image to download, program and finally Run that executable by selecting the appropriate commands in the IDE after VectorCAST starts up the MPLAB IDE for you. After inserting a test case and initializing the parameters, the user can execute the test case in the usual manner. When a test case is first created the IDE will be invoked to initialize the range data for your test MICROCHIP MPLAB C30FOR PIC24 ON EXPLORER 16 251 environment. This is the same procedure that you will follow to execute the test case. VectorCAST will bring up a dialog box to outline the steps you must perform to execute the harness as shown below. Click OK and VectorCAST will start up the MPLAB IDE and you should confirm that you have successfully connected to the target by examining that Output window in the MPLAB IDE which should look like as follows: Now import the harness by selecting File => Import and navigating to your test environment directory and choosing the vcast_pic24_tgt.cof . After loading this image, program it on the target by selecting Debugger => Program, you should then see that the image was successfully programmed by examining the status in the Output window again. MICROCHIP MPLAB C30FOR PIC24 ON EXPLORER 16 252 Now you can run the executable, (select NO when prompted to rebuild the project) and after it runs to completion you will see the following in the Call Stack window, at which point you can exit out of the MPLAB IDE debugger and control will automatically be returned back to VectorCAST and the results of your test case will be displayed. The successful execution of the tutorial test case PLACE_ORDER.001 result is shown below: MICROCHIP MPLAB C30FOR PIC24 ON EXPLORER 16 253 Target Debug Execution Test Execution with Debug follows the same procedure as described above for Target Execution except the user will set breakpoints before running the executable and then proceed with the typical debug process during that debug session and the exit out of the debugger again after you have completed your debug session and reached the end of the harness executable. NEC V850 254 NEC V850 Configuration This section provides details about configuring VectorCAST to integrate with the NEC Electronics Tools C compiler for the V850 Series. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “NEC V850” under the “Compiler” drop-down menu, as shown here: Second, ensure that the directories containing the NEC binaries are included in your PATH environment variable. These are most likely C:\devapps\tools\nec_v850\c\nec\2.72\win\BIN and C:\Program Files\NEC Electronics Tools\ID850QB\V3.40\bin, but may be slightly different on your particular system. To specify a different NEC installation directory: 1. On the Preprocessor/Compiler tab, change the “Library Include directories” entry to match the location of the “inc850” directory on your system. Use DOS formatted short-paths (8.3/no spaces). NEC V850 255 2. Click Apply to save the changes. 3. Edit the path of the SymInspect.tcl script in the “v850test.pri” file in the DATA directory of your VectorCAST installation. The default command settings should be sufficient to run the Tutorial example in the VectorCAST/C User’s Guide, and it is strongly recommended that you do so before trying to test your application code. It is your responsibility to customize these settings for your particular device and development environment. The “Preprocessor/Compiler” tab contains the compiler commands and options that will be used to compile the test harness. The command file for compiler arguments is v850_compile.cmd, and it is stored in the environment directory. The template for this file is in the DATA directory of your VectorCAST installation. Change this version of the file when you want the modification to apply to all future environments since the file is copied during environment creation. Since NEC does not have a malloc function, dynamic memory required by the harness is handled with a global array. You can set the size of this array by adjusting the VCAST_MAX_HEAP_SIZE value in the “Defined variables” box. At the beginning of execution, the stack must be set to a valid memory location. The default value is 0x3FFEFEC. If you would like to use a different value, change the VCAST_NEC_ SP variable in the “Defined variables” box. NEC V850 256 The “Linker” tab contains the linker commands and options that will be used to link the test harness. This tab is where you specify the object files containing your board startup code. Be sure to specify the full paths to all the object files that you need to link in. If you have a link command file, enter it under “Linker options”. For example, if you have a link command file in the C:\vcast_nec directory named v850_test.plk, you would enter @C:\vcast_nec\v850_ test.plk. A link command file contains the names of the object files with their full paths as well as the link options you wish to use. For example, if you have startup code in the object files startup.o, rom_hdr.o, and vectors.o, and they are in the directory c:\vcast_nec, your link command file might look like this: c:\vcast_nec\startup.o c:\vcast_nec\rom_hdr.o c:\vcast_nec\vectors.o -cpu f3359 -A -m -v -mask_reg -lc -lr c:\devapps\tools\nec_v850\c\nec\2.72\win\lib850\r32\rompcrt.o VectorCAST provides a default link directive file, v850_link.dir. The template for this file is in the DATA directory of your VectorCAST installation. Change this version of the file when you want the modification to apply to all future environments since the file is copied during environment creation. If you only want the changes to apply to the current environment, edit the v850_link.dir file inside the environment directory. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. Specific details and discussion of the options that ca850.exe and ld850.exe accept is outside the scope of this document. Refer to NEC’s compiler and linker documentation for more information on this topic. Lastly, click OK to save the settings and close the options dialog. NEC V850 257 Target Execution For execution with the NEC target, VectorCAST will invoke romp850 on the executable to create a romp.out file in the environment directory. Then it will create a Tcl control script in the environment directory and automatically invoke the Integrated Debugger ID850QB to run test cases. The script file that VectorCAST creates is called “execute.tcl” and is similar to the following: breakpoint vCAST_END go -wait go -wait upload -force -binary VCAST_STDOUT.DAT vcast_output_buffer vcast_output_buffer+0x1388 breakpoint -delete 1 breakpoint -delete 2 dbgexit The harness stores execution results in a buffer, and the execute.tcl script sends the contents of the buffer to a file. You can adjust the size of this buffer by changing the “Output buffer size” option on the Target tab. The template for the execute.tcl script is in the DATA directory of your VectorCAST installation. If you change this version of the script, all future environments will be affected. The project file used with the debugger is called “v850test.prj” and is found in the environment directory. The template for this file is in the DATA directory of your VectorCAST installation. If you change this version of the project file, all future environments will be affected since the file is copied during environment creation. The default project file uses a settings file, “v850test.pri”, which is copied into the environment directory from the DATA directory as well. Target Debug Execution For debugging on the NEC target, VectorCAST will invoke romp850 on the executable to create a romp.out file in the environment directory. Then it will create a Tcl control script in the environment directory and automatically invoke the Integrated Debugger ID850QB with it to load the executable. The script file that VectorCAST creates is called “execute_debug.tcl” and is similar to the following: breakpoint vCAST_END The template for the execute_debug.tcl script is in the DATA directory of your VectorCAST installation. If you change this version of the script, all future environments will be affected. If you only want changes to apply to the current environment, edit the execute_template.tcl file in the environment directory. If you allow the execution to reach the end of the driver main program, you can get the execution results by calling: NEC V850 258 upload -force -binary VCAST_STDOUT.DAT vcast_output_buffer / vcast_output_buffer+ Paradigm for 80186 Configuration This section provides details about configuring VectorCAST to integrate with Paradigm C++ compiler for an 80186 hardware target. First, select Tools => Options from the main toolbar. Choose the C/C++ tab and then select the entry for Paradigm => 80186EB => CPP under the “Compilers” drop-down menu, as shown here: Second, ensure that the directory containing the Paradigm binaries is included in your PATH environment variable as well as the path to the WinIdea application which is used to download and debug the application. set PATH=C:\Program Files\Paradigm\bin;C:\winIDEA\2008;%PATH% You can modify the path as appropriate on your particular system. Target-specific startup files: VectorCAST integration with 80186 target-specific startup files requires that the user point to the directory that contains all the precompiled startup files (*.obj) that will get linked in with the VectorCAST test harness files and the UUT code. The user must configure the environment variable P_ 186_STARTUP_FILES to point to these startup files. PARADIGM FOR 80186 260 An example list of startup files that VectorCAST expects to find are listed in the directory listing below, where the environment variable is set as follows: P_186_STARTUP_FILES=C:\80186_Startup_Files The user may also wish to include the source code for the startup code to assist in debug sessions where they may want to step through this code. Linking The user can modify the list of startup files to be linked in by editing the list included on the “Linker Options:” line which can be found by selecting the Tools => Options dialog, C/C++ tab, Linker sub-tab. See below for an example. It is your responsibility to customize these settings for your particular device and development environment. PARADIGM FOR 80186 261 VectorCAST will automatically invoke the Paradigm linker, plink.exe, and the locate utility, locate.exe, to produce a paradigm_186.axe executable image. This is the image that will be downloaded onto the target and executed when you run a test case. Target Execution As the test environment is being built by VectorCAST, it will invoke the WinIdea debugger to run an executable on the target that initializes range data. You must have a serial cable from your target connected to your test PC machine. VectorCAST collects range data and test data information from this serial port interface. The $VECTORCAST_DIR\IO\comreader.exe executable is used to record the results of target execution. The default settings are port "COM1", baud 9600, no parity, 8 data bits, and 1 stop bit. The comreader is started before test execution and stops when the debugger exits. Remember to close any other applications, such as HyperTerminal, that are reading from the same port, before executing tests. If you forget to power up your target and/or the In-Circuit-Emulator (ICE), or don’t have the USB cable connected from your PC to the emulator, you will likely get an error dialog box displayed like the one shown below. PARADIGM FOR 80186 262 The connection method to your target may vary depending on the emulator or target capabilities. As an example, if you are connected via an ICE with a USB connection to your PC that communicates with the WinIdea application, then you will see a download progress window like the one below as VectorCAST invokes WinIdea to download the target image and run it on your target. Target Debug Execution Test Execution with Debug functions in a manner similar to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. The script used to execute with debug is named p186_download_debug.isl. You can customize this script to store frequently used breakpoints/debugging commands conveniently for repeated debugging sessions. The template for the script is in $VECTORCAST_DIR\DATA\paradigm, and it will automatically be copied to your test environment when you select the “Execute with Debug” option for running your test case. The user should refer to the WinIdea documentation for more information on the API and supported functions that can be used in your .isl script. To stop debugging, kill the debug thread and exit WinIdea. PARADIGM FOR 80186 263 If you allow the execution to reach the end of the driver main program, all VectorCAST execution results will be generated when you exit WinIdea. PARADIGM FOR SC520 264 Paradigm for SC520 Configuration This section provides details about configuring VectorCAST to integrate with Paradigm C/C++ compiler for an SC520 HW target. The target board is the 586-Drive (5D) from Tern Inc. which is a C/C++ programmable controller based on the 32-bit 133 MHz AMD SC520 microcontroller. The ÉlanSC520 microcontroller combines a 32-bit Am5x86® CPU with a complete set of integrated peripherals for embedded application development. This board and RSP are designed to work with the Paradigm C++Tern Edition, Version 5.00 of the compiler. Target Connections and Configuration The 5D board comes with a +12V power cable and 2 flat ribbon serial port cables. Connect serial port 0 (SER0) cable to the COM1 port on your PC (DB9 connector) and use the Device Manager to configure that serial port communication interface for 115200 bits per second, 8 data bits, N (no parity), 1 (1 stop bit), and No flow control. This SER0 interface is used by the debugger to communicate/control the board and download your application for debug. Connect the other serial port cable (SER1) to COM2 port on your PC. You may need to use a USB-to-DB9 adaptor if your PC only supports a single DB9 connector (typical PC configuration). Use the Device Manager again to configure COM2 for 19200 8 N 1. VectorCAST uses this serial port interface to collect test data results. Note that these baud rate settings assume the default settings for the SC520 board. If the user changes these settings on the SC520 end, then the same settings should obviously be mirrored in the host PC port settings. First, ensure that the directory containing the Paradigm binaries is included in your PATH environment variable. (For example, set path=C:\Paradigm\bin;%path%). Note: When installing the Paradigm Tern edition of the Paradigm compiler, you should accept all the default options listed during the install, including the default directory locations for installing the Tern libraries. You will also need to configure an environment variable, VCAST_SERIAL_CFG, to point to a serial port configuration file which VectorCAST creates for you and installs in the DATA\paradigm directory in the VectorCAST install directory. set VCAST_SERIAL_CFG= The contents of this file should be as follows. COM2 19200 N 8 1 If the serial cable from the SER1 port on the SC520 is connected up to a COM port other than COM2 on your host PC, then modify the contents of p586_serial_cfg.txt file to point to the appropriate serial COM port (e.g. COM6 instead of COM2). You can identify the COM port by using the Device Manager on the PC to display the connected serial ports, (expand the Ports (COM & LPT) menu item). see figure below as PARADIGM FOR SC520 265 an example. In this particular test system configuration, we have the USB-to-Serial adaptor on the SER1 port from the SC520 board. Again, the serial cable from the SER0 port on the SC520 is used by the debugger to communicate/control the board and download your application If this serial cable is not connected up to COM1 port on your PC, then you must modify the configuration contained in the Paradigm p586 project file (p586_tern.ide) that has been copied by VectorCAST to your test environment directory. Open this Paradigm default project by double-clicking the p586_tern.ide project file, and edit the default remote link options to match the configuration of your system. You can access this option from within the Paradigm IDE by selecting Debug->Connect (Modify Settings) from the Paradigm C++ pull down menu. See below for sample settings screen shot. Next, after starting up VectorCAST, select Tools => Options from the main toolbar. Choose the C/C++ PARADIGM FOR SC520 266 tab and then select the entry for Paradigm => SC520 => C under the “Compilers” drop-down menu, as shown here: Paradigm startup scripts: The Paradigm integrated debugger will always run a few startup scripts automatically when you start up the Paradigm IDE. These include the startup.spp and the personal.spp scripts. Before running any of your test cases, you should copy the VectorCAST-generated script, p586_personal.spp, into the c:\Paradigm\script directory and rename it personal.spp. You will find the p586_personal.spp script in the $VECTORCAST_DIR/DATA/paradigm directory. You will want to save off the original personal.spp that comes with the Paradigm installation for reference. The VectorCAST modified script will not try to load recent project files like the default script does, as this may cause problems when running in debug mode. You may examine the differences between these scripts and modify as you wish in terms of initializing the debugger default windows that come up when VectorCAST invokes the debugger (“Execute with Debug”), but we don’t recommend loading recent project settings for the reason stated above. Stack size: The default stack size is defined in the c0.asm startup file from the Paradigm release and defaults to a size of 1024 bytes. For small test environments this is typically enough stack, but should your test environment require additional stack size, the user can increase the stack size by defining the desired stack size in the stklen.asm file, which is included in your test environment, and generating a stklen.obj PARADIGM FOR SC520 267 object file. The user would subsequently include stklen.obj in the link process by adding it to the linker options by selecting Tools->Options->C/C++ Linker/Debug Tab as shown below. A stklen.obj file is also included in your test environment which has been built to increase the stack size to 8K bytes, which can simply be included on the linker options line to increase the stack size to 8KB. If you want a different stack size, then edit the stklen.asm accordingly, build with the Paradigm assembler by running the “pasm /m3 /mx stklen.asm” command, and link the newly generated stklen.obj into your executable by selecting Environment->Relink. Linking: VectorCAST will automatically invoke the Paradigm linker, plink.exe, and the locate utility, locate.exe, to produce a paradigm_586.axe executable image. This is the image that will be downloaded onto the target and executed when you run a test case. Target Execution After the test environment has been built by VectorCAST, it will invoke the Paradigm debugger to run an executable on the target that initializes range data. You must have a serial cable from your target connected to your test PC machine as VectorCAST collects range data and test data information through this serial port interface. (SER1) The $VECTORCAST_DIR\IO\comreader.exe executable is used to record the results of target execution. The comreader is configured to match the baud rate settings on the 5D board via the serial configuration PARADIGM FOR SC520 268 file mentioned earlier. These settings are port "COM2", 19200 bits per second, N (no parity), 8 data bits, 1 stop bit, and No flow control. The comreader is started before test execution and stops when the debugger exits. Remember to close any other applications, such as HyperTerminal, that are reading from the same port, before executing tests. If you experience any connectivity problems with the target, like forgetting to connect serial port cables, or accidentally running another application that was already connected to that COM port, you should connect all the necessary cables, close the other application, and reboot the board as the state machine running on the 5D board needs to get synced up now. In VectorCAST, you may run any test case by selecting the test case, right-clicking, and selecting “Execute”, or clicking the Execute button in the toolbar. VectorCAST will then invoke the debugger via the command line interface and download the executable, run to completion, and then exit the debugger, returning control back to VectorCAST for test case result display. Target Debug Execution Test Execution with Debug functions in a manner similar to normal execution, except that the debugger will download the application but not run it automatically like it does in the Execute mode. You may run any test case in debug mode by selecting the test case, right-clicking, and selecting “Execute with Debug”. This allows you the opportunity to set breakpoints, step through source code, and view data as you would during any normal debug session. The script used to execute with debug is named p586_load_dbg.spp. VectorCAST will create this debug script on the fly when you select the “Execute With Debug” option for running your test case, and the file does not already exist in the test environment. You can customize this script thereafter to store frequently used breakpoints/debugging commands conveniently for repeated debugging sessions. The debugger will come up, load the executable, and stop at the startup code execution entry point, as illustrated below. PARADIGM FOR SC520 269 You may step through the startup code at this point or hit the Run button which will cause you to run to main() and stop there. Again you may step through code or set breakpoints at this point as with any typical debug session. Refer to the Paradigm documentation for more information on the cscript Object Scripting features and API. When VectorCAST reaches the vCAST_END function in the S0000003.c file, it has completed the test data gathering and processing. You may now exit the debugger manually at this point to see the results of your test case displayed in the VectorCAST GUI. QNX NEUTRINO & QNX MOMENTICS 270 QNX Neutrino & QNX Momentics Configuration This section provides details about configuring VectorCAST to integrate with QNX Neutrino and QNX Momentics compiler and debugger for a live x86 board. Once both the target and the host have been properly set up (see next section to learn how to do a proper setup), launch VectorCAST. Select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “QNX” under the “Compiler” drop-down menu, as shown here: The command line has the following parameters that must be changed if need be: Under Windows: $(VECTORCAST_DIR)\DATA\gnu_target\execute_rsh.bat IP -lusername The IP is the name or IP address of your target running QNX Neutrino. The username is the username on QNX Neutrino which will let you execute remote command (through rsh) without any password. QNX NEUTRINO & QNX MOMENTICS 271 Under Linux: Integration under Linux is also possible using shell scripts. Please consult your VectorCAST representative to learn how. It is your responsibility to customize these settings for your particular device and development environment. Please note that these changes will be saved as long as you will be using the same working directory. For more information about this, please contact your Vector Software representative. Target Execution Target execution on a QNX live x86 board requires a few steps. Please note that all of these steps can be made automatic, so that each time the target is booted, it will immediately be ready for unit testing. To know how, please consult your QNX Neutrino documentation. Setting up the Target It should be noted that at this point in time, the RSP method of communication is through TCP/IP to a target that is already running a full-fledged version of QNX Neutrino. This RSP does not support communication through the serial port. If you are interested in communicating with the target through the serial port, please contact a Vector Software representative. Before running a test case, you must configure the target board to be accessed through NFS and RSH. Here are the steps that need to be taken in order to enable both daemons: 1. Edit the file /etc/inetd.conf and uncomment the line describing the rshd and ftpd daemons by removing the ‘#’ sign at the beginning of that line. 2. Boot up inetd by typing ‘inetd’ at the command prompt. inetd will in turn boot up the rshd daemon whenever a rsh communication is initiated on the proper port. You can also make the change permanent by putting inetd in /etc/rc.d/local.rc file – this will have the effect of launching inetd each time the OS is booted up. 3. Make a directory where temporary files can be saved. This must be /tmp from the root level. 4. Also, create a /home/ftp directory, otherwise the FTP server may not launch properly. At this point in time, listing the services currently running (by typing ‘ps’ at the command prompt) should list inetd as being up and running. If this is not up, please revisit the previous steps. You may also try to rsh from your host to the target to see if commands can be successfully passed into the target. In case of problems, consult your QNX Neutrino documentation. It should be noted that communication with the target that is described here requires the existence of a username in Neutrino that has no password. We used ‘root’, but you may want to use something else. In any case, this username should not require you to input any password, and should have read and write privileges into the temporary file directory (/tmp). Note that all these steps can be automated, so when the target is rebooted both rshd and inetd will be up by default. For more details on how to do this, consult your QNX Neutrino User Manual. Target Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and QNX NEUTRINO & QNX MOMENTICS 272 disassembly, and view data as you would during a normal debug session. The default debugger for QNX Momentics is gdb; however other debuggers can be used. Refer to the QNX documentation for more details. RENESAS HEW – M16C/R8C 273 Renesas HEW – M16C/R8C Configuring for Renesas HEW – M16C/R8C This section provides details about configuring VectorCAST to integrate with Renesas HEW IDE with Mitsubishi chips. For the moment, the only target supported is M16C/62 on simulator, but this template can be used to perform unit testing on R8C-based programs. Support for other targets and simulators is quite possible, including for the M16C, M32C, and several other Mitsubishi-based targets. Please contact your Vector Software representative for more details. Please note that the Renesas HEW integration requires a few steps before it is possible to run VectorCAST with that IDE. This step is made mandatory on simulator by the fact that the Renesas environment writes files to the user directory, and that the RSP uses an API that must be first activated in the Renesas HEW environment. Thus, you must first create a Renesas HEW template for VectorCAST to use. Furthermore, you will need to set up the Renesas IDE correctly to interface with our COM program. These steps only need to be done once, and then the template can be used across work directories. See the section on Target Execution for more details. Putting the compiler on the path First, before launching VectorCAST, the compiler must be put on the path. The way to do this depends on the specifics of your Renesas installation. However, it could look like the following: SET BIN30=C:\Program Files\Renesas\Hew\Tools\Renesas\nc30wa\v545r00\bin SET LIB30=C:\Program Files\Renesas\Hew\Tools\Renesas\nc30wa\v545r00\lib30 SET INC30=C:\Program Files\Renesas\Hew\Tools\Renesas\nc30wa\v545r00\inc30 SET TMP30=C:\Program Files\Renesas\Hew\Tools\Renesas\nc30wa\v545r00\tmp SET PATH=%BIN30%;%LIB30%;C:\Program Files\Renesas\Hew\;%PATH% Please note that all of these environment variables must be set before VectorCAST/C++ can use them. You can make these environment variables to be permanently part of the Windows operating system, or you can launch VectorCAST from a batch file that first sets these environment variables correctly. It is your responsibility to customize these settings for your particular device and development environment. Target Execution Enabling the HEW Target Server As explained in the previous chapter, a number of steps must be followed before being able to run the Renesas RSP. Most of these steps need only to be taken once. First, you must enable the Renesas HEW Target Server on the machine that will host the test environments. Follow these steps: 1. Launch Renesas HEW. 2. Then, you need to make sure that the HEW Target Server is installed. When the welcome screen appears, click on Administration. If the welcome screen does not appear, then select Tools => Administration from the menu bar. RENESAS HEW – M16C/R8C 274 Expand Extension Components. Click on Search Disk, and then Start. HEW will list all the components you can register. Select HewTargetServer and then click on Register. You can now close the Tools Administration menu. 3. Then, if you want the execution of test cases to be entirely automated, you must disable Renesas HEW optional pop-ups and splash screens. Go to Setup => Options, and then the Confirmation tab. Click on Clear All, and then OK. Please note this change will affect all of your Renesas environments. Creating a Renesas HEW IDE template project Second, you must create a Renesas HEW IDE template project for VectorCAST to use. Follow these steps: 1. Launch Renesas HEW. 2. Select File => New Workspace. Select Application, and enter the appropriate information. Click OK. RENESAS HEW – M16C/R8C 275 3. Then select the right CPU series and CPU group. Click Next twice. 4. On the following screen please make sure that the Use Standard I/O Library option is set (unless your VectorCAST FAE told you otherwise). For the default implementation on M16C/62 RENESAS HEW – M16C/R8C 276 simulator, please select 128K of ROM. Click Next twice. 5. Select the target you need, and then click Next twice, then Finish. RENESAS HEW – M16C/R8C 277 At this point in time, you should see the following: 6. Select the appropriate session from the Session selection dropdown box (up and right). A popup will appear for simulator environments. Click on the Refer button. Select the appropriate MCU (here, M16c6x.mcu). Also, to ensure that test cases can run without user input, please make sure that option “Do not show this dialog box again” is checked. Click OK. 7. If you are using the simulator for Mitsubishi chips, you also need to set up the OutputPort window. Go to View => CPU => OutputPort. RENESAS HEW – M16C/R8C 278 8. In the window that appears, click the first icon (Set). Set the Printf to UART1, and Output Format for Window and File to TEXT. Click OK. 9. Then click the second icon (Column). Please set both Window Column and File Column to 1000, and then click OK. RENESAS HEW – M16C/R8C 279 10. Finally, right-click on ncrt.a30 (the startup code), and build the file. 11. Kill the HEW environment. When asked to, save the environment. Please note that all of these steps only need to be made once. Use VectorCAST You can now create a VectorCAST environment. Select Tools => Options from the main toolbar. Choose RENESAS HEW – M16C/R8C 280 the C/C++ tab to select the entry for “Renesas HEW 5.4x on M16C (62) Simulator” under the “Compiler” drop-down menu, as shown below. 1. On the Execute command line, replace the path following execute.bat with the path to the template you created before. Depending on your Renesas installation, you may need to change the default source directories for the Wizard. 2. Then, make sure the same change has been changed for the debugger command. located on the Linker/Debug tab. RENESAS HEW – M16C/R8C 281 3. Finally, provide the path to the ncrt.r30 file from your template file in the option “Environment Files,” located on the Misc tab. RENESAS HEW – M16C/R8C 282 Note: In order to use VectorCAST/C++ with Renesas HEW, no other HEW instance can be open. The only instance of HEW that should be open when using VectorCAST is the one used by VectorCAST. By default, VectorCAST will launch HEW, download the test harness to the HEW debugger, run a test case, and shut HEW down. There is a way to keep the template up to accelerate execution by changing the fourth argument on both the execute command and debug command lines from SHUTDOWN to CONTINUOUS. However, if you choose to do so, you must make this change to both the execute and debug command lines. Also, upon rebuilding the environment, you must shut down the HEW instance still open, otherwise the rebuild with fail. Target Debug Execution When executing under the control of the debugger, VectorCAST will open the HEW template and advance execution to the entry of the main function. From there, you will be able to execute the test harness manually, using your usual debugger command. For your convenience, VectorCAST will also automatically put a break point at the end of the test harness. During execution on simulator for the M16C/62, the test results are saved automatically. In order for the results to be complete, the inscription VCAST.END:END should appear in the output window. That will happen when the test harness hits the break point on vCAST_END(), indicating that you reached the end of the test harness. Then, you can close the HEW instance – by shutting down HEW or by clicking on the popup provided to that end by the RSP, and control will be returned to VectorCAST. Upon exiting, do not save the HEW template. Close HEW or click on the OK button on the popup open RENESAS HEW – M16C/R8C 283 for that specific purpose. Troubleshooting Corruption during simulator execution Problems may sometimes occur during simulator execution. If this happens, it is possible that HEW will refuse to normally load the project template. The message displayed in the pop-up will likely show that HEW cannot open additional I/O files. If this happens, you must go the Windows Task Manager and shut down all of the executables related to Renesas, including HEW (HEW2.exe), the HEW Target Server (HEWTAR~1.exe) and the simulator executable (sim30.exe). You may also need to regenerate a HEW template to use with VectorCAST if yours has somehow been damaged during your last execution. Execution not fully automatic If HEW hangs during the load of the main file (either S00000003.c or I00000003.c), it may mean that the integration program is not able to dismiss the window popup associated with the loading of that file in Renesas HEW. This may occur because VectorCAST operates in a Windows environment in which the language is not English. The solution is to change the language on both the execute and debug commands from ENGLISH to your language. At this time, only English and Korean are supported. Please call VectorCAST Technical Support to learn how to add support for your language. On the other hand, if HEW hangs on splash windows or other pop-ups, it is possible you did not disable these pop-ups during target setup. Please Go to Setup => Options, and then the Confirmation tab. Click on Clear All, and then OK. Please note this change will affect all of your Renesas environments. Compatibility This integration has received final testing with version 4.07 of HEW. Previous versions may or may not be compatible with this RSP. In case of any problems executing with other versions, please contact RENESAS HEW – M16C/R8C 284 VectorCAST Technical Support. RENESAS HEW SUPERH (SH) CHIPS 285 Renesas HEW SuperH (SH) chips Configuration for Renesas HEW - SH This section provides details about configuring VectorCAST to integrate with Renesas HEW IDE and the SuperH (SH) compiler. Integrations exist with both the HEW native debugger and the Lauterbach TRACE32 debugger. Note: The Renesas HEW integration with HEW native debugger requires a few steps before it is possible to run VectorCAST with that IDE. These steps only need to be done once, and then the template can be used across work directories. See the Target Execution section for more details. Putting the compiler on the path First, before launching VectorCAST, the compiler must be put on the path. The way to do this depends on the specifics of your Renesas installation. However, it could look like the following: set VCAST_RENESAS_INSTALL_DIR=C:\Program Files\Renesas\Hew\Tools\Renesas\Sh\9_3_2 SET SHC_LIB=C:\Program Files\Renesas\Hew\Tools\Renesas\Sh\9_3_2\bin SET SHC_INC=C:\Program Files\Renesas\Hew\Tools\Renesas\Sh\9_3_2\include SET SHC_TMP=C:\Program Files\Renesas\Hew\Tools\Renesas\Sh\9_3_2\Ctemp SET HLNK_LIBRARY1=C:\Program Files\Renesas\Hew\Tools\Renesas\Sh\9_3_2\lib\shdsplib.lib SET PATH=C:\Program Files\Renesas\Hew\Tools\Renesas\Sh\9_3_2\bin;%PATH% Please note that all of these environment variables must be set before VectorCAST/C++ can use them. You can make these environment variables to be permanently part of the Windows operating system, or you can launch VectorCAST from a batch file that first sets these environment variables correctly. Please also note that SHC_LIB must be pointing to the bin directory of your compiler, not the lib directory. If this environment variable points to the lib directory, the compiler will report an error when using VectorCAST. Finally, if using a virtual I/O method for simulator integration under HEW native compiler (the SH4/SH7750 integration is based on that model), you must set an extra environment variable VCAST_ IO_DIRECTORY to a directory where VectorCAST can write a IO file. This path must be pointing outside VectorCAST’s working directory, as the HEW simulator virtual I/O capability will not write into the working directory. By default, this directory is C:\Workspace. set VCAST_IO_DIRECTORY=C:\WORKSPACE If you must put the IO directory somewhere else, you will also need to change the file folder_path.h accordingly, which is located in the %VECTORCAST_DIR%\DATA\renesas\sh folder: #ifndef VCAST_STDOUT_FOLDER char *VCAST_STDOUT_FOLDER = "C:\\WorkSpace\\stdout.txt"; #endif Please note that in this header file, the path to the stdout.txt file must have double backspaces. If you are using the Lauterbach TRACE32 debugger, you will need to set the TRACE32 executable in RENESAS HEW SUPERH (SH) CHIPS 286 your PATH environment variable. The rest of this section is not relevant to an integration with Lauterbach TRACE32. Please consult the appropriate section in this user guide. It is your responsibility to customize these settings for your particular device and development environment. Target Execution Enabling the HEW Target Server If using the HEW native debugger, you must enable the Renesas HEW Target Server on the machine that will host the test environments. Follow these steps: 1. Launch Renesas HEW. 2. Then, you need to make sure that the HEW Target Server is installed. When the welcome screen appears, click on Administration. If the welcome screen does not appear, then select Tools => Administration from the menu bar. Expand Extension Components. Click on Search Disk, and then Start. HEW will list all the components you can register. Please select HewTargetServer and then click on Register. You can now close the Tools Administration menu. 3. Then, if you want the execution of test cases to be entirely automated, you must disable Renesas HEW optional pop-ups and splash screens. Go to Setup => Options, and then the Confirmation tab. Click on Clear All, and then OK. Please note this change will affect all of your Renesas environments. Reset the HEW template (.hws) Before using the HEW integration, you must first go to %VECTORCAST_DIR%\DATA\renesas\sh RENESAS HEW SUPERH (SH) CHIPS 287 directory, and from there go to the chip being supported (for instance, SH4/SH7750), and open the .hws file listed. This will open the project in the HEW IDE. You must then close the HEW IDE and save the project. This will reset the internal path of this project to the specifics of your environment. Failure to do so will cause the execution of the VectorCAST integration to hang. Use VectorCAST You can then create a VectorCAST environment. Select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for the Renesas template of your choice. Note: In order to use VectorCAST/C++ with Renesas HEW debugger, no other HEW instance can be open. The only instance of HEW that should be open when using VectorCAST is the one used by VectorCAST. By default, VectorCAST will launch HEW, download the test harness to the HEW debugger, run a test case, and shut HEW down. There is a way to keep the template up to accelerate execution by changing the fourth argument on both the execute command and debug command lines from SHUTDOWN to CONTINUOUS. However, if you choose to do so, you must make this change to both the execute and debug command lines. Also, upon rebuilding the environment, you must shut down the HEW instance still open, otherwise the rebuild with fail. RENESAS HEW SUPERH (SH) CHIPS 288 Target Debug Execution When executing under the control of the debugger, VectorCAST will open the HEW template and advance execution to the entry of the main function. From there, you will be able to execute the test harness manually, using your usual debugger command. For your convenience, VectorCAST will also automatically put a break point at the end of the test harness. Upon exiting, do not save the HEW template. Close HEW or click on the OK button on the popup open for that specific purpose. Troubleshooting Running out of heap space By default, VectorCAST/RSP for Hitachi chips will use static memory in lieu of a heap. The amount of space reserved for these operations is controlled by the VCAST_MAX_HEAP_SIZE variable. If the heap space is insufficient, the following error will occur: RENESAS HEW SUPERH (SH) CHIPS 289 The solution to this problem is to increase VCAST heap space by defining another value for VCAST_ MAX_HEAP_SIZE (the default size is 1000). For instance, placing VCAST_MAX_HEAP_SIZE=2000 among the macros will enable you to do integration testing on the tutorial code (with manager.c and database.c) at Level A code coverage, while not defining VCAST_MAX_HEAP_SIZE will result in the error message displayed above. On the other hand, if your program uses malloc, the default template provided might not have sufficient heap space for you to run your program. The default HEW value of 0x400 was used for the heap. Please consult your Vector Software representative to learn how we can customize this integration to suit your needs. Execution not fully automatic If HEW hangs during the load of the main file (either S00000003.c or I00000003.c), it may mean that the integration program is not able to dismiss the window popup associated with the loading of that file in Renesas HEW. This may occur because VectorCAST operates in a Windows environment which language is not English. The solution is to change the language on both the execute and debug commands from ENGLISH to your language. At this time, only English and Korean are supported. Please call VectorCAST Technical Support to learn how to add support for your language. On the other hand, if HEW hangs on splash windows or other pop-ups, it is possible you did not disable these pop-ups during target setup. Please Go to Setup->Options, and then the Confirmation tab. Click on Clear All, and then OK. Please note this change will affect all of your Renesas environments. Environment will not execute when using the simulator The template provided by VectorCAST for execution on HEW is valid only with version 4.07 of HEW and Compiler package for SH version 3.3. You may need to upgrade this template to your version of HEW by (1) clicking on %VECTORCAST_DIR%\DATA\renesas\sh_sim.hws, and then (2) save and close this template. The template may also refuse to execute if you installed VectorCAST anywhere but in C:\VCAST. This is because HEW templates define absolute links to a number of files. Fortunately, HEW is also generally able to redraw its dependencies. Open %VECTORCAST_DIR%\DATA\renesas\sh_sim.hws in HEW, save and close the template. Please note that in both cases you will need to do this quick operation each time you reinstall or upgrade VectorCAST. RENESAS HEW SUPERH (SH) CHIPS 290 Compatibility This integration has received final testing with version 4.07 of HEW. Previous versions may or may not be compatible with this RSP. In case of any problems executing with other versions, please contact VectorCAST Technical Support. TASKING 56K C COMPILER 291 TASKING 56k C Compiler Configuration This section provides details about configuring VectorCAST to integrate with the TASKING 56k C compiler and TASKING’s CrossView Pro debugger. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “Tasking 56k” under the “Compiler” drop-down menu, as shown here: Second, ensure that the directory containing the TASKING binaries is included in your PATH environment variable. This is most commonly C:\Program Files\Tasking\c56 v3.5\bin but may be slightly different on your system. Third, if TASKING is installed in a location other than the default, edit the “Default source directories for Wizard” field to reflect TASKING’s include directory on your system. Fourth, click ‘OK’ to save the changes. Target Execution Before executing tests with TASKING 56k C, you must specify the TASKING Compiler and Execute Command through the Options dialog. Also, ensure that the TASKING bin directory (most commonly C:\Program Files\Tasking\c56 v3.5\bin) is included in your PATH environment variable. TASKING 56K C COMPILER 292 See the previous section “Configuration” for detailed instructions on these requirements. When a test case is executed with TASKING, VectorCAST will automatically execute a command to invoke the CrossView simulator. The command passes the following initialization command script via the -p (playback) option: FSS 0<"C:\vcast_tutorial\DEMO\VCAST_STDIN.DAT" FSS 1>"C:\vcast_tutorial\DEMO\VCAST_STDOUT.DAT" break delete all F_exit bi R q y The first two lines configure CrossView’s simulated I/O, setting standard input (stdin/FSS 0) to the file VCAST_STDIN.DAT and standard output (stdout/FSS 1) to VCAST_STDOUT.DAT. Next, all break points are deleted (to ensure an uninterrupted execution) and a break point is then set on the assembly label “F_exit” (the end of the program). Lastly, the Run command is issued so that CrossView will open, initialize, run and complete without any required user input. Upon completion, CrossView will quit and VectorCAST will display the test’s results. The initialization script is named .xfw_exeinit.cmd and gets created in the VectorCAST environment directory. This file will not be overwritten, so any changes made by you are maintained from one execution to the next. As long as the simulated I/O setup commands are maintained, you may add any legal CrossView commands to this file. If you wish to make a change to the script for all future environments, you can edit $VECTORCAST_DIR\DATA\tasking\.xfw_exeinit.cmd. Target Debug Execution Test Execution with Debug is similar to normal execution except that the CrossView initialization command script does not contain a Run command. Because no Run command has been given to CrossView, it will wait for user input – debugging can proceed from this point as normal. The debug initialization script is named .xfw_dbginit.cmd and gets created in the VectorCAST environment directory. This file will not be overwritten, so any changes made by you are maintained from one execution to the next, making it useful for setting frequently used breakpoints. For example, if you are attempting to uncover when a particular variable “my_counter” is being changed, you would edit .xfw_dbginit.cmd to read as follows: FSS 0<"C:\vcast_tutorial\DEMO\VCAST_STDIN.DAT" FSS 1>"C:\vcast_tutorial\DEMO\VCAST_STDOUT.DAT" break delete all break data &my_counter, access_type=w R By adding the data breakpoint and a Run command, when you select “Execute With Debug,” the UUT will execute via CrossView and halt at any point where the variable my_counter is written. If you wish to make a change to the script for all future environments, you can edit $VECTORCAST_ DIR\DATA\tasking\.xfw_dbginit.cmd. TASKING 563XX C COMPILER 293 TASKING 563xx C Compiler Configuration This section provides details about configuring VectorCAST to integrate with the TASKING 563xx C compiler and TASKING’s CrossView Pro debugger. Note that this uses a different Tasking compiler toolset than the Tasking 56K. Before starting VectorCAST the user must configure the following environment variable to point to the TASKING install directory. This is most commonly C:\Program Files\Tasking\c563 v3.5\bin but may be slightly different on your system. Use DOS 8.3 pathnames when defining your environment variables as the compiler does not like whitespace in path defines. Also, ensure that the directory containing the TASKING binaries is included in your PATH environment variable. set VCAST_TASKING_INSTALL_BASE=C:\PROGRA~1\TASKING\C563V3~1.5 set path=%VCAST_TASKING_INSTALL_BASE%\bin;%path% Start up VectorCAST and create a new test environment and select “Tasking 563xx” under the “Compiler” drop-down menu, as shown here: Target Execution Before executing tests with TASKING 563xx C, you must specify the TASKING Compiler and Execute TASKING 563XX C COMPILER 294 Command through the Options dialog. Also, ensure that the TASKING bin directory (most commonly C:\Program Files\Tasking\c563 v3.5\bin) is included in your PATH environment variable. See the previous section “Configuration” for detailed instructions on these requirements. When a test case is executed with TASKING, VectorCAST will automatically execute a command to invoke the CrossView simulator. The command passes the following initialization command script via the -p (playback) option: FSS 0<"C:\vcast_tutorial\DEMO\VCAST_STDIN.DAT" FSS 1>"C:\vcast_tutorial\DEMO\VCAST_STDOUT.DAT" break delete all F_exit bi R q y The first two lines configure CrossView’s File System Simulation (FSS), setting standard input (stdin/FSS 0) to the file VCAST_STDIN.DAT and standard output (stdout/FSS 1) to VCAST_STDOUT.DAT, located in the environment directory DEMO in c:\vcast_tutorial. Next, all break points are deleted (to ensure an uninterrupted execution) and a break point is then set on the assembly label “F_exit” (the end of the program). Lastly, the Run command is issued so that CrossView will open, initialize, run and complete without any required user input. Upon completion, CrossView will quit and VectorCAST will display the test’s results. The initialization script is named .xfw_exeinit.cmd and gets created in the VectorCAST environment directory. This file will not be overwritten, so any changes made by you are maintained from one execution to the next. As long as the simulated I/O setup commands are maintained, you may add any legal CrossView commands to this file. If you wish to make a change to the script for all future environments, you can edit $VECTORCAST_DIR\DATA\tasking\.xfw_exeinit.cmd. Target Debug Execution Test Execution with Debug is similar to normal execution except that the CrossView initialization command script does not contain a Run command. Because no Run command has been given to CrossView, it will wait for user input – debugging can proceed from this point as normal. The debug initialization script is named .xfw_dbginit.cmd and gets created in the VectorCAST environment directory. This file will not be overwritten, so any changes made by you are maintained from one execution to the next, making it useful for setting frequently used breakpoints. For example, if you are attempting to uncover when a particular variable “my_counter” is being changed, you would edit .xfw_dbginit.cmd to read as follows: FSS 0<"C:\vcast_tutorial\DEMO\VCAST_STDIN.DAT" FSS 1>"C:\vcast_tutorial\DEMO\VCAST_STDOUT.DAT" break delete all break data &my_counter, access_type=w R By adding the data breakpoint and a Run command, when you select “Execute With Debug,” the UUT TASKING 563XX C COMPILER 295 will execute via CrossView and halt at any point where the variable my_counter is written. If you wish to make a change to the script for all future environments, you can edit %VECTORCAST_ DIR%\DATA\tasking\.xfw_dbginit.cmd. TASKING C166 CLASSIC 296 TASKING C166 Classic Configuration This section provides details about configuring VectorCAST to integrate with the TASKING compiler for C166 classic chips. Before you can use VectorCAST, the compiler must be set on your PATH environment variable, and the environment variable VCAST_TASKING_INSTALL_BASE should also be set. This is not done by default during TASKING installation, so you must either (a) set these variables permanently in the operating system, or (b) set them temporarily from the shell, and then launch VectorCAST from within that shell. In a regular DOS shell, setting the compiler on your path and setting VCAST_TASKING_ INSTALL_BASE may look like this: SET PATH=C:\Program Files\TASKING\c166 v8.8r1\bin;%PATH% SET VCAST_TASKING_INSTALL_BASE=c:\Progra~1\TASKING\C166V8~1.8.R1 As shown, VCAST_TASKING_INSTALL_BASE should be set with the DOS short path to the TASKING installation directory. Then, simply select the appropriate template from VectorCAST/C++ on the Tools => Options dialog, C/C++ tab. TASKING C166 CLASSIC 297 It is your responsibility to customize these settings for your particular device and development environment. Please note that these changes will be saved as long as you will be using the same working directory. For more information about this, please contact your Vector Software representative. Target Execution When a test case is executed with TASKING, VectorCAST will automatically execute the command specified by “Debugger command” in the C/C++ tab of the Options dialog: xfw166 by default, to invoke the CrossView simulator. The command passes the following initialization command script via the -p (playback) option: FSS 0<"C:\vcast_tutorial\DEMO\VCAST_STDIN.DAT" FSS 1>"C:\vcast_tutorial\DEMO\VCAST_STDOUT.DAT" break delete all R q y The first two lines configure CrossView’s simulated I/O, setting standard input (stdin/FSS 0) to the file VCAST_STDIN.DAT and standard output (stdout/FSS 1) to VCAST_STDOUT.DAT. Next, all break points are deleted (to ensure an uninterrupted execution). Lastly, the Run command (R) is issued so that CrossView will open, initialize, run and complete without any required user input. Upon completion, CrossView will quit and VectorCAST will display the test’s results. The initialization script is named .xfw_exeinit.cmd and gets created in the VectorCAST environment directory. This file will not be overwritten, so any changes made by you are maintained from one execution to the next. As long as the simulated I/O setup commands are maintained, you may add any legal CrossView commands to this file. If you wish to make a change to the script for all future environments, you can edit $VECTORCAST_DIR/DATA/tasking/c166_classic/.xfw_exeinit.cmd. Options passed to CrossView are read from the C_DEBUG_OPTIONS field of the CCAST_.CFG configuration file. If that line is not specified, then the default options, “-tcfg c167.cfg --load_application_use_map_file=true”, are used. The c167.cfg file is copied into the environment when it is built. This file will not be overwritten, so any changes made by you are maintained from one execution to the next. If you wish to make a change to the file for all future environments, you can edit $VECTORCAST_DIR/DATA/tasking/c166_classic/c167.cfg. Target Debug Execution Test Execution with Debug is similar to normal execution except that the CrossView initialization command script does not contain a Run command. Because no Run command has been given to CrossView, it will wait for user input – debugging can proceed from this point as normal. The debug initialization script is named .xfw_dbginit.cmd and gets created in the VectorCAST environment directory. This file will not be overwritten, so any changes made by you are maintained from one execution to the next, making it useful for setting frequently used breakpoints. If you wish to make a change to the file for all future environments, you can edit $VECTORCAST_DIR\DATA\tasking\c166_ classic\.xfw_dbginit.cmd. TASKING C166 VX 298 TASKING C166 VX Configuration This section provides details about configuring VectorCAST to integrate with the TASKING compiler for C166 VX chips. Before you can use VectorCAST, the compiler must be set on your PATH environment variable. This is not done by default during TASKING installation, so you must either (a) set these variables permanently in the operating system, or (b) set them temporarily from the shell, and then launch VectorCAST from within that shell. In a regular DOS shell, setting the compiler on your path may look like this: SET PATH=C:\Program Files\TASKING\C166-VX v2.3r3\bin;%PATH% SET VCAST_TASKING_INSTALL_BASE=C:\Progra~1\TASKING\C166-V~1.4R2 Then, simply select the appropriate template from VectorCAST/C++, as shown below: Please note that the template relies on an include directory to the compiler’s includes. That directory may change depending on the version of TASKING you are using. It is your responsibility to customize these settings for your particular device and development TASKING C166 VX 299 environment. Please note that these changes will be saved as long as you will be using the same working directory. For more information about this, please contact your Vector Software representative. Target Execution During the last revision of this text, only the simulator is supported, albeit across several chips. However, board support is possible. Please contact your VectorCAST representative for more details. The test harness will execute on the TASKING Script Debugger entirely automatically. The Script Debugger’s interface will not be launched. Target Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. Launching a debug execution of the test harness under TASKING C166 will launch the TASKING Script Debugger. To debug, you will need to edit a script. To help you get started, you can use the debug.dscr script file (located in %VECTORCAST_DIR%\DATA\tasking). Consult TASKING’s user manual to learn more about how to use the TASKING Script Debugger. The harness must be allowed to complete its execution in order for the test case results to be captured. TASKING TRICORE 300 TASKING TriCore Configuration This section provides details about configuring VectorCAST to integrate with the TASKING compiler for TriCore chips. Before you can use VectorCAST, the compiler must be set on your PATH environment variable, and the environment variable VCAST_TASKING_TRICORE_INSTALL_BASE should also be set. This is not done by default during TASKING installation, so you must either (a) set these variables permanently in the operating system, or (b) set them temporarily from the shell, and then launch VectorCAST from within that shell. In a regular DOS shell, setting the compiler on your path and setting VCAST_TASKING_ TRICORE_INSTALL_BASE may look like this: SET PATH=c:\Progra~1\TASKING\TRICOR~1.4R1\ctc\bin;%PATH% SET VCAST_TASKING_TRICORE_INSTALL_BASE=C:\Progra~1\TASKING\TRICOR~1.4R1 As shown, VCAST_TASKING_TRICORE_INSTALL_BASE should be set with the DOS short path to the TASKING installation directory. Then, simply select the appropriate template from VectorCAST/C++, Tools => Options dialog, C/C++ tab. TASKING TRICORE 301 It is your responsibility to customize these settings for your particular device and development environment. Please note that these changes will be saved as long as you will be using the same working directory. For more information about this, please contact your Vector Software representative. Target Execution For execution with the Tasking simulator, VectorCAST uses the command specified by “Execute command” in the C/C++ tab of the Options dialog: $(VECTORCAST_DIR)\DATA\tasking\execute.bat dbgtc <.dcf file name>. The .dcf file is specific to your chip and is copied into the environment at build time. If you wish to make a change to the .dcf file for all future environments, edit the copy in $(VECTORCAST_DIR)\DATA\tasking\tricore or produce a new .dcf file using the tasking IDE. Target Debug Execution For debugging with the Tasking simulator, VectorCAST uses the command specified by “Debugger command” in the C/C++ tab of the Options dialog: $(VECTORCAST_DIR)\DATA\tasking\debug.bat dbgtc. TASKING C166 CLASSIC WITHTRACE32 SIMULATOR ON LINUX 302 Tasking C166 Classic with TRACE32 Simulator on Linux Configuration This section provides details about configuring VectorCAST to work with Linux version of the Tasking C166 Classic compiler v7.5r5 with the Trace32 debugger/simulator. This particular setup is designed to work for the st10x280 chip. (Hence the “F280” cpu type argument passed to the execute/debug command.) Before you can use VectorCAST with TRACE32, both the compiler and TRACE32 must be set on your PATH environment variable. This is not done by default during TRACE32 installation, so you must either (a) set these variables permanently in the operating system, or (b) set them temporarily from the shell, and then launch VectorCAST from within that shell. Prior to running VectorCAST, the user must export the following environment variables. (modify these paths as necessary to match the install directories on your system. export VCAST_TASKING_INSTALL_BASE=/home/TOOLS/tasking_c166/7.5r5 export A166INC=/home/TOOLS/tasking_c166/7.5r5/include export C166INC=/home/TOOLS/tasking_c166/7.5r5/include export PATH=$VCAST_TASKING_INSTALL_BASE/bin:$PATH export Path=/opt/t32:$PATH export VCAST_TRACE32=/opt/t32 export T32SYS=/opt/t32 export T32TMP=/tmp export T32ID=T32 In the Tools => Options dialog, C/C++ tab, choose Tasking => C166_Classic => Linux => Simulator => F280=>C. Target Execution For the Trace32 debugger/simulator VectorCAST will create the necessary script file to start the simulator, load the appropriate executable image, set-up the input and output data for the target execution, and start the program running. The execution command for the c166 simulator using trace32 is as follows: $(VCAST_TRACE32)/bin/pc_linux/t32m166 -c $(VCAST_TRACE32)/configsim.t32,$(VECTORCAST_DIR) /DATA/trace32/simulator_linux_c166.cmm F280 Note that the last argument “F280” specifies the cpu type, (st10x280). Regular target execution will open a TRACE32 window, execute the code, save the data and automatically close the TRACE32 window upon harness termination. In the case of a problem, TRACE32 will generate an error and interrupt script execution. This will help you (or VectorCAST Technical Support) to troubleshoot the situation. However, in order to return to VectorCAST you must close the TRACE32 instance that was open during execution. It is your responsibility to customize these settings for your particular device and development environment. Please note that these changes will be saved as long as you will be using the same working directory. For more information about this, please contact your Vector Software representative. TASKING C166 CLASSIC WITHTRACE32 SIMULATOR ON LINUX 303 Target Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. Launching a debug execution of the test harness under TRACE32 will launch the TRACE32 debugger. You will have access to the very same functionality as in any TRACE32 environment. The execution will be stopped at the main function as shown below. If you need to get the results obtained during the execution under the control of the debugger, you must ensure that the test harness is enabled to run to its conclusion. For your convenience, a breakpoint is set at vCAST_END, which indicates the end of execution. The test data will not be captured automatically. Debug by single stepping through any code you wish to analyze. After the harness code reaches the breakpoint set at vCAST_END, you have completed harness processing but the data is only saved to memory at this point. You must save the data by typing the following script in TRACE32 command window, see TRACE32 screen shot below. d.save.binary path_to_working_directory\VCAST_STDOUT.DAT Y.range(vcast_output_buffer) This will save the data contained in vcast_output_buffer (the buffer containing the results of the test case (s)) to a file called VCAST_STDOUT.DAT which is the file that VectorCAST expects to contain the test TASKING C166 CLASSIC WITHTRACE32 SIMULATOR ON LINUX 304 results. TRIMEDIA 305 TriMedia Configuration This section provides details about configuring VectorCAST to integrate with the TriMedia C/C++ compiler. First, select Tools => Options from the main toolbar. Choose the C/C++ tab to select the entry for “Trimedia” under the “Compiler” drop-down menu, as shown here: Next, ensure that the directories containing the TriMedia binaries are included in your PATH environment variable. These are most likely C:\Trimedia\bin and C:\Trimedia\tmComm\bin, but may be slightly different on your particular system. To specify a different TriMedia installation directory: On the Preprocessor/Compiler tab, change the “Library Include Directories” entry to match the location of the include, libdev\include, libdev\include\tml, and include\ops directories on your system. Use DOS formatted short-paths (8.3/no spaces). TRIMEDIA 306 Click Apply to save the changes. The default command settings should be sufficient to run the Tutorial example in the VectorCAST/C++ User’s Guide, and it is strongly recommended that you do so before trying to test your application code. It is your responsibility to customize these settings for your particular device and development environment. The Preprocessor/Compiler tab contains the compiler commands and options that will be used to compile the test harness. Since the TriMedia preprocessor does not support retaining comments in preprocessed code, the “Use new generation preprocessor” option is selected by default (on the Misc tab). Having this option on allows you to use the “Provide code coverage in header files” feature (on the Coverage tab). For the new generation preprocessor to work, the predefined macros must be set in the Defined variables box. Use the macros that are defined for your set of compiler options. For example, if you add the compile option “-eb”, remove __LITTLE_ENDIAN__=1 and add __BIG_ENDIAN__=1. TRIMEDIA 307 The “Linker” tab contains the linker commands and options that will be used to link the test harness. When you are ready to begin testing your application code, a good starting point for these settings would be the actual values used to compile and link the code you are about to test. Specific details and discussion of the options that tmcc.exe accepts is outside the scope of this document. Refer to TriMedia’s compiler and linker documentation for more information on this topic. Lastly, click OK to save the settings and close the options dialog. Target Execution For execution with the TriMedia simulator, VectorCAST uses the command specified by “Execute command” in the C/C++ tab of the Options dialog: tmsim. Target Debug Execution For debugging with the TriMedia debugger, VectorCAST invokes tmdbg with the “-v0” option to determine the java command used to run the debugger. Then it runs this command to bring up the debugger. At the tmdbg> prompt, use the load command to load the harness executable. The executable is uut_inte.exe or uut_inst.exe if you have coverage enabled. The first time you execute with debug, you will get a reminder of how to do this: TRIMEDIA 308 When you are done debugging, exit the debugger to return to VectorCAST. WIND RIVER DIAB/SINGLESTEP SIMULATOR 309 Wind River Diab/SingleStep Simulator Configuration This section provides details about configuring VectorCAST to work with Wind River’s Diab/SingleStep debugger. In the Tools => Options dialog, C/C++ tab, choose Diab/Single Step PPC or Diab/Single Step 68k. Target Execution For the SingleStep debugger/simulator VectorCAST will create and use a singlestep.scr script file to start the simulator, load the appropriate executable image, set-up the input and output data for the target execution, and start the program running. The script file that VectorCAST creates is similar to the following: debug -V 68332 C:\TEST\singlestep.exe targetio –I C:\TEST\vcast_stdin.dat –O C:\TEST\vcast_stdout.dat Go A template version of the SingleStep script is saved in a file called “singlestep.tmp”. If you need to customize the SingleStep script that VectorCAST is using, you can make changes to the template script WIND RIVER DIAB/SINGLESTEP SIMULATOR 310 file. Upon the next execution of the target program, VectorCAST will use the modified template file. As long as you keep the “targetio” command the same, and load “singlestep.exe” as the target executable you may add any legal SingleStep commands to the template script. Because SingleStep does not currently offer a “quiet mode” command line interface to the target simulator, you will see the SingleStep GUI pop up and be required to manually exit from SingleStep when the target execution is complete. The following is an overview of this process. When VectorCAST is ready to run on the target it will put up a dialog similar to the following: When you click “OK” VectorCAST will automatically start the SingleStep simulator. Note that the path to the simulator must be on your path! The main SingleStep application window will appear. You may open a command window in SingleStep to see the commands that have been executed by the “singlestep.scr” start-up script. This is started using the CMD icon in the icon tool bar at the top of the screen: When the program completes you will see a " Wind River Diab with TRACE32 Simulator on Linux Configuration This section provides details about configuring VectorCAST to work with Wind River’s Diab v5.6 compiler with the Trace32 debugger/simulator. Before you can use VectorCAST with TRACE32, both the compiler and TRACE32 must be set on your PATH environment variable. This is not done by default during TRACE32 installation, so you must either (a) set these variables permanently in the operating system, or (b) set them temporarily from the shell, and then launch VectorCAST from within that shell. Prior to running VectorCAST, the user must export the following environment variables. (modify these paths as necessary to match the install directories on your system. export Path=/home/blduser/WindRiver/diab/5.6.0.0/LINUX386/bin:$PATH export Path=/opt/t32:$PATH export WIND_PREFERRED_PACKAGES=diab-5.6.0.0 export WIND_HOME=/home/blduser/WindRiver export WIND_DIAB_PATH=/home/blduser/WindRiver/diab/5.6.0.0 export WRSD_LICENSE_FILE=/home/blduser/WindRiver/license/WRSLicense.lic export VECTORCAST_DIR=/home/blduser/52 export LM_LICENSE_FILE=7650@licenseserver export VCAST_T32=/opt/t32 In the Tools => Options dialog, C/C++ tab, choose Diab => PPC => Linux host => TRACE32 Simulator => C. WIND RIVER DIAB WITHTRACE32 SIMULATOR ON LINUX 313 Target Execution For the Trace32 debugger/simulator VectorCAST will create the necessary script file to start the simulator, load the appropriate executable image, set-up the input and output data for the target execution, and start the program running. The execution command for the PPC 5554 using TRACE32 is as follows: $(VCAST_TRACE32)/bin/pc_linux/t32mppc -c $(VCAST_TRACE32)/configsim.t32,$(VECTORCAST_DIR) /DATA/trace32/simulator_linux.cmm MPC5554 Regular target execution will open a TRACE32 window, execute the code, save the data and automatically close the TRACE32 window upon harness termination. In the case of a problem, TRACE32 will generate an error and interrupt script execution. This will help you (or VectorCAST Technical Support) to troubleshoot the situation. However, in order to return to VectorCAST you must close the TRACE32 instance that was open during execution. It is your responsibility to customize these settings for your particular device and development environment. Please note that these changes will be saved as long as you will be using the same working directory. For more information about this, please contact your Vector Software representative. Target Debug Execution Test Execution with Debug functions similarly to normal execution, except a breakpoint is set in the main function so execution stops there. You can manually set breakpoints, step through source and disassembly, and view data as you would during a normal debug session. WIND RIVER DIAB WITHTRACE32 SIMULATOR ON LINUX 314 Launching a debug execution of the test harness under TRACE32 will launch the TRACE32 debugger. You will have access to the very same functionality as in any TRACE32 environment. The execution will be stopped at the main function. If you need to get the results obtained during the execution under the control of the debugger, you must ensure that the test harness is enabled to run to its conclusion. For your convenience, a breakpoint is set at vCAST_END, which indicates the end of execution. The test data will not be captured automatically. Debug by single stepping through any code you wish to analyze. After the harness code reaches the breakpoint set at vCAST_END, you have completed harness processing but the data is only saved to memory at this point. You must save the data by typing the following script in TRACE32 command window. d.save.binary path_to_working_directory\VCAST_STDOUT.DAT Y.range(vcast_output_buffer) This will save the data contained in vcast_output_buffer (the buffer containing the results of the test case (s)) to a file called VCAST_STDOUT.DAT which is the file that VectorCAST expects to contain the test results. WIND RIVER VXWORKS 315 Wind River vxWorks Overview VectorCAST supports vxWorks 5.x and 6.x.The former is generally used with the Tornado host tools, while version 6.x is generally used with the newer WRS Workbench environment. The following sections describe how to configure VectorCAST and run test cases in each environment. Some of the sections are common to both environments, others are specific to either Tornado or Workbench, and are labeled appropriately. The VectorCAST-vxWorks RSP works the same way, regardless of the underlying CPU being targeted. Although the examples used in this section are specific to a PPC target, they can easily be adapted to other target CPUs. Before using VectorCAST with vxWorks, you must have a vxWorks target or a vxSim simulator booted, and a target server running. Additionally, you must be able to attach to the target using the “windsh” shell application. All of the variations involved in booting and configuring a vxWorks target are beyond the scope of this guide. For the sake of simplicity, we will use an example with vxSim. Starting vxSim in Tornado From the Tornado IDE, choose Tools => Simulator... . Select either the standard simulator, or a custom simulator that you have previously built. When prompted, allow Tornado to start a target server, by clicking “OK” in the following dialog. WIND RIVER VXWORKS 316 It is important to note the target server name showing in this dialog, as this name will be required in the configuration of VectorCAST. Setting up the Command Line Tools for Tornado Before you can start using VectorCAST, you need to ensure that the compiler and associated WRS tools are on your default path. It is also required that a number of Tornado-specific environment variables are set. The easiest way to set this up properly is to use the WRS supplied torvars.bat file. A common location for this file is in C:\Tornado\host\x86-win32\bin. It may be in a slightly different location for your installation of Tornado. You can see how this works if you open a DOS window, and “run” the torvars.bat file. After running the torvars.bat file you will be able to execute tornado commands like windsh. You should try this, to ensure that it works properly. The easiest way to set the command line tools up for VectorCAST to use is to create a small .bat file that will start VectorCAST. Here is an example: cd c:\test\c\vxsim call C:\Tornado\host\x86-win32\bin\torvars.bat start %VECTORCAST_DIR%\vcastqt.exe -lc If you save these commands to a file named start_vcast_for_vxworks.bat for example, double-clicking this .bat file will set up your environment and start VectorCAST. Starting vxSim in Workbench From the Workbench IDE, choose Target => New Connection... . Select the appropriate options in the resultant dialog, and then open a host shell by high-lighting the vxsim0 item in the Target Manager window and selecting Target => Host Shell from the main menu. WIND RIVER VXWORKS 317 This will result in a host shell window opening, which looks like this: Note the target server name that is displayed in the title bar of the window. In this example, it is vxsim0@wintester1. This name will be required in the configuration of VectorCAST. Setting up the Command Line Tools for Workbench Before you can start using VectorCAST, you need to ensure that the compiler and associated WRS tools are on you default path. It is also required that a number of WRS environment variables are set. The easiest way to set this up properly is to use the WRS supplied wrenv.exe file. A common location for this file is in C:\windriver. It may be in a slightly different location for your installation of vxWorks. You can see how this works if you open a DOS windows, and “run” the wrenv.exe file. After running the wrenv.exe file you will be able to execute vxWorks commands like windsh. You should try this to ensure that it works properly. WIND RIVER VXWORKS 318 Note: The wrenv.exe program requires a “–p product_code” option. A common product code would be “vxworks-6.5”. Your product code may be slightly different. The easiest way to set up the command line tools for VectorCAST, is to create a small .bat file that will start VectorCAST. Here is an example: cd c:\test\vxworks C:\windriver\wrenv.exe -p vxworks-6.5 -o run %VECTORCAST_DIR%\vcastqt -lc If you save these commands into a file named start_vcast_for_vxworks.bat for example, double-clicking this .bat file will set up your environment and start VectorCAST. Configuration Now that you have identified how to set up the command line tools for the version of vxWorks that you are using and to start VectorCAST with visibility to these tools, you are ready to configure the VectorCAST options for vxWorks. After starting VectorCAST, you should select Tools => Options dialog, C/C++ tab, to configure the VectorCAST compiler interface, choose Compilers => WindRiver and then one of the many choices. The only additional modification that needs to be made to this tab is to add the path to the vxWorks target include directory to the VectorCAST “Include Directories” option. This path will normally be: For Tornado: C:\Tornado\target\h For Workbench: C:\WindRiver\vxworks-6.5\target\h Next, choose the Tools => Options dialog, Target tab, and insert the name of the target server for your target in the “Board Name” option. Note that the target server name is case sensitive. Target Execution Before running with vxWorks, you must tell VectorCAST the name of the target server to be used to execute on the target. This information is provided via the “Target Options” dialog which is described in a previous section. Note: The name of the target server is case sensitive. For vxWorks, VectorCAST will automatically create a WindSh script (windsh.scr) in the environment WIND RIVER VXWORKS 319 directory and use this script file to execute the target program using the Wind River WindSh shell. A sample windsh.scr file is shown here: chdir "john:C:/test/c/vxworks/TEST/" cd "C:\test\c\vxworks\TEST\" ? set r [wtxObjModuleLoad windsh.dat] set r [lreplace $r 0 3] if { [llength $r] != 0 } { set fd [open "vxworks_undef_sym.txt" w] puts $fd "Undefined symbols:" foreach i $r { puts $fd $i } close $fd wtxObjModuleUnload windsh.dat exit -1 } ? ld < windsh.dat vcastid = sp (vcast_main) ? while { [file exists VCAST.END] != 1 } {after 1000} ? td vcastid unld "windsh.dat" exit A template version of the windsh script is saved in a file called windsh. Note: UNIX Only. VectorCAST cannot be run in the background on Unix when running with vxWorks. This is because the Tornado "windsh" application cannot run in the background. If you run VectorCAST in the background, processing will hang when you attempt to run a test case. A simple solution is to type "fg" in the command window to put VectorCAST back in the foreground. Note: If the target execution seems to hang at any point when using VectorCAST with vxWorks, you can use the Unix "ps" command or the Windows task manager to kill the "windsh" executable. Target Execution with vxWorks 653 VectorCAST has three compiler templates related to vxWorks 653; there are templates for versions 1.8, 2.1, and 2.2. The templates for versions 1.8 and 2.1 only support executing tests in the kernel WIND RIVER VXWORKS 320 partition. The template for version 2.2 supports executing tests in an application partition. If you are using vxWorks 653 version 2.2 or higher and you want to run tests in the kernel partition, then you should choose the 2.1 template. If you want to execute tests in an application partition, you should choose the 2.2 template. If you are using a vxWorks 653 version that is older than version 2.2 and you want to execute tests in an application partition, please contact Vector Software Technical Support. The table below summarizes which compiler template to choose. To run in To run in kernel partition application partition Choose template not supported; Using vxWorks 653 v1.8 WindRiver => vxWorks 653 v1.8 contact Vector Software Technical Support Choose template not supported; Using vxWorks 653 v2.1 WindRiver => vxWorks 653 v2.1 contact Vector Software Technical Support Choose template Choose template Using vxWorks 653 v2.2 WindRiver => vxWorks 653 v2.1 WindRiver => vxWorks 653 v2.2 Because vxWorks 653 does not support C++ applications being run in the kernel partition, if you are building a C++ application then you must execute your VectorCAST test cases in an application partition. For both kernel partition and application partition testing, VectorCAST communicates with the target by using the vxWorks windsh tool. For kernel partition testing, you boot the kernel on the target, and then VectorCAST uses the "ld" command to load the test driver onto the target and execute it. This is the same way things work for "normal" vxWorks 5.x and 6.x environments. For application partition testing, things are more complicated. You cannot dynamically download an application into an application partition. It has to be built, together with the kernel, into a monolithic image that the target boots. To support this, VectorCAST delivers two vxWorks 653 projects with the VectorCAST distribution that you can use to easily create your test environments. To run with vxWorks 653, use one of the two .zip files provided in the VectorCAST installation directory (%VECTORCAST_DIR%\DATA\WindRiver). The VectorCAST_SinglePartition.zip file enables you to build an application partition and execute on the vxSim simulator; the VectorCAST_ SinglePartition_RAM_payload.zip file supports RAM payload testing on a live board (SBC). Note: You may notice a pair of .bat files associated with the .zip files in the directory. VectorCAST uses these files internally when running the make command. Example Using vxSim The following section takes you through the steps required to use the single partition project to build and execute a VectorCAST test environment with vxSim. In preparation, create a new directory (such as c:\vcast_target_testing), copy the file VectorCAST_ SinglePartition.zip to this directory, and then unzip it. WIND RIVER VXWORKS 321 1. Start a new vxWorks 653 Development shell (Start => WindRiver => vxWorks 653 2.2 for PPC => vxWorks Development Shell) 2. In the shell window, execute the following commands (click “Yes” to allow overwriting if you see any errors regarding that) : cd c:\vcast_target_testing\singlepartition make BSP=simpc CPU=SIMNT PARTADDR=0x28000000 create make BSP=simpc CPU=SIMNT PARTADDR=0x28000000 create mosbuild posbuild set VCAST_PSC_MAKE_FILE_BASE_DIRECTORY= c:\vcast_target_testing\singlepartition set VCAST_PSC_USE_ADDRESS_SPACE=true mkdir c:\vcast_target_testing\io_directory cd \vcast_target_testing 3. Start VectorCAST (%VECTORCAST_DIR%\vcastqt) 4. In VectorCAST’s Options dialog, C/C++ tab, select the compiler WindRiver => vxWorks 653 v. 2.2 => vxSim => C++. 5. Switch to the Target tab and set the “Board name” to vxsim0@ Note: The name of your target server will be different. You will only know the exact target server name after Step 12. We use the name vxsim0@ 6. Set the “I/O Directory” to C:\vcast_target_testing\IO_Directory 7. Build a simple test environment using the manager.c file from the VectorCAST Tutorial directory. Insert a test case and execute it. 8. When VectorCAST is ready to execute on the target, you see this message: Once you have completed the following steps to create the target connection, come back to this dialog and click OK. WIND RIVER VXWORKS 322 9. Open the Wind River WorkBench IDE, and create a new target connection for a vxWorks 653 Simulator. 10. For the boot filename, browse to: C:\vcast_target_testing\SinglePartition\simpc_SinglePartition\integration\boot.txt and then click Next. 11. For the Target Server Options, you need to change the -R option to match the VectorCAST option for IO_Directory. It should be: -R C:\vcast_target_testing\IO_Directory WIND RIVER VXWORKS 323 12. Click Next four times to accept the default options for everything else, and then click Finish to create the target. 13. Right-click on the new target, and select “Connect.” Note: If the target server name is not vxsim0@ 14. In VectorCAST, click OK in the previously displayed dialog. At this point the test executes. To run the next test case, you do not have to recreate the vxWorks target, you simply can type reboot into the vxSim shell window when prompted by VectorCAST to reboot the target. Example Using SBC The following section takes you through the steps required to use the single partition project to build and execute a VectorCAST test environment with a WRS SBC83XX PowerQUICC II Pro development board. In preparation, create a new directory (such as c:\vcast_target_testing), copy the file VectorCAST_ SinglePartition.zip to this directory, and then unzip it. 1. Start a new vxWorks 653 Development shell (Start => WindRiver => vxWorks 653 2.2 for PPC => vxWorks Development Shell). 2. In the shell window, execute the following commands (click “Yes” to allow overwriting if you see any errors regarding that): WIND RIVER VXWORKS 324 cd c:\vcast_target_testing\singlepartition make BSP=wrSbc834x CPU=PPC603 PARTADDR=0x40000000 create make BSP=wrSbc834x CPU=PPC603 PARTADDR=0x40000000 create mosbuild posbuild set VCAST_PSC_MAKE_FILE_BASE_DIRECTORY= c:\vcast_target_testing\singlepartition set VCAST_PSC_USE_ADDRESS_SPACE=true mkdir c:\vcast_target_testing\io_directory cd \vcast_target_testing 3. Start VectorCAST (%VECTORCAST_DIR%\vcastqt). 4. In VectorCAST’s Options dialog, C/C++ tab, select the compiler WindRiver => vxWorks 653 v. 2.2 => SBC83xx => C++. 5. Switch to the Target tab and set the “Board name” to tgt_wrsbc@ Note: The name of your target server will be different. You will only know the exact target server name after Step 12. We use the name tgt_wrsbc@ 6. Set the “I/O Directory” to C:\vcast_target_testing\IO_Directory 7. Build a simple test environment using the manager.c file from the VectorCAST Tutorial directory. Insert a test case and execute it. 8. When VectorCAST is ready to execute on the target, you see this message: Once you have completed the following steps to create the target connection, come back to this dialog and click OK. 9. Open the Wind River WorkBench IDE, and create a new target connection for a vxWorks 653 Target Server. WIND RIVER VXWORKS 325 10. For the boot filename, browse to: C:\vcast_target_testing\SinglePartition\wrSbc834x_SinglePartition \integration\boot.txt and then click Next. 11. For the Target Server Options, you need to change the -R option to match the VectorCAST option for IO_Directory. It should be: WIND RIVER VXWORKS 326 -R C:\vcast_target_testing\IO_Directory 12. Click Next four times to accept the default options for everything else, and then click Finish to create the target. 13. Now you need to boot the target with the same boot.txt that was configured into the target server. In general, this is accomplished by starting an FTP server on the boot host, and using the built in boot program on the target point to the boot.txt file. 14. When you see the vxWorks banner on the target terminal, right-click on the “tgt_wrsbc” target entry in WorkBench, and select “Connect.” Note: If the target server name is not tgt_wrsbc@ 15. In VectorCAST, click OK in the previously displayed dialog. At this point the test executes. To run the next test case, you do not have to recreate the vxWorks target, you simply can type reboot into the vxSim shell window when prompted by VectorCAST to reboot the target. Troubleshooting a vxWorks Target Connection There are multiple things that can go wrong when trying to run on a vxWorks target. This section will address some of the more common issues. A good place to start when diagnosing problems with a target connection is in the target output file. This is the file that contains a log of the windsh session that VectorCAST uses to communicate with the target. If there is a problem this file will contain the information required to determine a solution. The target output file can be viewed from the VectorCAST GUI under the Environment => View => Target Output menu choice. The actual file being viewed is in the Test Environment directory, and is named WIND RIVER VXWORKS 327 “windsh.out” The following is what this file looks like after a successful execution: chdir "john:C:/test/c/vxworks/TEST/" value = 0 = 0x0 cd "C:\test\c\vxworks\TEST\" value = 0 = 0x0 ? set r [wtxObjModuleLoad windsh.dat] 0xe75020 0x13c220 0x14cf48 0x14d0b0 set r [lreplace $r 0 3] if { [llength $r] != 0 } { set fd [open "vxworks_undef_sym.txt" w] puts $fd "Undefined symbols:" foreach i $r { puts $fd $i } close $fd wtxObjModuleUnload windsh.dat exit -1 } ? ld < windsh.dat Loading C:/test/c/vxworks/TEST/windsh.dat _|_/ value = 15159328 = 0xe75020 vcastid = sp (vcast_main) task spawned: id = 573238, name = s2u0 vcastid = 0x13b210: value = 5714488 = 0x573238 ? while { [file exists VCAST.END] != 1 } {after 1000} ? td vcastid Task not found. value = -1 = 0xffffffff unld "windsh.dat" value = 0 = 0x0 exit Problems Connecting to the Target The first obstacle to overcome is the attachment to the target server. If there is a problem with windsh attaching to the target server, VectorCAST will appear to hang, and you will have to kill the “windsh” process as detailed in the previous section. In this case, the target output file will contain: Waiting to attach to target server WIND RIVER VXWORKS 328 (press CTRL+Break to stop) In this case the most likely cause is that the name of the target server has not been entered properly in the VectorCAST Target options dialog. The name of the target server should be checked against the name displayed in the Tornado GUI. Note that the upper and lower case letters in the name must match (vxsim@MyHost is not the same as vxsim@myhost). Problems with Input/Output Devices The next most common error is that the “chdir” command in the “windsh script” script created by VectorCAST is not accepted by the windsh. In this case the “value” returned by vxWorks for the faulty command will be non-zero. chdir "host:C:/TEST/C/vxsim/TEST/" value = 0 = 0x0 In this example the “chdir” command has been issued by the script and accepted by vxWorks, so the returned “value” is 0. If the returned value is not 0, then there was an error. The “chdir” command tells vxWorks to use an alternate IO device for default file IO. The format of the command is: “chdir The default script that VectorCAST creates, uses the “hostname” of the machine you are running on as the default If you are having trouble with the “chdir” command you need to check if it is the -> devs drv name 0 /null 1 /tyCo/0 3 host: 4 /vio 5 /tgtsvr value = 0 = 0x0 If your hostname is not in the list, then it probably means that the target was booted from a different machine than the one you are currently using. To solve this problem you may reboot the target from your current machine, or use the Boot Hostname option on the Target tab of the Tools => Options dialog to enter the current boot host device name. Problems with Input/Output Paths Another problem that you can have with the “chdir” command is that the This is most often a problem on a Unix system when the “User” that has booted the target is not the same user who is using the target. There are two solutions to this problem: either reboot the target using a different Username, or use the VectorCAST “I/O Directory” option to provide a directory path to be used for all file I/O with the target. This “I/O Directory” would have world “read” and “write” permission. If this option is used, VectorCAST will use this directory in place of the environment directory to perform all I/O with the target. Using the /tgtsvr Device for Input/Output As an option to the above described host I/O mechanism, you can configure VectorCAST to use the /tgtsvr device for I/O. By default, VectorCAST is configured to use unqualified filenames for its target I/O. Unqualified names will be fully qualified by vxWorks using the value provided with the chdir command. As an alternative, you can configure VectorCAST to use the /tgtsvr device for I/O. In this case, the association between the /tgtsvr device and the physical directory on the host machine, will be made when you configure the Tornado Target Server. You can use this technique, if when you type: “devs” in any windsh window, “/tgtsvr” is one of the listed devices. This method works by having the target (vxWorks) create an association between the logical device “/tgtsvr” and a physical directory on the host machine. There are three steps involved in configuring this mechanism for I/O: 1. In Tornado, when you create your target server, you need to provide a “Root I/O” directory as shown in the following (Windows) screen shot. Note that we have chosen c:\vcast_io as the Root file system directory. WIND RIVER VXWORKS 330 2. In VectorCAST, you need set Harness File Prefix option to the value “/tgtsrv/”. 3. Also in VectorCAST, you need to configure the Target I/O directory to match the directory that you chose in the Target Server dialog. WIND RIVER VXWORKS 331 Improving I/O Performance With some target boards file I/O between the target board and the host system may be slow. In this case, the slowness is generally caused by the file open and file close commands being slow. To reduce the number of file open and close commands that are needed, you need to set two options. One is set via the defined variable: VCAST_USE_FILES. This variable is set in the C/C++ tab of the Tools => Options dialog as shown here: WIND RIVER VXWORKS 332 The other option is set via the Target option: I/O uses stdin/stdout. This option is located on the Target tab of the Tools => Options dialog as shown here: WIND RIVER VXWORKS 333 After these two options are set, you must recompile any existing environments for these options to take effect. Use the Environment => Recompile => Automatic menu option to recompile. If your test cases are running slowly (more than a few seconds to execute a test for the tutorial example) then please try this option. Debugging with Tornado Crosswind on Windows In order to execute test cases using the Crosswind debugger on a Windows platform, some manual steps are required. The manual steps are required because it is not possible to invoke the Crosswind debugger from outside of the Tornado IDE. On Unix, it is possible to invoke Crosswind directly. The following steps will take you through the process of debugging using Crosswind for a vxSim executable. Debugging with a live board is very similar. 1. At the time that you want to debug, go to the Tools => Options dialog, select the C/C++ tab, and then the Debug sub-tab. By default, for the vxSim compiler template, the value for Debugger command will be: gdbsimnt, as shown in the following screen shot: WIND RIVER VXWORKS 334 2. Change the Debugger command to be "cmd". This will cause a DOS command shell window to be popped up when VectorCAST is ready to debug. 3. Check that the linker command has the option string: ccsimpc –g –r -nostdlib -Wl,--force-stabs-reloc as shown in the following screen shot (this option is critical for debugging). 4. To debug a test case, right click on the test case name in the VectorCAST GUI, and select: Execute with debug. This will cause VectorCAST to run a windsh debug script that will load the executable image onto the simulator (or live target board). The script that VectorCAST uses to do this is called windsh.dbg and is located in the environment directory. Also, because you have changed the Debugger command option to be cmd, VectorCAST will spawn a DOS shell window, and hang until this window is closed. This gives you the opportunity to switch to the Tornado IDE and debug using Crosswind. 5. In the Tornado IDE, click on the "Bug" toolbar icon (A) to start up the debugger, and then click on the "Running Man" toolbar icon (B) to start the test execution. WIND RIVER VXWORKS 335 6. When you click on the "Running Man", a dialog will pop up asking you to provide the entry point. You should enter vcast_main, as shown in the following screen shot: 7. If you also select: Break at entry point, the debugger will stop execution at the start of the VectorCAST test driver. 8. At this point you can debug as you normally would using Crosswind. 9. If you allow the test to run through to completion after you are done debugging, VectorCAST will automatically close the DOS window, and build the test execution reports. If you wish to terminate debugging without allowing the VectorCAST test harness to complete, you will have to close the DOS window manually to release VectorCAST from its wait state. Execution Methods INTRODUCTION 337 Execution via a Remote Shell Introduction In some cases, it may be necessary to execute test cases on a remote machine via a remote or secure shell. VectorCAST allows this through the execute commands < These execute commands require the following: 1. The chosen VectorCAST compiler template has either no execute command associated with it or one of the < In some cases, it may be necessary to execute test cases on a remote machine via a remote or secure shell. VectorCAST allows this through the execute commands < These execute commands require the following: 1. The chosen VectorCAST compiler template has either no execute command associated with it or one of the < NFS is most convenient as a way to transfer the files between the local_machine and the remote_machine. If your target does not support NFS, or if your host system is Windows, then skip to the next section for information on setting up anonymous ftp to transfer files. EXECUTION VIA A REMOTE SHELL 338 The examples in this section assume that local_machine and remote_machine are both running a UNIX variant operating system. On each machine, there exists a user named vcast_user whose home directory is /home/vcast_user. Login to local_machine and create a test directory. [vcast_user@local_machine ~]$ mkdir test_dir [vcast_user@local_machine ~]$ touch test_dir/test_file_from_local Login to remote_machine as vcast_user and create the exact same directory (the full path to the directory must be identical on each machine). [vcast_user@remote_machine ~]$ mkdir /home/vcast_user/test_dir Next, login as root and mount the contents of the directory from local_machine using the Network File System (NFS). [root@remote_machine /]# mount local_machine:/home/vcast_user/test_dir /home/vcast_user/test_dir -t nfs Note: This mount will not persist over a reboot. If remote_machine is rebooted frequently, you’ll want to add an entry to remote_machine’s /etc/fstab file. Contact your system administrator or Vector Software technical support for assistance. Now verify that remote_machine can see the test file that exists on local_machine: [vcast_user@remote_machine ~]$ cd test_dir [vcast_user@remote_machine ~/test_dir]$ ls test_file_from_local Finally you should verify that vcast_user has permission to write to this directory from remote_machine: [vcast_user@remote_machine ~/test_dir]$ touch test_file_from_remote Login to local_machine as vcast_user and verify that /home/vcast_user/test_dir/test_file_from_remote exists. Note: All VectorCAST environments must be built inside this common directory for execution via a remote shell to succeed! Setting Up Anonymous FTP If your target does not support NFS or if your host system is Windows, then anonymous ftp is a suitable alternative to allow the transfer of files between the local_machine and the remote_machine. First, you should verify that you can create a file in the /tmp directory on remote_machine: [vcast_user@remote_machine ~]$ touch /tmp/test_file_from_remote If you cannot create a file in /tmp, or if /tmp does not exist, you will need to change the permissions on, or create this directory. EXECUTION VIA A REMOTE SHELL 339 Next, check if anonymous ftp is supported by the remote_machine. Open a shell window on the local_ machine and type: [vcast_user@local_machine ~]$ ftp remote_machine User (remote_machine.server): anonymous Password: When prompted for a username, enter: anonymous. The remote_machine should indicate that anonymous access is allowed, and to enter an email address as a password. Once logged in, you should be able to type: ftp> ls /tmp/test_file_from_remote /tmp/test_file_from_remote Setting Up scp If your target does not support NFS but is running an ssh server and your host supports the scp command, then secure copy is a suitable alternative to allow the transfer of files between the local_machine and the remote_machine. First, you should verify that you can create a file in the /tmp directory on remote_machine: [vcast_user@remote_machine ~]$ touch /tmp/test_remote If you cannot create a file in /tmp, or if /tmp does not exist, you will need to change the permissions on, or create this directory. Next, check if scp is supported by the remote_machine. Open a shell window on the local_machine and type: [vcast_user@local_machine ~]$ touch test_local [vcast_user@local_machine ~]$ scp test_local remote_machine:/tmp/ [vcast_user@local_machine ~]$ ssh vcast_user@remote_machine ls /tmp/test_local If you are prompted for a password during either the scp or ssh commands, follow the steps documented in “Setting Up ssh” on page 340 to enable automatic authentication. Setting Up rsh If remote_machine is running an rsh server, you can use the < Note: The required rsh.exe binary is not included in Windows 7 installations. Please see our online knowledgebase for information on how to resolve this issue. From local_machine, run the following command: [vcast_user@local_machine ~]$ rsh remote_machine Password: EXECUTION VIA A REMOTE SHELL 340 If you’re immediately logged into remote_machine without needing to enter a password, your configuration is already set up – skip to the section “Target Execution Using a Remote Shell” on page 345. If you receive a “remote_machine: Connection refused” message, then remote_machine’s rsh server is not functioning. Contact your system administrator or skip to the section “Setting Up ssh” on page 340 to try a secure shell. If you are prompted for a password, enter it and press Enter. Once you are logged on to remote_machine, edit or create the file ~/.rhosts adding the following line: local_machine vcast_user This will give vcast_user permission to rsh into remote_machine from local_machine without requiring a password. Login again to confirm this behavior. [vcast_user@remote_machine ~]$ exit rlogin: connection closed. [vcast_user@local_machine ~]$ rsh remote_machine [vcast_user@remote_machine ~]$ If you are prompted for a password, review the above steps making sure you’ve done everything correctly. Contact your system administrator or Vector Software technical support for further assistance. The last thing to ensure is that you can navigate to the common NFS mounted directory OR the /tmp directory, with permission to read, write and execute files. If you are using NFS for file sharing then type: [vcast_user@remote_machine ~]$ cd test_dir If you are using FTP for file sharing then type: [vcast_user@remote_machine ~]$ cd /tmp Next, verify that you can create a file: [vcast_user@remote_machine ~/test_dir]$ touch test_file_via_rsh If you receive a “touch: test_file_via_rsh: Permission denied” message you will have to adjust the permissions on the directory. If all of these tests have succeeded, you should now be able to skip to the “VectorCAST Configuration for Remote Shell Execution” section on page 342 and choose < If remote_machine is running an ssh server, you can use the < From local_machine, run the following command: EXECUTION VIA A REMOTE SHELL 341 [vcast_user@local_machine ~]$ ssh remote_machine vcast_user@local_machine’s password: If you’re immediately logged into remote_machine without needing to enter a password, your configuration is already set up – skip to the section “Target Execution Using a Remote Shell” on page 345. If you receive a message similar to: The authenticity of host 'local_machine (xxx.xxx.xx.xx)' can't be established. RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx. Are you sure you want to continue connecting (yes/no)? …type yes and press Enter, followed by your password and Enter. Once you’re able to login to remote_machine via ssh, you’ll need to automate the process so you’re not prompted for a password each time you run a test case. Logoff of remote_machine: [vcast_user@remote_machine ~]$ exit Connection to remote_machine closed. Note: Disclaimer: The following documents one potential way to automate a secure shell login. In no way does it assume to account for all possible scenarios involving versions of ssh past, present or future. Be warned that the following actions decrease the security level of the target machine and Vector Software takes no responsibility in doing so, nor in any or all behavior occurring as a result of these actions. Please consult your system administrator and/or management before continuing! First, generate an authentication key on local_machine: [vcast_user@local_machine ~]$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file to save the key (/home/vcast_user/.ssh/id_rsa): Then copy the key to remote_machine using secure copy (other methods are also fine, for example nfs, ftp, etc.): [vcast_user@local_machine ~]$ scp ~/.ssh/id_rsa.pub remote_machine:~ vcast_user@remote_machine's password: [password] Now login to remote_machine and add the new key to your ~/.ssh/authorized_keys file: [vcast_user@local_machine ~]$ ssh remote_machine vcast_user@remote_machine's password: [password] EXECUTION VIA A REMOTE SHELL 342 [vcast_user@remote_machine ~]$ cd ~/.ssh [vcast_user@remote_machine ~/.ssh]$ touch authorized_keys [vcast_user@remote_machine ~/.ssh]$ chmod 600 authorized_keys [vcast_user@remote_machine ~/.ssh]$ cat ~/id_rsa.pub >> authorized_keys [vcast_user@remote_machine ~/.ssh]$ rm ~/id_rsa.pub This will give local_machine permission to ssh into remote_machine without requiring a password. Login again to confirm this behavior. [vcast_user@remote_machine ~/.ssh]$ exit Connection to remote_machine closed. [vcast_user@local_machine ~]$ ssh remote_machine [vcast_user@remote_machine ~]$ If you are prompted for a password, review the above steps making sure you’ve done everything correctly. Contact your system administrator or Vector Software technical support for further assistance. The last thing to ensure is that you can navigate to the common NFS mounted directory OR the /tmp directory, with permission to read, write and execute files. If you are using NFS for file sharing then type: [vcast_user@remote_machine ~]$ cd test_dir If you are using FTP for file sharing then type: [vcast_user@remote_machine ~]$ cd /tmp Next, verify that you can create a file: [vcast_user@remote_machine ~/test_dir]$ touch test_file_via_ssh If you receive a “touch: test_file_via_ssh: Permission denied” message you will have to adjust the permissions on the directory. If all of these tests have succeeded, you should now be able to continue to the next section and choose < If you are using NFS for Remote Shell Execution, there are two options that must be configured to build environments and execute test cases via a remote shell: "Execute command", and "Board name."The "Execute command" is located on the C/C++ tab of the Tools => Options dialog, and the "Board name" is located on the Target tab. The "Execute command" must be set to either < The “Board name” field must be set to the target machine's IP address or resolvable hostname. Note: Hostnames are case sensitive. EXECUTION VIA A REMOTE SHELL 344 If you are using FTP for Remote Shell Execution, then only the "Execute command" option needs to be set. When using FTP, the default “Execute command” should be: $(VECTORCAST_DIR)\DATA\gnu_target\execute_rsh.bat 192.168.0.1 -lroot “execute_rsh.bat” is a script file that will use ftp to connect to the remote machine, transfer the test harness, and execute the test. The IP address of your target should be substituted for the default IP address shown above. The –lroot option should be modified to reflect a user that has permissions on the target to create and execute files. The only assumption that this script makes is that the directory /tmp exists on the remote machine and is writable. If you are using scp for Remote Shell Execution, then only the "Execute command" option needs to be set. When using scp, the default “Execute command” should be: $(VECTORCAST_DIR)/DATA/gnu_target/execute_scp.sh vcast_user remote_machine “execute_scp.sh” is a script file that will use scp and ssh to connect to the remote machine, transfer the test harness, and execute the test. The IP address or hostname of your target should be substituted for the default remote_machine shown above. The vcast_user option should be modified to reflect a user that has authentication to ssh onto the target without being prompted for a password, and permissions on the target to create and execute files. The test harness files will be copied and executed on the target in vcast_user’s home directory. If you prefer that this happen in another location, execute_scp.sh accepts an optional working_dir parameter. Set EXECUTION VIA A REMOTE SHELL 345 the “Execute command” field appropriately: $(VECTORCAST_DIR)/DATA/gnu_target/execute_scp.sh vcast_user remote_machine working_dir The working directory is relative to vcast_user’s home directory unless a full path is provided (passing in “tmp” would copy the test harness to /home/vcast_user/tmp whereas passing in “/tmp” would use /tmp). Target Execution Using a Remote Shell Before running test cases on a remote machine via a remote or secure shell, you must setup NFS OR anonymous ftp, setup automatic login with either rsh or ssh, choose the appropriate Execute command, and enter the target machine’s IP or hostname in the Tools => Options dialog, Target tab, Board name field. See the above setup and configuration sections for details and additional requirements. When a test case is executed via remote execution, VectorCAST will automatically execute an rsh or ssh command to login to the target, cd to the environment directory and run the required program. When running a test case, VectorCAST will output a message to the status window, similar to the following: Connecting to Target 'remote_machine' to Execute Program: rsh remote_machine 'cd /home/vcast_user/test_dir/DEMO/; ./UUT_INTE' A successful execution is followed by a “Test Execution Complete” message. If you see a “Test Execution Failed” message in the Message window or receive a pop-up dialog with a similar message, then your configuration is incorrect. To help diagnose the problem, in the status window, highlight the command VectorCAST is trying to run, right-click and select Copy. Now paste that text into a shell on the host machine and run the command from there. You’ll receive more information about the problem, which will fall into one of three categories: l Automatic login via rsh/ssh is not setup properly (see page 338 or 340); l Common directory is not NFS-mounted properly or has incorrect permissions (see page 337); l The program VectorCAST is trying to run isn’t compatible with the target’s operating system and/or machine architecture. All of the above problems can be resolved by carefully going through the above setup and configuration sections. If you’ve successfully passed each section and are still having problems executing, contact Vector Software support. If you had previously built an environment on the host, you’ll want to rebuild the range data to acquire the target’s type range information. Once you can successfully execute test cases, select Environment => Rebuild Range Data. (This is only necessary if you modify the execute command after the environment has been built.) Target Debug Execution Debugging the test harness on a remote machine via a remote or secure shell is similar to normal execution. Ensure that the normal target execution is functioning properly before continuing (see the EXECUTION VIA A REMOTE SHELL 346 preceding section). To configure debug execution, choose Tools => Options from the main menu bar. Select the C/C++ tab followed by the Linker/Debug tab. The “Debugger command” field contains the debugger executable that will be invoked on the program VectorCAST is running. If you need to pass any specific arguments to the debugger such as a startup file or target parameters, do so here: The text from this field is copied exactly and inserted before the program in the remote command. Again, the command is displayed in the status window: Connecting to Target 'remote_machine' to Execute Program: rsh remote_machine 'cd /home/vcast_user/test_dir/DEMO/; gdb ./UUT_INTE' If this command succeeds, the debugger will start and you’ll be able to set breakpoints, step through the code and view variables as usual. If the command fails, as the above section suggests, copy the exact command VectorCAST is running and run it on a local shell. One problem that can arise specifically when trying execute with a graphical debugger is the DISPLAY variable might not be set correctly for you to log into the target machine. A possible solution would be to set it in the Debugger command field: DISPLAY=local_machine:0.0 gvd. If problems persist and you’ve reviewed all the above configuration settings, please contact Vector Software technical support for further assistance. STANDARD I/O 347 Standard I/O Introduction When running a VectorCAST test, the test harness needs to read in the test stimulus data, and create the test results via some Input Output (I/O) mechanism. For all host (native) environments and many target environments, the I/O takes place via file operations. When the test harness needs to read the stimulus data, it will open the input data file, and read the stimulus data. Similarly, when the test harness needs to write the results data, it will create an output data file, and write to that file. The input data is actually contained in several files, and the output data is actually written to several files. In some target test environments, file operations, while supported, may be slow. The slowness is generally a function of the underlying connection mechanism that is used to connect the target to your network, the operating system being used, or some other unknown factor. In this case, or where there is no file IO capability from the target, the last resort solution is to use the Standard I/O mechanism to improve performance. There are two methods for customizing file I/O. One method uses the test harness standard input (stdin) and standard output (stdout) for the input and output data. VectorCAST will concatenate all input into a single file before the test is run (VCAST_STDIN.DAT). After the test is run, VectorCAST expects all of the output data to exist in the file: VCAST_STDOUT.DAT. The second method uses the compiler to compile the input test data directly into the test harness, and uses standard output for the output data. Using either of these methods requires configuration options to be set for both the VectorCAST application and for the test harness. The following sections describe the configuration process in detail. Configuring to Use Stdin and Stdout To configure the test harness to use stdin and stdout for I/O, you must set the option: "I/O uses stdin/stdout". This option is located on the "Target" tab of the Tools => Options dialog, as shown in the following screen shot: STANDARD I/O 348 This option causes the defined variable VCAST_STDIO to be set when the VectorCAST I/O module is compiled. If you set this option after a test environment is already built, you will need to use the Environment => Recompile => Automatic command to recompile the test harness with this setting active. When this option is active, the test harness will read input data from stdin, and all output data will be written to stdout. VectorCAST can be configured for manual or automatic text execution. To configure for automatic test execution, set the environment variable VCAST_EXECUTE_WITH_STDIO to True. This environment variable must be set at the operating system level before VectorCAST is started. To configure for manual test execution, set the option: Execute Command to “< Target Execution - Stdin/Stdout (Automatic) When the environment variable VCAST_EXECUTE_WITH_STDIO is set to True, VectorCAST will execute test cases automatically using the Execute Command specified on the Tools => Options dialog, C/C++ tab. (For example, the execute command simppc is used for Green Hills PPC Simulator C++.) VectorCAST automatically redirects the stdin of the process to the file VCAST_STDIN.DAT, and the output to the file VCAST_STDOUT.DAT. Target Execution - Stdin/Stdout (Manual) Setting the “Execute Command” string to be “< All the steps in between are performed by you. The nominal sequence to run in this mode is as follows: 1. VectorCAST creates VCAST_STDIN.DAT. 2. VectorCAST puts up the following dialog and “hangs” waiting for you to run the target program: STANDARD I/O 350 3. Run the target program (in this case UUT_INST.EXE) on your host machine, simulator, or target, with the stdin mapped to the file VCAST_STDIN.DAT and the output mapped to VCAST_STDOUT.DAT. (For example, execute the command “UUT_INST < VCAST_ STDIN.DAT > VCAST_STDOUT.DAT”.) 4. When the target program is done, click OK in this dialog. 5. VectorCAST will come off its “hang” and post process the VCAST_STDOUT.DAT file to create all of the normal VectorCAST execution reports. Configuring to Use Stdout Only To configure the test harness to use stdout, you must set the option: “I/O uses stdout only” in addition to "I/O uses stdin/stdout". These options are located on the "Target" tab of the Tools => Options dialog, as shown in the following screen shot: STANDARD I/O 351 This additional option causes the defined variable VCAST_STDOUT to be set, when the VectorCAST I/O module is compiled. If you set these options after a test environment is already built, you will need to use the Environment => Recompile => Automatic command to recompile the test harness with this setting active. When these options are active, the test harness will read input data compiled into the harness, and all output data will be written to stdout. VectorCAST can be configured for manual or automatic text execution. To configure for automatic test execution, set the environment variable VCAST_EXECUTE_WITH_STDOUT to True. This environment variable must be set at the operating system level before VectorCAST is started. To configure for manual test execution, set the option: Execute Command to “< Target Execution - Stdout (Automatic) When the environment variable VCAST_EXECUTE_WITH_STDOUT is set to True, VectorCAST will execute test cases automatically using the Execute Command specified on the Tools => Options dialog, C/C++ tab. (For example, the execute command simppc is used for Green Hills PPC Simulator C++.) VectorCAST automatically redirects the output to the file VCAST_STDOUT.DAT. Target Execution - Stdout (Manual) Setting the “Execute Command” string to be “< All the steps in between are performed by you the tester. The nominal sequence to run in this mode is as follows: 1. VectorCAST puts up the following dialog and “hangs” waiting for you to run the target program: VECTORCAST MONITOR 353 2. Run the target program (in this case UUT_INST.EXE) on your host machine, simulator, or target, with the output mapped to VCAST_STDOUT.DAT. (For example, execute the command “UUT_INST > VCAST_STDOUT.DAT”.) 3. When the target program is done, click OK in this dialog. 4. VectorCAST will come off its “hang” and post process the VCAST_STDOUT.DAT file to create all of the normal VectorCAST execution reports. For more information on using this functionality please contact Vector Technical Support via e-mail at [email protected]. VectorCAST Monitor If there exists a command line interface that allows downloading of the target via a serial port, it may be possible to use the VectorCAST monitor functionality. For information on using this functionality please contact Vector Software Technical Support via e-mail at [email protected]. Index: < Index COMREADER_ENABLED 36 COMREADER_PARITY 37 < application partition 320 PRECOMPILE_EXT 28 ARM SCORE_DEBUG_CMD 41 configuring 48 SCORE_EXECUTE_CMD 41 armsd 14 assembler command 27 STARTUP_FILE 28 ASSEMBLER_CMD 27 SUBSTITUTE_CODE_FOR_C_FILE 41 banked memory 143 TARGET_BOOT_HOSTNAME 31 banked memory model TARGET_IO_DIRECTORY 31 CodeWarrior HC12 116 TARGET_SIM_CMD 41 batch execute all 39 TEST_CASE_TIMEOUT 40 Board Name 30 Boot Hostname 31 VCAST_BUFFER_OUTPUT 36 Buffer I/O 36, 243 VCAST_DISABLE_TI_BITFIELD 38 C/C++ VCAST_DISABLE_TI_STRING 38 options 26 VCAST_DUMP_BUFFER 36 cannot open additional I/O files VCAST_ENVIRONMENT_FILES 29, 41 Renesas HEW - M16C/R8C 283 VCAST_EXECUTE_WITH_STDIO 35 CLICAST accessing in Unix 24 VCAST_EXECUTE_WITH_STDOUT 36 accessing in Windows 24 VCAST_FAR_STDIN_DATA 41 command format 24 VCAST_FILE_INDEX 36 command format, compound or init 25 VCAST_FILE_PREFIX 30 option VCAST_FORCE_NO_ Target_Board_Name 30 USERGLOBALS 37 options VCAST_GH_INT_FILE 42 ASSEMBLER_CMD 27 VCAST_GH_INTEX_CMD 41 COMREADER_BAUD 37 VCAST_IGNORE_PSC_RAM_ COMREADER_COMPORT 37 PAYLOAD_REBOOT_STATUS 34 COMREADER_DATA_BITS 37 VCAST_MAIN 40 VCAST_MAX_HEAP_SIZE 39 - 354 - Index: CMDIDE – CODEWARRIOR HC12 VCAST_MAX_STRING_LENGTH 31 VCAST_VXWORKS_NO_CSHELL 33 VCAST_MAX_TARGET_FILES 40 VCAST_VXWORKS_RTP_MODE 33 VCAST_MINIMAL_TERMINATION 38 template 26 VCAST_MONITOR 42 cmdIDE 14 Code Composer VCAST_NO_EXIT 39 C3x v4.1, configuring 52 VCAST_NO_FFLUSH 42 debugging with 60 VCAST_NO_FLOAT 38 default memory map 59 VCAST_NO_LIMITS 31 stand-alone, target execution 58 VCAST_NO_MALLOC 39 Studio 2, target execution 57 VCAST_NO_SETJMP 32 Studio 3.1, 3.3, target execution 55 Studio 4.0, target execution 53 VCAST_NO_SIGNAL 32 Studio 4.2, target execution 85, 94 VCAST_NO_STD_FILES 32 Studio 4.2.4, configuring for LM3S9B92 eval VCAST_NO_STDIN 35 board 83, 91 VCAST_NO_STDLIB 32 Studio 6x, configuring 52 Studio, configuring for 6713 target board 65, 69 VCAST_NO_TYPE_SUPPORT 38 Studio, configuring for DSP/BIOS 61 VCAST_OUTPUT_BUFFER_SIZE 36 Studio, configuring for OMAP 35x EVM target VCAST_POST_RUN_DELAY 40 board 75 VCAST_PRE_EXECUTE_CMD 40 CodeWarrior DSP56800E configuring 103 VCAST_PSC_RAM_PAYLOAD 34 target debug execution 106 VCAST_PSC_RAM_PAYLOAD_REBOOT_ CMD 34 target execution 105 CodeWarrior for MPC VCAST_PSC_USE_ADDRESS_SPACE 33 configuring 126 VCAST_RELINK_PROMPT_FOR_PSC_ target debug execution 128 RAM_PAYLOAD 34 target execution 127 VCAST_STDIO 35 CodeWarrior for MPC 8315 VCAST_TORNADO_CONSTRUCTOR_ configuring 129, 138 CALL_FILE 33 port settings 135, 140 VCAST_USE_COMPOUND_FOR_ target debug execution 136, 142 BATCH 39 target execution 134, 139 VCAST_USE_WINDSH_DOT_BAT 33 CodeWarrior for USB TAP VCAST_USE_WINDSH_IO_ installation 129 REDIRECTION 33 CodeWarrior HC12 VCAST_VXWORKS 32 configuring 113 - 355 - Index: CODEWARRIOR HCS08 – ENVIRONMENT VARIABLES configuring for banked memory model 116 data driven test harness 12 target debug execution 118 Diab with TRACE32 target execution 117 configuring 312 CodeWarrior HCS08 target debug execution 303, 313 configuring 119 target execution 313 target debug execution 124 Diab/SingleStep CodeWarrior StarCore SC140e configuring 309 configuring 108 target execution 309 target debug execution 109 dump buffer 36 target execution 109 environment creation 23 combining host- and target-based testing 23 environment does not execute communication details 13 Renesas HEW - SH 289 communication overview 12 environment files 29 Compiler lacks limits.h 31 environment variables Compiler lacks setjmp.h 32 $(ENV_VAR) in CCAST_.CFG file 28-29 Compiler lacks signal.h 31 A166INC 302 Compiler lacks stdlib.h 32 BIOS_INSTALL_DIR 66, 71, 77 concepts 11 C166INC 224, 302 Cosmic C166LIB 224 target debug execution 151 CCStudio Scripting libraries on PATH 56, 67, Cosmic 68HC12 73, 81 configuring 143 CodeWarrior binaries on PATH 103, 108, 113, 119 target execution 149 CodeWarrior for MPC 8315 on PATH 133, Cosmic HCS12X 138 configuring 145 CodeWarrior for MPC on PATH 126 target execution 149 Cosmic binaries on PATH 143, 146 Cosmic STM8 on STVD cscript on PATH 47 configuring 153 DEBUGSERVER_ROOT 84, 92 target debug execution 155 Diab binaries on PATH 312 target execution 155 EVP binaries on PATH 156 Cosmic STM8 on ZAP EVP_INSTALL_BASE 156 configuring 152 HighTec compiler on PATH 178 target debug execution 155 HLNK_LIBRARY 285 target execution 154 IAR binaries on PATH 183-184, 187 Create a Tornado constructor call source file 33 Keil binaries on PATH 224, 227 cscript 47 Keil for ARM on PATH 231, 235 - 356 - Index: EXECUTE COMMAND – FILES Lauterbach TRACE32 debugger on PATH 126 VCAST_MICROCHIP_INSTALL_DIR 246, MicroChip compiler on PATH 246, 249 249 MWCINCLUDES 126, 133, 138 VCAST_RENESAS_INSTALL_DIR 285 MWCLIBRARIES 126, 133, 138 VCAST_SERIAL_CFG 117, 128, 133, 135, 138, 140, 206, 244, 249, 264 MWCLIBRARYFILES 126, 133, 138 VCAST_T32 312 NEC binaries on PATH 254 VCAST_TASKING_INSTALL_BASE 296, 298, P_186_STARTUP_FILES 259 302 Paradigm binaries on PATH 259 VCAST_TRACE32 302 Perl utilities on PATH 56, 67, 73, 81 VisualDSP binaries on PATH 44 PERL5LIB 56, 66-67, 71, 73, 77, 81 WIND_DIAB 312 Renesas compiler on PATH 285 WIND_HOME 312 RVCT31INC 231, 235 WIND_PREFERRED_PACKAGES 312 RVCT31LIB 231, 235 WRS-specific 317 SC100_HOME 108 WRS binaries on PATH 317 SCTOOLS_HOME 108 WRSD_LICENSE_FILE 312 SHC_INC 285 execute command SHC_LIB 285 list of 14 SHC_TMP 285 Execute using stdin and stdout 35 T32ID 302 Execute using stdout only 35, 243 T32SYS 302 Execute with windsh.bat 32 T32TMP 302 execution hangs Tasking binaries on PATH 291, 293, 302 Renesas HEW - M16C/R8C 283 Tornado-specific 316 Renesas HEW - SH 289 Tornado binaries on PATH 316 execution methods 21, 337 TriMedia binaries on PATH 305 Explorer16 VCAST_CCS_INSTALL_DIR 66, 71, 77, 83, configuring MicroChip MPLAB for PIC24 91 on 249 VCAST_CUSTOM_QUALIFIERS 116 files VCAST_CW_INSTALL_DIR 133, 138 #included .c files 41 VCAST_EXECUTE_WITH_STDIO 348-349 .xfw_dbginit.cmd 297 VCAST_EXECUTE_WITH_STDOUT 351-352 .xfw_exeinit.cmd 297 VCAST_GH_INT_FILE 174 c167.cfg 297 VCAST_IAR_CONFIG_DIR 187, 192-193, debug.dscr 299 198-199, 204-205, 209, 214, 220 dspicsimldll 211, 216 VCAST_IAR_INSTALL_DIR 187, 192-193, 198, 204, 209, 214, 220 execute_rsh.bat 344 VCAST_KEIL_ARM_INSTALL_DIR 235 execute_scp.sh 344 - 357 - Index: FLAGS – IAR EMBEDDED WORKBENCH 4.X IAR device description file 210, 215 target execution 171 iar_lnkdspic_16kRAM.xcl 210, 215 Green Hills INTEGRITY rtserv limits.h 31 configuring 172 lm3s9b92_evb.ccxml 85, 94 target execution 174 loadti.bat 85-86, 94-95 Green Hills INTEGRITY Simulator main.js 87, 96 configuring 167 MPC5554.cmm 243 Green Hills Simulator MPC5554_debug.cmm 243 configuring 163 prepend /tgtsvr/ to names of 30 Green Hills targets setjmp.h 32 improving target execution speed 165, 168, signal.h 31 171, 176 stdlib.h 32 target execution 164 target cannot write to 36 grun 15 TESTDATA.DAT 30 harness architecture 11 Tornado constructor source call 33 Harness File Prefix 30 UUT_INST.mod 176 heap resources, limited 31 UUT_INTE.out 88, 100 Hightec TriCore-gcc vcast.int 173 configuring 178 vcast_debug.out 211, 217 target debug execution 182 VCAST_STDIN.DAT 35, 347 HyperTerminal 117, 128, 135, 140, 244, 261, 268 VCAST_STDOUT.DAT 35, 347 I/O devices VectorCAST_SinglePartition.zip 323 problems with 328 windsh.bat 32 I/O Directory 30 windsh.scr 318 I/O paths windsh.src 33 problems with 328 flags I/O performance 331 list of 18 I/O uses stdin/stdout 35, 332, 347 ftp I/O uses stdout only 35, 243, 350 setting up to execute tests remotely 338 IAR 1.4 for dsPIC Fujitsu Softune target debug execution 215, 217 configuring 159, 161 IAR Embedded Workbench 3.x target execution 160, 162 configuring 183 Green Hills Bare Board target debug execution 185, 195, 201, 212, 217, 222 configuring 163 target execution 184 Green Hills INTEGRITY mpserv IAR Embedded Workbench 4.x configuring 169 configuring 192 - 358 - Index: IAR EMBEDDED WORKBENCH 5.X – OPTIONS IAR Embedded Workbench 5.x Keil for ARM Cortex M3 configuring 198, 209, 214, 220 configuring 235 IAR Embedded Workbench 6.x ITM 236 MSP430X 5.1 Large Memory Model Instrumentation Trace Macrocell 236 configuring 187 ITM 236 target debug execution 189 itm.h, config.h 238 target execution 189 target debug execution 239 target execution 239 IAR Embedded Workbench v5.5 configuring 204 uVision project file 236 IAR Embedded Workbench v6.3 kernel partition 320 default serial port settings 206 Load executable as a Real_Time Process (RTP) 33 HyperTerminal 206 making your tests run faster 23 IAR installation and target customizations 205 Max string length 31 target debug execution 207 MicroChip MPLAB for dsPIC target execution 206 configuring 246 IAR Embedded Workbench v6.3. MicroChip MPLAB for PIC24 on Explorer16 configuring 204 configuring 249 insufficient heap mpserv 15 Renesas HEW - SH 288 NEC V850 IO link to target 13 configuring 254 IO mechanisms 13 target execution 257 execute command 13 NFS flags 18 setting up to execute tests remotely 338 JTAG server 178 No stdin, stdout, or stderr defined 32 Keil C166 NXP EVP C compiler for VD3204x configuring 224 configuring 156 target execution 229 options Keil C51 assembler command 27 configuring 227 board name 30 target execution 229 boot hostname 31 Keil for ARM Buffer I/O 36, 243 configuring 231 Build test harness into a vxWorks PSC target debug execution 233 partition 33 Keil for ARM Corex M3 C/C++ 26 environment files 238 CLICAST-only 41 integration notes 238 Compiler Integration tab 27 - 359 - Index: OUTPUT BUFFER SIZE – REMOTE SHELL EXECUTION Compiler lacks limits.h 31 target Compiler lacks setjmp.h 32 I/O uses stdin/stdout 332 Compiler lacks signal.h 31 Target 29 Compiler lacks stdlib.h 32 target simulator command 41 Create a Tornado constructor call source Testcase timeout 40 file 33 TFTP boot directory 40 dump buffer 36 Use 'vcast-main()' in place of 'main()' 39 environment files 29 use compound test for batch execution 39 Execute using stdio and stdout 35 Use RAM payload 34 Execute using stdout only 35, 243 use serial line I/O 42 Execute with windsh.bat 32 Use windsh I/O redirection 33 far stdin data 41 vcast environment files 41 file index 36 vxWorks 653 Build directory 34 File indexing mode 36 output buffer size 36-39 gh intex command 41 overview 11 gh intex filename 42 Paradigm Harness file prefix 30 configuring 259, 264 I/O directory 30 target debug execution 262, 268 I/O uses stdin/stdout 35, 347 partition I/O uses stdout only 35, 243, 350 application, running vxWorks in 320 Load executable as a Real-Time Process 33 kernel, running vxWorks in 320 Maximum string length 31 Post-run delay 40 Maximum target files 40 precompile command 28 no fflush 42 precompile extension 28 No stdin, stdout, or stderr defined 32 PRECOMPILE_CMD 28 Omit code to trap explicit calls to syslib 'exit() ' 39 PRECOMPILE_EXT 28 output buffer size 36-39 PXROS TriCore System Development Platform 178 Post-run delay 40 QNX Pre-test execution command 40 target debug execution 271 precompile command 28 QNX Momentics precompile extension 28 configuring 270 Running with vxWorks headers 32 QNX Neutrino SCORE debug command 41 configuring 270 SCORE execution command 41 remote shell execution startup file 28 configuring 342, 344 substitute code for .c file 41 - 360 - Index: REMOTE TEST EXECUTION – TARGET DEBUG EXECUTION of target 345 scp of target, debug 345 setting up to execute tests remotely 339 remote test execution sim850 15 requirements for 337 simarm 15 setting up anonymous ftp for 338-339 simmips 15 setting up NFS for 338 ssh setting up rsh for 339 setting up to execute tests remotely 340 setting up ssh for 340 stack resources, limited 31 Renesas HEW - M16C/R8 Standard I/O cannot open additional I/O files 283 configuring 347 execution hangs 283 target execution 349 Renesas HEW - M16C/R8C Standard out configuring 273 target execution 352 target execution 282 startup file 28 troubleshooting 283 STARTUP_FILE 28 Renesas HEW - SH target environment does not execute 289 problems connecting to 327 execution hangs 289 target debug execution insufficient heap 288 ARM 50 target execution 288 CodeWarrior DSP56800E 106 troubleshooting 288 CodeWarrior for MPC 128 Renesas HEW - SuperH CodeWarrior for MPC 83 136, 142 configuring 285 CodeWarrior HC12 118 rsh CodeWarrior HCS08 124 setting up to execute tests remotely 339 CodeWarrior StarCore SC 140e” 109 under Windows 7 339 Cosmic 151 rtasim 15 Cosmic STM8 on STVD 155 rtserv 41 Cosmic STM8 on ZAP 155 runmc 17 Diab with TRACE32 303, 313 Running with vxWorks headers 32 Embedded Workbench 3.x 185, 195, 201, 212, runsim 14 217, 222 SBC Embedded Workbench v6.3 207 vxWorks 653 example 323 Green Hills Multi Debugger 164 SBC83XX PowerQUICC II Pro development Hightec TriCore-gcc 182 board 323 IAR 1.4 for dsPIC 215, 217 scarc 17 IAR Embedded Workbench 6.x 189 Keil for ARM 233 - 361 - Index: TARGET EXECUTION – TASKING C166 CLASSIC Keil for ARM Cortex M3 239 NEC V850 257 Paradigm 262, 268 remote shell 345 QNX 271 Renesas HEW - M16C/R8C 282 remote shell 345 Renesas HEW - SH 288 Tasking 563xx 294 SingleStep 309 Tasking 56K 292 Standard IO 349 Tasking C166 Classic 297 stdout 352 Tasking C166 VX 299 Tasking 563xx 293 Tasking Tricore 301 Tasking 56K 291 with TRACE32 debugger 244 Tasking C166 Classic 297 target execution Tasking C166 VX 299 a graphical debugger 346 Tasking Tricore 301 Code Composer 58 Tasking with TRACE32 302 Code Composer Studio 3.1, 3.3 55 TriMedia 307 Code Composer Studio 4.0 53 Visual DSP 46 Code Composer Studio 4.2 85, 94 vxWorks 318 Code Composer Studio2 57 vxWorks 653 319 CodeWarrior DSP56800E” 105 with the VectorCAST Monitor 353 CodeWarrior for MPC 127 target interaction after environment creation 23 CodeWarrior for MPC 8315 134, 139 target testing CodeWarrior HC12” 117 combining host and target based testing 23 CodeWarrior StarCore SC140e” 109 TARGET_BOARD_NAME 30 Cosmic 68HC12 149 TARGET_BOOT_HOSTNAME 31 Cosmic HCS12X 149 TARGET_IO_DIRECTORY 30 Cosmic STM8 on STVD 155 TARGET_TFTP_DIRECTORY 40-41 Cosmic STM8 on ZAP 154 Tasking 563xx Diab with TRACE32 313 configuring 293 Fujitsu Softune 160, 162 target debug execution 294 Green Hills INTEGRITY mpserv 171 target execution 293 Green Hills INTEGRITY rtserv 174 Tasking 56K Green Hills targets 164 configuring 291 IAR Embedded Workbench 3.x 184 target debug execution 292 IAR Embedded Workbench 6.x 189 target execution 291 improving speed of 165, 168, 171, 176, 347 Tasking C166 Classic Keil C166 229 configuring 296 Keil C51 229 target debug execution 297 - 362 - Index: TASKING C166 VX – VISUAL DSP target execution 297 VCAST_EXECUTE_WITH_STDIO 35, 348-349 Tasking C166 VX VCAST_EXECUTE_WITH_STDOUT 35, 351-352 configuring 298 VCAST_FILE 174 target debug execution 299 VCAST_FILE_INDEX 36 target execution 299 VCAST_FILE_PREFIX 30 Tasking Tricore VCAST_GH_INT_FILE 174 configuring 300 VCAST_MAIN 39 target debug execution 301 VCAST_MAX_STRING_LENGTH 31 target execution 301 VCAST_MAX_TARGET_FILES 40 Tasking with TRACE32 VCAST_NO_EXIT 39 configuring 302 VCAST_NO_LIMITS 31 target execution 302 VCAST_NO_SETJMP 32 templates 26 VCAST_NO_SIGNAL 31 test harness VCAST_NO_STD_FILES 32 architecture 13 VCAST_NO_STDIN 35 data driven 12 VCAST_NO_STDLIB 32 TEST_CASE_TIMEOUT 40 VCAST_OUTPUT_BUFFER_SIZE 36-39 tmsim 18 VCAST_POST_RUN_DELAY 40 Tornado constructor call file VCAST_PRE_EXECUTE_CMD 40 creating 33 VCAST_PSC_RAM_PAYLOAD 34 TRACE32 debugger 126 VCAST_PSC_USE_ADDRESS_SPACE 33 configuring 242 VCAST_STDIO 35 target debug execution 244 vcast_tgt.elf.mcp file 135, 140 TriMedia VCAST_TORNADO_CONSTRUCTOR_CALL_ configuring 305 FILE 33 target execution 307 VCAST_USE_COMPOUND_FOR_BATCH 39 troubleshooting VCAST_USE_WINDSH_DOT_BAT 32 Renesas HEW - M16C/R8C 283 VCAST_USE_WINDSH_IO_REDIRECTION 33 Renesas HEW - SH 288 VCAST_VXWORKS 32 trserv 16 VCAST_VXWORKS_RTP_MODE 33 USB TAP, CodeWarrior VectorCAST Monitor 353 installation 129 VectorCAST/RSP Use compound test for batch execution 39 configuring for Code Composer C3x v4.1 52 Use windsh I/O redirection 33 configuring for Standard I/O 347 VCAST_BUFFER_OUTPUT 36 VECTORCAST_DIR 24 VCAST_ENVIRONMENT_FILES 29 Visual DSP list targets and platforms 47 - 363 - Index: VISUALDSP – ZAP DEBUGGER target execution 46 VisualDSP configuring 44 vrun.bat 15 vxSim 315 vxWorks 653 example 320 vxWorks 30 configuring 318 overview 315 target execution 318 troubleshooting connection to the target 326 vxWorks 653 example using SBC 323 example using vxSim 320 target execution 319 Wind River ELF executable file for TRACE32 244 Windows 7 support for rsh 339 windsh 315 ZAP debugger 143 - 364 -