Experimental Physics and
Industrial Control System

[email protected] (Jeff Hill) · Thu, 19 Oct 2000 14:51:17 -0600

Timo,

These routines will probably be moved out of EPICS base in the near 
future into a device and or OS specific distribution. If you send your 
patches I will attempt install them into the master copy. 

Jeff

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Timo Korhonen
> Sent: Thursday, October 19, 2000 5:16 AM
> To: [email protected]
> Subject: Interrupts, vectors and mv230x ioc
> 
> 
> The issue of interrupt vector handling in our PowerPC ioc (mv2306) has been a
> little bit of an open issue for us until recently. I had to study an existing
> driver
> (written and running on a 68K cpu) that hung completely and behaved somewhat
> randomly when we tried it on our mv2306 ioc's.  The problem turned out to be
> the following:
> 
> The driver uses functions from devLib.c to connect and disconnect routines to
> interrupt vectors: during initialization it connects to a dummy routine to check
> 
> if the board works as expected and then, if successful, it disconnects from this
> 
> vector and connects to the "real" irq handler.
> In vxWorks intArchLib, only a small subset of functions are implemented for
> the PPC architecture; notably, functions like intVecGet and intVecSet are not
> implemented (although they are in the symbol table and calling intVecGet for
> instance always returns zero!)
> 
> This behaviour confused the driver, because it could not disconnect from the
> first interrupt. devDisconnectInterrupt (in devLib.c) uses intVecGet to get
> the connected handler - and gets always NULL, even if the vector was connected.
> 
> On mv2306, the VME interrupts come through the interface chip (Tundra Universe)
> to a single handler which then dispatches the installed handlers based on the
> vector table information.
> The vectors are stored in linked lists by the interrupt controller driver. I
> wrote a small set of functions with which it is possible to get the
> equivalent (I guess....) behaviour to a 68K cpu.
> I also have modifications to make the devLib and veclist work.
> 
> However, I have a few open questions:
> 
> 1. The mv2306 structure permits having multiple handlers attached to the same
> vector. However, this causes problems for devDisconnectInterrupt (if the
> same routine is attached several times with different parameters, there is
> no way to tell which one to disconnect.)
> Allowing only one routine per vector (like in 68K) should be ok?
> 
> 2. The code in veclist.c makes a check (cISRTest) where it tries to match the
> handler attached to a pointer to a C routine. For those architectures where this
> 
> is imported, the call to intConnect constructs a handler from the passed
> function; in our ioc, a VOIDFUNCPTR and an int  are just put into a linked
> list of handlers. In my patch I do the following: I look for a symbol at the
> address
> and if a symbol is found, I assume that is a C funtion.  I believe this is a
> reasonable assumption?
> The generic VME irq handler (in universe.c) calls the user handler like this:
> 
>          currHandler->vec (currHandler->arg);
> 
> which to me looks pretty much like assuming a C routine.
> 
> 3. The list of unexpected interrupt handlers is not very relevant in the case of
> 
> mv2306, because the Universe interrupt handler checks the vector table and
> complains if the interrupt handler entry is NULL.
> It is not necessary to have a handler attached to unused vectors. This is just
> cosmetics, but in the patches I remove the default vxWorks handler stub
> definitions from the table, to avoid confusing error messages during startup.
> 
> 4. I am not sure if this applies to other than mv2300 series ioc. Because of
> this, I used #ifdef MV2300 in the patches.
> 
> 5. Could the experts help me to sort out the patches so that this could go into
> the next release (if they are still relevant)?
> 
> I do not attach any code here but I will send it to whoever wants to help (Marty
> Kraimer?).
> 
> Timo Korhonen/SLS
> 
> 
> 
> --
> Timo Korhonen  PSI (Paul Scherrer Institut), SLS
>                CH-5232 Villigen PSI
>                tel + 41- 56 3103262  fax + 41 - 56 310 3151
> e-mail:        [email protected]
> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System