Bus master with MXI-2 stops Windows XP clock

[bd5]

Visual C code attached.

[mr_]

How does Device #3 request bus mastering privileges? It must be communicating with the host controller as well, but I do not see a reference to this communication.
 
In a VXI system with additional bus masters each bus master will ask for the bus from the bus arbiter (e.g., host PC's MXI-2). The bus arbiter grants the bus to the first bus master that requests it (e.g., Device #3). Why are you using the arbiter to access the bus while Device #3 is performing its operations?

[bd5]

How does Device #3 request bus mastering privileges?

http://www.interfacebus.com/Design_Connector_VME.html  (also see the first post in this thread)

Why are you using the arbiter to access the bus while Device #3 is performing its operations? 

The host PC does not exactly know if (or when) device #3 is actually performing bus mastering operations.  This is one

of the things is would like to find out when it (Host PC) actually does communicate with it (in our real app, not just the simple example of reading the VXI ID register).

Furthermore, it does not matter if we try to read the VXI ID from device #3, we can attempt to read the id of any other device

with the same failure mode -- (host PC locks up and becomes frozen in time, then recovers with incorrect time vs. wall clock).

[LittleGiant]

Hello All,

This is ultimately what is causing the Windows XP clock to stop.  We added bus master capabilities to one of our custom modules.  It is requesting the bus from our MXI Slot 0 controller to do simple A16/D16 and A16/D32 register based transfers from other modules in our system.  According to the VXI spec, we can hold the bus indefinitely once we have been granted the bus by the bus arbitrator (our MXI slot 0 controller).  We sometimes take control of the bus for several millesoconds at a time.  The clock is stopping when our host PC issues a viIn16, viIn32, viOut16, or viOut32 VISA command to any module other than the MXI module while the MXI Slot 0 controller does not have control of the bus.  How can a host PC know that the MXI has relinquished control of the bus so it does not issue a viIn or viOut command to another module and thus stop the date and time clock of the OS?  It seems odd that this would stop the clock in the first place.

[Mr.F]

Hi Little Giant,

That’s a little bit more clear. I believe there is way to check if another device is bus mastering or take back control before attempting to perform additional writes/reads. I’m going to do a bit more research  and post back.

[mr_]

How did you design the custom module to relinquish the bus (e.g., Release When Done or Release On Request)? If you are using the RWD method, it should be releasing the bus when it completes a transfer. Therefore, it re-arbitrates for the bus before every subsequent transfer.

My guess is that you are following a ROR process. Here the bus master retains the bus by continuing to assert BBSY* between transfers. I'm curious to know if this is staying asserted if you are using ROR. Have you confirmed this?

How have you configured your device? 

[mr_]

Hi folks, are we still working on this issue?

This problem is happening because the CPU is issuing PCI commands that don't complete.  They don't complete because the MITE is issuing retries on the PCI interface until it can acquire the VXI bus and complete the transaction.  The CPU is stuck waiting for the transaction to complete before it can continue.  I don't know if having multiple CPUs or multiple cores would work around it.

The behavior was reproduced with a PCI device, which was configured to respond to PCI cycles with retries.  When in that mode the computer freezes as soon as a a PCI read is issued and directed at the device, or several writes (enough to fill the buffers of the bridges betweenthe  device and host).  It stays frozen until the cycle completes, and if it was over five seconds then it reboots.  It's a behavior that's related to PCI and the interface with the CPU.  You're seeing it because you're issuing PCI commands that can't complete until the VXI bus is free, and you're simultaneously holding the VXI bus.

Your idea of checking for a free VXI bus before issuing the commands would reduce the frequency of the failure, but it won't eliminate it unless you can also reserve/lock the VXI bus at the same time.  Otherwise you'll occasionally hit the case where you check, then your device grabs the bus, then you attempt your transactions.  There are a few things that might work, but they're not really tested, they have performance implications, and/or they're cumbersome.

1.  Don't hold the VXI bus for so long.  If you can split the transactions and re-arbitrate for the bus more often you'll avoid the issue.

2.  Put MXI in interlock mode (MXI-2 only, not required for embedded controller or MXI Express).  Then lock the bus, which will also lock the VXI bus; do accesses; then unlock the bus.  This has system performance implications since it's locking the bus, but it's probably more compatible with the driver/API than #3.  Locking the bus also reserves the bus, so when this succeeds you have unfettered VXI access.

3.  We think it's possible (using register-level programming) to issue a VXI transaction, then poll until it completes.  This is much more low-level, and there will be difficulties or limitations, but it may work for you.

[bd5]

This is interesting, all we are doing is calling the "ViIn" function in the NI visa library.  So the "ViIn" function is "issuing PCI commands that can't complete" ?  It would be really nice if there was an alternative to the "ViIn" function that did not do that.

Do you have instructions and/or example code on how to test out the alternatives #2 and #3 (#1 is not really an option) ?

[mr_]

Unfortunately, I do not have specific example code. Also, option #3 is quite complex and whether or not it will work is unclear. I'll try to explain option #2 so that you can test it accordingly.

If you refer to the user manual of the VXI-MXI-2, there is an Interlocked Mode section. This section describes this mode, as well as refers you to Chapter 5 for the particular register you'll need to write to. For instance, VCMR and bit number 0 (INTLCK).

Interlocked Mode

VXI-MXI-2 Control Register (VCMR) 

You should be able to write to this register space fairly easily.  You'll also want to implement your code to surround your ViIn and ViOut calls by locking and unlocking bus. Bear in mind that the code for locking the bus would also poll untils it owns the bus.

You can use the VXSR register to get status information as described in the following section.

VXI-MXI-2 Status Register (VMSR)

For example, you can verify that you are set up in interlock mode by launching VIC, select Bus Access, and set up these parameters:

Device Name VXI-MXI-2 » Operation Inreg » Register User Offset » Offset h20

Press the run button. The output should display a hex value. Bit number ten should be set to 1. 

In order to be successful, you likely need to test out the behavior and add additional checks. Chapter 5 has all the register descriptions for the VXI-MXI-2.

I hope this helps!

Regards,