VXI and VME

cancel
Showing results for 
Search instead for 
Did you mean: 

Testing VME-MXI-2 (PCI8015) That May Have Died

I've had a VME-MXI-2 kit running in a VME rack very nicely for a few months.  Recently, an experienced engineer (i.e., he knows how to religiously take ESD precautions) moved it to another rack and troubles began with the system.
 
We are seeing odd patterns on the VMEbus signals (*DTACK before *AS for example).  Another symptom... when we write (D16 mode) 0xAABB, 0xCCDD to address 0x100 of an A24 memory card... when reading back the two bytes (or really any address) we see 0xCCFF - ALWAYS.  Note, we are sure we are actually talking to the memory card because, if it is removed from the rack, we get *BERR as one would expect.  It just looks like something is hosed on the bus accesses.
 
My thought is that something bad has happened to the VME-MXI-2 card in the VME rack... does anyone know of a way to test the card to make sure it is still operating properly?  Are there any diagnostics that are already on the PC with VISA and MAX?  I'd like to figure out if it is the card or some other issue.  We have tried alternate card cages and the exact same symptoms show up in each one.
 
We are on a path to get a replacement kit to try, but, of course, we REALLY need this thing to work TODAY if at all possible.  Any input is welcome.  Thanks.
 
-felben
0 Kudos
Message 1 of 10
(9,951 Views)

I would verify that there are no bent or missing pins in the second chassis.

 

0 Kudos
Message 2 of 10
(9,947 Views)
We checked all pins and have tried the card in three different VME racks.  No joy.

-felben
0 Kudos
Message 3 of 10
(9,939 Views)
Something else I have had to do is reloead the PROM configuration on the MXI-VME boards.  See if you can download the board's configuration in MAX.  If not, if you have a "known good" board, save the configuration EEPROM to a file for a known good board, and try to load the "known good" config file to the bad board.
 
0 Kudos
Message 4 of 10
(9,935 Views)

I was just thinking yesterday that the config EEPROM might have been frazzled.  I will be back onsite tomorrow and will try your suggestion.  Unfortunately, we have exactly one system (thus, zero known-good boards).  We have ordered a second set so maybe we can recover and make the original one work again.  There is a way in MAX to read/write the configuration settings?  Thanks for the help.

 

-felben 

0 Kudos
Message 5 of 10
(9,927 Views)

Acutally, that reminded me of a simpler, preliminary test.  The version of Max I was using was pretty old (around LV version 6 & 7), so I am hoping the driver for the card are still similar.  Anyway, run RESMAN so that MAX will load the configuration of the board.  If the board does not show up in slot zero (or not at all) the board is definietly messed up.

 

This also reminds me that you can have to board boot up in "factory" safe EEPROM settings.  If you look in the manual, there is a jumper setting that will force the card to boot from the factory default.

 

Once MAX has reconized the board, you can right click on the device to get to the ?board configuration? menu.  This will then let you upload or download a configuration file.  Sorry I could not provide any more detail, this was over a year ago that I did this stuff...

0 Kudos
Message 6 of 10
(9,923 Views)

Joe... thanks again for the help.  Unfortunately, I tried all of this and it isn't making a difference.  The PCI and VME cards are recognized by MAX just fine, so I think that is working.  I first was able to download the configuration information (to a file) which I am now attempting to interpret as best as I can (it is simply a list of addresses and data values - not sure how to make sense of them... do you know where the definitions exist?).  I then set both the VME and the PCI cards to their "default" settings and dumped configuration again just to see if anything changed.  The behaviour of the card has not been affected.  Finally, I set the DIP switch to force factory load with protection and again, no change in behaviour.

 

Tomorrow or Monday we should have a new card set... I sincerely hope that takes care of the problem because I am coming up with nothing here.  Let me know if you think of anything else to try.  Thanks.

 

-felben

0 Kudos
Message 7 of 10
(9,916 Views)

No I don't know the definitions of the config file.

 

It seems that the MXI portion of the system is working.  Can you write and read memory locations on the local board?  In the card manual, there should be some basic registers you can read and write to.  I would see if I could write to those values.

 

I am also assuming you have some type of breakout board and logic analyzer to look at signals?  I would want to make sure writes are not corrupt for the address and data matches what you are sending to your memory device.

 

Hope this helps...

0 Kudos
Message 8 of 10
(9,909 Views)

Joe... I had checked the VMEbus signals with an extender card and found them pretty messed up.  Sometimes it kind of made sense, other times DTACK was not where it should have been.

 

We have now received the replacement card set and swapped out the VME-MXI-2 board... works perfectly.  We also tried to write a "known good" configuration from the new board to the failed board, but it continued to fail in exactly the same manner.  The failed board has been sent back to NI for repair/replacement (luckily it was under warranty).  I hope they can tell us what happened to the board as it is a rather critical piece of our developmental test platform.  I find it odd that nobody from NI every posted on this thread.... I suppose nobody is really using these old VME cards anymore?

 

Thanks for your suggestions.

 

-felben

0 Kudos
Message 9 of 10
(9,872 Views)

Felben,

 

No problem on the suggestions.  Good luck in all of your VME endevours! 

 

🙂

 

Joe

0 Kudos
Message 10 of 10
(9,869 Views)