On 10/5/22 04:30, Jukka Pietarinen via Tech-talk wrote:
Hi Heinz,
Yes, on the EVR and EVM the VME interface is implemented in a Kintex 7 FPGA, but the code is not related to the board from Struck.
In the interrupt handler you have to make sure to read back the register clearing the interrupt flag after clearing the flag with a write. This is to flush the write pipeline of the VME bridge of the CPU module before exiting the interrupt handler. Otherwise it may happen that the interrupt line is still active after leaving the interrupt handler and another interrupt is requested immediately after exiting the handler but there is no card acknowledging the already handled request.
This re-read should be happening in the mrfioc2 driver.
https://github.com/epics-modules/mrfioc2/blob/a8cb48d549b7aae13206cf2d168c6f1cfec2e1c4/evrMrmApp/src/drvem.cpp#L1215
The RTEMS VME bridge driver does an extra read, with the same goal.
I have no idea if the vxworks bridge driver does anything similar.
https://github.com/RTEMS/rtems/blob/05461aa47519c51d3ac5e73337ebeaf395b17589/bsps/powerpc/shared/vme/vmeTsi148.c#L1496-L1503
It is also worth noting that while I was at NSLS2, I would see occasional "spurious
interrupt on vector 0xff" messages indicating that an interrupt line was being pulled
down for too long. (I could see this with an analyzer as well) I suspected, but
was never certain, that this was an electrical issue (eg. extra capacitance), with no
firmware or software workaround.
Anyway, using a VME bus analyzer is the way to go. I'm wondering how the bus arbitration can affect this.
I'll second this. Although it can still be difficult to know which card is pulling
down one of the shared bus lines. (maybe add a per-card bus error counter register?)
While the mrfioc2 driver was being developed and tested, I often left a vmetro analyzer
set to trigger on bus error. Circa 2013 the only bus errors I saw were during the
occasional spurious IACK cycles.
Thanks,
Jukka
On 10/5/22 2:02 PM, Heinz Junkes via Tech-talk wrote:
I'm getting a little puzzled now.
I had similar problems with the interrupt vector on the VMEBus with the VMEbus board from Struck (SIS3316).
I could prove with a VMEbus bus analyzer (VMEtro) that Struck does not leave the vector on the bus long enough.
This was then fixed by Struck by adapting their VME-FPGA programming.
If I understood correctly, they use a Xilinx Spartan 6 FPGA for the VMEbus control.
With faulty register reading I had the same assumption that the timing of the FPGA is not kept
properly (this could have something to do with the clock frequency of the FPGA).
But here we didn't really come to a solution and to be able to put the system into use I found by chance
the the 2 CPU solution and use it since then.
Do the EVM and EVR boards also use FPGA's for the VMEbus?
Heinz
On 5. Oct 2022, at 04:38, Hong, Ran <rhong at anl.gov> wrote:
Dear Heinz,
I tried the 2-CPU scheme and it seems working. I have mvme3100 as the arbiter and mvme2500 as the CPU for the IOC. I will investigate a few other places of the code and see if this problem goes away. Particularly, I will check the ISR function. I had interrupt problems before. If I had more than 1 EVR in the crate, it had interrupt errors. I solved this problem by adding a read-back in the ISR function, but I had no idea why that could work.
Ran Hong
From: Heinz Junkes <junkes at fhi-berlin.mpg.de>
Sent: Tuesday, October 4, 2022 6:34 AM
To: Hong, Ran <rhong at anl.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Read and Write errors with VME-EVR-300
Hello Ran Hong,
I have similar problems in a constellation with MVME6100 and STRUCK SIS3316.
I could solve the problem ( not elegant ) by using another (old) CPU as VME arbiter in slot 1
and disabling the arbiter on the MVME6100 and plugging the CPU into slot 2.
Heinz
On 4. Oct 2022, at 02:29, Hong, Ran via Tech-talk <tech-talk at aps.anl.gov> wrote:
Hello All,
I am testing a VME IOC with 1 VME-EVM-300 and 6 VME-EVR-300 boards. The CPU board is mvme-3100, and the driver is derived from mrfioc2:
https://github.com/epics-modules/mrfioc2
I experienced many errors like missing time stamp, incorrect GTX waveform, and so on. They all stem from issues when reading from or writing to VME registries using READ32 or WRITE32 in the driver. For example, in evrMrmApp/src/drvem.cpp line 803 to 806 for latching the timestamp,
epicsUInt32
ctrl=
READ32
(base,
Control);
//
Latch timestamp
WRITE32
(base,
Control, ctrl|Control_tsltch);
It reads the control registry, modify the bit for timestamp latch, and write it back to the control registry. Occasionally, I saw the READ32 returns 0xffffffff, which is an invalid value for the control registry, and the subsequent WRITE32 results in a mess in the EVR.
Has anyone experienced similar issues? Any suggestions to prevent or mitigate the VME I/O errors?
Thanks!
Ran Hong
- References:
- Read and Write errors with VME-EVR-300 Hong, Ran via Tech-talk
- Re: Read and Write errors with VME-EVR-300 Heinz Junkes via Tech-talk
- Re: Read and Write errors with VME-EVR-300 Hong, Ran via Tech-talk
- Re: Read and Write errors with VME-EVR-300 Heinz Junkes via Tech-talk
- Re: Read and Write errors with VME-EVR-300 Jukka Pietarinen via Tech-talk
- Navigate by Date:
- Prev:
Re: Read and Write errors with VME-EVR-300 Michael Davidsaver via Tech-talk
- Next:
Re: Read and Write errors with VME-EVR-300 Andrew Johnson via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
<2022>
2023
2024
- Navigate by Thread:
- Prev:
Re: Read and Write errors with VME-EVR-300 Jukka Pietarinen via Tech-talk
- Next:
Re: Read and Write errors with VME-EVR-300 Wang, Lin via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
<2022>
2023
2024
|