Since you are reading 'F's, you are reading from non-existent memory, aka, I/O space, so here are a few ideas.
1) is the BAR a 64-bit BAR and you are only using the bottom 32-bits of the address? Not really likely, since most will only use a 32-bit address, even if the BAR is marked 64-bit.
2) check the hardware specs for the device. Some devices use a device specific mechanism to enable its function. For example, there might be a bit in the PCI config space that you must set. This bit will be in a device-specific byte offset within the PCI Config Space.
3) (You already checked?) Make sure the Mem I/O Enable bit is set in the PCI Config register.
4) check your memory read code. If the register is 32-bit read only, yet your compiler is optimizing it byte reads, the hardware might return 'F's. For example:
Code:
// the following line is coded so that you read a dword and mask off the byte
byte_val = bar->dword_sized_register & 0xFF; // mov eax,[address] mov [byte_val],al
// however, compilers will optimize the mask to read only a byte from the address
byte_val = bar->byte_sized_register; // mov al,[address] mov [byte_val],al
If I was to guess, I would think that 2) above is the culprit. I have seen this on about 3 or 4 machines when I was doing my R & R (not specific only to USB either).
Ben
-
http://www.fysnet.net/the_universal_serial_bus.htm