GPIB-USB_HS forgetting its hardware ID

[david_c_partridge]

My GPIB-USB-HS has not been used in the last few months.

Now when I connect it to the computer it is installed as an "Unknown Device".  Windows Device Manager says the device ID is USB\VID_04B4&PID_8613 which is the default ID for the Cypress USB chip:

USB Boot Methods
During the power-up sequence, internal logic checks the I2C port
for the connection of an EEPROM whose first byte is either 0xC0
or 0xC2. If found, it uses the VID/PID/DID values in the EEPROM
in place of the internally stored values (0xC0), or it boot-loads the
EEPROM contents into internal RAM (0xC2). If no EEPROM is
detected, FX2LP enumerates using internally stored descriptors.
The default ID values for FX2LP are VID/PID/DID (0x04B4,
0x8613, 0xAxxx where xxx = Chip revision).

So I2C communication to the device (EEPROM (?)) with the correct USB device ID would appear to have failed.

Does anyone know which component holds that information?  Does that come from the custom NI BGA device (U2)?? Or is there an EEPROM on the board that I've missed?

[NPowl]

Hey David,

Do you have the NI-488.2 driver (full version, not just run-time) installed correctly?

Are you able to manually assign the driver in Device Manager?

Is the NI GPIB Enumeration Service running in Windows?

Cheers,

Nick

[david_c_partridge]

Yes I have the complete NI 488.2 package installed. Yes the enumeration service is running.

Manually assign a driver ? Do you mean choose a .inf file to install - if so, you can't do that for the Cypress default hardware ID, as no-one should EVER release a driver with that ID ...

The EEPROM is U1 on the PCB is a 24LC256, and the Cypress USB IC is talking to it now that I have installed a jumper wire between the Cypress IC SDA pin and pin 5 of the EEPROM (there was an open circuit between the SDA pin on the Cypresss IC and the EEPROM pin 5).  Unfortunately that didn't fix the problem so I'm waiting for a TQFP to DIP adapter to arrive so I can read the EEPROM (my 'scope doesn't decode I2C).  I suspect that is the problem rather than the CY7C68013A.

[NPowl]

Hi David,

Thanks - apologies for making you repeat yourself on that front.

If the EEPROM isn't able to be read, then I expect the easiest route would be to repair/replace the GPIB-USB-HS as it would seem the memory is damaged (or otherwise unreadable).

If you contact NI here for a repair case, the procedures can be followed.

Cheers,

Nick

[david_c_partridge]

I can't do that as I don't have a support contract,  and the odds are that the repair cost would be more than I paid for the adapter (about USD120), so I'm going to have to repair it myself (if possible).

D.

[david_c_partridge]

Very odd! I finally received my TSSOP to DIP adapter and read the eprom (and verified it against what I'd just read from it).

The first eight bytes go 45 83 70 f9 22 90 e6 82 and the checksum is 003D41E8

So I'm not surprised that the hardware ID has been set to the default.

Has anyone ever read the EPROM from a known working GPIB-USB-HS, or is prepared to open up their adapter and read the EPROM, or indeed have a known correct image?

If so I'd be most interested to know what it contains !

Thanks
David

[david_c_partridge · Accepted solution]

A very helpful user of eevblog forums read the EEPROM from a known working GPIB-USB-HS:

https://www.eevblog.com/forum/testgear/ni-gpib-usb-hs-265350/

which I used to re-programme mine.

All now working as it should.

David