Bus master with MXI-2 stops Windows XP clock

Question

We are experiencing an issue with our MXI-2 modules in our VXI test systems. We recently implemented a module that has bus master capabilities. Up until now, all of our modules have been slaves. We have noticed that when our module requests the bus, we get a bus grant from the MXI-2 slot 0 controller and we can perform our register reads and writes to our other slave modules, we release the bus and everything looks good. However, we have noticed that our PC system real-time clock is losing time when we do this. It appears as long as we request the bus, the OS stops servicing real-time clock interrupts. In fact, if we request the bus for more than about 5 seconds, our PCs will reboot which is really strange. We are running Windows XP for an operating system. Has anyone else run in to this issue before? Any help/advice you could lend us would be appreciated.

Answer 1

I am going to jump in here.
>Thanks for clarify, do your programmers
have the “Date and Time Properties” window open to do this? When the
clock is no longer updating, is the rest of windows >responsive? Can you
have other programs running in the background?
Yes we can have the "Date and Time Properties" window open but it
really does not matter, the entire windows box is frozen, nothing works,
not even the mouse.  Later on, the windows box will come back to life
as if nothing has happened -- except the clock will be wrong, compared
to the clock on the wall.
>To get some more information about your system: What all
hardware are you using? Specifically, what is this module with bus
master capabilities?
Various off the shelf PC's (Mostly Dell's)  Windows XP, automatic updates.  The VXI module with the bus master capabilities is an
in house design.
>What
version of NI >VXI and NI VISA are you using?
  We think we have the very latest drivers, but that does not really
matter as we have seen this problem occur no matter what the driver
versions.  The latest drivers we have installed on the test machine are VXI 360 and (NIVXI360.EXE) and Visa 4.6
(visa460full.exe).
Problem occures on _ALL_ driver versions, both the MXI-2 and also the new MXI (PCI-Express version)
>And just so there is no confusion in the lingo,
specifically what “bus
master capabilities” does this device have?
Please explain.
 >Also, can you
>elaborate on
what you mean by “bus grant”.
 VXI bus grant signal.  (given after the module requests the VXI bus)
>Additionally
please describe how you have you VXI system Architected. A host computer
running XP, MXI-2 connection to a VXI chassis with assorted modules is
>pretty basic, please elaborate how your system differs, a picture may be
helpful. Did you change the “hardware configuration” in MAX on your
controller?
No nothing has been changed.  Everything should be at default values -- do we need to change them ?
>Also, please elaborate on your
Application environment and what function calls you are using to
accomplish this. Posting your code would be beneficial here as well.  Code is pretty simple, will post again if necessary.
Ok, I am going to speculate here, but perhaps the NI VXI drivers have interrupts disabled or the MXI hardware is causing an interrupt storm ? -- not sure how else to freeze the processor on the PC side of the MXI interface.
The problem (maybe?) can be boiled down to the following:
  1) A board in the VXI chassis starts to do bus mastering
  2) Software running on the PC with the MXI interface deceides to call a "viIn" function in the NI visa library (and the VXI bus is busy)
  3) The PC becomes "frozen" until the bus mastering is over (sometimes it spontaneously re-boots)
  4) The PC comes back to life, but was "frozen in time" so the clock is wrong compared with the wall clock, sometimes up to 
       10 minutes out of 20 and also lost the ability to do other useful work while it was frozen.
Thanks