PR for DSO-2090 device

[jedi7]

Hi, If I create a PR for the DSO-2090 device, will it be accepted? Or you want keep strictly only this 6022 device?

[Ho-Ro]

It depends how complex the changes are. Please give me a rough estimation. Long time ago I removed support for Hantek 2090, 2150, 2250 and 5200 from the project, because I do not own any of these devices and cannot test during development. In the past I developed firmware and implementation for scopes I do not have access to, but these parts (DSO6022BL, DDS120) were very similar to the 6022BE and nevertheless it took some loops until success.

[Ho-Ro]

Please give me a rough estimation.

Ok - after 7 days it looks if it is not so important - I close here. Feel free to reopen it if you can provide more info.

[jedi7]

Sorry I missed the previous response :( I had no time to look at it deeper. I just wanted to know if it will be ok for you, or you want keep strictly actual devices.

[jedi7]

no need to reopen :) it is not issue. Just there was no other way to contact you :)

[Ho-Ro]

As I wrote previously I'm not able to support "virtual" devices, i.e. a device I have not in my hands. But if the impact on the existing files is not too big we can try, otherwise you should provide your own branch with e.g. synced snapshots for the main releases.

[sl-maka]

How do I access this code change? I would very much like 2090 support but my own attempts have failed.

[jedi7]

There was no time to write it :( and probably will not be for longer time.

[Ho-Ro]

I would very much like 2090 support but my own attempts have failed. Did you check how it was done in openhantek? This legacy project supports DSO2090.

[sl-maka]

@Ho-Ro Ive been running OpenHantek for years. Its the only Linux sw I have found to work properly. But the OH6022 interfaces seems much nicer and cleaner. The source from OH did not help me more than the legacy branch of OH6022. The problem Im seeing (in my modified OH6022 build) is that I get a "Connection failed" when selecting DSO-2090 in the initial "Select device" dialog. Any spontaneous hints from that description?

[Ho-Ro]

• firmware ok?
• udev rule in place?

You could try to start with --verbose 7 - this gives the most info, and then you can add more debug output in e.g. finddevices.cpp. I used a lot of printf() or qDebug() << during development. And then do the same for the old OpenHantek (it has no -verbose option, just add printf() etc.)

[sl-maka]

Firmware hex is the one used by the legacy openhantek (although I dont know what to do with the *-loader.hex). Udev rule is already in place since im running legacy OH. But I tried replacing the udev rules with various those from github (OH and old OH6022). No diff. I dont think the firmware uploads. The "failed message" is immediate, no delay after choosing device (dso-2090 is only device in list).

I will test the verbose argument, thanks for the tip!

[Ho-Ro]

I dont know what to do with the *-loader.hex).

Have a look at UploadFirmware::startUpload(USBDevice *device) and compare it with the current code. IIRC all FW versions that wer extracted from a windows .exe had a loader and a firmware part, while my improved FW comes as one block. Just sprenkle a lot of printf in the legacy code and watch the steps. You can also look aut the output of dmesg, here with OH6022, branch last_legacy_support

[124806.365908] usb 4-1: new high-speed USB device number 116 using ehci-pci
[124806.526365] usb 4-1: New USB device found, idVendor=04b4, idProduct=6022, bcdDevice= 0.00
[124806.526374] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[124812.264256] usb 4-1: USB disconnect, device number 116
[124813.865923] usb 4-1: new high-speed USB device number 117 using ehci-pci
[124814.031202] usb 4-1: New USB device found, idVendor=04b5, idProduct=6022, bcdDevice= 2.00
[124814.031210] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[124814.031216] usb 4-1: Product: DSO-6022BE
[124814.031220] usb 4-1: Manufacturer: Hantek
[124814.031224] usb 4-1: SerialNumber: Custom FW

EDIT: This is the output of the old OH (with DSO-6022BE) when started in terminal, it loads two FW files (the last three lines are unimportant):

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
libpng warning: iCCP: known incorrect sRGB profile
compile shaders
compile shaders

[sl-maka]

Can you simply skip the loader hex? Or are the firmware hexes used by OH6002 not the same as those used by OH? It seems the firmware hex is uploaded in my case. I can follow every SREC line in the debug printout. Then a reset is issued, then nothing. As if the firmware content was bad somehow.

You say "my improved FW". Is OH6022 using custom FW for its supported devices? And this in practice includes the functionality the loader supplied?

I will examine my logs, thanks!

[Ho-Ro]

I can imagine that if there's a two-stage loading (loader.hex & firmware.hex) both should be loaded, compare old and new. I can't remember what actions the loader performed - maybe it initialises something in the EzUSB chip. OH6022 uses a completely new free open source FW that does not depend on the Hantek code - it is based on the Sigrok project with extensions, while the 2090 uses the Hantek FW extracted from the Windows binary (as did the old OH and the last legacy version). You don't have your development in GitHub - do you? If you set up your own GitHub repo from your local development it would be easier for us to communicate and for me to check some ideas - e.g. what does your ModelDSO2090::ModelDSO2090() look like, it might break the program if the FW version is wrong, with the same error screen you showed above. Also interesting would be the dmesg lines when you connect the scope and start the program.