|
The attached screen shot may be easier
to follow.
Ron
On 11/6/2014 2:05 PM, Ron Sluiter wrote:
FYI,
After several months of investigating various and intermittent
problems here at the APS, I have finally determined that the root
cause of these problems is the Delta Tau Turbo PMAC2 VME
Ultralight's VMEbus interface. A Turbo PMAC2 VME Ultralight,
whose DPRAM is configured for A24, will respond to a A32 write
cycle if it is preceded by a A24 write cycle to the PMAC's DPRAM
and the A32 write cycle has the same lower 24 address bits as the
A24 write (confusing, I know. See the five VMEbus transaction
steps below).
I have a test program that I use to drive VMEbus data collection
on a VMETRO VMEbus analyzer. The test program is NOT definitive;
it is sensitive to both compiler optimization (only works without
optimization) and out-of-order bus transactions; but the VMETRO
data IS definitive.
The order of bus transactions to create a failure is;
- A24@0x70 0674 write 0x1000 to PMAC DPRAM
- A24@0x70 0674 read 0x1000 from PMAC DPRAM (this step is to
confirm the previous write, not really a required bus
transaction)
- A24@0x70 0EA0 write 0x4000 to PMAC DPRAM
- A32@0xA070 0674 write 0x8000 to Hytec DAC8402 DPRAM, or MAXv
DPRAM, or no DPRAM (the problem occurs even if this bus
transaction results in a VMEbus BERR)
- A24@0x70 0674 read 0x8000 from PMAC DPRAM (this step
confirms that step #4 resulted in a write to the PMAC's DPRAM)
Steps #3 and #4 are key.
The same problem occurs if the PMAC is configured for A32 and step
#4 is a write to the A24 address space.
I was in contact with Delta Tau on this problem. They informed me
that "this is a product that will soon be placed on legacy status"
and there is no plan for a fix. The work-a-round is to make sure
that the low order 24 bits of the PMAC-VME DPRAM and mailbox
address spaces are unique in both the A32 and the A24 VMEbus
address spaces.
Ron
|
