VME access limitation

[poque]

I've sold the problem of interrupt 5. It seems it was a problem of MXI2/VME board.
I change it by another I just received and now it looks ok.

Here you can find (in the attached file) my setup sequence + assertion of interrupt INT4.
Function handle is not lauch and cycle is already not acquiert.


Something is strange with my PCI-MXI2 board (at logical adress 0): I can't change in "Hardware configuration"
the setting "number of interrupteur".
The only way I have to change it is to change the logical adress to an other value. But after that,
"run ressource VXImanager" do not performed.

I send you my configuration with niMXSreport.txt file.

[ScotSalmon]

Thanks. Can you also include reading both BACKPLANE's VI_ATTR_VXI_VME_INTR_STATUS in the Spy log, as well as the VME-MXI-2's interrupt routing register at offset 0x12 in A16 space? I know you reported those in an earlier post but since you have changed to a new MXI-2 board I'd like to confirm it, and it would be best to confirm it in combination with the rest of the Spy log so we can see that everything is in order.

One other thing you can try is doing viAssertIntrSignal with one of the VXI IRQ lines on both BACKPLANE resources and see if the handler runs in those cases. Be sure Spy is logging when you do this, also.

Thanks. I can't see any problem with what you're doing; I appreciate your patience as we try to figure this out.

As far as the number of interrupters and non-LA-0 operation: a VXI system must have exactly one LA 0 device, which is the resource manager. Since MXI-2 is based on the VXI specification for extenders, a MXI-2 system must also follow this rule in order for the extender to be configured by the resource manager. This is why your system doesn't work if your controller is not LA 0. As for the other half of the question, maybe you could clarify why your LA 0 controller needs additional interrupters? Normally LA 0 controllers are not interrupters, but handlers, although you can interrupt from LA 0 also regardless of that setting. If you want that behavior you might have to change configuration options to ensure that your device in the chassis receives the interrupt from across MXI-2 since normally interrupts are routed the other way.

-Scot

[poque]

I try to assert irq but there is an error code return when I launch viAssertIntrSignal function.
I attached the result log file.
The irq seems to be correctly detected.
Poque

[ScotSalmon]

---

I try to assert irq but there is an error code return when I launch viAssertIntrSignal function.
I attached the result log file.
The irq seems to be correctly detected.

---

The error (which you can see in the Spy log, by the way: "The interface cannot generate an interrupt on the requested level or with the requested statusID value") is due to the fact that you are trying to assert an interrupt with the LA field (the lower 8 bits) of 0 using a controller with LA 1. Try using statusID 0x0001 and see if that works.

There is more going on here that is not shown in the Spy log, though. In the log, at line 17 you check VI_ATTR_VXI_VME_INTR_PENDING on VXI0::0::BACKPLANE and it shows nothing pending, then you close and reopen VXI0::0::BACKPLANE and check the same attribute and it says interrupt 4 is pending. What triggered that interrupt? (Also, the "default RM" used in some of the viOpen calls is not shown in the Spy log anywhere, I'm not sure that's important but it indicates that there is missing information in the log.)

Anyway, I see that your viAssertIntrSignal using VXI0::0::BACKPLANE works, which means that the interrupt is pending from somewhere other than LA 0, because otherwise you'd get VI_ERROR_INTR_PENDING. So it looks like the interrupt in your chassis, probably from your VME device, is being routed correctly over MXI-2.

The question then is why your installed handler doesn't run. Check in MAX to see what interrupter levels are assigned to your VME device and make sure that 4 is among them. Let me know what you find. Thanks!

-Scot

[poque]

I try these new operation but interrupt is still pending at the end.
Have a look at the file I send to understant chronologie event.

"The question then is why your installed handler doesn't run. Check in MAX to see what interrupter levels are assigned to your VME device and make sure that 4 is among them. Let me know what you find. Thanks!"
-> All interrupts are assigned on my VME 259 device

Did I have to select something else in MXI or PCI devices?

Thanks
Poque

[ScotSalmon]

---

All interrupts are assigned on my VME 259 device

Did I have to select something else in MXI or PCI devices

---

You should not have to change any MXI or PCI configuration options to make this work. Based on your previous tests it really looks like the interrupt is correctly being mapped to your PCI-MXI-2, it's just not enabling/handling it for some reason.

What do you mean by "all interrupts are assigned on my VME 259 device"? The VME device should have one interrupter, on level 4, assuming that it only interrupts on level 4. That configuration works as expected on my system.

-Scot

[poque]

"What do you mean by "all interrupts are assigned on my VME 259 device"? The VME device should have one interrupter, on level 4, assuming that it only interrupts on level 4. That configuration works as expected on my system."

I mean that my board is able to assert all interrupt IRQ. In the test I generate the IRQ4 but it could be another.
That's why all interrupts are assigned on this device.

Is there any function NIVisa to run an acknowledge interrupt cycle?
It looks like the board was not an Interrupt Controler.

Poque.

[ScotSalmon]

---

I mean that my board is able to assert all interrupt IRQ. In the test I generate the IRQ4 but it could be another. That's why all interrupts are assigned on this device.

---

Ahh I understand. I was really just asking to confirm that MAX shows that your device has an interrupter on all the lines you want (i.e. right-click the device in MAX, check Properties>>Resources).

---

Is there any function NIVisa to run an acknowledge interrupt cycle? It looks like the board was not an Interrupt Controler.

---

Not normally, although I can give you a special address space to access if you really want to try it. This is totally unsupported behavior but we use it internally here in R&D sometimes:

#define VI_VXI_VME_INTR_ACK_SPACE      (0xD) /* manually acknowledge interrupt */
viIn32(instrSession, VI_VXI_VME_INTR_ACK_SPACE, level, &status32);

-Scot

[poque]

It works now !
Last function viIn32() you send me seems to works properly but now enable_even function works too.

The problem was the following : Our VME device was not properly running. First interrupt cycle acknowledge was not completed by our board on VME bus( no Interrupt status/id on bus and no DTAQ_n signal asserted because she was in RORA mode).
The impact is that PCI/VXI board didn't try to generate another cycle after first wrong interrupt acknowledge cycle. I have to reboot the PC and disconnect the power of PC (to clear all registers of PCI/MXI board I suppose)to have another cycle.
Closing session and run VXI ressource manager didn't sold the problem.

Now, Handler is correctly launch and I catch the interrput level and vector!

Last question for this problem :
We often use this system to test prototype board (so this case will be current). Did you know if there is a NI-VISA function (or low level access) to clear completely the system current state? (something like a general reset of PCI/VXI/VME NI system )

Thanks a lot for your help and patience.
Poque

[ScotSalmon]

Ahh, interesting. When there is an error trying to acknowledge the interrupt we have to leave the interrupts disabled otherwise your entire system could hang (spending all its time trying to run the interrupt handler). I think if you open Windows Device Manager and right-click on your PCI-MXI-2 and disable it, then re-enable it, the driver should reload the registers that enable interrupts again.

-Scot