Unofficial VxWorks & Tornado FAQ

Some examples:

• Flight simulators
• Radio and optical telescopes
• Automative ABS & realtime suspension
• Naviation systems
• Deep sea instrumentation
• PBXs
• Traffic control systems
• Modems
• Sonar systems
• Comm/weather satellite test equipment
• X terminals
• PostScript laser printers
• Video Editing, Audio Visual systems
• robotics
• NFS protocol accelerator product
• mass storage tape robot systems
• Internet appliances
• Printers
• Digital cameras
• Hand-held computing devices
• Routers, switches, and other network devices

VxWorks errno is composed of upper 16 bits indicating the library the error originates from, followed by 16 bits indicating specific error within that library.

The definition of upper 16 bit library categories is located in header file target/h/vwModNum.h. Once you find this module number, in our example 0xd0003 the upper 16 bit would be 0xd (decimal 13) which corresponds to M_iosLib, you can then look up the specific error number in the library's own header -- in our example, we look up target/h/iosLib.h to find out what error 3 in iosLib means.

Alternatively, if you have INCLUDE_STAT_SYM_TBL configured for your running target image you can look up the error by using printErrno() routine from the shell.

• When bootrom is counting down to boot VxWorks, waiting for keyboard interrupt, if you are in a hurry you can hit @ character to boot immediately. Of course, you can alter the timeout value or remove this time out waiting all together in your own version of bootrom.
• While modifying boot parameters via c command, if you make an error, you can use control-U to retype the whole line. If you made an error in previous entries, rather than starting the whole c session, you can use - key to go back one entry.

• If you know vi editor, you can use editing keys to command line edit. Make sure you hit escape charater to get into the vi editing mode. You can use vi commands to navigate the history of your command session. For example, use k to go up and retrieve previously entered command.
• Perhaps one of the most useful command in target shell is: lkup. This command will list out all symbos that contains the string passed. For example, to find all symbols that contain tcp, do lkup "tcp" from the shell. This only works if you have symbol table loaded.
• The Lost Art of Assembly Level Debugger in target shell: if you are new to VxWorks, you are perhaps unaware that VxWorks target shell contains a very useful and fully functional assembly level interactive debugger. To find out more use dbgHelp from the shell. You can set breakpoints in one or more tasks, single step, disassemble code, etc. Sometimes this works better than remote GDB based tools.

You can use ioGlobalStdSet() to redirect stdin, stdout, stderr console I/O devices. A frequent use of this is when using windsh under Tornado. You can use ioGlobalStdSet() along with virtual console I/O channel opened via open("/vio/0",2,0).

VxWorks does not have concept of "system call". Unlike Operating Systems such as pSOS, VRTX, Unix and many others, VxWorks calls are C function subroutines just like any other function call you may implement yourself. There is really no distinction between a "system call" and a generic C subroutine call.

In general, within an interrupt service routine, you cannot call any routines that can potentially block waiting for resources. Nor would you really want to (think about it). The printf() routine can block on a semaphore trying to get access to output device until it becomes available. A workaround is to call logMsg(). The logMsg() routine works by queueing your message content via message queue. It is sent to logTask, which prints it out at a task level when logTask gets to run as deemed proper by the scheduler.

To indicate that your task is using floating point registers which should be saved and restored per context switch, you should not forget to set VX_FP_TASK option in your task. Your ISR (Interrupt Service Routines) should call fppSave() and fppRestore() if it uses floating point registers. Depending on your compiler, it might be necessary to encapsulate your ISR in another dummy routine. For example, certain version of m68040 GNU compilers generate references to floating point registers even before your C code is generated. To avoid problems with these cases, you can create a C function that calls fppSave() and then calls your real ISR routine, and then calls fppRestore(), as a workaround.

The watchdog timer (wdLib) is a generic timer and not necessarily closely related to hardware watchdog facility available in many systems. It can certainly be used in association with a hardware watchdog resetting mechanism, but the name is a little bit of a misnomer.

A common error in using watchdog timer has to do with calling routines that can block. Since watchdog timer routine itself runs at interrupt level, you should not call any routines that can block. A frequent mistak is to call printf() inside a watchdog timer handler routine. You can use logMsg() instead.

VxWorks implementation of RT-11 filesystem is a simple filesystem that is similar to original filesystem of RT-11 RTOS for PDP-11 computers. It is no longer supported by WRS. However this filesystem is very simple and can be useful for realtime data logging into contiguous file space. It does not support hierarchical directories or long filenames (6 char + 3 suffix).

The VxWorks/Tornado includes support for DOS filesystem, RT-11, netDrv filesystem (emulated filesystem lookalikes over FTP and RSH protocols), nfsDrv filesystem (NFS client filesystem).

There are third party products that provide more Unix like filesystems. Ask WRS.

In truth, VxWorks does not really have a general filesystem layer. Each filesystem driver is implemented as I/O driver. The ioLib API which allows descriptor based open, close, read, write, ioctl, etc. is used to provide functionalities that are similar to the ones provided by filesystems in Unix.

However, not all filesystem drivers implement things uniformly. Some implement more (DOSFS) while others do less (netDrv). There is lsOld() which provides directory listing services for filesytems such as netDrv.

A public domain port of ppp-2.1.2 to VxWorks was available via anonymous ftp from ftp.netcom.com as /pub/da/dab/ppp-2.1.2.tar.gz, but this site seems to be down.

The KEEPALIVE was introduced into original BSD UNIX TCP/IP implementation. Since VxWorks uses a port of BSD UNIX TCP/IP, users can find the implementation details by reading BSD UNIX original software source code. The VxWorks versin of software works the same way as BSD.

There were at least two different ways of handing KEEPALIVE. Because KEEPALIVE was not part of original TCP/IP RFC specification, and only added by BSD implementors as convenience, it has gone through different changes. The 4.2 BSD TCP/IP implementation sent out a packet with sequence number set to snd_una - 1. That is "send unacknowledged sequence number minus 1". It then set the ack number to rcv_next - 1. This forced a response from a remote TCP implementation either in the form of a ACK or RST packet, depending on the connection's status.

The 4.3 BSD changed this to be a little more robust. It sent a packet with the sequence number set to snd_una - 1 and ack set to rcv_next. The same behavior is usually triggered on the remote end.

The intent behind KEEPALIVE is to consistently get either ACK or RST, depending on whether connection is still alive. RST (reset packet) will indicate that the remote peer is no longer there, indicating that connection probably should be shutdown on local side. This provides a way to terminate the TCP connection.

Unfortunately, the KEEPALIVE method will start after connection has been idle for about 75 seconds and KEEPALIVE probe will continue for about 2 hours. The dection of bad connection can therefore take a long time, perhaps inappropriate for realtime systems. However, this feature is in adherence to the spirit of TCP in that you should not randomly decide to drop connections unless you are really absolutely sure. In the old days of Internet (sometimes even nowadays) the noisy and congested traffic links caused inter packet delays that were very slow. TCP is designed to cover cases that cause 10 minute delays between each keystroke in a telnet session to remote regions of the world, for example.

Adjusting KEEPALIVE packet intervals is only possible using global variables in most BSD based implementations. You can tune the following variables: tcp_keepidle, tcp_keepintvl, tcp_maxidle. Please take a look at the source code for TCP/IP stack before making any global adjustments.

The netDrv is a very useful facility but it can also confuse some users. One can think of netDrv as an imcomplete filesystem emulation facility that sits on top of FTP or RSH protocol. The netDrv provides a pseudo file I/O interface to the users but it does so by first copying the entire file content to local buffer (RAM). If you are interfacing to a large file, using netDrv can eat up a lot of your memory. The protocol selection is done by password. If you provide password to your bootline, default VxWorks bootrom will create a netDrv device for the booting directory on the host via FTP. If no password is provided, it is assumed that you are using RSH protocol.

Because of the pseudo nature of netDrv, not all of the filesystem I/O semantics that are present in other filesystems are implemented transparently. For example, you may find that ls() often may not work over netDrv. However, you can also write a simple C function that sends a "ls" command to the host. For example, you can use rcmd() to send "ls" to the host side, if you are using RSH.

VxWorks NFS cache can be completely disabled by setting global variable nfsCacheSize to 0. To just flush the write cache as needed, nfsCacheFlush() can be used. You can also try using ioctl() with FIOSYNC.

This is usually due to the built-in 'feature' inside UNIX inetd program. The inetd tries to protect itself against clients that tries to connect too often too quick as a security measure, and disallows more than a certain number of connections per given period. When this happens, you will usually see some error messages about "looping..." in syslog (if your syslog is configured correctly) on your UNIX server (where inetd is running). You can either try "kill -HUP inetd_process_id" to get out of this looping mode by sending HUP signal to inetd, or try and install the patched version of inetd that has larger default limit for looping detection (some OS vendors will supply this to you), or just get a copy of BSD UNIX distribution of inetd source code and compile it with larger default values for looping and use it instead. Or you can consult the manual pages for your inetd program since it may already provide options to turn off the looping detection.

Using setsockopt() call, you can change the socket level buffer sizes of TCP sockets. This can affect the sizes of buffer windoes TCP protocol uses which can have different performance impact. The options are SO_SNDBUF and SO_RCVBUF.

You can also tune global variables: tcp_sendspace, tcp_recvspace, udp_sendspace, and udp_recvspace. Read original BSD TCP/IP code before attempting to change these globals.

To get around some latency related problems, you may turn on TCP_NODELAY option on TCP sockets which disables Nagle's algorithm.

Additionally there are various mbuf pool parameters in various configurable source files in your BSP.

Use setsockopt() with SO_REUSEADDR on your socket. If bind() still fails with EADDRINUSE, it is probable that you indeed do have another socket using that port you are trying to bind. You can use inetstatShow() to list out all the used sockets on your system to track it down.

VxWorks target shell is non-reentrant and only single instance is allowed to run at a time. The telnet daemon in VxWorks only allows single login session at a time. This is due to the way single console descriptor is shared globally, among other things.

An alternative is to use winsh from Tornado which will allow multiple target shell-like sessions. However winsh does not have all the facilities one might expect and it is not entirely compatible with original target shell. Some of the commands available in target shell are not available in winsh and vice versa.

A default route is a route table entry with destination field set to 0. To do the equivalent of "route add default gateway metric" in VxWorks, do: routeAdd("0",addr_of_gateway);

There is a global variable called ftpdWindowSize that can be tweaked.

Eventually KEEPALIVE will detect dead clients and tasks will be cleaned up. However, this takes a while (about 2 hours). See KEEPALIVE related FAQ entries above.

Look on the WindRiver site, there this information can be found. Or contact WindRiver directly.

	
	/**************************/
	/* for 68030 (e.g. mv147) */
	/**************************/
	
	/* 2 large areas, R/W, cache disabled */
	#define TT0_VALUE   0x403f8507  /* from $40000000 -> $77ffffff */
	#define TT1_VALUE   0x03018507  /* from $02000000 -> $03ffffff */
	
	test_tt ()
	{
	    register int *pVal;
	    int ttVal;
	    
	    pVal = &ttVal;
	    
	    ttVal = TT0_VALUE;
	    asm ("pmove %0,tt0" : : "g" (*pVal));
	    ttVal = TT1_VALUE;
	    asm ("pmove %0,tt1" : : "g" (*pVal));
	}
	
	/**************************/
	/* for 68040 (e.g. mv167) */
	/**************************/
	
	/* 2 large areas, R/W, cache disabled */
	#define TT0_VALUE   0x403f8507  /* from $40000000 -> $77ffffff */
	#define TT1_VALUE   0x03018507  /* from $02000000 -> $03ffffff */
	
	test_dtt ()
	{
	    asm ("movec %0,dtt0" : : "r" (DTT0_VALUE));
	    asm ("movec %0,dtt1" : : "r" (DTT1_VALUE));
	}
	

In the VMEbus, there are 4 levels of arbitration (0-3) where level 3 is the highest priority. By default, virtually all manufacturers ship their boards configured for BG3. Sometimes it is necessary to make adjustments. Within the 4 BG levels, there are two modes of operation: 1) priority and 2) round robin. Priority mode means that requests at level 3 will be honored before requests at level 2. Level 2 before level 1 and so on. This means that with priority mode arbitration, put your highest priority boards at level 3 and distribute the other boards at the other levels according to their relative priorities.

The round robin arbitration mode means that all 4 BG levels are treated equally and each level gets a fair slice of the pie so to speak. Use this mode when you have lots of boards, but no one has an inherently higher priority than any other. Remember, just because the boards are at different BG levels doesn't circumvent the implied priorities of the CPUs at the same level based on the bus daisy chain.

Typically, these modes are configurable on the system controller either through a jumper, PAL or software bit twiddling. However, there are boards that are hardwired for arbitration level 3 and they can't be changed. This means that you'll have to use these boards sparingly in VxWorks VME chassis (i.e., probably no more than 3-4 booting up from the backplane but probably more if you boot each of them up from local Ethernet).

Although not quite VxWorks specific, generic GNU toolchain binaries for various CPU architectures are available and can be useful alternative to Tornado host tools.

The winsh commands are implemented in TCL. The target shell running in the target has access to all subroutines that are in the symbol table. Winsh can run TCL commands that are currently implemented. This means that sometimes you will not be able to run some of the commands you are used to running in winsh. This only applies if you are an old VxWorks user who is used to doing things in target shell. Winsh does provide a '@' prefix which tells it to send a whole string to target and run in as a target side command, which can be useful for most things.