Experimental Physics and
Industrial Control System

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?

-----Original Message-----
From: Michael Davidsaver <mdavidsaver at gmail.com> 
Sent: Wednesday, 1 December 2021 3:09 AM
To: Johnson, Andrew N. <anj at anl.gov>; Peter Linardakis <peter.linardakis at anu.edu.au>
Cc: EPICS tech-talk <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>> 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="">
hub.com%2FRTEMS%2Frtems%2Fblob%2Fe945e3fc4d6a6a74789c9a348120ec7d06e1
9231%2Fbsps%2Fpowerpc%2Fshared%2Fvme%2FvmeTsi148.c%23L1715&amp;data="" class=""> 4%7C01%7Cpeter.linardakis%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="">
thub.com%2FRTEMS%2Frtems%2Fblob%2Fe945e3fc4d6a6a74789c9a348120ec7d06e
19231%2Fbsps%2Fpowerpc%2Fshared%2Fvme%2FvmeTsi148.c%23L1715&amp;data="" class=""> 04%7C01%7Cpeter.linardakis%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="">