Q1: I get a "virtual memory exhausted" compiler error message once a while. What should I do?
A1: This error usually happens in Tornado 2.0, 2.0.2, and 2.1 for the Windows platform. Sometimes, one might get errors like, "stack overflow" general exception, or "commit_and_inc: VirtualAlloc failed". Please contact technical support to get the pepatch from SPR 65294 to increase stack size. If this does not work, get cygwin32.dll from SPR 70926 (or download the latest dll from:
Q2: When I bring up the Torando IDE, I get 'couldn't read file "TRY=localhost\host\recource\tcl\WindView.win32.tcl":no such file or directory'. Why I am getting this message?
A2: This happens if Tornado 2.0 is installed on Windows 2000 + SP1. Please download the patch for SPR 62517
Q3: Why am I getting "parse error before 'M_BLK_ID'" when attempting to create a bootable vxWorks image?
A3: This problem usually appears when one is using a third party BSP with Tornado 2.2 + CP1. The third party BSP needs to include "netBufLib.h" to have the M_BLK_ID definition. One should include "netBufLib.h" in sysLib.c.
Q4: Why I can not download the symbol file for Windows XP via FTP during system startup?
A4: This is related to SPR 73874, "Every alternate downloading fails with Windows XP." Please try one of the following: 1) Contact technical support for patch for SPR 73874 then rebuild the bootrom and vxWorks image to have it take effect. 2) After applying the SPR 73874 patch, if there are still problems, please try the workaround in SPR 93954.
Increase conection timeout value to 180 seconds:
If using the Project Facility, change Parameter TCP_CON_TIMEO_DFLT value from 150 to 300.
If using the BSP build method:
In config.h, after the inclusion of configAll.h:
#define TCP_CON_TIMEO_DFLT 300
3) Also, try to add/change the Windows XP registry for the TcpTimedWaitDelay value. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] "TcpTimedWaitDelay"=dword:00000005
Q5: Why can't I get the bootrom_uncmp to load from the floppy? It just hangs with "v1.6+++++++++++++++".
A5: This is because Tornado 2.2 for Pentium BSPs (pcPentium, pcPentium2, and etc) use the serial port for target shell output by default. Previous Tornado versions use the PC console by default. If one is using PC console (target monitor and keyboard), he/she won't be able to see the VxWorks banner on target monitor. One either needs to use a serial connection for target shell output, or change the following in config.h.
change the following line from:
#undef INCLUDE_PC_CONSOLE /* PC keyboard and VGA console */
#define INCLUDE_PC_CONSOLE /* PC keyboard and VGA console */
and make bootrom (bootrom_uncmp is too big for floppy).
Q6: In Tornado 2.2, stddef.h and stdarg.h are in different locations from Tornado 2.0 (2.1/2.0.1) and as a result, the user gets a build error complaining that these two files cannot be found. Where are the files located?
We moved the location of these header files to:
For GNU Compiler:
For Diab Compiler:
This was done to prevent the header files with the same name getting confused by different compilers because we now offer two compilers. According to the GNU user's guide for Tornado 2.2 chapter 2, users should take out the -nostdinc flag in Tornado 2.2 project build.
Q7: How can I setup target/host symbol table syncronization?
Please follow the steps.
1) Launch Tornado and launch the Project tool.
2) From within the Tornado toolset under "Tools->Options->Tornado Registry (tab)", select "Remote registry" and enter the host IP address (even if the registry is on the host running this Tornado session. This is a known bug). For Unix hosts, set the WIND_REGISTRY environment variable to the host IP address. If this is not set, it will point to the local host (127.0.0.1). To setup this up, you can use "setenv WIND_REGISTRY 18.104.22.168". "22.214.171.124" is the host IP address in this example.
3) From the Project window open your project and make sure that the following VxWorks components have been added to support symbol table synchronization:
NOTE: These components may or may not force the inclusion of other dependent components.
4) [OPTIONAL STEP] Also insure the following VxWorks components are added to aid and debug any symbol table problems (NOTE: These components are only used for debugging and are not mandatory):
NOTE: These components may or may not force the inclusion of other dependent components.
5) Build the project and verify that a vxWorks and vxWorks.sym resulted.
6) Reboot your target and modify the boot parameters (as needed) to load and run the vxWorks image built in step (5). Be sure to keep the vxWorks and vxWorks.sym files in the same directory (loaded from).
7) From Tornado, setup a target server for the recently booted target. At a minimum specify the following:
a) "Target Name/IP Address" (IP addresses tend to work better than names)
b) the complete path and file name for the vxWorks image for "Core File and Symbols"
c) "Synchronize Target and Host Symbol Tables" turned on (checked)
d) Add any other needed target server parameters
8) When the target server is launched the following output (or similar) from the target server window will show success:
tgtsvr (MV5100@svl-tzhaopc): Mon May 05 09:16:06 2003
Checking License ...OK
Connecting to target agent... succeeded.
Attaching C++ interface... succeeded.
Attaching elf OMF reader for PPC CPU family... succeeded.
symbol synchronization: Giving "126.96.36.199" as registry address to the target
Added target_modules to target-server.....done
NOTE: The key line is "Added target_modules to target-server.....done".
9) After step (8) is performed you will have a new task on your target called tSymSync which can be seen after executing "i" from the target shell. If the synchronization had failed the tSymSync task would not exist and probably one or both of the following error messages would have been produced from the target (only upon failure will these appear):
Fatal WTX error (0x10136), synchronization stopped
Fatal WTX error (0x1012f), synchronization stopped
NOTE: If one or both of the above error messages is produced then the correct system configuration did not take place. Recheck the (above) steps and then check the following: a) Make sure all IP addresses, routes (if needed), gateways (if needed) are correct. b) Make sure all of the correct VxWorks components are included in the project. Make sure that INCLUDE_SYM_TBL_SYNC and INCLUDE_NET_SYM_TBL are included at the least. (Do not INCLUDE_STANDALONE_SYM_TBL instead of INCLUDE_NET_SYM_TBL. INCLUDE_NET_SYM_TBL is required along with the other mandatory includes.) c) Make sure that the target server is configured correctly, has synchronization turned on, specifies the path to the correct vxWorks image for core file and symbols and the correct IP address of the target.
Q8: When user downloads their application to the target, they get error, "unsupported relocation type 18".
A8: VxWorks does not support position independent code. So, the user should take out the "-fpic" flag when building applcation.
Q9: User gets error "System clock has been set back too far" when he/she starts the wlmd (license manager used in Tornado 1.0.1).
A9: For error message: "System clock has been set back too far", please see if the file /usr/adm/wtmp exists on your system, and if so, delete it and try again.
Q10: I am getting "WTX Error 0x10034(LOADER_RELOCATION_OFFSET_TOO_LARGE)" error when I download my application to the target. How can I fix it?
A10: Adding the "-mlongcall" flag when building the application usually solves the problem.
Q11: After successful setup of host/target symbol table synchronization, why does the debugger still not find the source file/symbol?
A11: This is related to SPR 29321. The workaround for this problem is to use the gdb command "add-symbol-file xxxx" to load the symbol file before using the debugger.
Q12: How do I solve fix the UITCLSH error during install?
During an installation process, usually occurring during a reinstall or adding a patch, the setup program fails reporting an error with UITCLSH.EXE. This is because Microsoft made an update to a file, msvcrt.dll, and it no longer works with our software installation. Originally removing Visual Studio, installing Tornado, and re-installing Visual Studio was suggested as a workaround.
A more sophisticated workaround is as follows:
1. Copy Tornado 2.0 CD to your harddrive
2. Replace setuptcl.dll in x86/win32 with the attached copy
3. Run setup from the copy on your harddrive.
Note: This problem has been already fixed with Tornado AE. Tornado 2.2x should also contain this fix.
Q13: How do I solve fix the "Error: cannot allocate main win static colors" error during a Solaris install?
On a Solaris host, the message:
Error: cannot allocate main win static colors, another mwcolor or mainwin application might be running.
is caused is the font path is too long. Wind River has used MainWin 3.1 to port the SETUP application, the Tornado Project facility, and WindView to UNIX systems. MainWin is sensitive to the length of the font path. If the path is too long, any application running on MainWin fails. To reduce the font path, run the following command:
% xset fp default
Then remove your MainWin font cache by removing the installDir/.wind/mw/fonts directory. If this does not work, you can use your X serverís font manager to remove font directories that you do not use (such as Japanese, Hebrew, or Chinese, depending upon your location).
Q14: My Windows 2000 system (laptop/desktop) returns "000000000000" or "FFFFFFFFFFFF" for the Ethernet host, when physically disconnected from the network.
This is a known issue with Windows 2000. This problem is associated with its Media Sense for TCP/IP. To workaround, disable the Media Sense for TCP/IP on Windows 2000. See the following MS web pate for details:
This problem has been fixed in the FLEXlm v7.2d. For this fix to take affect, both the client application and the vendor daemon has to be upgraded to FLEXlm 7.2d+.
Another workaround is to re-generate the license bind to a disk serial ID, rather than the MAC address.
Q15: How to redirect the logMsg()?
You can redirect the output from logMsg() to the required file descriptor using the call logFdSet().
The following steps not only set the STD IN/OUT and STD ERR to the file descriptor vf0 but also redirect the logMsgs to the file descriptor vf0.
vf0 = open ("/vio/0",2,0)
Q16: Why can't you suspend, delete or change the priority of the excTask()
A16: excLib library provides generic initialization facilities for handling exceptions. It safely traps and reports exceptions caused by program errors in VxWorks tasks, and it reports occurrences of interrupts that are explicitly connected to other handlers. The priority of the excTask is 0 which is the highest priority and if you lower the priority then you will not get important information about an exception that might have occurred. When an exception occurs the task that is executing gets suspended. If you reduce the priority of the excTask from 0 then you will be unaware of the suspension of the task that generated the exception since you will not see an exception message on the console. This might create a chaos in your application later. So it is best not to suspend, delete or change the priority of the excTask.
What can you tell me about the following error while booting :
Error loading file: errno = 0x610001. Can't load boot file!!
A17: The error string for 0x610001 is S_loadElfLib_HDR_READ ("Erroneous Header Read"). It could mean that either your vxWorks image is not in the correct format or during the transfer your vxWorks image got corrupted (may be the symbolic link got corrupted). Depending on the architecture and the version of the software being used the object module formats can be different. So make sure that the appropriate OMF(object module format) is being used for the VxWorks image so that the bootLoadModule can complete execution without returning the error above.
Q18: I am receiving the following message from the stdout when booting our application on our custom hardware. "interrupt : timerWdHandler : kill failed (timer=0x86d283a0, tid=0x87ed2070, errno=0x16)"
A18: Timers are mechanisms by which tasks signal themselves after a designated time interval. Since the signal handlers are running in the task's context, the task that created and connected the timer should be alive. When a timer expires and the task that creates the timer is no longer present, the error message: "interrupt : timerWdHandler : kill failed (timer=0x86d283a0, tid=0x87ed2070, errno=0x16)" is emitted. This message is informational and is not harmful. We do have SPR #7458 filed for this misleading and confusing error. You may use the "i" command to check whether the task with tid=0x87ed2070 is still running or not.
Q19: Attempting to download the kernel via the network resulted in: Error loding symbol table...Error code = 0xe0001 What does this mean?
The errorno 0xe0001 corresponds to the error string S_loadLib_ROUTINE_NOT_INSTALLED.
If you want to use the target based shell or the target based symbol table make sure that the following macros are included in the image by defining them in config.h or appropriately including the components in the project workspace. Rebuilding the image should take care of the error.
#define INCLUDE_LOADER /* object module loading */
#define INCLUDE_NET_SYM_TBL /* load symbol table from network */
#define INCLUDE_SHELL /* interactive c-expression interpreter */
#define INCLUDE_SYM_TBL /* symbol table package */
Q20: What do I do is I get the error : "Relocation value does not fit in 24 bits".
The limitation is due to how direct function calls are implemented for the EABI(Embedded Application Binary Interface).
The EABI is a standard we follow for the PowerPC architecture and it may be downloaded from the IBM web page. The EABI suggests that all direct function calls be made with the 'bl' instruction. Because the addressing range of the 'bl' instruction is +/-32MB, all direct function calls referencing functions defined more than 32MB away will fail with the
above relocation error.
For GNU Compiler: Using the compiler option "-mlongcall" is the safest way which usually resolves this problem.
For Diab Compiler: The equivalent of -mlongcall would be -Xcode-absolute-far if you are using the Diab compiler.
Make sure you rebuild the application after the compiler options are selected.
Warning: Failed opening '/www2/httpd/htdocs/windsurf/templates/footer.php' for inclusion (include_path='.:/php/includes:/www2/windsurf/treemenu/phplm') in Unknown on line 0