Experimental Physics and
| |||||||||||||||||
|
I was on vacation last week but I'd like to wrap this thread up with the comment that regarding bus errors, the MVME5500 and the MVME6100 are not any different. AFAIK, none of those have the MCP interrupt to the CPU hooked up, so even if the Tsi148 would generate a PCI target- abort it would still not raise a machine-check interrupt. I don't have the programmer's manual for the Discovery-II (MV64360) chip so I don't know whether the Host Bridge has the necessary capability or connections. You probably know more about the hardware than I do, and if there's no connection from the Bridge to the MCP input I accept what you say; this only increases my dislike of the MVME 3100 and 6100 boards though. The earlier Motorola boards did provide the necessary support, even though their BSPs didn't use it. The Programmer's Reference Guide for the MVME2700 has the following information about the PCI Host Bridge in the Raven ASIC: Error Handling... Each MERST error bit may be programmed to generate a machine check and/or a standard interrupt. The error response is programmed through the MPC Error Enable Register on a source by source basis. When a machine check is enabled, either the MID field in the MPC Error Attribute Register or the DFLT bit in the MEREN Register determine the master to which the machine check is directed. For errors in which the master who originated the transaction can be determined, the MID field is used, provided the MID is%00 (processor 0), %01 (processor 1), or %10 (processor 2). For errors The wording for the equivalent section about the Hawk ASIC in the MVME5100 Programmer's Reference Guide is almost identical. For the MVME2100 the Host Bridge is integrated onto the CPU, so the equivalent documentation is found in the MPC8240 User's Manual: 13.3.3.4 Received PCI Target-Abort Error If a PCI transaction initiated by the MPC8240 is terminated by target-abort, the received target-abort ïag (bit 12) of the PCI status register is set. If ErrEnR2[1] and PICR1[MCP_EN] are both set and the MPC8240 receives a target-abort, the MPC8240 reports the error to the processor core by asserting mcp (provided PICR1[MCP_EN] is set). Note that any data transferred in a target-abort transaction may be corrupt. Till Straumann wrote: OTOH, a VME bus error on read can be reported simply by using the respective interrupt (as demonstrated earlier). I will be implementing that in my version of the mv6100 BSP (but as demonstrated earlier though, this is of little use if the Bus Error occurs inside an ISR. I know about one device that will perform 97 bus accesses inside its ISR if it gets all-1s from its read cycles. Each access would take a VME bus timeout (2048us by default) to execute, thus interrupts would be locked out for almost 0.2 seconds while this ISR runs.) PS: does vxWorks raise a machine check on the 5500 as a result of a bus error??? I don't have a 5500, so I don't know; from what Kate says though it can't, and in any case I very much doubt if the standard vxWorks BSP would configure it that way even if the hardware could. - Andrew -- There is considerable overlap between the intelligence of the smartest bears and the dumbest tourists. -- Yosemite National Park Ranger
| ||||||||||||||||
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |