Experimental Physics and
Industrial Control System

"Johnson, Andrew N." <[email protected]> · Wed, 29 Jul 2015 19:34:15 +0000

Before proposing that this issue might be caused by a design problem in the slave card, please explain why MOTLoad is able to talk to it but VxWorks isn't. Any configuration of the Universe-2 chip which the MOTLoad debug ROM uses could also be set by the VxWorks BSP, and as I said before in my experience the default BSP settings for the VME master windows address modifier is often set wrong.

Amit, do you know for sure that the bus cycle hangs with DTACk* asserted? If in fact it isn't then I would be even more convinced that the issue is with the address modifier being generated by the MVME5500 under VxWorks.

- Andrew

-- 
Sent from my iPad

> On Jul 29, 2015, at 2:05 PM, Michael Davidsaver <[email protected]> wrote:
> 
>> On 07/29/2015 09:30 AM, Amit Chauhan wrote:
>> ...
>> That is what one aspect of the problem is and in some slaves the 
>> modification is not easy to make at present.
> 
> I've been involved in fixing several cards, both in-house designs, and
> commercial.  It's possible, but never easy :(
> 
>> The another aspect is that the same master is behaving differently under 
>> the control of different firmware (ie. MOTLoad vs. vxWorks)
>> thereby accommodating even a non-compliant slave under one condition( 
>> MOTLoad).
> 
> Any such configuration would be in one of the control registers for the
> universeII.  The two I can see which might relate to your situation are
> the Coupled Window Timer in the LMISC register.  Also the U2SPEC
> register.  It might be worth seeing if these are different in your two
> cases.
> 
> 
>> I am looking if the same master behavior can be 'programmed' under 
>> vxWorks also.
>> 
>> Regards,
>> Amit.
>> 
>> 
>>> On 29-07-2015 17:23, Michael Davidsaver wrote:
>>> Hello Amit,
>>> 
>>> Many VME bus control lines (AS, DS*, and DTACK) are used for
>>> asynchronous handshaking.  Sometimes the edge is important, and
>>> sometimes the level.  The rules are complex.
>>> 
>>> Simply saying "A24" or "A16" isn't necessarily sufficient.  Giving the
>>> exact address modifier in a good idea.  In this case I'm guessing its
>>> 0x39, 0x3A, 0x3D, or 0x3E.
>>> 
>>> I think you have a non-compliant slave card.  In my experience an
>>> unfortunate, but not unusual, occurrence.  VME is more difficult to get
>>> right than other parallel buses (ie PCI).  A VME master can't be
>>> expected to accommodate a non-complaint slave card.
>>> 
>>> You should find a copy of the VME standard document.  If you can find
>>> ANSI/VITA 1-1994 look for figure 2-8 "Non-multiplexed Address,
>>> Single-Byte Read Cycle".
>>> 
>>> In particular, the following statement describes a clear violation of
>>> the VME standard when applied to a single cycle read.
>>> 
>>>> Some slave boards do not use DS* to derive DTACK*.  They derive DTACK*
>>>> using AS* only.
>>> The following is a less clear violation.  My reading of the standard is
>>> that the slave should not react to the AS* line going high.  In figure
>>> 2-8 the slave side flow includes "Receive AS* low", but never "Receive
>>> AS* high".  The read is complete when the DS* lines are driven high.
>>> 
>>>>  1. CPU asserts AS* and DS* signals.
>>>>  2. Slave board responds with DTACK*,
>>>>  3. CPU removes only DS* and *not* AS*. It expects the slave to remove
>>>>     DTACK*.
>>>>  4. Only on finding the DTACK* removed by slave, the master removes AS*
>>>>     ending the cycle.
>>> In practice, after the slave asserts DTACK, I've seen VME masters
>>> release AS and setup the address for the next operation.  I don't think
>>> this is a question of master configuration, but rather of the time
>>> between accesses.
>>> 
>>> Isn't VME fun :)
>>> 
>>> 
>>> Michael
>>> 
>>> 
>>>> On 07/29/2015 02:32 AM, Amit Chauhan wrote:
>>>> Hi All,
>>>> 
>>>> This is regarding the working of Tundra Universe II on VME based
>>>> MVME-5500 CPU Board.
>>>> 
>>>> Three of the important signals on VMEbus are Address Strobe (AS*), Data
>>>> Strobes (DS0* & DS1*) and Data Acknowledgement (DTACK*).
>>>> 
>>>> In a normal VMEbus data transfer cycle, the master asserts AS* and DS*
>>>> signals. When a slave board responds with DTACK*, the master removes AS*
>>>> and DS* and in turn slave also removes DTACK* thereby ending the cycle.
>>>> 
>>>> Two common types of addressing (for slave boards)are :
>>>> *A16* (16-bit addressing) and
>>>> *A24* (24-bit addressing).
>>>> 
>>>> On a MVME-5500 CPU,we have observed following three cases:
>>>> 
>>>> _*Case-1:*_
>>>> CPU runs under *MOTload* (native bootloader) and performs *A24* cycle.
>>>> 
>>>>  1. CPU asserts AS* and DS* signals.
>>>>  2. Slave board responds with DTACK*
>>>>  3. CPU removes AS* and DS*
>>>>  4. In turn slave also removes DTACK* thereby ending the cycle.
>>>> 
>>>> _*Case-2:*_
>>>> CPU runs under *vxWorks* and performs *A16 *cycle.
>>>> 
>>>>  1. CPU asserts AS* and DS* signals.
>>>>  2. Slave board responds with DTACK*.
>>>>  3. CPU then removes AS* and DS*
>>>>  4. In turn slave also removes DTACK* thereby ending the cycle.
>>>> 
>>>> _*Case-3: *_
>>>> CPU runs under *vxWorks* and performs *A24 *cycle.
>>>> 
>>>>  1. CPU asserts AS* and DS* signals.
>>>>  2. Slave board responds with DTACK*,
>>>>  3. CPU removes only DS* and *not* AS*. It expects the slave to remove
>>>>     DTACK*.
>>>>  4. Only on finding the DTACK* removed by slave, the master removes AS*
>>>>     ending the cycle.
>>>> 
>>>> 
>>>> Case-3  (A24, vxWorks) is the most used cycle type.
>>>> It is causing the problem as not every slave follows the sequence expected.
>>>> Some slave boards do not use DS* to derive DTACK*.  They derive DTACK*
>>>> using AS* only.
>>>> In such cases CPU's AS* and Slave's DTACK* remain asserted causing a
>>>> deadlock.
>>>> 
>>>> It seems the vxWorks BSP programs the Tundra Universe II chip for
>>>> Case-3  in such a way that it behaves differently from Case-1 (MOTLoad)
>>>> for A24 cycles.
>>>> 
>>>> Can we make any changes somewhere in vxWorks BSP or initialization-codes
>>>> for Universe II so that CPU removes AS* when it finds DTACK* asserted by
>>>> slave for A24 cycles also, which it is doing for A16 cycles .
>>>> 
>>>> Regards,
>>>> Amit.
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System