Experimental Physics and Industrial Control System

Hi Keith,

On 03/28/2017 07:20 AM, [email protected] wrote:
> We want to run two MVME5500 processor boards in one VME crate where both
> processors run EPICS IOCs under VxWorks (v5.5) and receive interrupts
> from other I/O cards on the VME bus? (A mix of Hytec cards and Power
> Supply Controllers.)
>  
> We have cases of two processor boards in a one crate, but they are not
> both receiving interrupts from I/O modules in other slots.
>  
> My boards do not need to receive data from the same I/O modules. I’ve
> assigned interrupt vectors so they are unique to each IP module and
> processor, but both IOCs throw up errors for receiving uninitialised
> interrupt vectors. They seem to receive interrupts on vectors not
> configured for them, or rather not from the modules they are interested in.
>  
> There are 7 VME interrupt levels (on 7 VME bus lines) and I found some
> suggestion that the two processors must not both handle the same
> interrupt level, but it looks like our drivers do not give us freedom to
> configure this.
>  
> Can anyone clarify this or offer a solution?

Yes, unfortunately the only way to partition interrupts across a single
VME backplane to two or more CPU boards is to dedicate each IRQ line and
hence interrupt level to a specific CPU board. The interrupt vector
space is not shared so partitioning the vectors doesn't matter, only the
IRQ lines. If you have no control over which IRQ line a particular I/O
board drives then you can't decide which CPU to run the driver for that
board on, it *must* run on whichever CPU "owns" that IRQ line.

Many I/O boards configure their IRQ line with jumpers or switches; make
sure that you can't change it that way, even if that means you have to
build a special version of any driver that has hard-coded the level (I
would recommend modifying any such drivers you find to allow run-time
configuration if the hardware supports that).

You must also ensure that that the VxWorks BSP's sysIntEnable() routine
is only called for levels/IRQs that this CPU owns, which may mean that
you have to exclude some drivers from the binary when building the IOC
executable for each CPU. The sysIntEnable() routine tells the CPU's VME
interface to respond to requests on the given IRQ line, and only one CPU
can handle each line. Note that sysIntEnable() is called by devLib's
devEnableInterruptLevelVME() and devEnableInterruptLevel() routines
where a driver uses the devLib APIs instead of the VxWorks-specific ones.

I can explain in more detail if you really want to know it, but the
simple answer is that you may have to move I/O responsibilities between
your two CPUs to get your particular setup working.

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Replies:

RE: Two VxWorks IOCs in one VME Crate keith.baker

References:

Two VxWorks IOCs in one VME Crate keith.baker

Navigate by Date:

Prev: Info on reading Sensus AMR UI-1203 protocol? Ryan Pierce

Next: INP string length Siddons, David

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: Two VxWorks IOCs in one VME Crate keith.baker

Next: RE: Two VxWorks IOCs in one VME Crate keith.baker

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024