Author Topic: NI GPIB-USB-HS (Read 5904 times)

perdrix · « **on:** January 01, 2021, 12:27:59 pm »

I have one of these that I bought from a UK seller on eBay on 4th April 2020. It worked well at that time.

Since then I've not had the need to use it until yesterday (two Windows 10 version updates later).

So I connected it to the lappie and got "Unknown Device" ready for use! Say what? Device Manager says the device ID is USB\VID_04B4&PID_8613 which I believe to the Cypress USB 2 development kit ID which would never be used in the wild.

Has anyone got any idea what's going on here?

m k · « **Reply #1 on:** January 01, 2021, 06:19:42 pm »

My guess is that Windows has decided that you need some new drivers and have messed the USB stack.

gslick · « **Reply #2 on:** January 01, 2021, 07:45:00 pm »

Maybe the serial EEPROM has become corrupted.

CY7C68013A/CY7C68014A/CY7C68015A/CY7C68016A
EZ-USB® FX2LP™ USB Microcontroller High-Speed USB Peripheral Controller
https://www.cypress.com/file/138911/download

Code: [Select]

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).

Without taking a look at the EZ-USB FX2LP development tools I don't know if they provide tools to read the contents of serial EEPROM and reprogram it from the host PC. My guess is that such tools are provided. If the serial EEPROM contents have become corrupted you would need to find a copy of contents somewhere, maybe from someone else with a working device, and then maybe the device will magically work again when the serial EEPROM is reprogrammed.

DaJMasta · « **Reply #3 on:** January 01, 2021, 08:04:20 pm »

I believe the Cypress dev tools for these chips and earlier series are available, but in my limited experience I would suspect the EEPROM since it was IDing properly initially. I've worked on a unit with an EZ-USB controller, which I believe is the series before this one, that would revert to an "unprogrammed cypress ez-usb" identifier when the configuration EEPROM was removed.

KE5FX · « **Reply #4 on:** January 01, 2021, 08:35:02 pm »

Looks like either U7 or U9 has failed, as depicted in your photo. One of them will be a 24xCxx I2C PROM. You could double-check that by looking for I2C activity on pins 5 and 6 at plugin time. If there's no activity, the USB chip itself may have died. That would actually be preferable, since you could simply replace that chip.

perdrix · « **Reply #5 on:** January 02, 2021, 10:46:28 am »

Unfortunately U7 is a MAX604 regulator and U9 a C773I power supervisor. There's another 8 pin IC on the board:

which I've failed to ID so far. If its not that that has gone AWOL, then the EEPROM must be inside that large NI custom BGA IC

IF that IC is a I2C EEPROM AND it has a standard pinout (pin 5 SDA, pin 6 SCL), then the fault is simple: SDA (pin 30) on the CY7C68013A has no continuity to pin 5 of the EEPROM.

I *think* it is a Microchip 24LC256 Industrial Temp grade, May 2005 date code

I'd like to confirm what that IC is though before I just run a patch wire ...

So, is anyone able to confirm the identity of that IC?

Thanks
David

David

picburner · « **Reply #6 on:** January 02, 2021, 01:16:45 pm »

Yes, U1 is a 24LC256 eeprom produced by Microchip.
There is, however, an inconsistency with the case according to the datasheet.

perdrix · « **Reply #7 on:** January 02, 2021, 02:14:23 pm »

Look at page 12 not page 13. Good to have the confirmation...

Patch wire installed. But sad to say still reporting USB\VID_04B4&PID_8613

picburner · « **Reply #8 on:** January 02, 2021, 05:30:07 pm »

You should have this ID: usb\vid_3923&pid_709b (at least mine is this).

KE5FX · « **Reply #9 on:** January 02, 2021, 05:58:53 pm »

Interesting, never seen one of those PROMs in that form factor before.

What about activity on the SDA/SCL lines? Is it even trying to read it?

perdrix · « **Reply #10 on:** January 02, 2021, 09:13:03 pm »

Hi John,

Yes there's activity - at power on, SDA goes from 0V to 5V for a short time then a very short drop of 0V followed by 5V and then a burst of data and then sits at 5V.

SCL - oops my bad didn't check that.

My scope doesn't decode I2C so my guess is that either the EEPROM data is corrupt, or its OK and the Cypress USB IC is unwell.

The prospect of hand soldering a 128 pin TQFP is a touch scary!

Update: A quick skim of the manual for the development kit https://www.cypress.com/file/134666/download suggests to me that it will write the EEPROM but doesn't offer the ability to read it (if you know better please let me know). I've ordered a TSSOP to DIP adapter for my Rommer (from China) - when it arrives I'll remove the IC (U1) and read it ...

David

perdrix · « **Reply #11 on:** January 19, 2021, 11:28:12 am »

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 GPID-USB-HS, or is prepared to open up their adpater and read the EPROM?

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

Thanks
David

coromonadalix · « **Reply #12 on:** January 19, 2021, 03:29:23 pm »

looks like the cypress has been accessed and resetted in a way for the vid / pid ??

corruption ?

m k · « **Reply #13 on:** January 19, 2021, 07:12:16 pm »

Try educating Windows.

You have a suitable driver set but system is unaware of it.
Maybe it's just a standard port driver with a special filter driver.
If you try to update the current one with the real one manually, with some luck it's accepted.

Then you may be able to do something with the device anyhow.
At least you then know it's there.

TiN · « **Reply #14 on:** January 19, 2021, 11:38:54 pm »

Have one dead HS too, and one working HS here. Perhaps I'll give it a go. I barely used it as I prefer LAN-GPIB, but sometimes it's handy to have both interfaces..

TiN · « **Reply #15 on:** January 22, 2021, 05:21:05 am »

I think I made it worse

Before my bad dongle was at least detecting correctly, but could not operate.

I've desoldered and dumped I2C EEPROM contents (using TL866 and 24LC256 config).

Here's binary fw from bad dongle.

It looks like some data there is good. You can see National ascii text strings for example.

Then I read same I2C EEPROM from my good working dongle:

From good dongle.

Interesting enough PCB actually was little different on good one, using 24LC256 in SOIC8 package, not TSSOP.

I've wrote EEPROM in bad dongle with this good binary. Module detected in windows, but was blinking LEDs in various patterns. And attempt to use it failed.

Code: [Select]

root@raspb:/home/pi# gpib_config
failed to bring board online
failed to configure board
main: Operation not permitted

Then I wrote EEPROM back to what was in it before.

And now dongle does not detect correctly, but gets default Cypress "unknown device" crap.

Let's see if any other samaritan want to dump EEPROM from good dongle to check my images.

m k · « **Reply #16 on:** January 22, 2021, 09:05:47 am »

There seems to be only one difference, offset 0.
Bad is 00 and good is C2.

perdrix · « **Reply #17 on:** January 22, 2021, 11:36:15 am »

The one from the "good dongle" worked fine for me! Erased the IC, and programmed it with that file, soldered it back in and it all works!

Woohoo
Thank you TiN

coromonadalix · « **Reply #18 on:** January 22, 2021, 11:50:04 am »

@Tin do you have the Cypress utilities for the chipset, could it help to access the eeprom ?? and make a dump for it ?

TiN · « **Reply #19 on:** January 22, 2021, 02:07:48 pm »

Never used anything Cypress, so no, not familiar with their tools.

m k · « **Reply #20 on:** January 22, 2021, 02:53:59 pm »

There are 3 boot versions.

Offset 0 of ROM is C0 or C2, or all others.
C2 means that content of ROM is loaded to RAM and normal operation starts.
C0 means that only VID/PID/DID is loaded.
All others are for development only.

So if bad ROM offset 0 was 00 from the beginning and device was detected as configured device then something wasn't right somewhere else.

TiN · « **Reply #21 on:** March 30, 2021, 02:24:54 am »

A little follow up.

Fixed one of my bad dongles. It was dead SRAM chip, to my surprise

Updated my linux-gpib NI-USB-GPIB guide with info and details about it.

I still have another bad dongle with something loading down +3.3V rail. Might order new Cypress SOC and replace that, to see if it's dead uC. Expensive bugger

KE5FX · « **Reply #22 on:** March 30, 2021, 05:50:30 am »

Interesting, never seen one of those SRAMs fail before.

Do you have a thermal camera? Since you have a working dongle for comparison, you can probably tell at a glance what's consuming excess current.

max-bit · « **Reply #23 on:** August 31, 2021, 05:52:20 pm »

above
https://xdevs.com/doc/National/GPIB-USB-HS/fw/good_eeprom_24lc256.BIN
firmware is ... no orginal SN 014F3A71

max-bit · « **Reply #24 on:** September 02, 2021, 09:22:01 am »

f..ck ... programmed eeprom 24lc256 (from original unit) serial no. changed in NI MAX but software still sees it as not genuine? WTF?


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: NI GPIB-USB-HS (Read 5904 times)

Share me