NI does not actively maintain this document.
This content provides support for older products and technology, so you may notice outdated links or obsolete information about operating systems or other relevant products.
You can obtain the GNU tool chain for VxWorks either by purchasing a VxWorks development license from Wind River or by downloading the redistributable GNU tool chain attached to this document. Purchasing VxWorks enables you to use the Wind River Workbench IDE, featuring source code-level debugging and build management. The redistributable GNU tool chain downloadable here offers debugging only at the assembly code level, and you must use the included GNU Make to build binaries.
Note: NI LabVIEW Real-Time 8.5, LabVIEW Real-Time 8.6, and LabVIEW 2009 Real-Time install version 6.3 of the VxWorks OS to compatible targets. LabVIEW Real-Time 8.20 installs version 6.1 of the VxWorks OS to compatible targets. All builds should be targeted to corresponding versions and use corresponding header files. As new versions of LabVIEW Real-Time become available, different versions of VxWorks may be installed and may require you to rebuild your libraries. Refer to the readme file for LabVIEW Real-Time to find the corresponding VxWorks OS version.
If you are using the redistributable GNU tool chain attached to this document, you can compile your projects using GNU Make. Use the following makefile as a template to construct the makefile for your project.
# These variables control the compiler and linker flags. Change them as
DEBUG_MODE = 0
OBJ_DIR := PPC603gnu_DEBUG
CFLAGS = -g -mlongcall
OBJ_DIR := PPC603gnu
CFLAGS = -Os -fstrength-reduce -fno-builtin -fno-strict-aliasing -mlongcall
LINKFLAGS = $(CFLAGS)
# List all the *compiled* object files here, under the OBJ_DIR
# directory. Make will automatically locate the source file and
# compile it.
OBJECTS := $(OBJ_DIR)/example.o
# This is the name of the output shared library.
PROJECT_TARGETS := $(OBJ_DIR)/example.out
# If you have other VxWorks .a files to reference, list them here.
# Everything after this line should not need to be modified for
# basic compilation. However, significant changes to the build structure
# will probably involve modifying these lines.
WIND_BASE := $(subst \,/,$(WIND_BASE))
CPU = PPC603
TOOL_FAMILY = gnu
TOOL = gnu
CC_ARCH_SPEC = -mcpu=603 -mstrict-align -mno-implicit-fp
IDE_INCLUDES = -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip
# This basic rule compiles a .c file into a .o file. It can be adapted to
# all other source files that GCC can compile, including assembly (.s) and
# C++ (.cpp, .cc, .C, .cxx) files. To enable support for those extensions,
# copy this rule and modify its extension and compile flags for the
# required source file type.
$(OBJ_DIR)/%.o : %.c
ccppc $(CFLAGS) $(CC_ARCH_SPEC) -ansi -Wall -MD -MP $(ADDED_CFLAGS) $(IDE_INCLUDES) $(ADDED_INCLUDES) -DCPU=$(CPU) -DTOOL_FAMILY=$(TOOL_FAMILY) -DTOOL=$(TOOL) -D_WRS_KERNEL $(DEFINES) -o "$@" -c "$<"
# Adapted rule for .cpp files
$(OBJ_DIR)/%.o : %.cpp
c++ppc $(CFLAGS) $(CC_ARCH_SPEC) -ansi -Wall -MD -MP $(ADDED_CFLAGS) $(IDE_INCLUDES) $(ADDED_INCLUDES) -DCPU=$(CPU) -DTOOL_FAMILY=$(TOOL_FAMILY) -DTOOL=$(TOOL) -D_WRS_KERNEL $(DEFINES) -o "$@" -c "$<"
all : check_objectdir $(PROJECT_TARGETS)
$(PROJECT_TARGETS) : $(OBJECTS)
rm -f "$@" ctdt.c;nmppc $(OBJECTS) | tclsh $(WIND_BASE)/host/resource/hutils/tcl/munch.tcl -c ppc > ctdt.c
ccppc $(LINKFLAGS) $(CC_ARCH_SPEC) -fdollars-in-identifiers -Wall $(ADDED_CFLAGS) $(IDE_INCLUDES) $(ADDED_INCLUDES) -DCPU=$(CPU) -DTOOL_FAMILY=$(TOOL_FAMILY) -DTOOL=$(TOOL) -D_WRS_KERNEL $(DEFINES) -o ctdt.o -c ctdt.c
ccppc -r -nostdlib -Wl,-X -T $(WIND_BASE)/target/h/tool/gnu/ldscripts/link.OUT -o "$@" $(OBJECTS) $(LIBPATH) $(LIBS) $(ADDED_LIBPATH) $(ADDED_LIBS) ctdt.o
rm -f ctdt.c ctdt.o
@if [ ! -d "$(OBJ_DIR)" ]; then\
mkdir -p $(OBJ_DIR);\
rm -f $(OBJECTS) $(PROJECT_TARGETS) $(wildcard $(OBJ_DIR)/*.unstripped)
.DUMMY: check_objectdir clean
Launch Wind River Workbench, the main VxWorks application IDE. The following splash screen appears the first time you launch Wind River Workbench.
Select Start to continue.
Select Workbench to display the Wind River Workbench window.
You must create a new Wind River Workbench project to build a VxWorks Kernel Library. Select File » New » VxWorks Downloadable Kernel Module Project to create a new project.
Enter a unique name for the project using the Project name text box. Click the Next button until you arrive at the Build Specs page. Click the Deselect All button and the select PPC603gnu. Click the Finish button.
In the IDE, select File » Import to open the Import dialog box. Select File system from the import source list and then click the Next button.
Browse to your tutorial source code directory and select the library.cpp and library.h files. These files are the included sample code for the example library. Click Finish to import the source code into your new project.
Select Project » Build Project from the Workbench window.
The build output will appear in the Build Console. A dialogue for generating includes may appear on the first build. Accept the recommended include paths.
Use an FTP program to upload your built library to the ni-rt/system directory on the target. Your library is now ready to use from within LabVIEW VIs.
LabVIEW VIs call shared libraries on a VxWorks controller using the Call Library Function node, the same way they call libraries on other Real-Time targets. However, because the LabVIEW development environment cannot read the library information in VxWorks shared libraries, the Call Library Function node must be configured blindly, without parsed symbol lists. (You can work around this limitation by configuring the node to use a Win32 build of the same library. The VxWorks library will be used on the target.) Note that the Calling Convention configuration parameter is ignored.
For more information on calling shared library code, consult LabVIEW Help>>Fundamentals » Calling Code Written in Text-Based Programming Languages » Concepts » Using External Code in LabVIEW, and NI Developer Zone: An Overview of Accessing DLLs or Shared Libraries from LabVIEW.
This section describes debugging techniques available with the GNU tool chain that do not require the Wind River Workbench IDE.
VxWorks development often requires using the serial console. The serial console provides standard input/output for running code and a command shell for executing commands.
To connect your computer to the serial console, follow these instructions.
For more information about using the console, consult the VxWorks Kernel Programmer’s Guide.
CPU exceptions include crashes and breakpoints. By default, CPU exceptions trigger a reboot of the controller. You must disable the exception handler in order to set breakpoints or to debug a task that has crashed. There are two ways to disable the exception handler.
Adding the following text to the ni-rt.ini file on the controller will disable exceptions until the text is removed:
If you use the following procedure, the exception handler will be re-enabled on the next reboot.
The console can print debug statements compiled into the library, and can set breakpoints at functional scope. Execution debugging can be performed at assembly code scope. No licensing is required to use this functionality.
Here is a brief summary of the commands you can use through the console to debug shared libraries. Please consult the VxWorks documentation for more details.
taskSpawn “<task name>”, 100, 8, 65536,
The techniques described in this section require the Wind River Workbench, which can be obtained from and is supported by Wind River. You must disable the CPU exception handler before debugging. Refer to the Disabling the CPU Exception Handler section of this document.
The target server is a process running on the host that sends debugging commands to the target. You can use the target server for source-level debugging and to download shared libraries. By default, the CompactRIO controller is not configured to receive and process debugging commands from the target server, but you can configure it to do so as follows:
For more information, refer to the Wind River Workbench User’s Guide.
Workbench can capture standard I/O from the console, set breakpoints at function and line scope, and trace running code at source code scope.
Debugging with Workbench requires the following:
Breakpoints can be set from the console or from the source code view. To set a source code breakpoint, right-click on the left bar of the view and select “Add Global Line Breakpoint.”
The target console will report when a breakpoint is hit. To debug at the breakpoint location, locate the stopped task in the Process tree of the target server connection, right-click it, and select Attach to Process.
The Debug menu is now populated with a full set of debugging commands.
For additional information, refer to the Wind River Workbench User’s Guide.
Collaborate with other users in our discussion forums
A valid service agreement may be required, and support options vary by country.