#27 Problem in bringing up NI GPIB_USB_H+adapator in raspberrypi 3 model b+

[Athira]

HI

I am trying to install linux_gpib driver(latest driver 4.3) into raspberrypi 3 model b+ (raspbian).
installion seems to be successfull (checks were done with lsmod). But on giving gpib_config the following error appears:
failed to bring board online
failed to configure board
main: No such device

Iam using NI GPIB_USB_HS+ adaptor .
Are there any work arounds possible ?

Best reagrds,
Athira

[Frank Mori Hess]

Oh, that's interesting. I guess we are done then. It looks like the
NI windows driver permanently saved the firmware into the adapter's
EEPROM.

On Thu, Apr 16, 2020 at 5:06 AM Athira athi@users.sourceforge.net wrote:

Hello Frank

The lsusb -v gives the following :

Bus 001 Device 004: ID 3923:7618 National Instruments Corp.

the device id is changed to 7618.And theadaptor seems to be working with linux even after power on and off.

[Athira]

well then would it be not possible to connect the device to linux for first time ?

[Athira]

Hi frank

I connected a newHS+ device first time to windows and have capturedthe following attached. We can see here that device id changes fro 761e to 7618.

[Frank Mori Hess]

Ah thanks. This looks good, it appears to have the firmware upload. I'll let you know when I have something you can test.

[Frank Mori Hess]

Hmm this is not the usual ezusb initialization. It looks straightforward though, I could probably write a little C program and libusb to do the firmware load. What I see in the capture is:

packets 23 and 24:
control read with bRequest 144
response: 0x7618 (little endian) which is the product id the HS+ will have post initialization

packets 25 and 26:
control write with bRequest 145, data is a 4 byte integer which gives the number of 1st stage data bytes which will follow (0x5ea6 or 24230 decimal)

packets 27 to 38:
control writes with bRequest 146 containing the 24230 1st stage data bytes in 4096 byte chunks maximum

packets 39 and 40:
control read with bRequest 147. Reads back zero, so maybe checking for an error?

packets 41 and 42:
control write with bRequest 148 and wValue 0x100. Not sure what this does.

packets 43 and 44:
bulk read of 4 bytes with value 0xc0. Not sure what this means.

packets 45 and 46:
control write with bRequest 160 of 4 bytes with value 0xde12 (56850 decimal). This is the number of 2nd stage data bytes which will follow over the bulk endpoint.

packets 47 and 48:
bulk read of 4 bytes with value 0x2. Not sure what this means.

packets 49 to 52:
bulk writes of 2nd stage firmware data in chunks of maximum size 32768.

packets 53 and 54:
bulk read of 4 bytes with value 0x1. Not sure what this means.

packets 55 and 56:
control write with bRequest 162. This completes the initialization and the adapter reenumerates as a functional HS+

[Frank Mori Hess]

Ok, I've finished my first attempt at a firmware loader for the hs+. Get it here:

https://github.com/fmhess/hsplus_load

if you try it, let me know how it goes.

[Athira]

also when connected to windows the hs+ showsamber light. But whenconnected to same raspberrypi(raspbian) it blinks between amber and green. Still the gpib_config command works andlooks like it is up. do you know if this is a matter of concern ?

[Frank Mori Hess]

All HS+ do that. It is because the Linux driver was updated to support the HS which doesn't have the analyzer. The HS+ is mostly compatible with the HS but there is some difference which affects the led state. Noone has ever bothered to look into it.