Bus master with MXI-2 stops Windows XP clock

[LittleGiant]

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.

[Mr.F]

Hi Little Giant,

Windows XP is not a real time operating system; can you clarify what you mean by “real-time clock”? Are you refereeing to the system clock on your XP machine?

[LittleGiant]

I was referring to the display clock in the lower right hand corner of the Windows toolbar.  Our programmers here use it to log how long certain tasks take.

[Mr.F]

Hi Little Giant,

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?

To get some more information about your system: What all hardware are you using? Specifically, what is this module with bus master capabilities? What version of NI VXI and NI VISA are you using? And just so there is no confusion in the lingo, specifically what “bus master capabilities” does this device have? Also, can you elaborate on what you mean by “bus grant”.

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?

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.

[bd5]

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

[Mr.F]

Hi bd5,

Do you work with Little Gaint? Assuming so, I want to make sure I have it correct. You have multiple Computers running XP and when you grant bus master capabilities to your custom VXI card you computer will lock up for the duration of the grant. Currently you are using MXI 2 , VXI 3.6 and VISA 4.6 but have also seen the exact same thing with other version of VXI and VISA and with MXI express connection. Correct?

Your response of “No nothing has been changed.  Everything should be at default values” doesn’t make for the question I asked on your system’s architecture. Allow me to be clearer. Please describe you setup, Host PC, MXI -2 to VIX chassis, custom VXI card in a slot. What else. Please attach a picture if words are not a good description.

What application development environment ADE, ie LabVIEW, C, C++ etc. are you using? I’m glad to hear that the code needed to reproduce this is simple, please post it.

[bd5]

Host PC Windows XP box, MXI interface, Four custom built VXI modules

Here is some code:

for (i=0;i<10;i++)
{
  iStatus = viIn16( viMySession, VI_A16_SPACE, 2, &temp );
  assert( iStatus == 0 );
  printf( "0x%04x\n", temp );
}

Result:  PC will freeze in the viIn16 function if module happens to be bus mastering at the time.

Expected Result:  Wait for the bus (possibly forever), then do the I/O - or just return an error.

[Mr.F]

Hi bd5,

Is this on a single core or multicore machine? Does the printf statement update the temperature value to the screen or is the computer frozen at this point? Do the register reads proceed without interference? This snippet of code is not exactly what I wanted. Please post you code that exhibits this behavior, a .C file would be best. Are there four of the bus master cards in your VXI system? Please describe your system architecture better, post a picture if words are inadequate.

[mr_]

It would also be useful to know what exactly you are bus mastering to (e.g., system memory on the system containing the MXI or a different device on the VXI bus)?  How long are you bus mastering for and what type of transfers is your device doing (e.g., block transfers or single point ... D8, D16, D32, or D64)?

[bd5]

Most of the computers here have been core-2's lately, but I am pretty sure we have seen same or similar problems

with older computers.

VXI chassis:

(0) MXI-2 or MXI-PCExpress

(3) Custom built:  processor board

(4) Custom built:  Data acquisition board

() Custom built:  2nd processor board  (Irrelevant to this problem, board can be removed)

() Agilent module (Irrelevant to this problem, board can be removed)

- Board #3 can bus master to read data from board #4.  If and when it does it will use "register" transfers.

- The Host PC will normally communicate with board #3, using the NI Visa NI VXI software (with "register" transfers).

- When the Host PC attempts to communicate with board #3 AND board #3 also happens to be bus-mastering gathering data from board #4 at the same time is when the PC becomes momentarily "frozen in time".  The bus mastering activity may be anywhere from a few hundred microseconds up to multiple seconds.  In either case the problem is observed.

I will attach some simple code which has the host PC in a loop reading the "ID register" from board #3.  This code

will become "frozen" in the ViIn16 function call (the NI visa library) if the board (board #3) is bus mastering at the

time.