Wrong ID 04b4:8613 won't communicate with OpenHantek, should be 04b4:602a

[ruckusman]

Spent the day chasing rabbits down the wrong holes trying to get the scope to communicate with OpenHantek - then I realised it was right in front of me

Bus 002 Device 032: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit

I've installed Hantek6022API but I'm having trouble making heads or tails of the upload_6022_firmware_from_hex.py command to load/flash the dso6022bl-firmware.hex but it doesn't give and output as to either error or success.

I've just checked some more and found I was using the wrong command

fx2upload -v /home/glennb/Downloads/Hantek6022API/Firmware/DSO6022BL/build/dso6022bl-firmware.hex 0x04b4 0x8613

That works perfectly to change the VID:PID - OpenHantek then loads, however on unplug/replug it resets to VID:0x04b4 PID:0x8613

I've found this thread

OpenHantek/OpenHantek6022#395

I'm sure I'm missing something simple, been doing that all day.

If anyone can point me in the correct direction I'd appreciate it

thanks

Glenn

[Ho-Ro]

Questions

Please describe your setup:
OS = ?
device = DSO6022BL(?)

Why does this device enumerate as a Cypress device instead of Hantek?

Did you modify the EEPROM content?

The Cypress ID is the default when there's no I2C EEPROM found or the EEPROM does not contain useful data in the first 8 bytes.
See section 3.2 of the EZ-USB® Technical Reference Manual.

Quick fix

You can try to upload the firmware, go to the directory examples and execute this python script (this does not store anything permanently, it only writes to the RAM of the scope).

#!/usr/bin/python3

import sys
from PyHT6022.LibUsbScope import Oscilloscope

firmware = "dso6022bl-firmware.hex"
VID=0x04b4
PID=0x8613

scope = Oscilloscope( VID, PID )
scope.setup()
if not scope.open_handle():
    sys.exit( -1 )
scope.flash_firmware_from_hex( firmware )
print( "FW version", hex( scope.get_fw_version() ) )
scope.close_handle()

If this works as expected you should save the EEPROM content with the script read_eeprom_256_byte.py.

Until now nothing was changed to your device

Danger Zone

You can flash the correct Hantek ID permanently into the scope's EEPROM with this script (provided the previously loaded firmware is still active, i.e. you did not unplug and replug the device, the red LED is still blinking, and you are still in the directory examples).

#!/usr/bin/python3

import sys
from PyHT6022.LibUsbScope import Oscilloscope

scope = Oscilloscope()
scope.setup()
if not scope.open_handle():
    sys.exit( -1 )

# read eeprom content from file
f = open( "eeprom_602a.dat", "rb" )
eeprom = f.read()
f.close()

# write_eeprom content
scope.write_eeprom( len( eeprom ), eeprom )
scope.close_handle()

HTH
Martin

[ruckusman]

Questions

Please describe your setup: OS = ? device = DSO6022BL(?)

Linux MX 23.2 - a fresh install on a MacBookPro 9,1 - it dual boots with Monterey

Yes, it's a DSO6022BL - fresh out of the box this morning from aliexpress, which is why I was looking in the wrong places all day...initially I was loading it up on Monterey and getting all sorts of problems related to security permissions, switched to MX to take the potential OS issues out of the loop

Why does this device enumerate as a Cypress device instead of Hantek?

That's what had me stumped - it was like that from the moment I first plugged it in.

Did you modify the EEPROM content?

Not until I posted this question

The Cypress ID is the default when there's no I2C EEPROM found or the EEPROM does not contain useful data in the first 8 bytes. See section 3.2 of the EZ-USB® Technical Reference Manual.

I'll read through some of that

Quick fix

You can try to upload the firmware, go to the directory examples and execute this python script (this does not store anything permanently, it only writes to the RAM of the scope).

#!/usr/bin/python3

import sys
from PyHT6022.LibUsbScope import Oscilloscope

firmware = "dso6022bl-firmware.hex"
VID=0x04b4
PID=0x8613

scope = Oscilloscope( VID, PID )
scope.setup()
if not scope.open_handle():
    sys.exit( -1 )
scope.flash_firmware_from_hex( firmware )
print( "FW version", hex( scope.get_fw_version() ) )
scope.close_handle()

The above script worked perfectly as did the command below

fx2upload -v /home/glennb/Downloads/Hantek6022API/Firmware/DSO6022BL/build/dso6022bl-firmware.hex 0x04b4 0x8613

It then enumerates correctly and OpenHantek loads flawlessly

If this works as expected you should save the EEPROM content with the script read_eeprom_256_byte.py.

I did this an it worked, writing out to > eeprom_256.dat

EDIT I will add that because I was attempting to communicate with the dead EEPROM that upon checking the file output > eeprom_256.dat did not contain proper data - I don't know what it was reading but it wasn't reading actual EEPROM data

Until now nothing was changed to your device

Danger Zone

You can flash the correct Hantek ID permanently into the scope's EEPROM with this script (provided the previously loaded firmware is still active, i.e. you did not unplug and replug the device, the red LED is still blinking, and you are still in the directory examples).

#!/usr/bin/python3

import sys
from PyHT6022.LibUsbScope import Oscilloscope

scope = Oscilloscope()
scope.setup()
if not scope.open_handle():
    sys.exit( -1 )

# read eeprom content from file
f = open( "eeprom_602a.dat", "rb" )
eeprom = f.read()
f.close()

# write_eeprom content
scope.write_eeprom( len( eeprom ), eeprom )
scope.close_handle()

The above script seems to complete correctly, the red light flashes as something is happening, presumably the eeprom being written, the device still enumerates correctly, BUT, when I unplug and replug, it reverts back to enumerating as

Bus 002 Device 024: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit

thank you for your help so far - I'm stumped and exhausted...

Glenn

HTH Martin

[Ho-Ro]

the red light flashes as something is happening, presumably the eeprom being written

No, it is just the "heartbeat" of the hantek firmware.

BUT, when I unplug and replug, it reveres back to enumerating as
Bus 002 Device 024: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit

That could be a hint that the EEPROM is not working properly. Please see my drawing of the reverse-engineered schematics of the 6022BE, the green pin names are valid for 6022BL.

I do not know how the switching between scope and logic analyser is realised on the BL - did you check if the switch on the backside changes the VID/PID pair on USB?

[ruckusman]

I've read and understand 5 or so pages of that document, it's a very clever strategy the device re-enumeration, quick, simple and flexible.

OK, so I've opened the unit.
There are two EEPROMS, the [P]/[H] button connects the SDA pin on the EEPROMS alternatively to the CPU.
The SCL pin is cross connected between both EEPROMS and the CPU.

It was a simple enough task to check this with the unit powered - the 3.3v VCC is present on the SDA pin of only the switched EEPROM.

The device ID change "works" with the button press - this is VID:PID with the button out
Bus 001 Device 026: ID 0925:3881 Lakeview Research Saleae Logic - that EEPROM is working correctly and reporting that VID"PID.

Button in:
Bus 001 Device 027: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit

I think you've gone straight to the cause of the problem, one of the EEPROM's is faulty - so I will have to replace it.

Both VID:PID's "work" with pulseview, it shows either 8 or 16 channels accordingly depending on which EEPROM (no EEPROM with the button in the H position)

Just as a curiosity as I was using Pulseview whilst I was attempting to get my head around things not working for OpenHantek

When the VID:PID has already been set using:
fx2upload -v /home/glennb/Downloads/Hantek6022API/Firmware/DSO6022BL/build/dso6022bl-firmware.hex 0x04b4 0x8613

Pulseview changes the VID:PID to:
Bus 001 Device 020: ID 1d50:608e OpenMoko, Inc. Fx2lafw

That above is what tripped me up yesterday, Pulseview changing the VID:PID behind my back - cheeky.

I have one possible risky solution, that is to leave the defective EEPROM as it automatically loads & works as a 16 channel logic analyser in pulesview with VID:PID 04b4:8613

If I use the [P]/[H] function button reversed, and program the working/functional EEPROM with the VID:0x04b5 PID:0x602a then run the scope calibration and write it to the EEPROM.

Do I risk anything with that strategy, have I missed anything?

I do obviously need to backup the working EEPROM which ID's as
Bus 001 Device 045: ID 0925:3881 Lakeview Research Saleae Logic as I do intend to replace the non-functional EEPROM.

[Ho-Ro]

OK, so I've opened the unit.

Would you mind to provide a good picture of the PCB (top/bottom)?

There are two EEPROMS, the [P]/[H] button connects the SDA pin on the EEPROMS alternatively to the CPU.
The SCL pin is cross connected between both EEPROMS and the CPU.
It was a simple enough task to check this with the unit powered - the 3.3v VCC is present on the SDA pin of only the switched EEPROM.
The device ID change "works" with the button press - this is VID:PID with the button out
Bus 001 Device 026: ID 0925:3881 Lakeview Research Saleae Logic - that EEPROM is working correctly and reporting that VID"PID.
Button in:
Bus 001 Device 027: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit

Good job, I will add this info to my reverse engineered document to reflect also the BL schematics.

I have one possible risky solution, that is to leave the defective EEPROM as it automatically loads & works as a 16 channel logic analyser in pulesview with VID:PID 04b4:8613
If I use the [P]/[H] function button reversed, and program the working/functional EEPROM with the VID:0x04b5 PID:0x602a then run the scope calibration and write it to the EEPROM.
Do I risk anything with that strategy, have I missed anything?
I do obviously need to backup the working EEPROM which ID's as
Bus 001 Device 045: ID 0925:3881 Lakeview Research Saleae Logic as I do intend to replace the non-functional EEPROM.

That sounds reasonable to me, based on your experience with the SW tools. And it makes sense, especially because you don't have to "fake" a Saleae ID if you use pulseview, which would also restrict the LA to 8 lines.
To save the EEPROM content you need EEPROM access support. This is either available in my Hantek FW (because the EEPROM is used for calibration data storage) or you can try the tool fx2eeprom that can read and write the EEPROM of all EzUSB devices w/o any previous uploads.

I learned a lot about these Cypress devices during development of the Hantek FW and I use it also in other projects. You can get cheap devel boards (Saleae compatible LA for about 10€/$) and there are two libs that support all kind of USB interfacing (the older fx2lib that is used here and the easier to handle libfx2).

EDIT:

Spent the day chasing rabbits down the wrong holes trying to get the scope to communicate with OpenHantek - then I realised it was right in front of me
Bus 002 Device 032: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit

When checking USB enumeration I use sudo dmesg -Hw in another terminal window to see what is happening when I plug in a DUT.

[Ho-Ro]

Schematics update according your description:

[ruckusman]

I'll open the box again today and take some photos for you

Would you mind to provide a good picture of the PCB (top/bottom)?

Good job, I will add this info to my reverse engineered document to reflect also the BL schematics.

I have one possible risky solution, that is to leave the defective EEPROM as it automatically loads & works as a 16 channel logic analyser in pulesview with VID:PID 04b4:8613
If I use the [P]/[H] function button reversed, and program the working/functional EEPROM with the VID:0x04b5 PID:0x602a then run the scope calibration and write it to the EEPROM.
Do I risk anything with that strategy, have I missed anything?
I do obviously need to backup the working EEPROM which ID's as
Bus 001 Device 045: ID 0925:3881 Lakeview Research Saleae Logic as I do intend to replace the non-functional EEPROM.

That sounds reasonable to me, based on your experience with the SW tools. And it makes sense, especially because you don't have to "fake" a Saleae ID if you use pulseview, which would also restrict the LA to 8 lines. To save the EEPROM content you need EEPROM access support. This is either available in my Hantek FW (because the EEPROM is used for calibration data storage) or you can try the tool fx2eeprom that can read and write the EEPROM of all EzUSB devices w/o any previous uploads.

I learned a lot about these Cypress devices during development of the Hantek FW and I use it also in other projects. You can get cheap devel boards (Saleae compatibele LA for about 10€/$) and there are two libs that support all kind of USB interfacing (the older fx2lib that is used here and the easier to handle libfx2).

EDIT:

Spent the day chasing rabbits down the wrong holes trying to get the scope to communicate with OpenHantek - then I realised it was right in front of me
Bus 002 Device 032: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013 EZ-USB FX2 USB 2.0 Development Kit

When checking USB enumeration I use sudo dmesg -Hw in another terminal window to see what is happening when I plug in a DUT.

I like the '-Hw' option on Linux, it just sits there displaying the hardware changes and I could see in real time where upon loading Pulseview runs a CPU reset and re-enumerates the USB device, changing it to:
Bus 001 Device 020: ID 1d50:608e OpenMoko, Inc. Fx2lafw
then loading the program - pulseview works fine with both USB ID's - the 16 channel is better functionality.

I used to fx2eeprom to both read to save out the date from the first 8 bytes, and then write the working EEPROM - as much because I wanted to get it to compile and run, I'd missed the libusb-1.0 development headers previously.

I can confirm that your updated schematic shows the correct connections - I'll take the photos and leave the unit opened to assist with any questions you may have

thank you for your assistance as without it I would still be puzzled as to what's wrong - the non-functional EEPROM was the key to the mystery

[ruckusman]

Here are the board photos - hopefully the tracks between the mode button and the EEPROM located beside it are easily visible.
There's also a closer photo of the second EEPROM which is close to the CPU which shows the joined tracks between both EEPROMS

hope this helps you broaden your knowledge of the 6022BL

Glenn

[Ho-Ro]

Here are the board photos - hopefully the tracks between the mode button and the EEPROM located beside it are easily visible.
There's also a closer photo of the second EEPROM which is close to the CPU which shows the joined tracks between both EEPROMS

Hi Glenn,
If you would provide two more pictures, one of the complete (empty) bottom side and a close-up of the right third of the bottom side (the same part as in your 3rd picture, showing both EEPROMs), then the documentation for this bipolar scope/LA character is complete. I will include it in the documentation for other hacking activities.

hope this helps you broaden your knowledge of the 6022BL

Yes, this BL with some (at least questionable) schematic changes compared to the BE initially drove me crazy when I decided to take on the no-longer-maintained openhantek project. FW development without a physical target on your desk can be tedious. See this discussion as an example. Another difficulty was building a macOS package, I don't have a Mac (I don't use Windows at home either) and had to use the Travis CI and later the GitHub worker to debug the build process :(

[Ho-Ro]

There's a new example upload_firmware_6022.py that could be useful in cases like your's:

usage: upload_firmware_6022.py [-h] [-V VID] [-P PID] [--be | --bl]

Upload firmware to Hantek6022 devices with different VID:PID

options:
  -h, --help         show this help message and exit
  -V VID, --VID VID  set vendor id (hex)
  -P PID, --PID PID  set product id (hex)
  --be, --6022be     use DSO-6022BE firmware
  --bl, --6022bl     use DSO-6022BL firmware