macOS: "select device" dialog stays forever on first launch: "upload in progress"

[richardklingler]

Launching OpenHantek on macOS 10.12.6 from shell shows:

stop CPU
... WROTE: 792 bytes, 10 segments, avg 79
reset CPU
2nd stage: write external memory
stop CPU
2nd stage: write on-chip memory
... WROTE: 5092 bytes, 68 segments, avg 74
reset CPU

But dialog stays forever with the message "Upload in progress"...
Quitting the application and relaunching the dialog tells that the device is ready to use...

Un-/replugging the device causes it to fail again...

No crash after first launch, only when device is used...

[davidgraeff]

macos seems to have issues with the libusb library, especially the libusb_release_interface call. Is it possible to update to a newer libusb version?

[richardklingler]

brew on macOS has already installed latest version:

OSX86:~ me$ brew upgrade libusb
Error: libusb 1.0.21 already installed

[TjardF]

if got exatly the same problem,
my specs: 10.13.1 & Hantek 6022be....

[JackHunt]

I also have this problem on Windows 10.

[nosolobots]

Same problem on Kubuntu 16.04 and Hantek 6022BE... Any idea?

[osmanypereira]

Please double check what the Hantek 6022BE is reporting as vendor ID. In my case the problem was that the Hantek changed the vendor id unexpectedly from "VID_04B5" to "VID_04B4". Don't ask me how, it does not make sense for me either, but correcting it in the libusb_device_inf and reinstalling the driver made it to load again. Weird!

[davidgraeff]

The device changes it usb vid and pid as soon as the firmware is uploaded. A windows driver need to cover both pairs, indeed.

[jon-daemon]

Please double check what the Hantek 6022BE is reporting as vendor ID. In my case the problem was that the Hantek changed the vendor id unexpectedly from "VID_04B5" to "VID_04B4". Don't ask me how, it does not make sense for me either, but correcting it in the libusb_device_inf and reinstalling the driver made it to load again. Weird!

I got the same issue. Could you give a little more info on fixing it? Thank you

[mwcarlis]

Update/Edit: It doesn't work on my USB3 ports, but it works fine on my USB2.0 ports. FWIW.

I appear to be having the same issue on Ubuntu Linux.. I don't see a Make target for a debug build, anyone know how to get a debug build? I tried running gdb on the binary, but it goes async after the process spawns 5 threads.

Linux Z97X-UD5H 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

// Without Hantek Scope connected to USB.
~/open_hantek/OpenHantek-openhantek-5954747/build/openhantek->lsusb
Bus 002 Device 002: ID 8087:8001 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8009 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 045b:0210 Hitachi, Ltd
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 1038:160c SteelSeries ApS
Bus 003 Device 002: ID 045b:0209 Hitachi, Ltd
Bus 003 Device 005: ID 046d:c24e Logitech, Inc. G500s Laser Gaming Mouse
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
~/open_hantek/OpenHantek-openhantek-5954747/build/openhantek->lsusb | wc -l
10

// With Hantek connected to USB.
~/open_hantek/OpenHantek-openhantek-5954747/build/openhantek->lsusb | wc -l
11
~/open_hantek/OpenHantek-openhantek-5954747/build/openhantek->lsusb
Bus 002 Device 002: ID 8087:8001 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8009 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 045b:0210 Hitachi, Ltd
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 007: ID 04b4:6022 Cypress Semiconductor Corp. // This is the Hantek. 04b4? Need to update source.
Bus 003 Device 004: ID 1038:160c SteelSeries ApS
Bus 003 Device 002: ID 045b:0209 Hitachi, Ltd
Bus 003 Device 005: ID 046d:c24e Logitech, Inc. G500s Laser Gaming Mouse
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[ABonner]

For Mac users: In case it isn't clear from the initial description, at least for me, if you run OpenHantek one time, let the upload complete, then click "Close" button on the dialog, THEN run OpenHantek again without unplugging the device, it will work the second time.

[fredericgermain]

Quick note on Linux :

• Don't forget to install the /lib/udev/rules.d/60-hantek.rules file
• Maybe run "sudo udevadm control -R"
• Replug your device

For cmake projects, having a debug build is usually done with : "cmake -DCMAKE_BUILD_TYPE=Debug .."

[oz-matt]

Still having this issue on Windows :[ Anyone know of a fix?

[yurivict]

I have the same issue on FreeBSD.
What is it uploading?

[Ho-Ro]

Let me explain in short what happens (at least with Hantek 6022 and compatible devices):
This device is based on the Cypress EzUSB chip
The scope doesn't have a permanent storage for application program, so the firmware has to be loaded every time after power-on, read more about the EZ-USB FX1/FX2LP Boot Options.

After 1st power-on the devive is seen on USB as VID/PID 0x04B4/0x6022. If openhantek detects this devive it starts uploading the firmware file (typical an intel hex file that is included in the resources of the Linux/Windows/FreeBSD/MacOSX binary, coming from there). After uploading the file a new USB enumeration takes place automatically - the device 04B4/6022 disconnects from bus and reconnects - now with VID/PID 0x04B5/0x6022 (this VID/PID comes from the firmware). Until this point everything works fine.
Then openhantek searches for this new number and as soon it is found the uploading... message disappears. This is the normal behaviour.

BUT if there are some other devices on the same USB bus (the USB subsystem is structured in busses and ports as shown by lsusb; lsusb -t), this re-enumeration could be disturbed and the program doesn't find the device anymore (openhantek looks every second for the changed ID iirc, yes, I'm correct -> https://github.com/OpenHantek/openhantek/blob/master/openhantek/src/selectdevice/selectsupporteddevice.cpp).
If you close the window without unplugging the scope and restart openhantek it will start a new search and subsequently it finds the scope with the correct VID/PID 04B5/6022.

See also OpenHantek/OpenHantek6022#35
And now for something completely different: openhantek is unmaintained at the moment #277, but you could try my fork https://github.com/OpenHantek/OpenHantek6022.

HTH, Martin

[yurivict]

How long does such upload normally take?

vendor 0x04b4 product 0x6022 never disconnects, it just stays this way.

[ABonner]

For me at least, the upload takes about 2-3 seconds

[yurivict]

For me it never ends, device never switches to any other ID.
I guess I'll need to debug this further.

[Ho-Ro]

Have you also tried OpenHantek6022, which recently received support for FreeBSD?

[yurivict]

No luck with OpenHantek6022 for me, it behaves the same way.

[yurivict]

This line

int status = libusb_claim_interface(handle, 0);

fails but the error message is never printed: libusb_claim_interface() failed: LIBUSB_ERROR_OTHER

So the error triggered in UploadFirmware::startUpload is never reported to the user, and never terminates the "waiting for upload" state.

Additionally, libusb_set_auto_detach_kernel_driver(handle, 1); is executed without checking the return code.

These are for the OpenHantek6022 project.

[Ho-Ro]

Thx für reporting, I will check the code flow.

[yurivict]

With the line libusb_set_auto_detach_kernel_driver(handle, 1); libusb_claim_interface(handle, 0); fails.

Removing the line libusb_set_auto_detach_kernel_driver(handle, 1); allows it to work.

I'll update the port with a patch for this.

[Ho-Ro]

I moved the issue tracking into "my" domain, #35.