Experimental Physics and
Industrial Control System

"Szalata, Zenon M." <[email protected]> · Fri, 11 Nov 2011 09:54:50 -0800

Andrew, Thank you for the very useful info.

Ernest, I believe I will need your  help to resolve this.
Present window of opportunity will close one week from this coming Monday.  If you are not available next week to help with this, then the next opportunity will be during Christmas shutdown.

Thanks again,
Zen

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Friday, November 11, 2011 8:34 AM
> To: [email protected]
> Cc: Szalata, Zenon M.
> Subject: Re: Allen Bradley VME-AB1771, 6008-SV2R
> 
> Hi Zen,
> 
> On 2011-11-11 Szalata, Zenon M. wrote:
> > >        drvAb link 0 sysBusTas failed
> > >        drvAb link 0 sysBusTas failed
> > >        drvAb: link 0 sc_lock failure fl_lock 0
> > >
> > > Has anyone successfully used AB R2.2 with mvme6100, EPICS R3.14.11, and
> > > vxWorks 6.6?
> 
> We use AB Scanners on 3.14.11 IOCs here, although not with vxWorks 6.x yet.
> the problem is not with EPICS, it's the MVME6100 but I think you'll find the
> same issues with almost any PowerPC-based board using the default Wind
> River
> BSP.
> 
> The above sysBusTas failure messages tell me that your MVME6100 BSP is not
> configured to do an 8-bit read-modify-write cycle on the VMEbus when the AB
> driver calls sysBusTas(), which is an essential requirement for controlling an
> AB scanner.  VxWorks has an alternative method for atomic access across the
> VMEbus which involves acquiring bus mastership and not releasing it until the
> access is complete, but that doesn't work if the TAS location is on another
> VME card which doesn't itself follow the same protocol.  In the case of the AB
> cards the TAS location is in the scanner's shared memory, and you really do
> have to use a VMEbus 8-bit read-modify-write cycle — the board's CPU uses a
> 68K TAS instruction to acquire access to its internal command buffer.  I make
> changes to all our BSPs here at APS to ensure that sysBusTas() does that, so
> Mark Rivers won't normally see that problem as he uses my BSPs.
> 
> That may not be the only issue, but it's one that you will definitely have to
> fix before this can work properly.  You need to ensure that sysBusTas() ends
> up calling sysVmeRmwTas(), and that it will generate an D08 cycle.  Among
> others I make the changes below to the sysVmeRmw() routine in the file
> mv6100/sysLib.c, but I'm not sure if these will be sufficient for you:
> 
>  LOCAL BOOL sysVmeRmw
>      (
>      char * vmeAdrs          /* VME address to be tested and set */
>      )
>      {
> 
>      BOOL state = FALSE;  /* semaphore state */
>      int  lockKey;        /* interrupt lock key */
> +    UINT32 mask = 0x80000000 >> ((UINT32) vmeAdrs & 3) * 8; /* bit to TAS */
> 
>      lockKey = intLock ();
> 
>      /* Enable RMW cycle */
> 
> -    sysBusRmwEnable(VME_RMW_ENABLE_BITS,		/* enable bits */
> -                    VME_RMW_COMPARE_BITS,		/* cmpare */
> -                    VME_RMW_SWAP_TO_SET,		/* swap */
> -                    (char *)vmeAdrs);
> +    sysBusRmwEnable(mask, 0x00000000, 0x80808080, vmeAdrs);
> 
>      /* perform RMW to try and set TAS location */
> 
> -    state = *((UINT32 *)vmeAdrs);
> +    state = *vmeAdrs;
>      EIEIO_SYNC;
> 
>      /* Disable RMW cycle */
> 
>      sysBusRmwDisable();
> 
>      /* unlock the interrupt */
> 
>      intUnlock (lockKey);
> 
>      /* return TAS test result */
> 
> -    return (state ? FALSE : TRUE);
> +    return (state & 0x80) ? FALSE : TRUE;
>      }
> 
> 
> - Andrew
> --
> Optimization is the process of taking something that works and
> replacing it with something that almost works, but costs less.
> -- Roger Needham

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System