27 Feb
2014
27 Feb
'14
10:32 p.m.
David Gesswein wrote:
>
> Using FUTIL, I can read in a block, change any but the first word in
> the block, and write it out, then read it back, and it's fine. I
can
> do this with words 1 through 255 of any of the
blocks on the disk.
> However, if I read in a block, change the first word (word 0) of the
> block, and write it out, then read it back, the first word is as I
set
it to be --
but, if I read any other block, the first word is always
the same as what I wrote out.
Is this likely because the write and read buffer is the same memory when you do a read the first word is not being
modified so is the last
written
word? If you know where the buffer is change the first
word before the
read
and see if it gets modified.
What I do with FUTIL is read in a block, which reads into a buffer. I
then can change word 0 of the buffer, and issue a write command to write
the buffer out.
Then I issue another read command on the same block, and the change
shows up. I then do read commands on other disk sectors, and the change
I made to word 0 shows up in all of the other reads that I do.
I'll have to dig through the FUTIL source and find where the buffer is,
and try the trick you mention and see what happens.
> Does anyone out there have any ideas what I could do to track this
> down further? The RK8E is the only data break device I have in the
> system, everything else uses programmed data transfers, so I can't
try
> with another data break device and see if the
behavior is
consistent.
work that may be easiest to start with. Looking at the
control signals
you
should be able to tell if the dma write doesn't
happen or what goes
wrong.
I have a good four channel (analog, classic Tektronix) oscilloscope, and
a Tektronix 1240 Logic Analyzer loaded up with acquisition channels.
I have scoped the break request that is asserted by the peripheral
device when it requests a data break, and it definitely does twitch even
on the single word transfer.
So, I know the RK8E is generating the request for a data break cycle.
It's somewhere after that that the problem occurs.
I guess I'll have to tack wires to points on the RK8E to bring out the
relevant signals to a header that I can then connect the logic analyzer
up to so I can grab captures as I run a simple one-word DMA using the
maintenance mode instructions in the RK8E. The existence of the top
connectors on the RK8E makes direct probing of anything on the boards
somewhat difficult (e.g., almost impossible). I really hate soldering
little tails onto the boards, but I think that it's the only way I'm
going to be able to get to all of the signals of interest.
I'll see what I can get done over the coming weekend, and post anything
interesting that I find.
Thanks,
-Rick Bensene