Ben,
_4FM_WriteRegister is writing to the BAR directly. _4FM_ReadRegister is reading from the BAR directly, this cannot fail. It is translated to writing to PCI addresses. Maybe you are using wrong addresses. I think the BAR is 64kB wide, and an address is word address (Register 0 is byte address 0 to 3, Register 1 is byte address 4 to 7, etc..). This cannot fail normally. Typically try to use _4FM_WriteRegister with an address of 0 and value of 1, this is what _4FM_Reset does, writing a '1' at address 0, which is the 4 first bytes of the BAR.
The debug version of the API will not help you; there is a simple IOCTL call we use for years already, this is sent to a device driver which is in charge of sending that to the correct hardware address.
Here is the source code for the read register function:
_4FM_error_t _4FM_CALL _4FM_ReadRegister(_4FM_DeviceContext *ctx, unsigned regno, unsigned int *value)
{
if (!ctx)
return FDSP_ERROR1(ERR_NO_CTX, MSG_NO_CTX);
if (_4FM_IoCtl_WrRd(ctx, IOCTL_4FM_RD_REG, ®no, sizeof(regno), value, sizeof *value))
return FDSP_ERROR1(ERR_IO_FAIL, MSG_IO_FAIL);
return FDSP_OK;
}
Here the most relevant IOCTL code from the device driver, besides deep system calls, this is the place that could fail if the address is bigger than 16k (16k * 4 = 64k). It is pretty weird, the same code is there on the Write side. Note that this code translates to a READ_REGISTER_ULONG() call to the address of bar+addr*4.
if( RegNo * sizeof(ULONG) >= 64*1024 ) {
status = STATUS_INVALID_PARAMETER;
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP,
"Register not withing current BAR: %lu", RegNo);
break;
Is this happening with a the PC720 firmware when recompiled and not modified? We have 10 engineers working on PC720 and they all been doing release based on our PC720 host interface. It sounds like you did not reuse our material as-is but you are modifying/rewriting instead.
Also keep in mind updating PC720 FPGA when Windows is running require to reboot Windows as the PCI engine is in the FPGA. Typically Windows still knows/found the device so you could be communicating with a ghost. This is easily spotted out, reading from any address of the BAR will return -1 (0xFFFFFFFF) in this case. PCI tree is perfectly able to read/write from any PCI devices in the system.
As explained, first four bytes of the BAR is the reset register, write a '1' and see if you get any LED activity or triggers in your design. Then try to read some known addresses. Address 0x11 and 0x12 should return so diagnostics information. If you extended the BAR space and try to read/write above 64kB, then you know the driver will not allow you to do that. Once again PCITree is handy here for these simple read/write to BAR. There is also a commercial solution, called windriver from jungo, there are evaluation version available, it will allow you to code your own API wrapping around a generic PCI driver.
Best Regards,
Arnaud
[/code]