Author Topic: Hacking the DSO2X1X (Read 141147 times)

Poogo · « **Reply #225 on:** July 08, 2021, 01:08:31 pm »

I agree with that. I checked this, really the pinout is similar to GW2, not GW1 ... and you scared me )) ... I reduced it to 1.15v. CPU - 704 MHz, RAM - 360 MHz.

Device Id: 00000000000000000000100000011011 (0x0000081B) = GW2A(R)-18

DavidAlfa · « **Reply #226 on:** July 08, 2021, 02:55:07 pm »

You're right, I missed that entry when checking the IDs!
It might be a normal version then?

Poogo · « **Reply #227 on:** July 08, 2021, 03:45:33 pm »

Developing a custom FPGA for a cheap device would be unprofitable, I think it's just non-standard labeling. By the way, maybe the function name "spi_fpga_tn652" hints at the document "TN652 Gowin FPGA Products Slave SPI Configuration Manual" https://www.gowinsemi.com/upload/database_doc/342/document/5df0660d4cf09.pdf

H2Nut · « **Reply #228 on:** July 10, 2021, 06:41:44 pm »

Great find Poogo!

The FPGA GW2AR18 costs less than €10 on Taobao!

Poogo · « **Reply #229 on:** July 11, 2021, 07:28:08 pm »

A couple of observations: I parsed dso3kb_20210630_auto_update_fpga.upk and analyzed the do_update.sh file. The tp-adc.ko driver is installed first, then \dso\app\adc_test application is started.

Ghidra adc_test main section translated code:

Code: [Select]

undefined4 main(void)
{
  int local_10;
  int local_c;
  local_c = open("/dev/tp_adc",2);
  if (local_c < 1) {
    puts("open adc device error!");
  }
  else {
    sleep(1);
    local_10 = 0;
    read(local_c,&local_10,4);
    printf("tp_adc_value =%d\n",local_10);
    close(local_c);
    if ((local_10 < 0xf85) || (0xfff < local_10)) {
      system(
            "cp /dso/var/run//package/fpga/SCOPE_TOP_V3002.bin /lib/firmware/psram_board_test.fs.bin -rf"
            );
    }
    else {
      system(
            "cp /dso/var/run//package/fpga/SCOPE_TOP_V3202.bin /lib/firmware/psram_board_test.fs.bin -rf"
            );
    }
    system("sync");
  }
  return 0;
}

Depending on the return value from /dev/tp_adc device, adc_test write FW3102 or FW3202. In my case, adc_test always returns different values in the range 0x4DC - 0x4E0. The question is what is the driver tp-adc.ko, what is the device /dev/tp_adc? Why are different values returned? Maybe TP - Touch Panel (see datasheet F1C200s).

I also found a hardware way to increase the processor core voltage without increasing the FPGA supply voltage.

carlosedp · « **Reply #230 on:** July 12, 2021, 03:48:09 pm »

Hey David, first of all thanks for your awesome hacking into it!

Any idea if the UART decode in asc/hex could be made into a script or config? Would be pretty great!

Quote from: DavidAlfa on June 04, 2021, 01:01:38 am

People complained about the UART decoding only showing HEX data.
It was extremely easy to patch the phoenix binary to show ASCII:

Sync decode patch:

Monitor patch:

DavidAlfa · « **Reply #231 on:** July 12, 2021, 11:47:13 pm »

I've had a hard time searching for a simple tool that parses binary files searching for a pattern just like grep does for text files.
Most options used perl or python, not an option here, these libraries use a lot of space and are messy.

Then I found this guy, who seems to have gotten into my same situation, and wrote his own tool.
https://github.com/tmbinc/bgrep

It worked like a charm. I cross-compiled it, it's uploaded into the folder mods/static binaries.

Patching is easy. Configuring isn't. There isn't a known way to modify the system menu, everything seems to be hardcoded inside phoenix app.
The xml files do nothing else than defining the strings.

I made a simple script with that tool, and worked perfect.

I'm tired, tomorrow is another day! Scripts coming soon!

DavidAlfa · « **Reply #232 on:** July 13, 2021, 11:07:52 am »

Update package ready. Check mods/patcher.
Patcher for enabling uart ascii decoding and plot color modding. Uses pattern search so it should work on any version.
Usage is simple: set the options to 1 or 0 in the file patch_values.
The patcher always uses a clean copy of phoenix, so setting it to 0 will revert that option to defaults.
For the colors, also set in patch_values, use any RGB color picker. Values must be in HEX!
The dso software applies some processing to the colors: White, black or any grey are always painted with the same shade of grey shade.
Sorry if you loved 50 Shades Of Grey!

tifkat · « **Reply #233 on:** July 13, 2021, 11:22:15 am »

Any chance of updating the first post with all instructions, or a link to the Google drive location, and a full doc in there?

DavidAlfa · « **Reply #234 on:** July 13, 2021, 12:29:08 pm »

Each folder in drive has it's own info.txt with instructions.
If you don't see the GDrive link, check your eyes and have a look at my signature!

carlosedp · « **Reply #235 on:** July 13, 2021, 01:07:17 pm »

That is pretty awesome, just patched mine and it's working perfectly... I went LeCroy scheme, channel 1 yellow, channel 2 magenta and FFT cyan.

You know what would be awesome (I don't have the binary so can't search for it)... having the bottom channel label(where it shows the coupling, BW, volts/div) in the same color as the trace

Any idea if it's possible?

DavidAlfa · « **Reply #236 on:** July 13, 2021, 02:42:05 pm »

No idea. That requires more reverse engineering and lots of spare time.
Don't have the binary? Take it from any decrypted update, then have fun with guidra!
The binary is Phoenix, everything is in the Gdrive folder.

carlosedp · « **Reply #237 on:** July 13, 2021, 06:18:54 pm »

Since yesterday I've applied a couple of mods to my DSO2D15:

- Overclock to 720MHz
- Lock-up fix
- Patching to trace colors and ASCII UART

I've noticed that every couple of minute while on, it does the "hardware initialize" again pretty quickly (like 1-2 seconds) with the progress bar and clicks some relays. It didn't do it previously... any idea which mod might be causing this behavior?

Thanks!

DavidAlfa · « **Reply #238 on:** July 13, 2021, 06:38:19 pm »

That's the lockup fix. Instead permanently freezing and requiring manual power cycle, it restarts the process.
You might be overclocking too much causing the crashes. For now disable the overclock, to make sure it's not teh software.
Anyways, I hope you first made a backup.

carlosedp · « **Reply #239 on:** July 13, 2021, 06:56:42 pm »

Just tuned-down the overclock to 684(18 mult) and it stopped re-initializing... you were right!

Ah yes, I did it... BTW, I believe the backup_builder is not "compatible" with the lockup fix... when it reaches 35%, the process restarts and the backup files are not created.

DavidAlfa · « **Reply #240 on:** July 13, 2021, 07:52:41 pm »

So your are doing things backwards? Modifying first?

Yes, backup builder kills phoenix to stop it from using all the cpu power, otherwise it would take ages.
Edit: Updated the lockup monitor to exit when a system update is started. Run the new installer.

The colors are set in the image resources, so you'll have to modify these files.
This great guide explains how to open them (section 6.2):
https://www.eevblog.com/forum/testgear/upgrading-the-hantek-dso4072c-osciloscope-bandwidth-from-70mhz-to-200mhz/?action=dlattach;attach=848068

carlosedp · « **Reply #241 on:** July 13, 2021, 08:28:53 pm »

Nice, gonna take a look at the PDF.

Nono, I did the backup first but tried to take another one after the mods were applied and noticed it

carlosedp · « **Reply #242 on:** July 13, 2021, 09:25:32 pm »

Just modified the icons... one question... can you modify the patch script (dso3kb_patcher.upk) to do something like copy and overwrite any file in the "icons" directory from the USB root to /dso/app/res/drawable and also "chmod 777" it?

You might ask why the hassle... I'm a little colorblind so having the traces yellow and green messes up a bit in my eyes.

DavidAlfa · « **Reply #243 on:** July 13, 2021, 10:27:58 pm »

Make your do_other_update script and execute it with script launcher.

Code: (do_other_update) [Select]

cp -rf /mnt/udisk/icons/* /dso/app/res/drawable/

No need of chmod-ing anything.

carlosedp · « **Reply #244 on:** July 13, 2021, 10:47:32 pm »

Yay, did it! Although I changed the "voltage2.ico" the small voltage arrow was not replaced... gonna investigate a bit more

Thanks David!

DavidAlfa · « **Reply #245 on:** July 13, 2021, 11:45:17 pm »

You missed:
vb_ch1_xx.ico
vb_trig1_xx.ico
vb_ch2_xx.ico
vb_trig2_xx.ico

voltage1.ico and voltage2.ico are both green, don't ask me why.

carlosedp · « **Reply #246 on:** July 14, 2021, 01:51:36 am »

It did it! I've posted the modified patcher package and the magenta icons into the public folder of your drive.

DavidAlfa · « **Reply #247 on:** July 14, 2021, 11:57:51 am »

Not bad, but you could do it in a single package. Simply copy "icons" into package folder.
Then in the script:

Code: [Select]

cp -rf $WORKPATH/package/icons/*.ico /dso/app/res/drawable/

Also, since you made specific icons, you want the plot to match their colours.
So user adjustable settings make no sense. So I modified your package.
I modified the patcher packages to also backup drawable, and tar.gz everything, so it uses very little storage, less than 200KB.

DavidAlfa · « **Reply #248 on:** July 14, 2021, 01:00:28 pm »

I noticed you missed a small detail. Please change the math gnd icon to match the plot color!

Then I'll make a "Themes" folder. Now we can have any combination. Looks nice!

The measurings text is still displayed in yellow/green, I'll try to find where the color is set.

carlosedp · « **Reply #249 on:** July 14, 2021, 01:55:39 pm »

Just dropped the cyan math icons into my writable "icons" folder.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Hacking the DSO2X1X (Read 141147 times)

Share me