VME access limitation

[poque]

Hello,

I am using a system with the following configuration :
* VME card VME-MXI-2 : 183105A-01
* cable MXI-2-1 P/N : 182801A-002
* PCI card : PCI-MXI-2 : 182685H-01

to access and test VME boards inside a VME rack.

To verify capabilities of target boards, I have to realize access with specific mode, so I use the VISA functions to modify access parameters. But if I look what happens on the VME bus, I see limitation of the system :

1- the "Address modifier" cannot be changed (AM0~5 signal on the VME bus) to change the access mode (program, data, user...)

2- the "burst access" on the VME bus is not processed normally; the access succeed but physically, only single accesses are repeated with incremental address (the burst access might be one address and multiple access, the address is implicitly increased by the target board)


Is there a way to fix those problems ? Is there new revision of NI board to be able to realize those kind of access ?

Thanks

[ScotSalmon]

poque-

In your message you said "I use the VISA functions to modify access parameters." What functions are you using for this? If you set the attributes (or properties if you're using LabVIEW) appropriately, the transfer will use the address modifiers you set. For example, VI_ATTR_SRC_ACCESS_PRIV and VI_ATTR_DEST_ACCESS_PRIV, which correspond to the LabVIEW properties "Source access privilege" and "Dest access privilege", allow values such as VI_DATA_NPRIV, VI_BLCK_PRIV, etc., to switch between data, program, block, and D64 transfer types and, where appropriate, to allow privileged or not privileged access. Choosing a block modifier (BLCK or D64) will automatically enable block mode allowing the target to increment the address within a block. These attributes apply to all other operations that do I/O directly including viMove (all variants) and viIn/Out. VI_ATTR_WIN_ACCESS_PRIV is the corresponding atrtibute for viMapAddress/Peek/Poke. Note that some settings such as D64 do not apply to all address spaces or all operations. Also, remember that most attributes, including these, are set independently on each session, so if you want an I/O to happen with certain address modifiers, you must set the attributes in the same session that you use for the I/O.

Also, what version of NI-VXI are you using? In older versions with the NI-VXI API as the primary API instead of VISA, these same features are controlled by the "srcparms" and "destparms" for the VXImove operation, and similar parameters for other operations such as MapVXIAddress and VXIin/out. (And just to be clear, if you use the VISA attribute to set the modifiers but then use the NI-VXI API to do the I/O, your VISA setting will not be used by the NI-VXI API. Only the VISA API uses the VISA attributes for the modifiers.)

-Scot

[poque]

Hello Scot,

To change address modifiers, I change the attributes just like you wrote, but somewhen during the transfer, this information is not used and the transfer on the bus is not modified.
I am not using Labview but C++Builder to create my application.
I use the NI-VXI version 3.2

I have been told that the MXI2 system is not able to manage block transfer and change of address modifier, and that I have to get an MXI3 system to use those features. Do you know something about this ?

Thanks

Poque

[ScotSalmon]

---

@poque wrote:
To change address modifiers, I change the attributes just like you wrote, but somewhen during the transfer, this information is not used and the transfer on the bus is not modified.
I am not using Labview but C++Builder to create my application.
I use the NI-VXI version 3.2

I have been told that the MXI2 system is not able to manage block transfer and change of address modifier, and that I have to get an MXI3 system to use those features. Do you know something about this ?

---

MXI-2 uses a conversion protocol to handle block transfers. It is enabled automatically if you do the transfer using a block privilege. It's true that the MXI-3 based VXI controller, the VXI-8340 Series, doesn't require conversion from MXI-2 to VXI, but I don't think MXI-2 is the cause of the problem. I just confirmed on my logic analyzer that setting VI_ATTR_SRC_ACCESS_PRIV to 4 (VI_BLCK_PRIV) and performing a viMoveIn does block (BLT) transfers even if the controller uses MXI-2.

I don't think this is the problem, but I would recommend updating to the latest driver. The latest is available at http://www.ni.com/support/vxi/drivers.htm and minor updates, such as from 3.2 to 3.3.1, are free.

If that doesn't work, can you paste or attach a code snippet and/or NI Spy log that illustrates the problem? You can try to duplicate the problem in VISA Interactive Control as well, which may make it easier for me to reproduce your setup.

-Scot

[poque]

Thanks for your help,

I am not able to reproduce the problem because I don't have anymore a system at this time.
But soon, I have to rebuild a system to test some VME boards inside a VME rack, so I wonder if I have to buy a VME-MXI2 system (that I used before) or a VXI-MXI3 system to be sure to be able to validate block transfer and others acces mode.

[ScotSalmon]

---

@poque wrote:
I wonder if I have to buy a VME-MXI2 system (that I used before) or a VXI-MXI3 system to be sure to be able to validate block transfer and others acces mode.

---

I still believe MXI-2 will do the block move behavior you need, and that there is some other problem which might be detected with a Spy log or other debugging, or possibly by updating the driver. Therefore I would recommend purchasing whichever controller works best for your application in other respects (cable length, power cycling behavior, etc.), because both controllers (like all of our controllers) should support block address modifiers.

-Scot

[poque]

Hello,
I try to install the new driver revision (3.3)and I have an other problem.
I'm trying to configure interrupt mode in ROAK but VME acknowlage cycle is not performed.
I probe the VME bus on a logic analysis system and I can see the interrupt falling to 0.

I'm using following functions :
status |= viInstallHandler(LCibleSession, VI_EVENT_VXI_VME_INTR, IrqTraitement, 0);
status |= viEnableEvent(LCibleSession, VI_EVENT_VXI_VME_INTR, VI_HNDLR, VI_NULL);
Status return is always OK (value is 0)

IrqTraitement() function is never launch when the IRQ is activated to 0.
Did I make a mistake with some parameters or function?

Poque

[ScotSalmon]

---

I'm trying to configure interrupt mode in ROAK but VME acknowledge cycle is not performed.

---

Your use of the API looks correct for the two lines you quoted. What type of resource is LCibleSession? Based on your original post and your followups, I think you are using a VME (rather than VXI) INSTR resource, with a pseudo-LA; let me know if that is not correct (for example, let me know if this is a real VXI INSTR with a VXI logical address, or maybe a BACKPLANE resource).

For VME resources, the INSTR will receive the interrupt based on the interrupt mask for that resource, which is controlled by how the VME pseudo-LA is set up in MAX, so please check that MAX has the correct configuration for your VME device.

Your NI-VXI 3.x CD includes a utility called BusMonitor which can be used to check the status of a particular VXI bus, including one on the other side of a MXI connection, to see if the software sees an interrupt pending there. You can also open the BACKPLANE resource (probably easiest to do this in VISA Interactive Control) and check VI_ATTR_VXI_VME_INTR_STATUS yourself, which is what BusMonitor does, to see if the VME-MXI-2 sees the interrupt. If the VME-MXI-2 sees it and the PCI-MXI-2 doesn't, there may be a problem with the interrupt not being routed out of the chassis due to the MAX interrupt configuration, and you'll want to check that configuration on your VME-MXI-2 in MAX. You can also confirm the interrupt routing yourself by reading the appropriate register from the VME-MXI-2's A16 configuration space: offset 0x12 should be something like 0x7f00 (refer to the VXI-6 specification for details) where the 0x7f byte enables the 7 interrupt levels for routing and the 0x00 byte routes them all out of the chassis, from VME to MXI.

Often VME devices are RORA (not ROAK) and the VISA specification does not support RORA; if you need that functionality, let us know and we may be able to describe some unsupported NI-specific extensions we use internally to support RORA. Based on your last post it sounds like ROAK should work for you, but I just wanted to mention that in case it affects you.

-Scot

[poque]

here is the function we use to create session :
LStatus = viOpen(LDefaultSession, "VXI0::259::INSTR", VI_NULL, VI_NULL, &LDEDSession);
LCibleSession = LDEDSession;

It's a VME resource and devices are ROAK. The MXI/VME NI board is in slot 1.

With MAX,

VME-MXI-2's A16 configuration space :
-------------------------------------
-> offset 0x12 value is 0x7f00 (it seems to be OK)


BACKPLANE resource:
-------------------
-> When there is no interrupt on VME asserted, I can read VI_ATTR_VXI_VME_INTR_STATUS to 0x10??
-> When interrupt 4 on VME is asserted, I can read VI_ATTR_VXI_VME_INTR_STATUS to 0x18.
Interrupt 5 seems to be always asserted, and I don't understand why.

The results is the same when I'm using VXIbus Status Monitor.


With Max, do we have to select something in :
- interrupt level assignment,
- mapping,
in VXI system properties?

Besides, in the frame, MXI/VME NI board (VXI0::1:INSTR) slot parameter is "unknown".
Is there any jumper to select Arbiter mode for this board?

Poque

[ScotSalmon]

Can you attach an NI Spy capture (use the "log to file" mode for most thorough capture) of the setup and the problem? Also check both BACKPLANE sessions (LA 0 and your mainframe LA) for the INTR_STATUS attribute.

I can't really make any guess about why interrupt 5 is always asserted. It's possible the explanation will show up in the Spy log but I am not very hopeful about that one. You might try removing some of your other modules to see if it goes away.

I believe the reason slot is unknown is that VME does not support VXI module ID (MODID) functionality to determine slot.

You can control the arbiter mode and other options in the Hardware Configuration panel in MAX for your VME-MXI-2.

-Scot