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.
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:
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:
Q7: How can I setup target/host symbol table syncronization?
Please follow the steps.
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.
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:
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:
Q15: How to redirect the logMsg()?
You can redirect the output from logMsg() to the required file descriptor using the call logFdSet().
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 :
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.
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.