VXIcpu-030 SYSFAIL & FAIL durning boot-up

[asippio]

Problem Description:
VXIcpu-030 (slot 0) SYSFAIL and FAIL LED's illuminate approximately 2 seconds after power is applied to VXIcpu-030 module. No other LED's are on.

Pressing the VXIcpu-030 reset button clears the SYSFAIL and FAIL. VXIcpu-030 continues
normal boot-up after the reset button clears the faults.

VXIcpu-030 produced the same results when tested in spare system.

VXIcpu-030 failed during normal operation and configuration is unchanged.

Do you have any suggestions to correct the fault?
Do you manufacture an upgraded fully compatible VXIcpu-030 module?

Thank you,

[David S]

Dear Anthony,

From your description, it sounds as if your VXIcpu-030 is damaged and needs to be repaired. Unfortunately, because this controller is so old, support for repairs is limited. I suggest you upgrade to a VXIpc-770. The VXIpc-770 is a single slot embedded VXIbus controller that supports Windows, VXWorks, and Linux.

Porting NI-VXI applications from the VXIcpu-030 with VxWorks to the VXIpc series with VxWorks should be very straightforward. For many applications that rely on the NI-VXI API, the code won't need to change at all. Those using special
features of the '030 may require more changes.

1. Endianness (byte order). The VXIcpu-030 was big-endian (Motorola), the VXIpc series is little-endian (Intel). This will affect users who make use of
pointers to data structures and do not account for possible endianness changes. The NI-VXI and NI-VISA libraries include many functions that automatically
convert between the two styles.

2. Memory mapping. The VXIcpu-030 directly mapped VXI address spaces into the controller's native 32-bit address space. This is no longer done, and the user needs to explicitly map regions of memory from VXI into their address space using the appropriate NI-VXI or NI-VISA API call.

3. Bus error and VXI interrupt handling. This is similar to #2: on the -030, bus errors from VXI accesses and VXI interrupts were passed back as native bus
errors and interrupts on the controller. However, Intel does not support this, and the user must use the NI-VXI or NI-VISA API to enable and handle these events.

4. The Wind River VME API. The '030 supported some of Wind River's VME API for VxWorks, functions like sysBusToLocalAdrs(), sysIntEnable(), sysIntDisable(), vxMemProbe(), etc. Now we support these functions only through the standard NI-VXI or NI-VISA API calls like MapVXIAddress(), EnableVXIint(), DisableVXIint(), VXIin(), etc.

Also worthy of note: consider the recent improvements in performance of non-real-time OS's before committing to VxWorks for a VXIpc system that is
replacing an '030. Ten years ago when the '030 was probably spec'd into most systems, it was reasonably fast and up-to-date, and running VxWorks on it was
the only answer for some applications. Come forward to 2003, and some of our Windows VXIpc offerings might be able to solve problems that required a
real-time OS ten years ago. Of course, Windows won't be real-time but the overall system performance may be better enough to compensate for this in some
types of applications where hard real-time performance was not strictly necessary.

The length of this list may sound scary, but really that's just about it for possible issues, and most of them won't apply for most users. In general,
porting an NI-VXI application from the '030 to the VXIpc with VxWorks can just be a recompile.

For more information on the VXIpc-770, please review the following webpage

http://sine.ni.com/apps/we/nioc.vp?cid=11279〈=US

Regards,

David Shatila
Applications engineer
National Instruments
www.ni.com/support