Hacking the DSO2X1X

[DavidAlfa]

Edit: Nope, my code is optimized for Hantek DSO2x1x, only works with spi-nand, also I had to modify it to backup the ECC area as well.
Use xfel (Download latest release), should work fine.
Boot into FEL mode, ensure the WinUSB driver is installed. Follow the Hantek FAQ for that, it's the same for all.
For 32Mbit SPI-NOR, commands are:

Code: (detect) [Select]

xfel spinor


Code: (read) [Select]

xfel spinor read 0 0x400000 backup.bin


Code: (erase) [Select]

xfel spinor erase 0 0x400000


Code: (write) [Select]

xfel spinor write 0 backup.bin

You don't need erasing before writing, it'll do it automatically.

So anyone with the same scope only needs to to read it and send the file to you, then write it into your's.
Although it's is bricked, better make a backup, some calibration data might be still present and recoverable.
Should be pretty fast, takes 45 minutes for 1Gbit, so 32Mbit will be about 2 minutes.

[DavidAlfa]

I swear I had uploaded it, but now I didn't find it anywhere, so re-uploading.
This the devicetree used by Hantek, decoded from suniv-f1c100s-licheepi-nano.dtb (From platform-tools)

[DavidAlfa]

Following the wave generator calibration, I ran Ghidra again.

I found it effectively checks the eeprom if the calibration file couldn't be opened.
(I renamed the functions for easier reading)

Code: [Select]

void Read_AWG_calibration_file(void)

{
  iVar1 = open("root/dds_calbration.dat",2,0x180);
  if (iVar1 < 1) {
    iVar1 = read_AWG_calibration_from_eeprom(&DAT_009e0f28);
    if (0 < iVar1) {                   
      regen_dds_cal_data();
      return;
    }
    printf("[%s]open %s failed\n","dds_calibration_load","root/dds_calbration.dat");
  }
  else {
    __fxstat(3,iVar1,&sStack112);
    if (sStack112.st_size == 0x28) {
      read(iVar1,&AWG_CAL_DATA,0x28);
    }
    else {
      ftruncate(iVar1,0);
      AWG_CAL_DATA = &DAT_00100010;
      DAT_009e0f28 = 0;
      DAT_009e0f2c = 0x3ff00000;
      DAT_009e0f40 = 0;
      DAT_009e0f44 = 0;
    }
    DAT_009e0f18 = (uint)(sStack112.st_size == 0x28);
    close(iVar1);
  }
  return;
}



Code: [Select]

int read_AWG_calibration_from_eeprom(char **param_1,char **param_2)
{
    ...
    (char *)read_eeprom(extraout_s0,__fd,&local_40,4,0xdc);
    if (local_40 == 1) {
        ...
        (char *)read_eeprom(pcVar4,__fd,__nptr,8,0xe0);
        dVar5 = strtod((char *)__nptr,(char **)0x0);
        ...
        (char *)read_eeprom(pcVar4,__fd,__nptr,8,0xe8);
        dVar5 = strtod((char *)__nptr,(char **)0x0);
    }
   ...
}

So there're 3 eeprom addresses:

Code: [Select]

  0xDC-0xDF (4bytes). 0x01000000 (little endian) means there's awg calibration present in the eeprom.
  0xE0-0xE8 (8bytes).  First coefficient. Float represented as text string (ex. "0.818373")
  0xE9-0xEF (8bytes).  Second coefficient.

Very stupid, why not store the double float directly? Loses precision this way.
Sso far I haven't found the equation it uses.

I made a test:

Code: [Select]

cd /cache
mv dds_calbration.dat dds_calbration.bak
i2cset -y 0 0x50 0xdc 1 0 0 0 i

It worked, reading the data from eeprom I already had written using the calibration tool:

Code: [Select]

calibration_dds_result_read_eeprom,amp 0.833157,off 13.485450

On booting, it regenerated the dds_calbration.dat file, but the string conversion lost a digit. Not a big deal, but stupid programming.
Orig: 13.485453
New: 13.48545

Did we already see how terrible Hantek programmers are?

Edit:
There's another calibration block, seems to be the ADC gain calibration.
- 0x19-0x1C (4-bytes). A value of 0x01010000 means there's calibration data.
- 0x28-D7. (176 bytes). The're 4 calibration blocks. Each has 11 4-byte integers (32-bit) .


Deleting cali.dat regenerates it from the eeprom (if present), but it's pretty useless, needs a new calibration anyways.
This is how data is stored:

Code: [Select]

  EEPROM        Cali.dat
  0x28-0x53    0x4B0-0x4DB
  0x54-0x7F    0x4E8-0x513
  0x80-0xAB    0x1F0-0x21B
  0xAC-0xD7    0x228-0x253
These areas in cali.dat don't change after calibrating the scope, but new ones appear.

Doesn't seem to be critical. I zeroed my eeprom, deleted cali.dat, rebooted and calibrated afterwards, the channels were fine!
Perhabs it's just the default calibration? (But doesn't mean it's accurate)

The eeprom contents vary a lot between devices, probably they added new features, so earlier scopes lack them.

[meq123]

First, Thanks to all that have made these hacks possible (esp. DavidAlfa).  I just want to add another data point here...

I just found the DSO210C for sale at the Hantek store on Amazon for under $200 - which compares very favorably even with AliExpress prices from China.  There are a couple of item pages, one for $197 at time of writing: https://smile.amazon.com/Hantek-DSO2C10-Benchtop-Oscilloscope-100MHz/dp/B08YNY9G75, and another (I got this one) with a few extra 'accessories' for an extra $3: https://smile.amazon.com/Hantek-DSO2C10-Digital-Oscilloscope-Bandwidth/dp/B08Y6SKTX6  Also note that both of these come with two probes, as well as an alligator-clip set for the AWG (I saw that some folks in the past only got a single probe).

So, I bought one last week.  As soon as it came, I took the back off and found !!YEAH!! that all the AWG components were there already.  This, even though it was brand new and with the latest firmware and software (see screenshots below).  So maybe they are building them all like that now.  Then today, I downloaded the backups and hack from Davids page, and successfully upgraded it to a DSO2D15 - after backing-up of course.

Two other points:
 - For those still to do this, you only need a very small FAT32 USB drive.  Even with the upk files and backups, it only takes a few MB of space.
 - I notice (see the screenshots) the hardware version is reset to all-0's-1.  Not sure why (or if I care), but just to note.

Here are the Before and After screenshots. Thanks again, all!

[DavidAlfa]

Yes, that was the known values back then. Then newer dso came with that... no idea what they do, else than last digit meaning AWG enabled or not (The one that changed from 000 to 001).
Anyways the software checks for both, the "D" in 2D1x and the digit, any of them will enable the AWG.
Having a backup, just use it freely, tell us if you detect anything different.
FW3204 will give you some problems, specially with the decoders, better switch to FW3202 for now.

[pu6k1n]

Does anyone have a full nand w25n01g memory dump for dso2d15???

[dirtmover]

Anyone else having problems recalling a .arb file created by WaveEditor on a hacked DSO2C10. I get a "Recall Failed" message when I try.

Everything else about the wave gen seems fine - well as fine as it can be.

[Jonatan2025]

Hello, does anyone know if it is possible to increase the speed of the oscilloscope DSO2D10 to see the graph faster or so that the response time of the oscilloscope is faster? Thanks

[DavidAlfa]

Overclocking improves that (Check the FAQ for this), the CPU is rather limited.

[StuBudd]

Thank you.

Please note: I do have a full backup using dso3kb_backup_builder.upk and proceeded at my own risk. There isn't much need to hack the DSO2 if you don't want to.

This is quite a long thread so forgive my ignorance.

I've this week received my new 2C10 (Aug 2022). I was lucky and surprised to see a fully populated board "DSO2D15_V1.7 2021.1.14".

With the help of OPs Mark5 first post I realised the CP command could work both ways. From "/cache/" to "/mnt/udisk" and back.

So copied my system.inf from my DSO2, edited it and sent it back.

I had no luck with the Hack using sed in the do_other_update. Just seemed odd! Had my TXT format been wrong? Using "whoami" command did work and left me with the whoami.txt file with the root contents on my USB stick, so do_other_update was correct.

dso3kb_20220517.upk from Hantek was used to initiate do_other_update.

Code: [Select]

whoami >/mnt/udisk/whoami.txt
cp /mnt/udisk/cache/system.inf /cache/

I had created a cache folder on my USB to store the system.inf file

Code: [Select]

[machine]
Model=DSO2D15
Vendor=undefined
Product=undefined
Manufacturer=undefined
Serial=CNXXXXXXXXXX
[version]
Pcb=003.002.001.000.000.000.000.000
Keyboard=undefined
[language]
Lans=65535
Language=2
[add]
Start=35
Update=0

Above shows the edit (serial removed). DSO2C10 has been edited. Your serial will be intact. "undefined" is as your original. PCB will also be populated with the correct values.

The only upk package required is from Hantek. The only other files are do_other_update which you create using notepad++ with Unix (LF).

whoami command is a good test to check the do_other_update was run. Delete the whoami.txt file before each update to confirm.

I ran dso3kb_20220517.upk twice with two versions of the do_other_update file. First to copy my system.inf file (which I edited). The second time to send the system.inf file back. It overwrites, I guess as the operation is done by root.

do_other_update can be removed for future updates.

First:
cp /cache/system.inf /mnt/udisk/cache/
copies your system.inf to a folder called cache on your USB (create folder first)
Second:
edit system.inf on your computer
Third:
cp /mnt/udisk/cache/system.inf /cache/
copies system.inf back to /cache/ overwriting the original with your edit.

 

[DavidAlfa]

All that is unnecessary, check the faq, there's a package to do that in a very simple way (2D15 Conversion), same for overclocking.

[StuBudd]

Hi David. Thanks for your google resource and info.

I wanted to keep Hardware 003.002.001.... and had a little fun doing so. Using do_other_update and the official update to call do_other_update and the commands within, just keeps all original files. dso3kb_2D15_conversion.upk changes Hardware to ...000.001, at least on my system.

I haven't used the decrypt to unpack any upk files so don't know what's run in dso3kb_2D15_conversion.upk. "sed" or "cp" or some other magic 

I've relied on these threads to gain a little understanding of the OS and software used in these DSOs. It's my first DSO and chosen based on reviews and videos. None are perfect at this price. It was a toss up between this and the 5000P after whittling down the opposition using "ignorant bliss" as my main tool. Needles to say, as the race was so close with these two models, there's a 5072P on it's way to me.

Thanks again for all the work you put into helping users get the most out of their unit. Without knowledgeable users and an independent place to share that knowledge, there'd be a lot of stuck people.

Overclocking and decode looks like the next upgrades to pursue, so a thank you in advance for those 

[Horse4Horse]

Hi David!
Tried usb console hack, but my windows 7 could not find drivers for COM device properly - it says "CDC Serial"(error 28) and I can't find any working drivers.
Windows default "Serial port"(serenum.sys, serial.sys) driver inst working - error 10

DID is "USB\VID_049F&PID_505E&REV_0502&MI_01"

And if driver would work - do I need to specify baud rate and other serial settings?

[DavidAlfa]

Baudrate isn't important, it's a virtual port, doesn't care.
Ensure nothing is plugged in the front USB port.
I'm not at home, can't check right now, but maybe Windows 7 is a bit old for CDC, no idea, in win10 & 11 it worked right away.

I'll modify the DSO2D15 converter to modify the last bit instead replacing the HW string.

[Horse4Horse]

Yup, you're totally right - win 10 catches driver right away - "usbser.sys".
There's must be an msu named "KB925681" that installs this driver on the system, but I could not find it. So I just copied driver from win10.
Win7 is angry at missing signing and driver isn't properly working.
I'll try to find an win7 ISO which contain this driver.

[DavidAlfa]

Try Zebra CDC driver, it's signed:
https://www.zebra.com/us/en/support-downloads/software/drivers/usb-cdc-driver.html

[Horse4Horse]

Wow, works like a charm, many thanks!

[DavidAlfa]

I don't know why I didn't detect this before. I haven't use the scope much lately!
The usb console package broke the usb mode switch, so the front USB wouldn't work anymore.
The issue happens when modifying the USB after Phoenix (The scope process) already started.
The fix was to do some minimal usb initialization before Phoenix, only adding the serial function, but not starting the USB.
Then Phoenix boots and does the rest of the initialization. That way everything works.
I modified the package fixing this.

For people who already installed the old package, I attached some basic commands to remove the console, so the usb works again and the new package can be installed.
Check "old_usb_fix.txt" in my usb console folder.

Also updated 2D15 converter to modify the Hardware number, only replacing the last ".000" with ".001".

[powerstroke7.3]

I don't know why I didn't detect this before. I haven't use the scope much lately!
The usb console package broke the usb mode switch, so the front USB wouldn't work anymore.
The issue happens when modifying the USB after Phoenix (The scope process) already started.
The fix was to do some minimal usb initialization before Phoenix, only adding the serial function, but not starting the USB.
Then Phoenix boots and does the rest of the initialization. That way everything works.
I modified the package fixing this.

For people who already installed the old package, I attached some basic commands to remove the console, so the usb works again and the new package can be installed.
Check "old_usb_fix.txt" in my usb console folder.

Also updated 2D15 converter to modify the Hardware number, only replacing the last ".000" with ".001".

thank you so much! i just got a 2c10 on amazon 2 days ago. the first page of this thread didnt work for me but the converter link sure did! i guess i probably did something wrong  from the first post instructions

[DavidAlfa]

Great! Enjoy

[powerstroke7.3]

Is it normal to see random mV readings while nothing is hooked to scope?
Measurements of my ham radio power supply show 14.4v  and everything else reads close to 13.85v.  Is there any reason ? I dont think it was like this beforehand.  Might have to see if Amazon will send a replacement.  No point in owning something not accurate 😕

[pcprogrammer]

Well if you wanted something accurate you should not have bought a cheap scope to start with

Single digit mV readings yes, very likely. Double digits maybe. It depends on how noisy (electric) your environment is.

Edit: It also depends on the sensitivity setting of the scope.

I watched the video you linked to in your other post about this, and nothing strange there. A signal will have some noise on it and will flip one or two bits in the ADC output. Your DMM will have a higher resolution ADC and some filter to reduce on the high frequency noise.

Furthermore just a little friendly advise on when posting about an issue, please do it only once. You will get an answer rest assured, but with different time zones across the world it might take a bit of time for someone to read your post and respond to it.

[powerstroke7.3]

Well if you wanted something accurate you should not have bought a cheap scope to start with

Single digit mV readings yes, very likely. Double digits maybe. It depends on how noisy (electric) your environment is.

My friend has a even cheaper FNRSI tablet scope and it reads just fine. I have broken tektronix 2247a its what i always used.  I figured this had ok reviews.  Is it really that  bad like 13.8v to 14.1v ?

[pcprogrammer]

Don't get me started on the FNIRSI scopes. They are crap. Just check out the thread about it. https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4354183/#top

But yes, and read the explanation atadarov gave to your post for this, a single bit flip means so many mV depending on the volts per division setting.

[powerstroke7.3]

Don't get me started on the FNIRSI scopes. They are crap. Just check out the thread about it. https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4354183/#top

But yes, and read the explanation atadarov gave to your post for this, a single bit flip means so many mV depending on the volts per division setting.

it wont read a 9v battery now. No response.  I think something is wrong with it.  Im testing it right now. But its not reading the  9v battery  and its reading a saw tooth wave from a aa   battery haha.