Prev: obtain list of hardrive guid's
Next: Do WIA scan without calling IWiaDevMgr->DeviceDlg()
From: Jeff on 10 Feb 2010 10:52
Thanks to help that I got from a previous post, I was able to get my driver
rebuilt and going again. I am very much appreciative. Here is a tricky
question that I may not fully grasp yet:

My driver is for a PCI card. Hence the address space is 32 bits. The
memory on my card is 16 bits. So there is some mapping that occurs. Now, I
did a little calculation already that tells me that byte 4 in PCI space is
byte 2 in my card's memory, byte 6 is byte 3, etc. That works fine enough so
that when my Windows application writes to byte x, the write goes to byte
x/2. No problem there. I can live with that. I am doing my writes with a
macro called WRITE_REGISTER_UCHAR. I give it a byte to write, but what
happens is that the write affects the adjacent byte as well! So if I write
to address 0x100, for instance, the correct value (the one I pass in as
parameter to WRITE_REGISTER_UCHAR) gets written to 0x100, but then something
else gets written to 0x101! Most of the time, it is 0x00 that gets written
to the adjacent byte, but sometimes it is a random byte.

Where should I look to alleviate this?
From: Maxim S. Shatskih on 10 Feb 2010 11:30
> My driver is for a PCI card. Hence the address space is 32 bits. The
> memory on my card is 16 bits. So there is some mapping that occurs. Now, I
> did a little calculation already that tells me that byte 4 in PCI space is
> byte 2 in my card's memory, byte 6 is byte 3, etc.

This does not seem to conform to PCI spec.

No wonder you have electrical issues writing single bytes.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

From: eagersh on 11 Feb 2010 17:48
On Feb 10, 8:52 am, Jeff <J...(a)discussions.microsoft.com> wrote:
> Thanks to help that I got from a previous post, I was able to get my driver
> rebuilt and going again.  I am very much appreciative.  Here is a tricky
> question that I may not fully grasp yet:
>
> My driver is for a PCI card.  Hence the address space is 32 bits.  The
> memory on my card is 16 bits.  So there is some mapping that occurs.  Now, I
> did a little calculation already that tells me that byte 4 in PCI space is
> byte 2 in my card's memory, byte 6 is byte 3, etc.  That works fine enough so
> that when my Windows application writes to byte x, the write goes to byte
> x/2.  No problem there.  I can live with that.  I am doing my writes with a
> macro called WRITE_REGISTER_UCHAR.  I give it a byte to write, but what
> happens is that the write affects the adjacent byte as well!  So if I write
> to address 0x100, for instance, the correct value (the one I pass in as
> parameter to WRITE_REGISTER_UCHAR) gets written to 0x100, but then something
> else gets written to 0x101!  Most of the time, it is 0x00 that gets written
> to the adjacent byte, but sometimes it is a random byte.
>
> Where should I look to alleviate this?


Run PCI bus analyzer to see transactions on a bus. And if everything
is OK, as you expect, show a result to a hardware team to fix a bug.

Igor Sharovar
 | 
Pages: 1
Prev: obtain list of hardrive guid's
Next: Do WIA scan without calling IWiaDevMgr->DeviceDlg()