Experimental Physics and
Industrial Control System

Kate Feng <[email protected]> · Thu, 24 Aug 2006 13:16:01 -0400

Andrew Johnson wrote:
Kate Feng wrote:

Discovery deos not have the necessary capability or connections to
the MCP. I was told that

on the boards which use a Discovery system controller, the MCP signal
is connected to a

pull-up and therefore not used as it is on other boards. That's the
design on the

MVME5500 and MVME6100 boards. I do not see it as a big problem for the

MVME5500 board because ......
Till Straumann wrote :
(currently, a PCI error such as target abort is routed to the one
and only EE interrupt of the powerpc).

The MCP, if available, is routed to the EE interrupt as well.

I personally would see it as a problem, because the EE interrupt is
maskable. It's not trivial to write an exception handler that can
nest properly such that if an interrupt service routine receives a
Target- Abort from a PCI device it will immediately halt and abort the
ISR rather than continuing on to completion and only then running the
Target-Abort interrupt handler. If all you have is an interrupt, your
ISRs probably ought to check with the Tempe chip that they're not
getting VME bus errors before relying on the data they've just read
(at least if the value they read back was all-1s).

Yes, that is why, as what I stated in the previous E-mail,  I do'nt worry
about the MVME5500 application because it utilizes the Universe chip instead
of the Tempe chip. I was concerned about the application which relies on the
Tempe chip of the MVME6100.  At this point, our application will only need
the PCI bus via the PMCs.

For the MVME6100, I am more concerned with the

"making use of the dud all-1's read data in the process"

that Andrew mentioned earlier. I do'nt seem to get the answer from the

http://www.aps.anl.gov/epics/tech-talk/2006/msg00892.php, which was
posted by Till.

Is it in the "vmeTsi148ClearVMEBusErrors(&erraddr);" ? How is it
programmed?

I'm not sure I understand your question. The "all-1s read data" I was
talking about is the data that is returned if you do a programmed read
cycle to the VMEbus that ends in a Bus Error.

This read cycle could happen before the ISR and accidentally update

a value. What I meant is that "Can the bus error handler detect that

and reverse the update?" I guess it does not matter because the wrongly

updated value will not get updated to the EPICS save/restore since

the interrupt latency is probably so fast that the operation would have
to be

shut down. 
If the Bus Error occurs during a DMA operation using one of the DMA
controllers in the Tempe chip then the DMA will be stopped immediately
instead, since the controller is inside the Tempe and can see the Bus
Error status.

Do you mean the Tempe chip has its own DMA?
I do'nt have any datasheet regarding the Tempe chip.
Regards,
Kate

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System