Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Wed, 29 Jul 2015 15:57:06 -0400

On 07/29/2015 03:34 PM, Johnson, Andrew N. wrote:
> 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.

As I stated before, the expectation Amit describes appear to violate the
VME standard.  Once we start down that road it's a question of where
things fail, not if.

Also, the timing of accesses comes into play.  I'm guessing that MOTLoad
is driving the UART directly, while buffered I/O is used with vxWorks.
So the time between VME bus reads is likely different.

Partly it's also my bias.  I can remember working with 9 different VME
slave cards in the past 8 years.  I found significant functional problem
due to VME spec. violations with 4 of these.  Happily all of these are
now corrected.

> 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.

Granted, and this should also be checked.

> 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.

Also, I'd recommend that anyone developing VME slave cards invest in a
dedicated bus analyzer card.  I've used several generations of VMetro
cards.  The high end ones include automatic monitoring for protocol
violations.

https://www.google.com/?gws_rd=ssl#q=vme%20bus%20analyzer

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System