Re: MVME3100 boot failure at "Trying to find CSR on VME"

[Pete Jemian via Tech-talk <tech-talk at aps.anl.gov>]

We've also seen instances of a VME card where surface components on the pin side of the VME board have been sheared off by clumsy (!) handling while installing or removing the board, scraping the back side of the board against the enclosure opening.  In other cases, VME board pins have been bent while forcing a board to mount with the backplane.

While these were interesting discoveries and helped us to caution our non-expert staff in use of great caution while inserting and removing VME boards, from your description, neither of these are likely since you used the same boards in other enclosures with no observed problems.

Pete

On 12/2/2021 11:50 AM, Matt Rippa via Tech-talk wrote:
> Interesting discussion. We've dealt with many similar VME issues. FWIW, we've also identified some of our chassis builds as mechanically compromised. The proper insertion of a card fully connecting and mating with the P1 and P2 connectors is not always obvious. Some chassis connect nicely whereas others require an unthinkable amount of force to properly connect.  Some chassis are designed for use with the older scanbe vme card handles. Other newer crates have the proper extrusions for the IEEE card handles you should have on your 3100.
>
> -Matt
>
> On Thu, Dec 2, 2021 at 5:18 AM Johnson, Andrew N. via Tech-talk <tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>> wrote:
>
>     Hi Peter,
>
>     On Dec 1, 2021, at 7:20 PM, Peter Linardakis <peter.linardakis at anu.edu.au <mailto:peter.linardakis at anu.edu.au>> wrote:
> >     Thank you all for the input.  I've been trying different combinations without much success. There are other cards in the crate but the behaviour is the same whether there are none, some or all cards inserted.  We have other similarly configured crates and the DIP switch settings match.  Since three MVME3100 units display the same behaviour in that crate, but get past that boot stage in another crate/backplane, the only thing I can think of is that we may have damaged the backplane?  Does an MVME3100 theoretically even need a backplane to get past that boot stage?
>     That depends what the software is doing when it boots. In the case of RTEMS it looks like the BSP code that Michael pointed to on GitHub first tries to run a VME bus cycle with the CSR address modifier, then it will look for its own CRG register area on the bus and probe that. In both cases I’m pretty sure the read cycle must be completed properly for the probe test to return, and your symptoms imply that it isn’t being.
>
>     There are 2 ways for a VME bus cycle to finish — if another card accepts the cycle it will respond by pulling the DTACK* line low. If nothing on the bus responds there should be a timer on the system controller board (in slot 0, usually the TSI-148 chip on your CPU board) which will pull the BERR* line after some (programmable) timeout period.
>
>     Michael was wondering if there might be an issue with using an MVME3100 board on a backplane that is older than the VME-64X standard; I can confirm there should be no issues there, the development system in my office pre-dates that and I have never had any problems running any VME-64X CPUs in it.
>
>     I think you may have a damaged backplane, although it’s also possible that someone added or removed jumpers or termination resistors which have left it in an unusable state — if you have a working system from the same manufacturer you could do a detailed comparison to see what if anything is different about the two backplanes. It might be worth checking the power supply too, ensuring that all the voltages are still within spec — PSUs are usually the first pieces of electronics that fail on older equipment, and it’s possible that this might affect the ability to run bus cycles on it.
>
>     - Andrew
>
>
>
> >     -----Original Message-----
> >     From: Michael Davidsaver <mdavidsaver at gmail.com <mailto:mdavidsaver at gmail.com>>
> >     Sent: Wednesday, 1 December 2021 3:09 AM
> >     To: Johnson, Andrew N. <anj at anl.gov <mailto:anj at anl.gov>>; Peter Linardakis <peter.linardakis at anu.edu.au <mailto:peter.linardakis at anu.edu.au>>
> >     Cc: EPICS tech-talk <tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>>
> >     Subject: Re: MVME3100 boot failure at "Trying to find CSR on VME"
> >
> >     On 11/30/21 7:05 AM, Johnson, Andrew N. wrote:
> > >     On Nov 29, 2021, at 8:33 PM, Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov> <mailto:tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>>> wrote:
> > > >     On 11/28/21 9:12 PM, Peter Linardakis via Tech-talk wrote:
> > > > >     vmeTsi148 IRQ manager: looking for registers on VME...
> > > > >     Trying to find CSR on VME...
> > > > >     *********
> > > > >
> > > > >     Does anyone have any ideas why a certain backplane will cause this?
> > > >     CSR in this context refers to the CSR address space, which is a VME64
> > > >     extension using the geographic address pins, which won't be present
> > > >     in an older VME32 crate.
> > > >
> > > >     Still, this error shouldn't be fatal as the TSI148 driver should fall
> > > >     back and print "Trying to find CRG on VME...".
> > > >
> > > >     https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit>
> > > >     hub.com <http://hub.com/>%2FRTEMS%2Frtems%2Fblob%2Fe945e3fc4d6a6a74789c9a348120ec7d06e1
> > > >     9231%2Fbsps%2Fpowerpc%2Fshared%2Fvme%2FvmeTsi148.c%23L1715&amp;data=0
> > > >     4%7C01%7Cpeter.linardakis%40anu.edu.au <http://40anu.edu.au/>%7Cc0b7a358faa84bbe6a1c08d9b41b
> > > >     c1c7%7Ce37d725cab5c46249ae5f0533e486437%7C0%7C0%7C637738854022347930%
> > > >     7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> > > >     k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=BkfYhyq83jjPQ2dBF9F5fiKLGIzOub
> > > >     xxbAtOSuIu3jk%3D&amp;reserved=0
> > > >     <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi>
> > > >     thub.com <http://thub.com/>%2FRTEMS%2Frtems%2Fblob%2Fe945e3fc4d6a6a74789c9a348120ec7d06e
> > > >     19231%2Fbsps%2Fpowerpc%2Fshared%2Fvme%2FvmeTsi148.c%23L1715&amp;data=
> > > >     04%7C01%7Cpeter.linardakis%40anu.edu.au <http://40anu.edu.au/>%7Cc0b7a358faa84bbe6a1c08d9b41
> > > >     bc1c7%7Ce37d725cab5c46249ae5f0533e486437%7C0%7C0%7C637738854022347930
> > > >     %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> > > >     Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=BkfYhyq83jjPQ2dBF9F5fiKLGIzOu
> > > >     bxxbAtOSuIu3jk%3D&amp;reserved=0>
> > >     Since the CPU on this backplane apparently hangs before printing that "CRG" message, my guess is that either the VME system controller isn't generating a BERR signal if/when nothing responds to the I/O cycle after some suitable timeout interval (I assume from the probe operation in the call at line 1717), or maybe that the backplane has a problem with its BERR* signal line not working properly (is it terminated properly?). If the CPU doesn't see a falling edge on either the BERR or DTACK signal it will hang waiting for a data from the read cycle which never completes. If this CPU *is* the VME system controller the code should have enabled a cycle timeout, but going back to what Heinz was talking about you need to make sure that the SCON is properly enabled and that the CPU is in slot 0.
> >     For what little it is worth, I once successfully setup a mvme3100 with RTEMS (4.9.x) in an old (antique?) VME32 crate.  However, that was 10 years ago and I don't now recall what all I had to do.
> >
> >     wrt. SCON there are a pair of DIP switches in the S4 bank which can be set to force a mvme3100 to be SCON.
> >
> >     see sections 1.4.2 and 1.4.3.
> >
> >     https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.slac.stanford.edu%2Fgrp%2Flcls%2Fcontrols%2Fglobal%2Fhw%2Fusers_guides%2Fvme%2Fcpu%2Fmvme3100%2FMVME3100-programmer-ref.pdf&amp;data=04%7C01%7Cpeter.linardakis%40anu.edu.au%7Cc0b7a358faa84bbe6a1c08d9b41bc1c7%7Ce37d725cab5c46249ae5f0533e486437%7C0%7C0%7C637738854022357890%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=7tDbebKF%2B8ch5RLLVxWIt7deApqdtl1H%2FJFeDs73s9g%3D&amp;reserved=0
> >     <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.slac.stanford.edu%2Fgrp%2Flcls%2Fcontrols%2Fglobal%2Fhw%2Fusers_guides%2Fvme%2Fcpu%2Fmvme3100%2FMVME3100-programmer-ref.pdf&amp;data=04%7C01%7Cpeter.linardakis%40anu.edu.au%7Cc0b7a358faa84bbe6a1c08d9b41bc1c7%7Ce37d725cab5c46249ae5f0533e486437%7C0%7C0%7C637738854022357890%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=7tDbebKF%2B8ch5RLLVxWIt7deApqdtl1H%2FJFeDs73s9g%3D&amp;reserved=0>
>     -- 
>     Complexity comes for free, simplicity you have to work for.
--
----------------------------------------------------------
Pete R. Jemian, Ph.D.                 <jemian at anl.gov>
Beam line Controls and Data Acquisition (BC, aka BCDA)
Advanced Photon Source,    Argonne National Laboratory
Argonne, IL  60439                    630 - 252 - 3189
-----------------------------------------------------------
      Education is the one thing for which people
         are willing to pay yet not receive.
-----------------------------------------------------------