New Hantek DSO2X1X models?

[DavidAlfa]

You're right. Then there're few options left.
- Corrupted fpga FW file? I don't think so, the buttons wouldn't work either.
- Corrupted filesystem? Maybe... still, rare that only the buttons work.
 (Both would be fixed with platform-tools)

- Defective chips? Still rare, maybe a bad soldering joint.

The encoders common wires are Scan_Data_4 &  Scan_Data_6.
Maybe one of these are bad, or any of the diodes is shorted.

The Scan_Lines are also used for the buttons, so they would also fail if bad.

[morgan_flint]

Just read your post, that came up while I was editing mine  :'(

I had checked for continuity between diodes and U2, but I didn't check for shorts on the diodes. Will dismount it again and check.

EDIT: Done, all the diodes are OK. Also checked the connections between U2 and U1, also OK. Tried also some more cleaning and heating around U1 and U2 with hot air. No luck. Time for platform tools

EDIT2: Updated to SW 1.0.2.0.0 (221028.00) FW 3205 with Platform Tools (it was 1.0.1.1.0 (20210726.00) 3202). No luck. Must be a hardware failure (probably U2 or, maybe, U1). I will retouch all solders before trying anything else.

Any other ideas?

[DavidAlfa]

Is R109 OK? It's the only thing powering the keypad matrix.

[morgan_flint]

Yes, I also checked R109. Although it is common with the rest of the keys, I suspected it could be also the problem because of the forward drop in the diodes (supposing there was a weaker pullup also in the FPGA). But no, it's OK.

Although I had already checked them with the multimeter, I also resoldered relevant pins of U2 (1, 2, 9, 10, 11) and U1 (3, 4, 5), but no luck.

If it's not a SW or FW problem, I can only suspect bad U2, more remotely, bad U1, or, even more strange, a failure in the FPGA section in charge of reading the keyboard.

If I had a longer ribbon cable, I could also try some "live" measurements in the user interface board, but I don't have it.

Unfortunately, without the encoders, the scope is practically useless, but maybe I can still use it with the Keysight application

[DavidAlfa]

Do you have access to the serial port? It would be interesting to see the kernel messages.
But you need flash the oldest platform-tools version, the keypad kmod (/dso/etc/fpga_i2c_kb.ko) debugging output was silenced in newer versions.
On rotation you should see a lot of messages like:

Code: [Select]

[   22.793724] Get irq key
[   22.818725] Get irq key


[morgan_flint]

Yes, I have access to serial port. As I said before, I updated to the latest version SW 1.0.2.0.0 (221028.00) FW 3205 to see if that solved the problem but, seeing that it didn't, I went back to SW 1.0.1.1.0 (20210726.00) FW 3202, and the problem persists.

With the old SW&FW, I can't see any "irq" messages in the console. I'm attaching the console's output after a reboot and after pressing several keys and rotating knobs. Also checked that /dso/etc/fpga_i2c_kb.ko exists, but I don't know if I have to do something else to get the "irq" messages

EDIT:
I opened a ticket in Banggood; I don't expect anything as I bought it on 2022-03-20, more than a year ago, but you never know if you don't try.. I'm suggesting them to send me a replacement for the interface board, that should be cheap for them, and replace it by myself. Let's see what happens...

Also checked at https://www.eediscuss.com/forum.php that problems with knobs and keyboard are frequent

[DavidAlfa]

Nah, try the oldest build, I know it's FW3000, it won't damage anything.
The kernel module in FW3202 version is already silent.

Alternatively you can manually replace the module with the attached ones and rebooting afterwards to take effect:

Code: [Select]

cp /mnt/udisk/fpga_i2c_kb_verbose.ko /dso/etc/
# Or
cp /mnt/udisk/fpga_i2c_kb_silent.ko /dso/etc/

reboot

Any key/encoder activity is shown:

[  123.838713] Get irq key                                        <---------- Encoder rotation
[  124.113703] Get irq key
[  124.138710] Get irq key
[  124.163720] Get irq key
[  124.188729] Get irq key
[  124.213696] Get irq key

[  124.238704] Get irq key                                             <---------- Button press
[  125.617587] dso keyboard: key (code 0x1) pressed.,0
[  125.738713] Get irq key                                           <---------- Button Release
[  125.742694] dso keyboard: key (code 0x1) released.,0

Code 0x1 is F0 button.

[morgan_flint]

Nah, try the oldest build, I know it's FW3000, it won't damage anything

Done!

Code: [Select]

[  136.417041] Get irq key
[  136.433047] dso keyboard: key (code 0xe) released.,13
[  149.642025] Get irq key
[  149.658439] dso keyboard: key (code 0x7) pressed.,6
[  149.842016] Get irq key
[  149.858236] dso keyboard: key (code 0x7) released.,6
[  156.892013] Get irq key
[  156.908293] dso keyboard: key (code 0x3) pressed.,2
util_thread_pause:thread 0xa8fc70 is paused
[  157.004948] fpga_ctl_kbd_event:17, 3, 0, 50
[  157.009204] cnt =1,80,124
[  157.022758] cnt =0,80,124
[  157.026935] fpga_ctl_kbd_event:17, 5, 0, 40
[  157.033041] fpga_ctl_kbd_event:17, 7, 0, 0
[  157.042905] Get irq key
[fpga_dds__set_dds_light] 0
[  157.058569] dso keyboard: key (code 0x3) released.,2
[  157.082690] cnt =1,64,124
[  157.102674] cnt =1,0,124
[  157.122654] cnt =0,0,124
ia_self_test_on_key_up:65471
[  159.617033] Get irq key
[  159.632270] dso keyboard: key (code 0x12) pressed.,17
[  159.767034] Get irq key
[  159.782249] dso keyboard: key (code 0x12) released.,17
ia_self_test_on_key_up:75
[  160.567032] Get irq key
[  160.582264] dso keyboard: key (code 0xa) pressed.,9
[  160.692035] Get irq key
[  160.707332] dso keyboard: key (code 0xa) released.,9
[  160.712348] dso keyboard: key (code 0xa) pressed.,9
[  160.717354] dso keyboard: key (code 0xa) released.,9
ia_self_test_on_key_up:67
[  162.567031] Get irq key
..............................................................................
[  239.767014] Get irq key
[  239.782266] dso keyboard: key (code 0x20) pressed.,31
[  239.892018] Get irq key
[  239.907317] dso keyboard: key (code 0x20) released.,31
ia_self_test_on_key_up:88
[  249.142022] Get irq key
[  249.167045] Get irq key
[  249.192009] Get irq key
[  249.217037] Get irq key

Apparently, the same results as you: it responds to encoder rotation, but they don't work doing what they're supposed to do!

I understand this discards any hardware failure, at least at the user interface PCB

Completely clueless now!

EDIT: sometimes I stop getting "Get irq key" on rotating the knobs. But no response on the screen even when the "Get irq key" appears

[DavidAlfa]

Rotate V0 knob while not in any menu, so the dso app doesn't show its stuff.
You should get plenty of irq messages in a single rotation.
Do you have any signal analyzer? Would be interesting to see what's going on at the encoder pins.
I'd replace the 4051s and the 4066, they're cheap so you won't lose anything trying.

[morgan_flint]

Rotate V0 knob while not in any menu, so the dso app doesn't show its stuff.
You should get plenty of irq messages in a single rotation.

That's what I get, not only with V0, but with all the knobs, although sometimes there are some interruptions and lags.

Do you have any signal analyzer? Would be interesting to see what's going on at the encoder pins.

No, unfortunately, I don't (although planning to get one of those cheap USB login analyzers one of these days...). I should also need a longer ribbon cable to be able to access the user interface PCB with the rest of the scope connected.

I'd replace the 4051s and the 4066, they're cheap so you won't lose anything trying.

Yes, I think I'll try that, but considering the HW detects the knobs' movement, as stated by the IRQ messages, I don't have much confidence that it'd solve the problem, but it's worth a try.

Just a last crazy elucubration: when the rear USB is connected to the PC and Keysight's application is running, the front panel keys are locked... ¿Could it be something is blocking the response to the knobs, although nothing is connected? Would be very strange, as buttons should also lock, but almost all the sensible possibilities have come to an end

[DavidAlfa]

I forgot something: You get the IRQ on *any* change, even if the knob didn't made a full quadrature cycle.
It seems everything is processed in software, the fpga just sends raw data when something changes.
So imagine the encoder contacts "A" and "B"... Only "A" might be toggling, and "B" stuck high/low, nothing would happen but you will get the IRQ messages as well.

This is while rotating the Time/Div control.
At first I'm making full steps, but then I'm making half steps, backwards and forwards, so it never settles into the next step.
Still, you get plenty of IRQs.

[   94.585066] Get irq key
[   94.610065] Get irq key
dso_acq_control:1:store_depth 4000, extra_len 64,acq_all_nm_for_read 4064,acq_dot_nm_of_timerange 80,sample_rate = 1000000000.000000
[   95.285081] Get irq key
[   95.310090] Get irq key
dso_acq_control:1:store_depth 4000, extra_len 64,acq_all_nm_for_read 4064,acq_dot_nm_of_timerange 160,sample_rate = 1000000000.000000
[   96.110066] Get irq key
[   96.135080] Get irq key
dso_acq_control:1:store_depth 4000, extra_len 64,acq_all_nm_for_read 4064,acq_dot_nm_of_timerange 320,sample_rate = 1000000000.000000
[   96.985074] Get irq key
[   97.010073] Get irq key
dso_acq_control:1:store_depth 4000, extra_len 64,acq_all_nm_for_read 4064,acq_dot_nm_of_timerange 800,sample_rate = 1000000000.000000
[  101.035063] Get irq key
[  101.310079] Get irq key
[  101.935058] Get irq key
[  101.985166] Get irq key
[  102.060081] Get irq key
[  102.110083] Get irq key
[  102.410074] Get irq key
[  102.560081] Get irq key
[  102.660067] Get irq key
[  102.735065] Get irq key
[  102.860078] Get irq key
[  102.935082] Get irq key
[  103.160093] Get irq key
[  103.310069] Get irq key
[  103.335062] Get irq key
[  103.410078] Get irq key
[  103.485066] Get irq key
[  103.510078] Get irq key
[  103.635070] Get irq key
[  103.760065] Get irq key
[  103.835067] Get irq key
[  103.860062] Get irq key

Take any of the stepping encoders, and slighly turn them to right or left, about 1/4 of the step, much less than it would need to make the "click".
Do you notice one side behaving differently? I one side needs more than the other, then it's likely to be a bad common signal.
Try soldering two wires to any encoder pins, then randomly touch ground with one at a time. Or just shorting them with tweezers or whatever.
I guess one of them won't make the IRQs!

[morgan_flint]

It's a good guess, although not all the encoders are going to get one contact stuck at the same time. But the symptoms would also be the same if one of the signals Scan_Data_4 or Scan_Data_6 (not both at the same time) had gone nuts!

Time to look for an HC4051!! Thanks!!

[DavidAlfa]

I don't mean the encoder is stuck, but one of 4051s!

[morgan_flint]

Ah, OK, I didn't understand it well. Sorry!

Most probably, U2, as it is the one that has two signals exclusively for the encoders, so it's the first one to be changed, but I'll buy more than one, just in case.

[morgan_flint]

Take any of the stepping encoders, and slighly turn them to right or left, about 1/4 of the step, much less than it would need to make the "click".
Do you notice one side behaving differently? I one side needs more than the other, then it's likely to be a bad common signal.
Try soldering two wires to any encoder pins, then randomly touch ground with one at a time. Or just shorting them with tweezers or whatever.
I guess one of them won't make the IRQs!

I tried this and, as you guessed, one of them (the one that corresponds to Scan_Data_6) doesn't make IRQs.

It seems clear that channel 6 of the analog multiplexer U2 is not working.

I also checked that pulling down the Key_Scan_Data generates lots of IRQs, with lots of random key detections 

I also made another desperate attempt: shorting out pins 2 and 4 of U2, in the hope that channel 7 (unused, as Scan_Data_7 doesn't exist) would work and the software would "understand". But no luck. Replacing U2 is now the only hope...

[DavidAlfa]

You got it! Should be it. What else if not?
Damaged FPGA? Strange, but go figure.
Maybe they called them "LemonTrees" because they didn't pass QA and GoWin didn't want to its name there.

[Joemega]

...sorry for my bad english...

Maybe, your problem is the same like mine DSO2D10 after a few month: suddenly shortcut in one of rotary encoder case (GND) to the inner encoder PCB.
It's blocking the data lines.
Mine repair was simple: teardown the encoder case, a little tape to isolate.
Search this video in YouTube: "Hantek DSO5202P: Knobs/Encoders Not Working Repair"
Maybe helping you...

[IonutL]

Hello experts!
I got a DSO2D15 and I started making backups. First I used Backup_Builder so now I have all the files it produced. Then I made a safety backup with Dsoflash and it produced the 135168kB file. Then at the first power cycle the problems started. Serial and Hardware in system information show "undefined", so i tried to update them using the file "dso3kb_CN2318029043950_Model.upk", but I got an error:
Updated failed! Error code is -2
I tried also the USB fix update, the latest update from Hantek site, the full update I have got from Backup_Builder, even do_other_update without any script (just to test if it runs), all throw immediately the same error:
Updated failed! Error code is -2

I also tried the "Default setup" key, nothing changed.
Also tried in the Keysight Connection Expert console
PRIVate:SET:PCB "003.002.001.000.000.000.000.001"
error:
 ! VI_ERROR_TMO: A timeout occurred
Visa ErrorCode: 0xBFFF0015 (-1073807339)
and
PRIVate:SET:SERIal CN2318029043950
 ! VI_ERROR_TMO: A timeout occurred
Visa ErrorCode: 0xBFFF0015 (-1073807339)
however, the command:
PRIVate:FACTORY:RESET
reboots the scope, but returns error
-> PRIVate:FACTORY:RESET
 ! VI_ERROR_IO: I/O error
Visa ErrorCode: 0xBFFF003E (-1073807298)

What is weird is that after every power cycle the scope seems to forget some of the settings (if I disable the sound, it comes back at next power on); or if I save the settings in the internal memory it says it was done ok, but when I recall them it say "Recall failed".

Before making backups the system info showed (it looks to me that there are the latest versions of software and firmware):
Model: DSO2D15
Serial CN2318029043950
Software 1.0.3.0.0(230327.00)
Hardware 003.002.001.000.000.000.000.001
Firmware 3205

So my question is: is it any way to get back the update functionality? and as a bonus to set the serial and hardware fields?
Best regards,
Ionut

[DavidAlfa]

That's really weird. Try platform-tools then restoring your backupbuilder backup.
Or restoring the entire dsoflash backup.

[IonutL]

It doesn't work. Platform-tools ends in error:

FLASH FAILED!
ERASE PARTITIONS...
Erasing 'boot'                                     OKAY [  0.045s]
Finished. Total time: 0.053s
Erasing 'cache'                                    OKAY [  0.077s]
Finished. Total time: 0.091s
Erasing 'dtb'                                      OKAY [  0.034s]
Finished. Total time: 0.048s
Erasing 'kernel'                                   OKAY [  0.073s]
Finished. Total time: 0.082s
Erasing 'rootfs'                                   FAILED (remote: 'failed erasing from device')
fastboot: error: Command failed

Failed to erase the memory!

[DavidAlfa]

No damn idea! Post the complete log.

[IonutL]

Not easy because of the cls in the batch:

FLASH PARTITIONS...
Selected:    2022.10.28_fpga_3205

< waiting for any device >
Sending 'boot' (202 KB)                            OKAY [  0.022s]
Writing 'boot'                                     OKAY [  0.137s]
Finished. Total time: 0.177s

Sending 'logo' (750 KB)                            OKAY [  0.063s]
Writing 'logo'                                     OKAY [  0.606s]
Finished. Total time: 1.892s

Sending 'dtb' (11 KB)                              OKAY [  0.008s]
Writing 'dtb'                                      OKAY [  0.039s]
Finished. Total time: 0.086s

Sending 'cache' (1612 KB)                          OKAY [  0.109s]
Writing 'cache'                                    OKAY [  0.710s]
Finished. Total time: 0.846s

Sending 'kernel' (2999 KB)                         OKAY [  0.197s]
Writing 'kernel'                                   OKAY [  1.468s]
Finished. Total time: 1.682s

Sending 'rootfssize' (0 KB)                        OKAY [  0.007s]
Writing 'rootfssize'                               FAILED (remote: 'ubi erase failed')
fastboot: error: Command failed
FLASH FAILED!
ERASE PARTITIONS...
Erasing 'boot'                                     OKAY [  0.045s]
Finished. Total time: 0.051s
Erasing 'cache'                                    OKAY [  0.077s]
Finished. Total time: 0.085s
Erasing 'dtb'                                      OKAY [  0.034s]
Finished. Total time: 0.050s
Erasing 'kernel'                                   OKAY [  0.075s]
Finished. Total time: 0.082s
Erasing 'rootfs'                                   FAILED (remote: 'failed erasing from device')
fastboot: error: Command failed

Failed to erase the memory!

Press any key to continue . . .

[IonutL]

And I have to add that a normal boot leads to a blank screen, now it's totally bricked...

[DavidAlfa]

For whatever reason the nand can't be written to!
Of course, if new data can't be written, it won't boot.

What does "dsoflash erase" do?

Also try erasing the entire flash with xfel.
Only boot in fel mode, then:

xfel spinand

if detected

xfel spinand erase 0x0 0x8000000

But it's basically the same.

[IonutL]

xfel spinand
Found spi nand flash 'W25N01GV' with 134217728 bytes

xfel spinand erase 0x0 0x8000000
100% [================================================] 128.000 MB, 13.645 MB/s        00

dsoflash erase did erase it ok also.

But platform-tools still fails with the same errors as before.