Driver Development Kit (DDK)

cancel
Showing results for 
Search instead for 
Did you mean: 

Accessing registers on a PCI board

Here is the situation:
I have a PCI board I use as a platform to train in NT driver development.  The board uses 3 resources:
1. IRQ;
2. Memory     (Mem0 - contains 32-bit control registers )
3. Memory     (Mem1 - contains data registers    )
All the resources are processed smoothly in my StartDevice function (below are debug messages from my AddDevice 😞
MC431PCI - PNP Request (IRP_MN_START_DEVICE)
MC431PCI - Resources:
    type CmResourceTypeMemory start        03FDFFF00 length 100
    type CmResourceTypeMemory start        03FE00000 length 200000
    type CmResourceTypeInterrupt  level 16, vector 16, affinity FFFFFFFF
MC431PCI - Translated Resources:
    type CmResourceTypeMemory start        03FDFFF00 length 100
    type CmResourceTypeMemory start        03FE00000 length 200000
    type CmResourceTypeInterrupt  level 8, vector 194, affinity 3
MC431PCI - Found control memory block. Physical base address - 3FDFFF00, length - 255
MC431PCI - Found data memory block. Physical base address - 3FE00000, length - 2097152
MC431PCI - Got Interrupt Resource 2
MC431PCI - Mapping control memory  ...
MC431PCI - Control memory virtual base address F7CD9F00
MC431PCI - Mapping data memory  ...
MC431PCI - Data memory virtual base address  A9687000

After that I probe my control registers (which called RUK#) using READ_REGISTER_ULONG():
MC431PCI Reading ruk0: 0h
MC431PCI Reading ruk1: 0h
MC431PCI Reading ruk2: 0h
MC431PCI Reading ruk3: 1h
MC431PCI Reading ruk4: 0h
MC431PCI Reading ruk5: 0h
MC431PCI Reading ruk6: 0h
MC431PCI Reading ruk7: 0h
MC431PCI Reading ruk9: 12000012h
MC431PCI Reading ruk10: 0h
MC431PCI Reading ruk11: 0h
MC431PCI Reading ruk12: 0h
MC431PCI Reading ruk13: 0h
As we can see they are all read ok.
Bit 15 of RUK2 controls onboard LED. So just to make sure everything's ok I set bit 15 high, writing 0x8000 to RUK2 and my LED goes bright red.
MC431PCI Reading ruk2: 0x8000h.
After that I leave my HandleStartDevice routine feeling absolutely confident my board is ready to accept control codes and actually execute them. Device manager shows the board just the way i described it in the inf file and resources pane shows the resources settings correct.
I connect to my device via CreateFile and then use DeviceIoControl to send the control code to turn off the LED (remember it's still on). The code which I believed should be written was:
WRITE_REGISTER_ULONG((PULONG) (pdx->membase0 + p->RUK), p->buffer);, where p is a pointer to my PARAMS structure that arrived with the IRP. It simply contains address and data;

Here is what my DispatchControl says to me:
....
MC431PCI - DATA TO BE WRITTEN: 0h
MC431PCI - ADDR TO BE WRITTEN TO: 8h
MC431PCI - WRITING 0h TO RUK2 ....
MC431PCI - SEE WHAT'S IN RUK2: FFFFFFFFh
.....
Well as we can guess the LED is still on and I end up being unable to write nor can i read from my device.
So the question is why once I leave HandleStartDevice routine I lose contact with the PCI board.  I can no longer read or write. I even tried to address my register directly avoiding HAL :
first writing into RUK2 still hoping to turn off that LED:
*((PULONG)(pdx->membase0+RUK2)) = 0x00;
and then reading from it
*((PULONG) (pdx->membase0+RUK2)).
The result is still FFFFFFFFh . I of course can turn it off while still in HandleStartDevice.
Any idea where to look? What happens once HandleStartDevice returns?
0 Kudos
Message 1 of 2
(7,125 Views)
What chip are you using on this PCI card? Is this an NI chip like the TNT chip?

-Matt S.

LabVIEW Integration Engineer with experience in LabVIEW Real-Time, LabVIEW FPGA, DAQ, Machine Vision, as well as C/C++. CLAD, working on CLD and CLA.
0 Kudos
Message 2 of 2
(7,106 Views)