Experimental Physics and
Industrial Control System

"Eric Bjorklund, NPSM" <[email protected]> · Tue, 4 Aug 1998 11:11:14 -0600 (MDT)

>
>I am having problems with a Hytec VSD2992 CAMAC Serial Highway Driver.  I am
>using the LANL driver software.
>
>The module works fine when the CAMAC link is working.  If I momentarily
>disconnect the link or otherwise try to generate link errors,  the MVME177
>hangs with its VMEbus LED stuck on.  Channel Access disconnects and I can't
>access the '177 from the local console.  The 2992 LEDS show errors and LAMs.
>Reconnecting the CAMAC link back doesn't help,  the only way to resume
>operation is to reboot the '177.
>
>This is my 3rd 2992 and the first two never exhibit this problem.  Hytec has
>the problematic 2992 and claim "it works here (in the U.K.)".  They  are
>claiming that I must be configuring the 2992's registers to generate
>interrupts ,  which are not being serviced properly.
>
>
>  1)  Is the '177 hung or is it continually servicing a (high priority) VME
>interrupt?
>

Paul,

My guess would be that you are in a continuous interrupt loop.  The LAM light
on the front of the 2992 means that it is trying to generate an interrupt (the
use of LAM, in this context, is a holdover from when serial highway drivers
were CAMAC modules themselves that lived in parallel or branch highway crates). 
There are two possibilities here -- both of which can be generated by
disconnecting the link.
 1. If the highway is fast enough, the 2992 driver will busy wait after sending
    a serial command until the reply message is received.  The driver makes a
    measurement at system startup time to see how many iterations it takes for
    the reply message to come back.  If it hasn't seen a reply in twice that
    many iterations (e.g. because the cable is unplugged), it enables 
    interrupts on the "READY" and "TIMEOUT" signals and waits for one of these
    interrupts or a timeout (thus releasing the CPU for more important tasks).
 2. Disconnecting and reconnecting the highway can generate spurious "Demand"
    messages which typically manifest themselves as LAM requests from strange
    crates.  The "Demand" interrupt is always enabled by the driver, so
    this will cause you to go into the interrupt service routine (or attempt
    to).  An easy way to check for this kind of interrupt is to check the "DMD"
    light on the front of the 2992.
>
>  2)  Is there a way to disable ISR's from the 2992 ?
>

You can disable interrupts on the 2992 by clearing the interrupt enable bit
(bit 7) in the control/status register (register 4).  The following example
shows how to do this, with the following assumptions:
  1) You are on branch 0 using the default addressing of DE00.
  2) The MV177 maps A16 space starting at 0xffff0000 (like the MV167 does).
  3) It's not already too late and you still have console access.
	-> m 0xffffde04
	   ffffde04:  4be5-0
	   ffffde06:  0000-.	
	->
(note that the interrupt enable bit is the only writeable bit in the register
except for "BUSY" (which we ignore) hence ).

>
>  3)  How can I track what's going on in either the '177 or in the 2992
>software driver.
>

I would recommend a good VME analyzer.  We use the "VMETRO" (don't remember
off-hand who makes it) and have found it more than worth the purchase price.
The most likely thing I can think of that is happening to you -- especially
since it seems to occur on only one board -- is that the 2992 is not vectoring
the interrupt correctly.  This is something that can be easily seen on a VME
analyzer.  When the 2992 asserts an interrupt, you should see a vector of "80"
(or ffffff80) show up in the trace (again, assuming branch 0 and default
addressing).  Another easy possibility you could check without an analyzer is
to make sure you have the bus grant and IAG jumpers removed on the VME
backplane for the slot in which the 2992 is mounted.  Not having these jumpers
removed can sometimes cause funky behavior.

I too have had boards work here but not in the UK (a different problem from
yours, but a similar phenomenon).  Worse yet, I have had boards "cured" simply
by shipping them back and forth across the atlantic.

Good Luck.
-Eric Bj.

==============================================================================
Eric Bjorklund				Voice: 505-667-6031
Los Alamos National Laboratory		Email: [email protected]
LANSCE-6 MS H820
PO Box 1663
Los Alamos, NM 87545
==============================================================================
"Try not to sweat the petty things.
 And for sure don't pet the sweaty things."

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System