EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: Mark5 on March 18, 2021, 08:42:55 am
-
Here's how you can "hack" your DSO2X1X and turn it into a DSO2D15 :
All you need is :
1) A FAT32 formatted USB stick
2) The latest firmware update (http://www.hantek.com/download?word=dso2C10&sid=0&pid=0&key=fjzl (http://www.hantek.com/download?word=dso2C10&sid=0&pid=0&key=fjzl))
3) A text editor.
Copy the firmware update to the root of the USB stick (after « unraring" it of course)
Create a file named do_other_update in the root of the USB stick (no extension, no .txt just do_other_update)
Add the following two lines in the do_other_update file :
sed -i 's/DSO2.1./DSO2D15/g' /cache/system.inf >/mnt/udisk/sed.log
sed -i 's/DSO2.1./DSO2D15/g' /dso/app/sys_inf.new >>/mnt/udisk/sed.log
/!\ Make sure that the file is UNIX formatted (ie line breaks should be unix style, you can check that with notedpad++)
Then all you have to do is launch the firmware update from the oscilloscope.
Please note that the AWG will only work if the PCB is fully populated (it doesn’t work on my 2C10 because the DAC, a relay and some other stuff are missing).
I know for sure that SOME 2C10 (early version as far as I understand)) are fully populated but not all.
I take no responsibility if anything goes wrong. All you do is at your own risk.
Technical stuff :
All this wouldn't have been possible without the help of @tinhead who provided the updater decryption key to the community. Kudos to him.
Now let me explain how I found how to hack the 2X1X :
Once the firmware update was decrypted and extracted, I looked into it and found the shell script that the scope launches in order to do the update.
This script name is do_update.sh
Here's its content (I removed all commented stuff for the sake of readability)
#!/bin/sh
WORKPATH=/dso/var/run
echo "-------------------update start------------------"
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc
cp $WORKPATH/package/spi-fpga-tn652.ko /dso/etc
cp $WORKPATH/package/load_fpga_kb.sh /dso/etc
if [ ! -d /dso/app/home/ref ]
then
mkdir /dso/app/home/ref
fi
if [ -f /mnt/udisk/do_other_update ];then
chmod +x /mnt/udisk/do_other_update
/mnt/udisk/do_other_update
fi
echo "-------------------update end------------------"
sync
sync
sync
Notice the last if statement.
This is meant to execute arbitrary code from the file do_other_update if this file is present in the root directory of your USB stick.
I then checked the updater priviledge level by creating a do_other_update file containing the followng code :
whoami >/mnt/udisk/whoami.txt
The content of whoami.txt was root. Which is good. Very good indeed.
Now that I knew that the update was being executed as root, I was able to check various important stuff, like the mtd mapping and content of the mount table.
And I was also able to dump the whole firmware using dd (I know that dumping as live system with dd is not the best idea but it can still be quite usefull).
So I added this in my do_other_update script :
ls / -R >/mnt/udisk/ls.txt
dd if=/dev/mtdblock0 of=/mnt/udisk/mtd0_boot.bin >/mnt/udisk/dd.log
dd if=/dev/mtdblock1 of=/mnt/udisk/mtd1_cache.bin >>/mnt/udisk/dd.log
dd if=/dev/mtdblock2 of=/mnt/udisk/mtd2_dtb.bin >>/mnt/udisk/dd.log
dd if=/dev/mtdblock3 of=/mnt/udisk/mtd3_kernel.bin >>/mnt/udisk/dd.log
dd if=/dev/mtdblock4 of=/mnt/udisk/mtd4_rootfs.bin >>/mnt/udisk/dd.log
dd if=/dev/mtdblock5 of=/mnt/udisk/mtd5_data.bin >>/mnt/udisk/dd.log
This gave me a dump of each mtd partition (unfortunately, the first time I tried this, my USB stick died and I had to do it again).
Of course this process took quite a long time but it finaly ended and I was able to check the content of my USB stick.
The first line (ls -R) was really helpful because it contains a listing of ALL the files stored in the rootfs.
Then came another update from Hantek. After decrypting and unpacking, I noticed a new file named system.inf
The content of that file looked like this :
[machine]
Model=DSO2C15
Vendor=Hantek
Product=undefined
Manufacturer=undefined
Serial=CN0000000000000
[version]
Pcb=000.000.000.000.000.000.000.000
Keyboard=undefined
[language]
Lans=65535
Language=2
[add]
Start=0
Update=0
I searched my ls -R listing and found that same file located in /cache/system.inf
Once again, I modified the do_other_update script so it copies that file from my scope to the root of the USB stick.
cp /cache/* /mnt/udisk
Looking into the system.inf, I found MY model and serial number.
The last step was to write the small sed command in order to modify the model number from 2C10 to 2D15, and voila.
Feel free to comment and report success (or not).
Cheers,
Mark5
Edit : typos and firmware link.
-
Well done. :clap:
And where did the /dso/app/sys_inf.new came from?
-
I think it is used by Hantek to initialy set the model number.
Since they may check this file in future updates, I thought it'd be a good idea to edit this one as well.
But as far as I know it's not used in normal case.
-
Keyboard=undefined .. It could be entirely practical to bring up a root console onscreen with that do_other_update (Provided a USB hub works to operate both the keyboard and USB drive at the same time).
There is a button hidden on the underside of the PCB, accessible through the venting holes under the unit. Likely to reset into a bootloader mode.
-
@Mark5. Thank you very much for the above.
2 questions:
1. Would the file do_other_update have to be created every time Hantek issues a new upgrade or just the first time?
2. Without an actual 150MHZ signal to test out the hack how can one confirm that the hack actually works?
-
thanks, it worked perfect on DSO2C15
-
Did anyone actually populated the missing components x1, u18, u35 and then Hacked the DSO2C1x to enable the AWG or you were just lucky and the AWG components were already on your scope?
-
@Mark5. Thank you very much for the above.
2 questions:
1. Would the file do_other_update have to be created every time Hantek issues a new upgrade or just the first time?
2. Without an actual 150MHZ signal to test out the hack how can one confirm that the hack actually works?
1) Once the model has been changed, there's no need to change it again. So no.
2) Some lucky "beta testers" had a 2C10 that were succesfully converted to 2D15 with the AWG working as expected.
-
That Button underneath the unit puts the Allwinner F1C200S CPU into FEL mode.. Some generic documentation here:
https://linux-sunxi.org/FEL
sunxi-fel.exe --list --verbose
Warning: no 'soc_sram_info' data for your SoC (id=1663)
USB device 009:003 Allwinner 0x1663
sunxi-fel.exe version
Warning: no 'soc_sram_info' data for your SoC (id=1663)
AWUSBFEX soc=00001663(unknown) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000
It is communicating with the Allwinner CPU through the back USB connection, though it looks like generally need to attach directly to the UART interface to do much more with it. Could dump/debug active memory over the interface.
sunxi-fel.exe hex 0 47000 spits out a whole bunch of raw memory into in Hex format.
-
I might also be possible to gain ssh acces through the back USB port.
Dropbear is present in the filesystem. I'd have to look how (and if) it is launched.
-
Connecting the DSO2D15 in FEL mode showed up on my system as the SNES mini.. The USB idenifier used in FEL mode was common to the Allwinner R16 found in those recent Nintendo Mini consoles when they're also placed in FEL mode. (Basically a Firmware recovery mode)
Hakchi2 is an open source program for unlocking and loading additional data into those mini consoles' flash memory could give us a good foundation examples for accessing the onboard memory and firmware of those Allwinner chips. While the F1C200s is newer than the R16, there is likely much that remains in common, besides some changes in the boot memory mappings.
It would be somewhat amusing to run some classic games onscreen.. Its all entirely possible to do from that FEL mode.
-
At some point my DSO2D10 hanged when I rebooted it. It only Initialized the hardware to 80% then it hanged.
I reported it to Hantek after which they've send me the platform tools as well as Phoenixsuite_CN to be able to reload the .bin files directly through the rear USB connector to the usb port of the Allwinner controller. This cleared the problem and it could reboot normal again.
When the bottom button is pressed during booting to put it into FEL mode ,Sunxi-fel is used to convert the Allwinner to an Android system. It will show up on the PC's Device Manager as an Android Device. This is accomplished using Phoenixsuite_CN then all the .bin files can be programmed directly onto the Allwinner via its USB port.
-
The FEL mode could be used to load and execute temporary custom programs into RAM memory and execute it over the USB. This has potential to read and write changes into the existing firmware and further explore RAM or Flash memory from the common USB port.
Yes, FEL is primarily used for base level firmware loading and disaster recovery, but its capable of temporarily loading a custom set of instructions into the CPU's RAM and then executing them without modifications to the system.
Basically an factory self testing and initial firmware loading mode.. but it does leave the system fully open to modifications without relying on the internal Firmware update scripts (that could be changed in future updates).
-
Strange, I have both calibrations in the factory device, but the amplitude does not work either.
-
@VISTORIK, Your explenation on how to use the platform tools and PhoenixSuit_CN is nicely done.
Regarding the Amplitude Calibration, it does nothing.
When I queried HANTEK about this they told me its only necessary to do the Offset.
Answer from wangshuang@hantek.com "Users don't need to perform amplitude calibration."
-
I see your notes mention:
fastboot flash dtb images/suniv-f1c100s-licheepi-nano.dtb
So this scope is technically a F1C200s based Lychee-PI-nano as its foundation .. That makes documentation research much easier.
Still missing the actual Platform tools posted by Cmaass
Uboot features a UMS mode that can present the onboard storage as a USB mass storage device to the host, Provided the right platform drivers (DeviceTreeBlob)(.DTB) have been loaded to access the SPI NAND.
-
For reference the: The Lichee PI Nano, this image was posted previously by
@GeorgeOfTheJungle: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3145826/#msg3145826 (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3145826/#msg3145826)
-
Mark5, you are not the first to hack this device. The first was the Chinese from Hantek who provided platform-tools.
I definitely agree with that : people from Hantek were the first to hack their own scope.
And I'm pretty sure they can hack every model they sell ;D
-
How can one get a copy of these Platform Tools?
-
I will upload the Platform-Tools on the Filemail.com server since it is too big to post on this forum.
Will post the link as soon as it is ready.
It will take a while since my upload speed is slow ;D
-
You can also download the platform-tools here.
You have 7 days to download the file.
PhoenixSuit_CN is included in the file.
Remember to read the readme_English.docx on how to use the tools.
All the files are included in the one .rar file so the file is much smaller than the file posted by vistorik Its 114.28 Mb in size.
Please read the post by vistorik of a description on how these tools are used. Reply #13 on: Yesterday at 01:47:56 pm
https://www.filemail.com/d/advzemzwfpioyvw (https://www.filemail.com/d/advzemzwfpioyvw)
-
@ Algoma. Getting back to your post Reply #72 on: January 29, 2021 on the topic. New Hantek DSO2X1X models?, regarding the ADC numbers that you speculated about.
When I did the dot test then in Single Ch. mode I could get only 1 dot every 2ns at 1Gs/s thus 500 Ms/s. After I hacked the scope to 150MHz, I now get two dots, thus 1ns sampling which relates to 1Gs/s..
Thanks Mark5.
-
Thanks for the info. I have some advice for newbies (like myself)...
Perhaps foolishly, I tried the firmware/SED hack on my brand new DSO2C15 hoping the board was populated for the AWG, but without checking.
Bad idea, my machine transmogrified into a DSO2D15 and the WAVE-GEN button lit up, scope menus updated etc. but no output signals. OK, missing components, no harm right? Well yes actually... the scope can no longer calibrate and other operations gave errors too. I also discovered that the hidden files my Mac puts on the USB stick cause problems, gotta delete them before trying to update firmware. That may have been part of my problem...
Anyway, long story short, I erased the USB drive, loaded a new copy of the firmware from Hantek, cleared all the Apple .junk off it and edited your SED script to revert the machine from D15 back to C15. It worked perfectly and now I can calibrate and use everything I paid for :-)
Hope this helps. I'll be interested to see if anyone bothers to install the missing components and if that works but right now I'm glad I didn't brick my new toy.
-
@ boyeen, if ever you brick it you can use the platform-tools to unbrick it. :)
You can still download the tools from this post Reply #22 on: March 22, 2021, 06:26:19 pm
-
I looked at my C10. Haven't hacked it yet, but soon.
-
Making Progress, Custom Boot Logos at least...
(http://[attach=2])
Using the platform tools you can upload custom logo.bin to the logo partition.
Boot Scope into FEL mode by holding the button underneath at power on.
Connect to PC with zadig-2.5 WINUSB driver loaded to support connections to the Allwinner in FEL mode.
sunxi-fel.exe uboot images/uboot_fb.bin Boot the Scope into a basic Fastboot mode, the screen backlight should come on, some random color lines may appear on the screen.
fastboot flash logo images/logo3.bin This line flashes the Logo into the LOGO partition
fastboot reboot Reboot the scope and load the operating system.
You can copy the existing logo3.bin found in the Platform-tools\images folder, rename it to logoTEST.raw
This raw image file can be loaded into a photo editing program that supports opening raw images. In this case I used Corel Paint Shop Pro to open the RAW image.
Import settings were 1600 Width x 480 Height, Single Channel Greyscale, Interleaved, RGB Order
If you call the TESTLOGO.DATA then GIMP (GNU Image Manipulation Program) will basically do the same thing.
Once you edit the LogoTEST.raw and save the file, rename it back to a logoTEST.bin file of your choosing, then upload it to to logo partition on the scope.
FEL Mode -> Load Fastboot as above -> fastboot.exe flash logo images\logoTEST.bin
Results are still Work in progress, trying to figure out REAL size and data format. Likely may need to custom written a converter to properly support full color images. Works alright if you stick to Generally high contrast Black and White images till we figure out the exact format of that logo .bin file.
That images\logo.bin file is a curious one, at a RAW resolution of 320x800 Greyscale Interleaved RGB, and Rotated upside down... Anyone heard of FOX? I don't recognize the logo in that file.
-
Okay, Looks like GIMP is the program to
edit view the logos
logo3.bin format: Andriod RGB565 Little Endian 800x480
Now to find a program to save in that RGB565 format..
-
Used Paint.NET
https://www.dotpdn.com/downloads/pdn.html (https://www.dotpdn.com/downloads/pdn.html)
With Plugin from here:
https://forums.getpaint.net/topic/16747-rgb565-android-splash-screen-format/ (https://forums.getpaint.net/topic/16747-rgb565-android-splash-screen-format/)
Converted the image into .RAW 565 format (Renamed to .BIN) and uploaded to the scope's LOGO partition.
Colors are a bit off (Missing red color), but its progress, You can upload up to a 2MB image in the LOGO partition, provided you can get it converted to RAW RGB565 format in 800x480 size. Adobe Photoshop has the required feature built right in (but I don't have photoshop).
resulted in:
[attachimg=1]
-
Nice work Algoma !
I was planning to do the same but I was using https://rawpixels.net/ (https://rawpixels.net/) to determine the image format.
Images found in the file system are slightly different. There's a 8 bytes header (2 * 4) which contains width and height.
Knowing that, we could change every icon used in the GUI os the scope.
-
Came the memory and programming. I asked again, everything worked out Thank you Vitroks and Mark5 for the help provided.
-
Well, I have sourced the 3 missing parts for the AWG...( DAC, OP-AMP & RELAY)... the relay has to come from China but I got the others in a few days from Arrow/Digi-Key. When I get everything I think I’ll have a go at installing them. Has anyone tried this yet? One question I need to resolve concerns the strap options on the board next to the (unpopulated) Relay. Not sure if I need to cut a trace or whatever. I’ll have to figure that out by buzzing the board I guess.
Anyone come across a service manual or schematic?
Anyone with ideas or feedback to share let me know. When I get the Relay from China I’ll be sure to take some photos and share my experience.
-
What strap are you talking about?
-
This image of the front end posted by @microcheap : https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3515614/#msg3515614 (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3515614/#msg3515614)
Looks like L9 isn't populated while the relay is present, so likely L11 isn't used either.
So it's likely enough to simply install the missing relay. Thankfully it seems the passive array around the Wave Gen OpAmp is usually already populated.
-
vistorik, this relay is closed, I already wrote about it here. Jumpers L11 and L9 are connected in parallel to the relay contacts, and can be soldered in the absence of a relay. If the relay is present, there are no jumpers.
-
Again, this is a DSO2C10 board, NO relay. I DON'T see any jumpers on L9 or L11!
-
Check with a tester L11. Check external sync. Does she work for you?
-
Dang it's hard to post pictures here...
I promised an update when I upgraded my DSO2C15 to a DSO2D15 by installing 3 missing components on the motherboard.
It was a hairy install as I have soldering skills but not of surface mount and the DAC is horrendously small pitch.
However, it works...
The missing parts were easy to find:
DAC : DAC902E (Arrow)
OpAmp : LMH6702 (Arrow)
Relay : FD4/4.5-S |428||282| XA0920A (EBay)
Total incl. shipping was under $27
-
Well done !
I may try to do the same in the following month.
-
Thanks Mark,
The relays I ordered from China came in a pair... you are welcome to the other one if you want it. Are you in the US?
-
Alas, I'm definitely not in the US. Right on the other side of the pond, living in the country where people eat frogs ;D
Anyway, thank you very much for your offer. It's too bad as shipping would have cost you 10x the price of the relay.
-
So it's nearly the same cost as getting the DSO2D10, with the Wave Gen parts already installed, and then upgrading it to a DSO2D15 through software.
Though your DAC902E you've installed is now proven genuine TI part, while the chip in the scope could still possibly be a lower cost clone part... Yeah, there are definitely some sketchy looking obvious clone parts available on Aliexpress.
Though this also resolves the known part number is correct, and make the function gen fully repairable if we accidentally blow the output. That's what I like about this scope's Design, basic, simple and easy to follow, and so many of the parts appear possibly to be genuine TI. That large ADC they put is here is quite an awesome part if you dig into its datasheet, I look forward to Hantek making better use of it with firmware updates.
-
I agree, the scope is basic and simple but easy to work on. It hangs occasionally on me (before my upgrade :-) when I do something advanced (FFT?) but a quick on/off restores it. Maybe it will get better with firmware upgrades. Meanwhile I have no complaints. My ESP32 projects certainly don’t require any more. Probably they don’t justify even this scope but I have always wanted one. I have a couple of the MINI-DSO units which are so fiddly to work with and not much cheaper...
The other evening I had a blast generating Lissajous figures with my iPhone as function gen... great fun.
-
G'day all! and thank you heaps for all the good work you've been doing..
My 2C10 came with the AWG components installed, lucky me!
I would like to enable the AWG in the simplest way as possible.
I have read the "Hacking the DSO2X1X" thread and got a bit scared, especially by the need to write in the correct format and load the "do_other_update" script.
I use a Mac and I'm not sure whether Apple's TextEdit will do the trick. I'm NOT a script writer!
I will update to the latest F/W, but is the Model name change script necessary to make the AWG work?
Thanx & regards,
lm
-
Yes, the script is required. It's the script that changes the model from 2C10 to 2D15, hence enabling the AWG.
On a Mac, I'd suggest you install and use bbedit (freeware version) to create the do_other_update script.
FWIW, the risk of bricking your scope is close to zero (unless you add a "rm -R /" in the script).
And even bricked, there's a way to recover to a fully working state using the platform tools.
-
Much appreciated Mark5,
I will try and report..
also very impressed by your opening post on how you developed the hack and the step-by-step dissection of the F/W..!!
lm
-
As one Mac user to another, the problem you might have is those pesky "hidden files" that OSX adds to removable media. Like .Trashes or .Spotlight-V100.
You MUST get rid of those before putting the drive in your Scope. I used Terminal as follows... sorry if this is too remedial, but you said you are not a script guy.
My USB drive was called "THK"
cd /Volumes
ls
Macintosh HD THK
cd THK
ls -la
total 3840
drwxrwxrwx@ 1 tim staff 16384 Apr 15 17:48 .
drwxr-xr-x 20 root wheel 640 Apr 15 17:43 ..
drwxrwxrwx 1 tim staff 16384 Apr 15 17:48 .Spotlight-V100
drwxrwxrwx 1 tim staff 16384 Apr 15 17:48 .Trashes
-rwxrwxrwx 1 tim staff 137 Apr 15 17:47 do_other_update
-rwxrwxrwx 1 tim staff 1896592 Mar 11 16:00 dso3kb_20210311.upk
rm -r .Spotlight-V100 .Trashes
ls -la
total 3776
drwxrwxrwx@ 1 tim staff 16384 Apr 15 17:49 .
drwxr-xr-x 20 root wheel 640 Apr 15 17:43 ..
-rwxrwxrwx 1 tim staff 137 Apr 15 17:47 do_other_update
-rwxrwxrwx 1 tim staff 1896592 Mar 11 16:00 dso3kb_20210311.upk
cd
The last "cd" command is important or OSX won't let you cleanly eject the drive because Terminal is still "in it"...
Hope this helps
-
Hi Boyeen,
that's absolutely invaluable, I'll get on with it tomorrow.
Many thanx
lm
-
Boyeen, Mark5 and all..
reporting all good and well.
Model # hack and F/W upgrade done with minimal effort... I mean, given up on the Mac trying deleting the hidden files, too confusing for me, went instead to an old Ubuntu laptop and simply created "do_other_update" with the default Text Editor.
Reformatted the stick (FAT), copied "do_other_update" and F/W file on it, went to the scope and did the Update thing and voila, tout est bon.
Thanx again,
lm
P.S. oh forgot, AWG enabled and working.
-
FWIW, the hack still works with the lastest firmware (dso3kb_20210416.upk).
-
Hello everyone. I've hack my DSO2c10 just for checking it has no awg hardware, and obviously, it doesn't.
Now I want to come back to my factory firmware but when I install it through usb it install automatically dso2d15 firmware.
How can I come back to my original dso2c10 firmware?? I'm thinking between buying 3 parts needed for get awg working or wait for itg962 or something like that.
Thank you and I hope you can help me.
Kisses.
-
Hi,
Mark is infinitely more qualified to help you than me but I will have a go at least. He can correct me when I get it wrong.
I think the problem you are having is that you changed the device ID from DSOC10 to DSOC15 in the "do_other_update" script.
I had this problem earlier when I tried to reverse it. I found that I had to edit the script to specifically change the device
back to DSOC10. I don't have the script handy but it was an easy edit. On the other hand it does no harm to have the device
ID be "wrong". The firmware is exactly the same... although I was unable to reclibrate automatically because the AWG chips were missing.
Speaking of the update, if you have some surface mount soldering skills it is very doable. If not, it might
be a very tricky and expensive way to learn :-) Good luck.
UPDATE: If memory serves I modified "do_other_update" as follows and it worked for me...
sed -i 's/DSO2.1./DSO2C10/g' /cache/system.inf >/mnt/udisk/sed.log
sed -i 's/DSO2.1./DSO2C10/g' /dso/app/sys_inf.new >>/mnt/udisk/sed.log
-
I see its been asked 100 times, but can i get a copy of platform tools? Im willing to host on my g drive so it doesnt expire.
-
+1
All the platform-tools links are dead! Please stop using temporal file services!
There are a ton of alternatives, Gdrive, file.io, mediafire, mega...
Fastboot can only write... Was anyone able to dump the spi contents using sunxi-fel?
-
there are the platform-tools i got from:
I had a similar problem with freezes and I was able to solve that reprogramming the system images with some files sent by Hantek's support.
If you dare, you can try it yourself. I've uploaded the files to a temporary file sharing page, the link will be valid for only 7 days before it expires:
https://www.filemail.com/d/mmnhoxtbjdututb (https://www.filemail.com/d/mmnhoxtbjdututb)
In the downloaded file you will find included a .doc text with the instructions on how to proceed.
Note 1: this procedure will blank some details on the system info screen of the scope, but that is easily fixed later if you mind the missing information. I would just recommend that you take a picture before to have as reference.
(Attachment Link)
Note 2: this images install the firmware 3101 on the oscilloscope, looks like there's already newer scopes with version 3200. Which version yours scope is running now?
https://download.gg/en/file-12180247_e6b8784930457ac2 (https://download.gg/en/file-12180247_e6b8784930457ac2)
BE AWARE, noone is responsible if something goes wrong, make backups, especially the SPI-Flash. This changed my FIRMWARE to 3101, at least works fine on my scope
my scope is the DSO2D15, original firmware 3000
I had no backup and tried the 20210510 firmware, my firmware changed to 3202...sadly my 2nd channel was random offset, calibration was broken with the 505...something error.
so i was lucky to get the platform-tools last time they were uploaded to filemail.
however, following the readme_English.docx i had to reboot my Windows 10 20H2 to get the Android device recognized properly.
with the sunxi-fel uboot images/uboot_fastboot.bin my scope wouldnt boot to the phoenix frontend.
but with only using the commands from cmds.bat it works just fine.
afaik there are 3 firmware versions i am aware of which could be cause of hardware changes onboard or in the fpga which are not compatible between firmware 3000/3101 and 3202.
interestingly enough, a dmesg on the scope shows it booting [ 0.000000] Linux version 5.2.0-licheepi-nano (root@ubuntu) (gcc version 5.4.0 (Buildroot 2017.02.5)) #122 Tue Jan 19 10:01:16 CST 2021
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317fI am gonna order me the Sipeed Lichee Pi nano board to play around with, still waiting so they translate the documentation to english and fix broken links.
also im gonna try reverse engineering the phoenix app with ghidra to see if i can change the functions of the scope to what i expect from it (f.e. i want ASCII shown when i am decoding iic or spi, hex only is somehow no enough for me)
-
Thanks for uploading!
Mine arrived today. I've managed to crash it in the first minute :-DD
Model DSO2D10
SW 1.1.0(202012221.00)
HW 000.000.000.000.000.000.001
FW 3000
Calibration shows error 50041.
As the platform tools instructions, I installed WinUSB driver for the device "USH Device(VID_1f3a_PID_efe8)"
After that, running sunxi-fel ver showed:
AWUSBFEX soc=00001663(F1C100s) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000
Then I tried to dump the 128MB SPI contents: sunxi-fel.exe spiflash-read 0 134217728 orig.bin
It takes about 15mins. However most of the file reads 0, with patches here and there. Doesnt look nice!
Can anyone upload their backup to compare?
Edit: Running sunxi-fel.exe spiflash-info shows:
Manufacturer: Unknown (00h), model: EFh, size: 1024 bytes.
EFh is correct for the 25N01G, but it seems that FEL or whatever is unable to correctly detect/handle/identify the SPI flash.
So, I guess I'll have to open it and use my good old friend CH341A.
Do you remember how hard/expensive these things were before the Arduino boom, in the years 200x or before?
I you told me you got an USB programmer for $3 I would told you were fuc*** nuts!
I thought desoldering the memory was going to be harder thanks to the ground pad. But it was pretty straightforward.
Since I didn't have any kapton, I just used kitchen aluminium foil, folded to make 4 layers(more isolation), and cut a window for the memory. Easy.
wson and soic have similar footprints, so the pcb adapter I had worked well. But the bottom pad can cause shorts to the soic pins!
Clean the pads thoroughly and make continuity checks before powering it up!
Also remember that most CH341 programmers output 5V! This memory is 3.3V only! However you can mod the programmer to use 3.3V.
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1223749)
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1223751)
I've been unable to read anything from the serial port. Rx and Tx are always at 3.3V.
I'll make a Gdrive folder with all the tools, documentation, updates, dumps... It would be nice to have dumps for every HW revision just in case someone loses it, who wants to contribute?
-
You can also simply copy, move, rename or execute contents of the internal filesystem to and from your USB drive during the Do_other_update procedure that is executed during a firmware update. It can executes most basic Linux commands, and could run arbitrary code from your USB drive.
Of course a full off-board image will properly backup all the other hidden partitions before picking at the file system.
-
I know, but that's not useful when you mess up the system.
It's easy to fu*** everything up! Just touch something you shouldn't, or make a mistake...
Definitely needing to disassemble everything, desolder the flash with hot air, solder to the programmer pcb, wait 20min for programming, desolder from the adapter, solder back to the PCB and assemble everything back, can be called a lot of things, but absolutely not "hacking friendly".
So I decided to hack the hack!
I opened a SD card adapter, embedded the flash with a 22uF cap and glued everything together.
Made 2 adapters with SD slots.
One for the CH341 programmer, other soldered to the Hantek PCB using twisted pairs to avoid noise.
The result is great, now I only need to remove 4 screws for programming.
I could make a slot in the housing for direct access, but it's sad to break it on the first day!
(Yeah, I have a ton of parts that my company was going to send to waste, so I got them. About 8kg of small parts!),
-
So the calibration worked after trying again.
Updated to the 20210510 fw, it completely broke calibration.
Tried 20210416, the error is still there.
Edit: Because 20210510 changed FW version. After restoring the backup, 20210416 works nicely.
A very interesting option would be to chroot the system, and use an external USB drive.
That way restoring the system would be a breeze. I'll have too look at it!
I want to enable the shell so badly....!
-
I know I already said this in the other DSO2x1x thread, but I think it's relevant.
I took everything I found for them and made a Gdrive folder here:
https://drive.google.com/drive/folders/1Tqk8YbL_M3S0vtk7h_cZ-01U2idIaqqx
I'd appreciate if you guys send different original dumps to have handy!
For example, updating to the 20210510 changed my FW version and there was no way to restore it back without the dump.
So it's better to have them, someone could make a mistake...
-
DavidAlfa great work with the GDrive folder :-+
nice collection of firmware-updates there.
i did spot that the '20210517' is a lot larger than the others, there is a different platform-tools included!
did reflashing the spi-flash with your dump put you back to FW3000?
Im off work from thursday to sunday due to a holyday here, so i will have some time to look into all this information :D
btw '20210510' system.inf file has some weird hacks in it
[machine]
Model=250M$DSO2C10
Vendor=hantek
Product=DSO
Manufacturer=hantek
Serial=CN21030229002304
[version]
Pcb=501.001.001.000.000.000.000.000
Keyboard=1
[language]
Lans=65535
Language=3
[add]
Start=0
Update=0that is part of hacking the DSO4xx4B/C , check the section 3.4 Extending the Bandwidth by Software
in the PDF file at https://github.com/WiZZteXX/DSO4xx4c. very strange someone from Hantek would put that into the DSO2000 series system.inf (not to mention that we are somehow running on the dso3000c 'line' of scopes :-DD
-
Yes, in fact it's the only way to restore FW version. You can rollback any update, but it wont restore or change your FW version.
How do you extract the data from the rootfs images? I'm a bit confused with so many ubi files.
NeoProgrammer + CH341 writes the data in ~11 minutes, as it's clever enough to skip 0xFF sections (All the memory become FF after chip erase).
A little hint: Remove the usb drive before connecting the oscilloscope to the computer.
I left mine plugged in, the USB enumeration was resetting like crazy.
I thought my computer went nuts!
Since my usb is small, low profile type, I didn't notice it was plugged in. I lost 10 minutes of my life! :-DD
-
Im gonna have to look into extracting and building the rootfs files, all i know so far is that it's a Filesystem specially used for nand flash memory. Found a website with some links to info via google...that's why I'm so into the sipeed LicheePi nano, it's the same architecture that is used in the DSO2000 series and that's the source I'm gonna milk to find all the info.
Not giving up the hope to do everything in software ( the thing does change the FW version in software anyway)
-
WHen you see "ubi", you say: "OK, it's ubifs, supported by linux, should be easy as executing few mount commands..."
But then you see rootfs.ubi, rootfs.ubifs, rootfs.ubifsaa, rootfs.ubifsab...
And I got lost. Didn't find info about that.
-
My calibration is lost now after messing with different firmware files.
How can I restore it? I got the DSO2C10 and can't find any guide using the platform tool thing I've spent hours and still stuck without calibration.
any help would be appreciated!
-
Did you make a backup?
None of the available firmwares restored my FW version, neither the platform-tools.
I had to fully restore the backup.
-
No backup unfortunately what are my options at this point?
-
I've been only one day with it... You can try contacting Hantek, or you can remove the SPI flash and program it.
I uploaded my 2D10 dump... could work.
Added to Gdrive some system logs (dmesg, cpuinfo, ls...) and most system files (bin, sbin, usr, etc...).
I found lighttpd server. So LAN port might be operative in the kernel.
-
I've see your folder which is awesome I just can't figure out how to update the spi flash using the dump files you provided I got lost.
The thing is everything is working its just that the calibration gives me an error every time I calibrate. Did you manage to get calibration back?
-
Yes, by restoring my backup. As long as my FW version is 3000, calibration works.
The backup is done with a CH341A programmer. You'll have to remove the flash...
Luckly someone will figure out how to program it from FEL, or how to extract the partititions from the dump and flash them using fastboot.
-
Btw i also used the 10/5 firmware which put me to firmware 3202 and with the platform tools I went back to 3101.
With 3202 calibration was broken, channel 2 was random offset.
With 3101 calibration worked just fine!
That from original DSO2D15 fw 3000.
So platform tools with original fw 3000 should fix everything... The question is how we get that from hantek :)
-
But how to calibrate amplitude in 31xx?
-
@VISTORIK, Your explenation on how to use the platform tools and PhoenixSuit_CN is nicely done.
Regarding the Amplitude Calibration, it does nothing.
When I queried HANTEK about this they told me its only necessary to do the Offset.
Answer from wangshuang@hantek.com "Users don't need to perform amplitude calibration."
We are not supposed to, only offset... Im gonna find out as soon as I find it in the firmware and/or phoenix app which is the frontend.
Iirc there is an older folder with the file system provided with the platform tools i have, didn't try it yet, but remembered it before falling asleep, will have to test it and see what happens.
-
Try it, and share if the sw version is different than those in the folder! :)
-
Do you have a link to the original firmware and maybe instructions on how to do it with the platform tools? I'm still lost and don't have calibration
-
Check my Drive folder! Download the platform-tools version you like.
Versions 3101 and 3102 calibrate ok in my 3000.
Check readme inside platform-tools.
You have to push the button below the DSO, power it on, then release.
Open zadig, check show all devices, select "USH Device(VID_1f3a_PID_efe8)", then select WinUSB, click on install driver.
Open a cmd window in platform-tools and run sunxi-fel ver, it should recognice the device.
Now run cmds.bat, it will flash everything.
-
To sad I can't play with my scope at work :(
Maybe we need a faq as pdf that stores all info from various posts, ppl tend to not read all info, like in tldr :p
-
I also uploaded the decrypted updates for easy access.
Maybe we can find what changes the FW version, and revert it back using the do_other_update script.
I noticed that the platform-tools-20210129(FW3101) comes with two set of images:
images and images_adc
The rootfs CRC is different!
Edit: images_adc files restore FW3000!
I separated these, so now we have 3 platform tools versions:
- platform-tools-20201221(FW3000)
- platform-tools-20210129(FW3101)
- platform-tools-20210517(FW3102)
Remember that flashing platform tools will set Model, Serial and Hardware undefined! Take note of these to restore them later!
I made this do_other_update to restore them automatically (edit as your needs):
sed -i "s/Model=.*/Model=DSO2D10/g" /cache/system.inf /dso/app/sys_inf.new
sed -i "s/Serial=.*/Serial=CN0000000000000/g" /cache/system.inf /dso/app/sys_inf.new
sed -i "s/Pcb=.*/Pcb=000.000.000.000.000.000.000.001/g" /cache/system.inf /dso/app/sys_inf.new
After updating with platform-tools, /dso/app/sys_inf.new file no longer exists, but it doesn't seem to change anything.
Made some scripts to backup, restore, dumps log, edit the configs... Of course, copied to Gdrive folder!
-
I managed to make a custom update package that only runs "do_other_update".
And it's only the start, as now we can make our own update packages!
Huge thanks to tinhead (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3407968/#msg3407968)!
Check it in the scripts folder, "dso3kb_run_other_update.upk"
To make your own, get some linux shell (Ubuntu VM in my case) and run these commands:
# Decrypt the firmware (Adjust dso3kb_package.upk to the package name)
gpg --batch --passphrase dso3000c --output decrypted.tar.gz -d dso3kb_package.upk
# Extract "decrypted.tar.gz". The output file should be "dso3kb.upk.tar"
tar -xvzf decrypted.tar.gz
# Extract "dso3kb.upk.tar" to "dso" folder
mkdir dso
tar -xvf dso3kb.upk.tar --directory dso
Inside dso folder, you will find "upend" and "package".
"upend" contains a listing of the files and folders stored in "package" folder.
I edited it and deleted everything, keeping only do_update.sh, Manifest.xml and special.
Did the same with package folder, I deleted everything except these files.
Last, I edited do_update.sh, deleting everything, leaving only the part that executes the script file.
Now I had to pack everything back:
# Enter dso folder and make the tar file
cd dso
tar -cvf ../dso3kb.upk.tar *
# Exit dso folder and make the tar.gz file
cd ..
tar -zcvf dso3kb_custom.tar.gz dso3kb.upk.tar
# Encrypt the file:
gpg --batch --passphrase dso3000c --output dso3kb_custom.upk -c dso3kb_custom.tar.gz
The update name must start with "dso3kb_", otherwise the update process will fail!
Copy the upk file to the usb, and enjoy!
-
DavidAlfa great work, I'm a bit jealous how much time got left to invest.
That folder where you found the FW3000 was exactly the one I wanted to flash this evening and find out what it is. Ah well, there is still stuff to figure out left :)
The allwinner F1C200s is capable of playing 1080p in hardware , even adding network / WiFi should be possible. So animated startup sequences etc.
From the F1C200s datasheet: The F1C200s is based on the ARM9 CPU architecture with a high degree of functional integration, and supports
Full HD video playback, including H.264,H.263,MPEG1/2/4 decoder. Integrated audio codec and I2S/PCM interface
provide end users with a good audio experience. TV-IN interface enables video input by connecting to video
devices such as camera, and TV-OUT interface enables video output by connecting to TV devices.
After all the Filesystem almost got 32MB free space left :)
The board for experimenting (sipeed licheepi nano) should arrive here in 10-14 days
-
The problem is that we don't have the sources.
Shouldn't hantek release their uboot/kernel sources to comply with the GPL?
About these fancy things: This is an old-school arm core. Performance is pretty poor.
It barely can move the DSO software, do you want to add more work to it? :-DD
I tried to overlock it, sadly it seems there's no module for that.
-
There is some legal info and URLs in the status informations of the scope itself, its in 'utility->F6'. The Linux itself is free. The hardware modules itself will never be. I'm not sure if there is a decompiler for VHDL, we don't have any information about that Lemontree FPGA anyway.
But the phoenix app is written in C++, had it open in ghidra some days ago, the work is just commenting the code and after playing with it one should be able to implement new functions or improve them(speeding it up with some assembler) .
The UI is written in xml and the logos are easy to open/save in
nd
One more day and I will 'rebrand' it to "Hacktek" :)
-
For overclocking the cpu check
https://whycan.com/t_3730.html
It's explained in english, the sources one needs are in the platform tools iirc. You need however to cross compile if your system ain't arm based.
Measure temperatures and slap a heatsink on, we don't want 'magic smoke' :)
-
I'd put a LN2 cooler, overvolt the core to 12V and oc it to 4GHz it if that makes the damn thing to work :-DD
Yeah, if the code/modules are propietary they don't need to share it. But the kernel, u-boot and such, yes!
That would open a nice window for hacking. I've been busy with other stuff, no time yet for guidra!
I've been trying to open the serial port, but no way.
I think the UART registers shloud be configured in u-boot. And are not.
Everything appears ok (uboot and kernel use ttyS0), but nothing comes out.
Not being able to access the console makes it very slow and tedious.
Regarding guidra, did you check the file dso/etc/check_sys_inf?
Seems it's what parses system.inf.
-
I am not sure if you guys have seen this, but George Hilliard has been working on the F1C200s and has some good information on his blog about this $1 32-bit ARM CPU:
https://www.thirtythreeforty.net/posts/2020/02/trying-the-allwinner-f1c200s/ (https://www.thirtythreeforty.net/posts/2020/02/trying-the-allwinner-f1c200s/)
And a big thank you to DavidAlfa for his excellent work. :-+ :-BROKE
-
Yeah, I saw that....
Chinese devices with no support at all, depending on user patches? Gave me headaches only to thing about it.
Will try to compile that, but when it starts with strange dependency/incorrect library versions, I spend my time elsewhere :palm:
Edit: Ater 30 min of compiling it drops error:
CMake Error at CMakeLists.txt:4 (SHLOMIF_COMMON_SETUP):
Unknown CMake command "SHLOMIF_COMMON_SETUP".
Tried deleting the games, as described here:
https://github.com/thirtythreeforty/businesscard-linux/issues/15
And it worked. Now we'll see if the files are useful for anything!
I also found this forum: https://whycan.com/f_17.html
But that's the same crap as most chinese pages, use your mobile phone, register using weChat, and pay or start making useful posts which something impossible when you are trying to learn.
Also, Baidu no longer works, my user is blocked, I guess because it's not chinese. They ask for a passport number... Sure! :palm:
Do you understand now my hate for chinese products? And Linux in general. Compiling these things almost never work on first time.
I think I figured out why the serial console doesn't work.
Rx and Tx is connected to pins 63 and 64 (TPY1, TPY2).
They're UART1_RX, UART1_TX! The system uses ttyS0, so I guess everything goes to UART0?
Edit:
After running:
stty 115200 -F /dev/ttyS1
echo "Testing ttyS1" >/dev/ttyS1
I got: Testing ttyS1
I modified platform-tools/images/uboot-with-spl-spinand.bin, editing the bootargs and replacing ttyS0 with ttyS1. The patched file is attached.
Flashed the new binaries (Booting in FEL mode):
sunxi-fel uboot images/uboot_fb.bin
fastboot flash boot images/uboot-with-spl-spinand.bin
fastboot flash logo images/logo3.bin
fastboot reboot
If I flash only uboot-with-spl-spinand.bin the boot logo is erased. That's why I also flash logo3.bin
And I got shell! Login is "root", no password.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.2.0-licheepi-nano (root@ubuntu) (gcc version 5.4.0 (Buildroot 2017.02.5)) #127 Fri Apr 30 08:59:43 CST 2021
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] OF: fdt: Machine model: Lichee Pi Nano
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16256
[ 0.000000] Kernel command line: earlyprintk console=ttyS1,115200 ubi.mtd=4 ubi.fm_autoconvert=1 root=ubi0:rootfs rw rootfstype=ubifs
[ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Memory: 54488K/65536K available (5120K kernel code, 187K rwdata, 2000K rodata, 1024K init, 209K bss, 11048K reserved, 0K cma-reserved, 0K highmem)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] random: get_random_bytes called from start_kernel+0x254/0x430 with crng_init=0
[ 0.000050] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[ 0.000130] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[ 0.000716] Console: colour dummy device 80x30
[ 0.000815] Calibrating delay loop... 203.16 BogoMIPS (lpj=1015808)
[ 0.070257] pid_max: default: 32768 minimum: 301
[ 0.070700] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.070745] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.072436] CPU: Testing write buffer coherency: ok
[ 0.074460] Setting up static identity map for 0x80100000 - 0x80100058
[ 0.076756] devtmpfs: initialized
[ 0.085338] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.085403] futex hash table entries: 256 (order: -1, 3072 bytes)
[ 0.085705] pinctrl core: initialized pinctrl subsystem
[ 0.087795] NET: Registered protocol family 16
[ 0.089365] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.091596] cpuidle: using governor menu
[ 0.128315] SCSI subsystem initialized
[ 0.128753] usbcore: registered new interface driver usbfs
[ 0.128914] usbcore: registered new interface driver hub
[ 0.129104] usbcore: registered new device driver usb
[ 0.129846] Advanced Linux Sound Architecture Driver Initialized.
[ 0.132482] clocksource: Switched to clocksource timer
[ 0.162391] NET: Registered protocol family 1
[ 0.163580] NetWinder Floating Point Emulator V0.97 (double precision)
[ 0.166212] workingset: timestamp_bits=30 max_order=14 bucket_order=0
[ 0.183004] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 0.197546] suniv-f1c100s-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver
[ 0.200060] pwm-backlight backlight: backlight supply power not found, using dummy regulator
[ 0.211510] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 0.236459] 1c25000.serial: ttyS0 at MMIO 0x1c25000 (irq = 25, base_baud = 6250000) is a 16550A
[ 0.259194] 1c25400.serial: ttyS1 at MMIO 0x1c25400 (irq = 26, base_baud = 6250000) is a 16550A
[ 0.555677] printk: console [ttyS1] enabled
[ 0.572819] panel-simple panel: panel supply power not found, using dummy regulator
[ 0.586613] loop: module loaded
[ 0.590740] SCSI Media Changer driver v0.25
[ 0.599149] spi-nand spi0.0: Winbond SPI NAND was found.
[ 0.604617] spi-nand spi0.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
[ 0.613336] 6 fixed-partitions partitions found on MTD device spi0.0
[ 0.619694] Creating 6 MTD partitions on "spi0.0":
[ 0.624628] 0x000000000000-0x000000300000 : "boot"
[ 0.636224] random: fast init done
[ 0.648153] 0x000000300000-0x000000d00000 : "cache"
[ 0.695051] 0x000000d00000-0x000000f00000 : "dtb"
[ 0.711217] 0x000000f00000-0x000001500000 : "kernel"
[ 0.743084] 0x000001500000-0x000006400000 : "rootfs"
[ 1.053505] 0x000006400000-0x000008000000 : "data"
[ 1.164845] random: crng init done
[ 1.176687] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 1.183362] ehci-platform: EHCI generic platform driver
[ 1.188966] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 1.195299] ohci-platform: OHCI generic platform driver
[ 1.201063] usbcore: registered new interface driver usb-storage
[ 1.208262] usb_phy_generic usb_phy_generic.0.auto: usb_phy_generic.0.auto supply vcc not found, using dummy regulator
[ 1.220276] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[ 1.226219] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1
[ 1.236376] hub 1-0:1.0: USB hub found
[ 1.240283] hub 1-0:1.0: 1 port detected
[ 1.247017] <<-GTP-INFO->> GTP driver installing...
[ 1.253074] i2c /dev entries driver
[ 1.261312] sunxi-wdt 1c20ca0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0)
[ 1.270228] hidraw: raw HID events driver (C) Jiri Kosina
[ 1.276249] usbcore: registered new interface driver usbhid
[ 1.281823] usbhid: USB HID core driver
[ 1.288809] NET: Registered protocol family 17
[ 1.307968] sun4i-backend 1e60000.display-backend: Couldn't find matching frontend, frontend features disabled
[ 1.318543] sun4i-drm display-engine: bound 1e60000.display-backend (ops 0xc06e92d4)
[ 1.327675] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xc06e7f2c)
[ 1.335471] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 1.342076] [drm] No driver support for vblank timestamp query.
[ 1.349406] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0
[ 1.357373] panel_simple_get_fixed_modes:4119
[ 1.365373] sun4i-drm display-engine: __drm_fb_helper_initial_config_and_unlock:bf3883c7, d8218831, 768000, e1a9cce9
[ 1.425789] sun4i-drm display-engine: fb0: sun4i-drmdrmfb frame buffer device
[ 1.434078] ubi0: default fastmap pool size: 30
[ 1.438624] ubi0: default fastmap WL pool size: 15
[ 1.443539] ubi0: attaching mtd4
[ 1.784151] ubi0: attached by fastmap
[ 1.787837] ubi0: fastmap pool size: 30
[ 1.791669] ubi0: fastmap WL pool size: 15
[ 1.820816] ubi0: attached mtd4 (name "rootfs", size 79 MiB)
[ 1.826675] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[ 1.833613] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[ 1.840420] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[ 1.847420] ubi0: good PEBs: 632, bad PEBs: 0, corrupted PEBs: 0
[ 1.853457] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[ 1.860695] ubi0: max/mean erase counter: 4/1, WL threshold: 4096, image sequence number: 0
[ 1.869072] ubi0: available PEBs: 0, total reserved PEBs: 632, PEBs reserved for bad PEB handling: 20
[ 1.878993] vcc3v0: disabling
[ 1.881986] vcc5v0: disabling
[ 1.885059] ALSA device list:
[ 1.888031] No soundcards found.
[ 1.891730] ubi0: background thread "ubi_bgt0d" started, PID 38
[ 1.902247] UBIFS (ubi0:0): Mounting in unauthenticated mode
[ 1.913654] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 39
[ 2.030101] UBIFS (ubi0:0): recovery needed
[ 2.467038] UBIFS (ubi0:0): recovery completed
[ 2.471683] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[ 2.479210] UBIFS (ubi0:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[ 2.489217] UBIFS (ubi0:0): FS size: 74407936 bytes (70 MiB, 586 LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
[ 2.499702] UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
[ 2.505585] UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0), UUID CBFD45FE-89E5-4BA2-86E7-47B23AAFD4FD, small LPT model
[ 2.526196] VFS: Mounted root (ubifs filesystem) on device 0:14.
[ 2.538123] devtmpfs: mounted
[ 2.546166] Freeing unused kernel memory: 1024K
[ 2.550817] Run /sbin/init as init process
Welcome to phoenix
phoenix login: anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
util_thread_start_with_sched_priority:thread 0xa15a18 is running
[ 6.943846] spi_fpga_tn652: loading out-of-tree module taints kernel.
[ 8.324318] input: afg3050_kbd as /devices/platform/soc/1c27000.i2c/i2c-0/0-0037/input/input0
CN2101029000000
[ 8.638890] Mass Storage Function, version: 2009/09/11
[ 8.644194] LUN: removable file: (no medium)
[ 8.700976] dual speed tmc: IN/ep1in, OUT/ep1out, INTep2in/
[ 8.707047] phy phy-1c13400.phy.0: Changing dr_mode to 1
[calibration_dds_result_read_eeprom] faild
[dds_calibration_load]open root/dds_calbration.dat failed
util_thread_start_with_sched_priority:thread 0xa1b0f8 is running
dso_acq_control:1:store_depth 4000, extra_len 64,acq_all_nm_for_read 4064,acq_dot_nm_of_timerange 4000,sample_rate = 1250000.000000
dbus session addr is unix:path=/var/run/dbus/system_bus_socket,guid=6c8daf60806bc81ddb86c4ee0000000c
dbus is valid and addr is unix:path=/var/run/dbus/system_bus_socket,guid=6c8daf60806bc81ddb86c4ee0000000c
[ 13.614793] usbcore: registered new interface driver USBTMC
[ 14.437448] phy phy-1c13400.phy.0: Changing dr_mode to 2
util_thread_start:thread 0xaff280 is running
******************** usb thread creat *********************
[ 15.819291] configfs-gadget gadget: high-speed config #1: c
[ 18.007883] tmc_function_setup:32, 7
[ 18.011621] tmc_function_setup:32, 7
==========str_model = DSO2D15
str_vendor = hantek
str_serial = CN2101029000000
str = hantek, DSO2D15, CN2101029000000, 1.1.0(20210517.00)
Welcome to phoenix
phoenix login: root
login[51]: root login on 'console'
unix:path=/var/run/dbus/system_bus_socket,guid=6c8daf60806bc81ddb86c4ee0000000c
# uname -a
Linux phoenix 5.2.0-licheepi-nano #127 Fri Apr 30 08:59:43 CST 2021 armv5tejl GNU/Linux
# ls /
THIS_IS_NOT_YOUR_ROOT_FILESYSTEM mnt
bin opt
cache proc
data root
dev run
dso sbin
etc sys
lib sys_inf.new
lib32 tmp
libexec usr
linuxrc var
media www
#
No wonder why it crashes. CPU usage is 80% all the time!
Mem: 24924K used, 30588K free, 20K shrd, 0K buff, 7204K cached
CPU: 52% usr 46% sys 0% nic 0% idle 0% io 0% irq 0% sirq
Load average: 3.65 1.90 0.77 3/33 1575
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
53 1 root S 62536 113% 83% ./phoenix
33 2 root SW 0 0% 2% [spi1]
30 2 root IW 0 0% 1% [kworker/0:1-pm]
7 2 root SW 0 0% 1% [ksoftirqd/0]
1327 51 root R 2404 4% 1% top
5 2 root IW 0 0% 0% [kworker/u2:0-ev]
107 1 dbus S 2792 5% 0% dbus-daemon --system --print-address
51 1 root S 2404 4% 0% -sh
1 0 root S 2276 4% 0% init
34 2 root IW 0 0% 0% [kworker/0:2-pm]
32 2 root SW 0 0% 0% [spi0]
38 2 root SW 0 0% 0% [ubi_bgt0d]
8 2 root SW 0 0% 0% [kdevtmpfs]
37 2 root IW 0 0% 0% [kworker/0:3-pm]
39 2 root SW 0 0% 0% [ubifs_bgt0_0]
2 0 root SW 0 0% 0% [kthreadd]
3 2 root IW 0 0% 0% [kworker/0:0-pm]
4 2 root IW< 0 0% 0% [kworker/0:0H]
6 2 root IW< 0 0% 0% [mm_percpu_wq]
9 2 root IW< 0 0% 0% [netns]
-
However u-boot is still quiet. Checking the binary I found these strings:
serial0
serial0:115200n8
/soc/serial@1c25000
1c25000 is the UART0 address! Tried replacing it with 1c25400 (UART1) but it crashes.
Replacing any of "serial0" strings with "serial1" also crashes.
Maybe it's not implemented or hardcoded somewhere, further investigation is needed.
-
DavidAlfa, you got a root shell, this opens up infinite possibilities!
Amazing work! :-+ :-BROKE
Btw there usually is some interesting information to be found inside /proc. For example, if /proc/config.gz is there, that is the configuration file for the kernel when it was compiled.
In any case, congratulations!
-
I had already search for that file, but it's missing. Neither there's cpu clock control. |O
The memory bus seems to be 16bit, so there's a big bottleneck there.
Some people did overclock the cpu to 800MHz, and DDR to 240MHz (From 156MHz).
That should help a little!
-
DavidAlfa,
I would leave the overclocking for later, since usually with these ARM SOCs, the various clocks are interconnected, including the memory, USB clock, the video clock, UART, etc (all the peripherals on the AHB (Arm High speed Bus).
The most important information if you want to recompile the kernel is to find the kernel configuration information and the dtb file. If the kernel config is not in /proc it could be somewhere else, or you can try using George Hilliard's kernel config as a start, and enable the modules that you think are missing. There is probably a proprietary module for the ASIC, but that too can come later.
In any case, as root, you now have total control of the DSO. Check how you can write something to the LCD display, perhaps? And the USB connector at the back can probably be used as a serial-over-USB port, so in theory at least one could just connect the USB cable to a PC and login to the DSO (definitely more practical than soldering a USB to serial adapter to the PCB).
-
I leave that for more experienced linux users, this is not my field!
I can fight for days to achieve something, then someone comes and makes 10x more work in 5 minutes.
As far as I've seen, it seems eerything has its own PLL, so there should be no issues?
I found this u-boot already patched that supports nand spi flash:
https://github.com/TiNredmc/u-boot
There you can see that core runs at 408MHz and RAM at 156MHz.
I'm playing with it...
-
However u-boot is still quiet. Checking the binary I found these strings:
serial0
serial0:115200n8
/soc/serial@1c25000
1c25000 is the UART0 address! Tried replacing it with 1c25400 (UART1) but it crashes.
Replacing any of "serial0" strings with "serial1" also crashes.
Maybe it's not implemented or hardcoded somewhere, further investigation is needed.
Yes, you have to recompile u-boot to change the serial port it uses as a boot console. You can use the source at George Hilliard's GitHub account. But since you already have a Linux console as root, I don't think you really need a console for u-boot.
-
You seem to know a lot, why don't you recompile it? ;D
-
DavidAlfa,
Check BuildRoot here: https://buildroot.org/
You can use George Hilliard's buildroot configuration file, it will install the toolchain and build u-boot, the kernel and a basic Linux root filesystem for the L1C200s which should in principle boot in the DSO and give you the same root console access that you have now, but with control of the kernel (so you can compile different modules, etc).
If you want to further hack your DSO that is one way of doing it. Another way is to reverse engineer the user program(s) that is(are) are responsible for the DSO functions. I believe it should be possible to load a module for a USB serial driver that will give you access to a root console through the USB A connector on the back of the DSO. Quite possibly the module is already compiled, in fact.
Personally I am not interested in hacking my DSO2C10, I just want to use it in my home projects and it's working well enough for my purposes as it is.
-
I've tried, no way. Too complex for me. The compiled u-boot images don't work.
Since the CPU load is 80%, my intention was to overclock it and see if the performance gets better.
I don't plan to reverse engineer anything., but I left the door open for everyone!
And that's were my knowledge/time wasting ends.
-
I thought on directly writing to the SOC registers, by accessing memory space using devmem.
It turned out to work! Made some compression tests:
After clean boot:
14.76s
15.14s
15.23s
15.15s
# Set CPU PLL multiplier to 29 (720MHz). Stock=16(408MHz)
devmem 0x1C20000 32 0x90001D00
# Set DDR PLL Multiplier to 17(432MHz). Stock=12(312MHz)
devmem 0x1C20020 32 0x90101100
10.19s
10.99s
10.53s
10.52s
So it clearly does something. 50% extra performance!.
It's nice to know we can access the SOC registers directly :D
The stability needs to be tested. Any higher than those values resulted in crashes and exceptions.
To apply at boot time I edited /etc/init.d/S31local.sh.
I also fixed the script, as Hantek programmers didn't care about the start and stop arguments, so it would start another process of Phoenix when rebooting, sometimes crashing.
I guess they didn't care because the DSO it's never supposed to be rebooted from the console!
#!/bin/sh
# Increase frequency in small steps, too fast would cause a crash sometimes.
apply_oc () {
echo "Applying Overclock!"> /dev/kmsg
#set CPU to 696MHz
devmem 0x1C20000 32 0x90001100
sleep 0.2
devmem 0x1C20000 32 0x90001200
sleep 0.2
devmem 0x1C20000 32 0x90001300
sleep 0.2
devmem 0x1C20000 32 0x90001400
sleep 0.2
devmem 0x1C20000 32 0x90001500
sleep 0.2
devmem 0x1C20000 32 0x90001600
sleep 0.2
devmem 0x1C20000 32 0x90001700
sleep 0.2
devmem 0x1C20000 32 0x90001800
sleep 0.2
devmem 0x1C20000 32 0x90001900
sleep 0.2
devmem 0x1C20000 32 0x90001A00
sleep 0.2
devmem 0x1C20000 32 0x90001B00
sleep 0.2
devmem 0x1C20000 32 0x90001C00
sleep 0.2
devmem 0x1C20000 32 0x90001D00
sleep 0.2
# set DDR to 408MHz
devmem 0x1C20020 32 0x90100D00
sleep 0.2
devmem 0x1C20020 32 0x90100E00
sleep 0.2
devmem 0x1C20020 32 0x90100F00
sleep 0.2
devmem 0x1C20020 32 0x90101000
sleep 0.2
devmem 0x1C20020 32 0x90101100
sleep 0.2
}
if [ "$1" = "start" ]; then
# Apply OC and start DSO software
apply_oc
/dso/etc/boot.sh &
elif [ "$1" = "stop" ]; then
# Kill the DSO software
pidof phoenix | xargs kill -9
fi
I don't know if it's placebo or not, but the system seems a little more responsive!
-
Well done, DavidAlfa! Very, very impressive hacking. :-+
Note that with increased CPU clock and DDR clock, the chip temperatures have probably gone up considerably, it would be good to check the temperatures before/after overclocking. And unfortunately the little L1C200s SOC does not have an onboard temperature sensor, so you'll have to rely on an external infrared thermometer for that.
-
Yeah, it's strange that a such highly integrated SOC doesn't have something simple as a temp sensor. C'mon, it even has TV input!
Sad, I'll I have my finger IR sensor. I don't think it gets so hot, at stock speeds it barely gets warm.
I'm tired of disassembling it! ::)
Before running benchmarks, remember to kill phoenix process! (screen will freeze, don't panic)
pidof phoenix | xargs kill -9
To make it easier, so you can just type "stop" to kill phoenix process:
echo "pidof phoenix | xargs kill -9" >/usr/bin/stop
chmod +x /usr/bin/stop
sync
I wrote a small Pi calculation program
Copypasted some code from internet and adapted for my needs, making a Pi benchmark.
Cross-compiled to arm, worked great.
My idea was, being very smalll, it should avoid cache misses and show the real cpu performance difference.
There was very little difference between O1, O2, O3 and Os optimizations,less than 1%.
From O0 it was 10% faster. I had to compile with static libraries, as it complained about LIBC libraries version.
And it's very obvious:
# ./pi 1000000
Starting PI...
Pi: 3.141592653589794004176383168669417500495910644531250000000000
Loops: 1000000
Time: 9932mS
# ./pi 1000000
Starting PI...
Pi: 3.141592653589794004176383168669417500495910644531250000000000
Loops: 1000000
Time: 5626mS
Almost 200% cpu power!
In this case, DDR speed made no difference, clearly stating my cache supposition.
# ./pi 1000000
Starting PI...
Pi: 3.141592653589794004176383168669417500495910644531250000000000
Loops: 1000000
Time: 5624mS
Benchmarked it for 10 minutes, no stability issues. Running top showed 100% cpu usage
# pi 100000000
Starting PI...
Pi: 3.141592653589794004176383168669417500495910644531250000000000
Loops: 100000000
Time: 568621mS
However in memory operations the DDR performance boost is huge:
# time dd if=/dev/zero of=/dev/null bs=1M count=8192
8192+0 records in
8192+0 records out
real 0m 35.62s
user 0m 0.02s
sys 0m 35.59s
# time dd if=/dev/zero of=/dev/null bs=1M count=8192
8192+0 records in
8192+0 records out
real 0m 24.76s
user 0m 0.00s
sys 0m 24.76s
I used the scope for few hours with no issues.
[Irony on] With this cpu power, you could start mining bitcoin and it would self-pay in about 10 years! [Irony off]
I made a video. Notice how the FFT update rate almost doubles with the overclock!
https://www.youtube.com/watch?v=VRHXwlwrJMQ (https://www.youtube.com/watch?v=VRHXwlwrJMQ)
`
Now I'm figuring out how to write to the display buffer.
We need DOOM running in this!
-
More hacking! The Model, Serial, Vendor and PCB can be changed using the VISA API.
Running strings in Phoenix app showed to be very productive:
PRIVate:SET:SERIal
PRIVate:SET:SERIal?
PRIVate:SET:MODEl1
PRIVate:SET:MODEl2
PRIVate:SET:MODEl?
PRIVate:SET:VENDor
PRIVate:SET:VENDor?
PRIVate:SET:PCB
PRIVate:SET:PCB?
PRIVate:SET:LANGuage:VALId
PRIVate:SET:LANGuage:CONFig
PRIVate:CLEAr:EE
PRIVate:SET:BIAS
PRIVate:SET:CODE
PRIVate:SET:BOARD
PRIVate:SET:BOARD?
PRIVate:GET:ERRO?
PRIVate:FACTORY:RESET
PRIVate:WRITE:EEPROM
PRIVate:READ:EEPROM
PRIVate:READ:BANDWidth
PRIVate:TEST:RESUlt?
PRIVate:HARDWare:TEST
PRIVate:HARDWare:INFO
DDS:CAL:OFFSet
DDS:CAL:AMP
DDS:CAL:RESUlt
PRIVate:TEST:CH1:FACTOR
PRIVate:TEST:CH2:FACTOR
PRIVate:RELAY
SYSTem:ERRor?
SYSTem:ERRor:NEXT?
SYSTem:ERRor:COUNt?
SYSTem:VERSion?
SYSTem:IP
SYSTem:IP?
SYSTem:SET:TIME
SYSTem:TIME?
SYSTem:USB?
STATus:QUEStionable?
STATus:QUEStionable:EVENt?
STATus:QUEStionable:ENABle
STATus:QUEStionable:ENABle?
STATus:PRESet
AUTorange:STARt
AUTorange:STOP
SETUp:NORMal?
PRIVate:GET:STATus?
CHANnel1:BWLimit
CHANnel1:BWLimit?
CHANnel1:COUPling
CHANnel1:COUPling?
CHANnel1:DISPlay
CHANnel1:DISPlay?
CHANnel1:INVert
CHANnel1:INVert?
CHANnel1:OFFSet
CHANnel1:OFFSet?
CHANnel1:RANGe
CHANnel1:RANGe?
CHANnel1:SCALe
CHANnel1:SCALe?
CHANnel1:PROBe
CHANnel1:PROBe?
CHANnel1:VERNier
CHANnel1:VERNier?
CHANnel2:BWLimit
CHANnel2:BWLimit?
CHANnel2:COUPling
CHANnel2:COUPling?
CHANnel2:DISPlay
CHANnel2:DISPlay?
CHANnel2:INVert
CHANnel2:INVert?
CHANnel2:OFFSet
CHANnel2:OFFSet?
CHANnel2:RANGe
CHANnel2:RANGe?
CHANnel2:SCALe
CHANnel2:SCALe?
CHANnel2:PROBe
CHANnel2:PROBe?
CHANnel2:VERNier
CHANnel2:VERNier?
CHANnel3:BWLimit
CHANnel3:BWLimit?
CHANnel3:COUPling
CHANnel3:COUPling?
CHANnel3:DISPlay
CHANnel3:DISPlay?
CHANnel3:INVert
CHANnel3:INVert?
CHANnel3:OFFSet
CHANnel3:OFFSet?
CHANnel3:RANGe
CHANnel3:RANGe?
CHANnel3:SCALe
CHANnel3:SCALe?
CHANnel3:PROBe
CHANnel3:PROBe?
CHANnel3:VERNier
CHANnel3:VERNier?
CHANnel4:BWLimit
CHANnel4:BWLimit?
CHANnel4:COUPling
CHANnel4:COUPling?
CHANnel4:DISPlay
CHANnel4:DISPlay?
CHANnel4:INVert
CHANnel4:INVert?
CHANnel4:OFFSet
CHANnel4:OFFSet?
CHANnel4:RANGe
CHANnel4:RANGe?
CHANnel4:SCALe
CHANnel4:SCALe?
CHANnel4:PROBe
CHANnel4:PROBe?
CHANnel4:VERNier
CHANnel4:VERNier?
TIMebase:WINDow:ENABle
TIMebase:WINDow:ENABle?
TIMebase:WINDow:POSition
TIMebase:WINDow:POSition?
TIMebase:WINDow:SCALe
TIMebase:WINDow:SCALe?
TIMebase:WINDow:RANGe
TIMebase:WINDow:RANGe?
TIMebase:POSition
TIMebase:POSition?
TIMebase:SCALe
TIMebase:SCALe?
TIMebase:RANGe
TIMebase:RANGe?
TIMebase:MODE
TIMebase:MODE?
TIMebase:VERNier
TIMebase:VERNier?
TIMebase:XY:XSOUrce
TIMebase:XY:XSOUrce?
TIMebase:XY:YSOUrce
TIMebase:XY:YSOUrce?
ACQuire:MODe
ACQuire:MODe?
ACQuire:POINts
ACQuire:POINts?
ACQuire:TYPE
ACQuire:TYPE?
ACQuire:SRATe?
ACQuire:COUNt
ACQuire:COUNt?
TRIGger:FORCe
TRIGger:MODE
TRIGger:MODE?
TRIGger:COUPling
TRIGger:COUPling?
TRIGger:STATus?
TRIGger:SWEep
TRIGger:SWEep?
TRIGger:HOLDoff
TRIGger:HOLDoff?
TRIGger:NREJect
TRIGger:NREJect?
TRIGger:SENSitivity
TRIGger:SENSitivity?
TRIGger:EDGe:SOURce
TRIGger:EDGe:SOURce?
TRIGger:EDGe:SLOPe
TRIGger:EDGe:SLOPe?
TRIGger:EDGe:LEVel
TRIGger:EDGe:LEVel?
TRIGger:PULSe:SOURce
TRIGger:PULSe:SOURce?
TRIGger:PULSe:POLarity
TRIGger:PULSe:POLarity?
TRIGger:PULSe:WHEN
TRIGger:PULSe:WHEN?
TRIGger:PULSe:WIDth
TRIGger:PULSe:WIDth?
TRIGger:PULSe:LEVel
TRIGger:PULSe:LEVel?
TRIGger:SLOPe:SOURce
TRIGger:SLOPe:SOURce?
TRIGger:SLOPe:POLarity
TRIGger:SLOPe:POLarity?
TRIGger:SLOPe:WHEN
TRIGger:SLOPe:WHEN?
TRIGger:SLOPe:WIDth
TRIGger:SLOPe:WIDth?
TRIGger:SLOPe:ALEVel
TRIGger:SLOPe:ALEVel?
TRIGger:SLOPe:BLEVel
TRIGger:SLOPe:BLEVel?
TRIGger:TV:SOURce
TRIGger:TV:SOURce?
TRIGger:TV:POLarity
TRIGger:TV:POLarity?
TRIGger:TV:MODE
TRIGger:TV:MODE?
TRIGger:TV:LINE
TRIGger:TV:LINE?
TRIGger:TV:STANdard
TRIGger:TV:STANdard?
TRIGger:VIDeo:LEVel
TRIGger:VIDeo:LEVel?
TRIGger:TIMeout:SOURce
TRIGger:TIMeout:SOURce?
TRIGger:TIMeout:LEVel
TRIGger:TIMeout:LEVel?
TRIGger:TIMeout:WIDth
TRIGger:TIMeout:WIDth?
TRIGger:TIMeout:POLarity
TRIGger:TIMeout:POLarity?
TRIGger:WINDOw:SOURce
TRIGger:WINDOw:SOURce?
TRIGger:WINDOw:ALEVel
TRIGger:WINDOw:ALEVel?
TRIGger:WINDOw:BLEVel
TRIGger:WINDOw:BLEVel?
TRIGger:INTERVAl:SOURce
TRIGger:INTERVAl:SOURce?
TRIGger:INTERVAl:SLOp
TRIGger:INTERVAl:SLOp?
TRIGger:INTERVAl:WHEN
TRIGger:INTERVAl:WHEN?
TRIGger:INTERVAl:TIME
TRIGger:INTERVAl:TIME?
TRIGger:INTERVAl:ALEVel
TRIGger:INTERVAl:ALEVel?
TRIGger:UNDER_Am:SOURce
TRIGger:UNDER_Am:SOURce?
TRIGger:UNDER_Am:POLarity
TRIGger:UNDER_Am:POLarity?
TRIGger:UNDER_Am:WHEN
TRIGger:UNDER_Am:WHEN?
TRIGger:UNDER_Am:TIME
TRIGger:UNDER_Am:TIME?
TRIGger:UNDER_Am:ALEVel
TRIGger:UNDER_Am:ALEVel?
TRIGger:UNDER_Am:BLEVel
TRIGger:UNDER_Am:BLEVel?
TRIGger:UART:SOURce
TRIGger:UART:SOURce?
TRIGger:UART:CONdition
TRIGger:UART:CONdition?
TRIGger:UART:BAUd
TRIGger:UART:BAUd?
TRIGger:UART:ALEVel
TRIGger:UART:ALEVel?
TRIGger:UART:DATA
TRIGger:UART:DATA?
TRIGger:UART:WIDTh
TRIGger:UART:WIDTh?
TRIGger:UART:STOP
TRIGger:UART:STOP?
TRIGger:UART:PARIty
TRIGger:UART:PARIty?
TRIGger:UART:WHEN
TRIGger:UART:WHEN?
TRIGger:UART:IDLe
TRIGger:UART:IDLe?
TRIGger:CAN:SOURce
TRIGger:CAN:SOURce?
TRIGger:CAN:IDLe
TRIGger:CAN:IDLe?
TRIGger:CAN:BAUd
TRIGger:CAN:BAUd?
TRIGger:CAN:CONdition
TRIGger:CAN:CONdition?
TRIGger:CAN:ID
TRIGger:CAN:ID?
TRIGger:CAN:DLC
TRIGger:CAN:DLC?
TRIGger:CAN:DATA
TRIGger:CAN:DATA?
TRIGger:CAN:ALEVel
TRIGger:CAN:ALEVel?
TRIGger:CAN:VALId
TRIGger:CAN:VALId?
TRIGger:LIN:SOURce
TRIGger:LIN:SOURce?
TRIGger:LIN:IDLe
TRIGger:LIN:IDLe?
TRIGger:LIN:BAUd
TRIGger:LIN:BAUd?
TRIGger:LIN:CONdition
TRIGger:LIN:CONdition?
TRIGger:LIN:ID
TRIGger:LIN:ID?
TRIGger:LIN:DATA
TRIGger:LIN:DATA?
TRIGger:LIN:ALEVel
TRIGger:LIN:ALEVel?
TRIGger:LIN:VALId
TRIGger:LIN:VALId?
TRIGger:IIC:SDA:SOURce
TRIGger:IIC:SDA:SOURce?
TRIGger:IIC:SCL:SOURce
TRIGger:IIC:SCL:SOURce?
TRIGger:IIC:CONdition
TRIGger:IIC:CONdition?
TRIGger:IIC:ADDer
TRIGger:IIC:ADDer?
TRIGger:IIC:DATA
TRIGger:IIC:DATA?
TRIGger:IIC:ALEVel
TRIGger:IIC:ALEVel?
TRIGger:IIC:BLEVel
TRIGger:IIC:BLEVel?
TRIGger:IIC:VALId
TRIGger:IIC:VALId?
TRIGger:IIC:ACT:LEVEl
TRIGger:IIC:ACT:LEVEl?
TRIGger:SPI:SDA:SOURce
TRIGger:SPI:SDA:SOURce?
TRIGger:SPI:SCL:SOURce
TRIGger:SPI:SCL:SOURce?
TRIGger:SPI:IDLe
TRIGger:SPI:IDLe?
TRIGger:SPI:SCK
TRIGger:SPI:SCK?
TRIGger:SPI:WIDth
TRIGger:SPI:WIDth?
TRIGger:SPI:DATA
TRIGger:SPI:DATA?
TRIGger:SPI:MASK
TRIGger:SPI:MASK?
TRIGger:SPI:ALEVel
TRIGger:SPI:ALEVel?
TRIGger:SPI:BLEVel
TRIGger:SPI:BLEVel?
TRIGger:SPI:OVERtime
TRIGger:SPI:OVERtime?
TRIGger:SPI:ACT:LEVEl
TRIGger:SPI:ACT:LEVEl?
TRIGger:PATTern:PATTern
TRIGger:PATTern:PATTern?
TRIGger:PATTern:LEVel
TRIGger:PATTern:LEVel?
CALibrate:STARt
CALibrate:STATus?
CALibrate:QUIT
CALibrate:GET:TEMPerture?
CALibrate:GET:CONDition?
MATH:DISPlay
MATH:DISPlay?
MATH:OPERator
MATH:OPERator?
MATH:SOURce1
MATH:SOURce1?
MATH:SOURce2
MATH:SOURce2?
MATH:SCALe
MATH:SCALe?
MATH:OFFSet
MATH:OFFSet?
MATH:FFT:SOURce
MATH:FFT:SOURce?
MATH:FFT:WINDow
MATH:FFT:WINDow?
MATH:FFT:UNIT
MATH:FFT:UNIT?
MATH:FFT:HSCale
MATH:FFT:HSCale?
MATH:FFT:HCENter
MATH:FFT:HCENter?
REFerence1:DISPlay
REFerence1:DISPlay?
REFerence1:SOURce
REFerence1:SOURce?
REFerence1:VSCale
REFerence1:VSCale?
REFerence1:VOFFset
REFerence1:VOFFset?
REFerence1:CURRent
REFerence1:CURRent?
REFerence1:SAVe
REFerence2:DISPlay
REFerence2:DISPlay?
REFerence2:SOURce
REFerence2:SOURce?
REFerence2:VSCale
REFerence2:VSCale?
REFerence2:VOFFset
REFerence2:VOFFset?
REFerence2:CURRent
REFerence2:CURRent?
REFerence2:SAVe
WAVeform:SOURce
WAVeform:SOURce?
WAVeform:SOURce:SUBSource
WAVeform:SOURce:SUBSource?
WAVeform:BYTeorder
WAVeform:BYTeorder?
WAVeform:FORMat
WAVeform:FORMat?
WAVeform:POINts:MODE
WAVeform:POINts:MODE?
WAVeform:UNSigned
WAVeform:UNSigned?
WAVeform:PREamble?
WAVeform:COUNt?
WAVeform:POINts
WAVeform:POINts?
WAVeform:STARt
WAVeform:STARt?
WAVeform:STOP
WAVeform:STOP?
WAVeform:DATA
WAVeform:DATA:DISP?
PRIVate:WAVeform:DATA:ALL?
WAVeform:XINCrement?
WAVeform:XORigin?
WAVeform:XREFerence?
WAVeform:YINCrement?
WAVeform:YORigin?
WAVeform:YREFerence?
DISPlay:CLEar
DISPlay:DATA?
DISPlay:TYPE
DISPlay:TYPE?
DISPlay:GRADing:TIME
DISPlay:WBRightness
DISPlay:WBRightness?
DISPlay:GRID
DISPlay:GRID?
DISPlay:GBRightness
DISPlay:GBRightness?
CURSor:MODE
CURSor:MODE?
CURSor:MANual:TYPE
CURSor:MANual:TYPE?
CURSor:MANual:SOURce
CURSor:MANual:SOURce?
CURSor:MANual:AX
CURSor:MANual:AX?
CURSor:MANual:AXValue?
CURSor:MANual:AY
CURSor:MANual:AY?
CURSor:MANual:AYValue?
CURSor:MANual:BX
CURSor:MANual:BX?
CURSor:MANual:BXValue?
CURSor:MANual:BY
CURSor:MANual:BY?
CURSor:MANual:BYValue?
CURSor:MANual:XDELta?
CURSor:MANual:YDELta?
CURSor:MANual:IXDELta?
CURSor:TRACk:SOURcea
CURSor:TRACk:SOURcea?
CURSor:TRACk:SOURceb
CURSor:TRACk:SOURceb?
CURSor:TRACk:AX
CURSor:TRACk:AX?
CURSor:TRACk:AXValue?
CURSor:TRACk:AY?
CURSor:TRACk:AYValue?
CURSor:TRACk:BX
CURSor:TRACk:BX?
CURSor:TRACk:BXValue?
CURSor:TRACk:BY?
CURSor:TRACk:BYValue?
CURSor:TRACk:XDELta?
CURSor:TRACk:YDELta?
CURSor:TRACk:IXDELta?
MEASure:ENABle
MEASure:ENABle?
MEASure:SOURce
MEASure:SOURce?
MEASure:COUNter:VALue?
MEASure:CLEar
MEASure:RECover
MEASure:ADISplay
MEASure:ADISplay?
MEASure:AMSource
MEASure:AMSource?
MEASure:CHANnel1:ITEM
MEASure:CHANnel2:ITEM
MEASure:CHANnel3:ITEM
MEASure:CHANnel4:ITEM
MEASure:CHANnel1:ITEM?
MEASure:CHANnel2:ITEM?
MEASure:CHANnel3:ITEM?
MEASure:CHANnel4:ITEM?
MEASure:MATH:ITEM?
MEASure:GATE:ENABle
MEASure:GATE:ENABle?
MEASure:GATE:AY
MEASure:GATE:AY?
MEASUre:GATE:BY
MEASure:GATE:BY?
MEASure:COUNter
MEASure:CHANnel1:COUNter?
MEASure:CHANnel2:COUNter?
MEASure:CHANnel3:COUNter?
MEASure:CHANnel4:COUNter?
MEASure:CHANnel1:FREQ?
MEASure:CHANnel2:FREQ?
MEASure:CHANnel3:FREQ?
MEASure:CHANnel4:FREQ?
MEASure:DEL:ALL
MASK:EANBle
MASK:EANBle?
MASK:SOURce
MASK:SOURce?
MASK:OPERate
MASK:OPERate?
MASK:MDISplay
MASK:MDISplay?
MASK:SOOutput
MASK:SOOutput?
MASK:OUTPut
MASK:OUTPut?
MASK:X
MASK:X?
MASK:Y
MASK:Y?
MASK:CREate
MASK:PASSed?
MASK:FAILed?
MASK:TOTal?
SAVE:SETup
SAVE:MULTi
SAVE:CSV
SAVE:IMAGe
SAVE:MASK
RECall:SETup
RECall:MULTi
RECall:MASK
SYSTem:GAM?
SYSTem:RAM?
SYSTem:PON
SYSTem:PON?
SYSTem:LANGuage
SYSTem:LANGuage?
SYSTem:LOCKed
SYSTem:LOCKed?
DDS:SWITch
DDS:SWITch?
DDS:TYPE
DDS:TYPE?
DDS:FREQ
DDS:FREQ?
DDS:AMP
DDS:AMP?
DDS:OFFSet
DDS:OFFSet?
DDS:DUTY
DDS:DUTY?
DDS:WAVE:MODE
DDS:WAVE:MODE?
DDS:MODE:TYPE
DDS:MODE:TYPE?
DDS:MODE:WAVE:TYPE
DDS:MODE:WAVE:TYPE?
DDS:MODE:FREQ
DDS:MODE:FREQ?
DDS:MODE:DEPThordeviation
DDS:MODE:DEPThordeviation?
DDS:BURSt:SWITch
DDS:BURSt:SWITch?
DDS:BURSt:TYPE
DDS:BURSt:TYPE?
DDS:BURSt:CNT
DDS:BURSt:CNT?
DDS:BURSt:SRC
DDS:BURSt:SRC?
DDS:BURSt:SLOPE
DDS:BURSt:SLOPE?
DDS:BURSt:GATE:POLArity
DDS:BURSt:GATE:POLArity?
DDS:BURSt:TRIGger
DDS:SETUp:ALL?
You can send these commands using KeySight Interactive IO.
Also, you can open Keysight IO Monitor and see what DigitalScope or WaveEditor apps are doing.
PRIVate:FACTORY:RESET does what its name says. Resets the user settings and reboots. Serial, model remains unchanged.
Be careful of these commands!
- PRIVate:WRITE:EEPROM
- PRIVate:CLEAr:EE
PRIVate:READ:EEPROM returns:
<- 0????????????????????????«x01»«x01»But in the IO Monitor:
30 ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff 01 01
I don't know how to restore these values since the cmd box only allows ascii characters!
The commands ended in '?' are queries. First, you send them, then click on "Read response".
The commands with arguments don't have response.
Don't execute a read response if you didn't send a query first, phoenix handles that pretty bad, it's easy to cause a buffer overflow, crashing the system.
You can easily change the values in seconds:
PRIVate:SET:MODEl1 DSO2D15
PRIVate:SET:SERIal CN2101029000000
PRIVate:SET:VENDor Hantek
PRIVate:SET:PCB "000.000.000.000.000.000.000.001"
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1224741)
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1224743)
-
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:
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1224756)
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1224758)
Monitor patch:
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1224765)
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1224767)
-
DavidAlfa,
If you have the time, could you please check what happens when you plug in the DSO to your PC using the USB cable on the back:
1. What is the kernel message you get (dmesg)?
2. What kernel module if any is loaded (lsmod)?
3. What USB devices are seen by the kernel (lsusb)?
4. Can you list the kernel modules available in /lib/modules?
5. Can you list the tty devices in /dev (ls /dev/tty*)?
What I am trying to determine is if it's possible to get a serial console on the USB OTG interface. This would make it possible to login to the DSO as root without opening it. :-BROKE
See here for Allwinner SOCs: https://linux-sunxi.org/USB_Gadget/Serial
About writing to the display: it should be as simple as writing to memory, since I believe the display buffer is mapped to RAM, you have the specific region in the kernel message I believe.
-
Dmesg is very quiet. Little information is shown.
There are very few kernel modules. The system is really stripped down.
I already have some logs in my Drive folder, including dmesg and ls of the whole system (/bin, /dev, /proc, /sys, /lib... everything).
Did you check them?
# lsmod
Module Size Used by Tainted: G
tp_adc 16384 0
usbtmc 24576 0
fpga_i2c_kb 16384 0
spi_fpga_tn652 16384 0
# lsusb
Bus 001 Device 001: ID 1d6b:0002
# ls -R /lib/modules
/lib/modules:
3.10.65
/lib/modules/3.10.65:
kernel modules.builtin.bin modules.order
modules.alias modules.dep modules.softdep
modules.alias.bin modules.dep.bin modules.symbols
modules.builtin modules.devname modules.symbols.bin
/lib/modules/3.10.65/kernel:
drivers net sound
/lib/modules/3.10.65/kernel/drivers:
input media spi staging usb video
/lib/modules/3.10.65/kernel/drivers/input:
touchscreen
/lib/modules/3.10.65/kernel/drivers/input/touchscreen:
icn85xx
/lib/modules/3.10.65/kernel/drivers/input/touchscreen/icn85xx:
icn85xx_ts.ko
/lib/modules/3.10.65/kernel/drivers/media:
platform v4l2-core
/lib/modules/3.10.65/kernel/drivers/media/platform:
sunxi-vfe
/lib/modules/3.10.65/kernel/drivers/media/platform/sunxi-vfe:
actuator device vfe_io.ko vfe_v4l2.ko
/lib/modules/3.10.65/kernel/drivers/media/platform/sunxi-vfe/actuator:
actuator.ko ad5820_act.ko dw9714_act.ko ov8825_act.ko
/lib/modules/3.10.65/kernel/drivers/media/platform/sunxi-vfe/device:
ar0330.ko gt2005.ko ov5647_mipi.ko s5k5e2yx.ko
gc0307.ko hi253.ko ov5648.ko sp0718.ko
gc0308.ko imx214.ko ov5650.ko sp0838.ko
gc0311.ko nt99141.ko ov7736.ko sp0a19.ko
gc0328.ko ov12830.ko ov8825.ko sp2518.ko
gc0328c.ko ov13850.ko ov8850.ko sp2519.ko
gc0329.ko ov16825.ko ov8858.ko sp5408.ko
gc2035.ko ov2640.ko ov8858_4lane.ko sp5409.ko
gc2145.ko ov2686.ko s5k4e1.ko t8et5.ko
gc2155.ko ov2710_mipi.ko s5k4e1_mipi.ko
gc5004.ko ov5640.ko s5k4ec.ko
gc5004_mipi.ko ov5647.ko s5k4ec_mipi.ko
/lib/modules/3.10.65/kernel/drivers/media/v4l2-core:
videobuf2-core.ko videobuf2-dma-contig.ko videobuf2-memops.ko
/lib/modules/3.10.65/kernel/drivers/spi:
spi-fpga-tn652.ko
/lib/modules/3.10.65/kernel/drivers/staging:
android
/lib/modules/3.10.65/kernel/drivers/staging/android:
ion
/lib/modules/3.10.65/kernel/drivers/staging/android/ion:
sunxi
/lib/modules/3.10.65/kernel/drivers/staging/android/ion/sunxi:
ion-kernel-use-demo.ko
/lib/modules/3.10.65/kernel/drivers/usb:
gadget
/lib/modules/3.10.65/kernel/drivers/usb/gadget:
g_android.ko libcomposite.ko
/lib/modules/3.10.65/kernel/drivers/video:
backlight
/lib/modules/3.10.65/kernel/drivers/video/backlight:
backlight.ko generic_bl.ko lcd.ko
/lib/modules/3.10.65/kernel/net:
ipv4 netfilter
/lib/modules/3.10.65/kernel/net/ipv4:
netfilter
/lib/modules/3.10.65/kernel/net/ipv4/netfilter:
ipt_REJECT.ko iptable_mangle.ko
/lib/modules/3.10.65/kernel/net/netfilter:
xt_LOG.ko xt_comment.ko xt_mac.ko xt_multiport.ko
xt_TCPMSS.ko xt_limit.ko xt_mark.ko xt_time.ko
/lib/modules/3.10.65/kernel/sound:
core
/lib/modules/3.10.65/kernel/sound/core:
oss seq
/lib/modules/3.10.65/kernel/sound/core/oss:
snd-mixer-oss.ko snd-pcm-oss.ko
/lib/modules/3.10.65/kernel/sound/core/seq:
oss snd-seq-dummy.ko snd-seq.ko
snd-seq-device.ko snd-seq-midi-event.ko
/lib/modules/3.10.65/kernel/sound/core/seq/oss:
snd-seq-oss.ko
# ls /dev/tty*
/dev/tty /dev/tty2 /dev/tty31 /dev/tty43 /dev/tty55 /dev/ttyS0
/dev/tty0 /dev/tty20 /dev/tty32 /dev/tty44 /dev/tty56 /dev/ttyS1
/dev/tty1 /dev/tty21 /dev/tty33 /dev/tty45 /dev/tty57 /dev/ttyS2
/dev/tty10 /dev/tty22 /dev/tty34 /dev/tty46 /dev/tty58 /dev/ttyS3
/dev/tty11 /dev/tty23 /dev/tty35 /dev/tty47 /dev/tty59 /dev/ttyp0
/dev/tty12 /dev/tty24 /dev/tty36 /dev/tty48 /dev/tty6 /dev/ttyp1
/dev/tty13 /dev/tty25 /dev/tty37 /dev/tty49 /dev/tty60 /dev/ttyp2
/dev/tty14 /dev/tty26 /dev/tty38 /dev/tty5 /dev/tty61 /dev/ttyp3
/dev/tty15 /dev/tty27 /dev/tty39 /dev/tty50 /dev/tty62 /dev/ttyp4
/dev/tty16 /dev/tty28 /dev/tty4 /dev/tty51 /dev/tty63 /dev/ttyp5
/dev/tty17 /dev/tty29 /dev/tty40 /dev/tty52 /dev/tty7 /dev/ttyp6
/dev/tty18 /dev/tty3 /dev/tty41 /dev/tty53 /dev/tty8 /dev/ttyp7
/dev/tty19 /dev/tty30 /dev/tty42 /dev/tty54 /dev/tty9
When plugging the usb to the computer:
[ 51.724893] configfs-gadget gadget: high-speed config #1: c
[ 53.919748] tmc_function_setup:32, 7
[ 53.923503] tmc_function_setup:32, 7
==========str_model = DSO2D15
str_vendor = Hantek
str_serial = CN2101029000000
str = Hantek, DSO2D15, CN2101029000000, 1.1.0(20210517.00)
The usb depends somehow on the phoenix app for the initial setup. It monitors the usb and changes the usb modes.
I guess it reads some GPIO or registers in the SOC that are set when something is connected to the usb port.
And enables Host or device mode by writing some register bits.
Once phoenix did whatever to make usb work, killing it won't make the usb to stop working.
But USB will stay in the last mode phoenix configured it, host or device mode.
So if it was in host mode, only a usb drive will work, but not connecting to the computer. And so on.
Edit: I found how to change the USB mode:
echo host > /sys/devices/platform/soc/1c13000.usb/musb-hdrc.1.auto/mode
echo peripheral > /sys/devices/platform/soc/1c13000.usb/musb-hdrc.1.auto/mode
To turn the usb power on/off
echo 1 > /sys/class/gpio/gpio0/value
echo 0 > /sys/class/gpio/gpio0/value
You can write directly to the LCD framebuffer using /dev/fb0
The drawing seems to be done by libanolis(in /dso/lib), there are a lot of references to it inside phoenix:
anolis_picture_fill(uVar2,local_b4)
anolis_canvas_draw_string(uVar1,0x118,5,"UART DATA",0xffffffff);
anolis_canvas_draw_line(uVar1,0,0x19,600,0x19);
-
Dmesg is very quiet. Little information is shown.
There are very few kernel modules. I already have some logs in my Drive folder, did you check them?
I am going to check them, thanks!
-
Reading the peripherals registers, I found that Uart0 hardware is actually linked to the GPIO pins.
So the patching is no longer needed, only find their connection in the board.
Here's the F1C200s pinout asignment:
PIN GPIO NAME FUNCTION CONNECTED TO
6 GPIO96 PD0 TWI0_SDA(I2C) U9 5, LemonTree 118
7 GPIO97 PD1 LCD_D3 LCD
8 GPIO98 PD2 LCD_D4 LCD
9 GPIO99 PD3 LCD_D5 LCD
10 GPIO100 PD4 LCD_D6 LCD
11 GPIO101 PD5 LCD_D7 LCD
12 GPIO102 PD6 LCD_D10 LCD
13 GPIO103 PD7 LCD_D11 LCD
14 GPIO104 PD8 LCD_D12 LCD
15 GPIO105 PD9 LCD_D13 LCD
16 GPIO106 PD10 LCD_D14 LCD
17 GPIO107 PD11 LCD_D15 LCD
18 GPIO108 PD12 TWI0_SCK(I2C) U9 6, LemonTree 117
19 GPIO109 PD13 LCD_D19 LCD
21 GPIO110 PD14 LCD_D20 LCD
23 GPIO111 PD15 LCD_D21 LCD
24 GPIO112 PD16 LCD_D22 LCD
25 GPIO113 PD17 LCD_D23 LCD
26 GPIO114 PD18 LCD_CLK LCD
27 GPIO115 PD19 LCD_DE LCD
28 GPIO116 PD20 LCD_HSYNC LCD
29 GPIO117 PD21 LCD_VSYNC LCD
37 GPIO140 PE12 PWM0 LCD BACKLIGHT
38 GPIO139 PE11 Input R196, V USB detect from computer
39 GPIO138 PE10 SPI_MISO LemonTree 87
40 GPIO137 PE9 SPI1_CLK LemonTree 15
41 GPIO136 PE8 SPI1_MOSI LemonTree 90
42 GPIO135 PE7 Output LemonTree 88
43 GPIO134 PE6 Input Buzzer signal from LemonTree 21, R19
44 GPIO133 PE5 Output LemonTree 20, R101
45 GPIO132 PE4 EINTE4 LemonTree 22, R278
48 GPIO129 PE1 UART0_TX UART0
49 GPIO128 PE0 UART0_RX UART0
59 GPIO64 PC0 SPI0_CLK SPI NAND FLASH U2
60 GPIO65 PC1 SPI0_CS SPI NAND FLASH U2
61 GPIO66 PC2 SPI0_MISO SPI NAND FLASH U2
62 GPIO67 PC3 SPI0_MOSI SPI NAND FLASH U2
63 GPIO3 PA3 UART1_TX UART1
64 GPIO1 PA2 UART1_RX UART1
65 GPIO1 PA1 TP_X2 ?_?
66 GPIO0 PA0 Output V OTG enable
After looking at the pinout, it definitely seems a Gowin product. Probably a customized version for Hantek.
But most pinout, if not all, is the same as the GW1N-4. Edit: It seems to be a GW2AR-18 (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg3598420/#msg3598420)
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1231973)
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1231975)
We got distracted thinking the unpopulated connector was a RJ45!
U1 seems to be a MAX232, as RX and TX go to pins 9 and 10.
I prefer to avoid soldering wires to 0603 pads, it's like asking for trouble, these pads will break easily.
So I had to put two 100ohm resistors to route the circuit to the connector pins.
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1224811)
On unmodified firmware, u-boot and linux shell are shown!
U-Boot SPL 2018.01 (May 25 2021 - 08:44:03)
DRAM: 64 MiB
Trying to boot from sunxi SPI
U-Boot 2018.01 (May 25 2021 - 08:44:03 +0800) Allwinner Technology
CPU: Allwinner F Series (SUNIV)
Model: Lichee Pi Nano
DRAM: 64 MiB
show_dram_config:82ea5bc0, 82ea7ee8, 0, 82fc8000
SPI-NAND: W25N01GV is found size: 128MB.
*** Warning - bad CRC, using default environment
cfg_video_init:in:e59ff014
Setting up a 800x480 lcd console (overscan 0x0)
SPI-NAND: W25N01GV is found size: 128MB.
sunxi_lcdc_backlight_enable_user pwm 80
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
SPI-NAND: W25N01GV is found size: 128MB.
SPI-NAND: 3145728 bytes @ 0xf00000 Read: OK
SPI-NAND: 20480 bytes @ 0xd00000 Read: OK
## Booting kernel from Legacy Image at 80500000 ...
Image Name: Linux-5.2.0-licheepi-nano
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3071416 Bytes = 2.9 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80c00000
Booting using the fdt blob at 0x80c00000
Loading Kernel Image ... OK
Loading Device Tree to 816fa000, end 816ffee3 ... OK
add fb mem rsv ok, 83f44000, bc000
Starting kernel ...
-
I overcame the ocassional lockups.
The problem happens because the phoenix process crashes, but the system keeps running normally.
This do_other_update file (attached) will create a script that monitors phoenix, set it to start at boot time, and restart phoenix if it dies.
The result can be read in result.log in the usb drive.
#!/bin/sh
SCRIPT="/etc/init.d/S31local.sh"
echo "Adding phoenix monitor to the system" >/mnt/udisk/result.log
# Create phoenix_monitor
echo '#!/bin/sh' >/usr/bin/monitor_phoenix
echo 'LD_LIBRARY_PATH=/dso/lib/:$LD_LIBRARY_PATH' >>/usr/bin/monitor_phoenix
echo 'export LD_LIBRARY_PATH' >>/usr/bin/monitor_phoenix
echo 'while true; do' >>/usr/bin/monitor_phoenix
echo ' sleep 1' >>/usr/bin/monitor_phoenix
echo ' if [ "$(pidof phoenix)" = "" ]; then' >>/usr/bin/monitor_phoenix
echo ' echo "Phoenix killed! Restarting..."' >>/usr/bin/monitor_phoenix
echo ' /dso/app/app &' >>/usr/bin/monitor_phoenix
echo ' fi' >>/usr/bin/monitor_phoenix
echo 'done' >>/usr/bin/monitor_phoenix
# Set exec permissions
chmod +x /usr/bin/monitor_phoenix
# Ensure file exists and the line wasn't already added
if [ -f $SCRIPT ]; then
if [ "$(cat $SCRIPT | grep monitor_phoenix)" = "" ]; then
echo '/usr/bin/monitor_phoenix &' >> $SCRIPT
echo "Entry added to the boot script" >>/mnt/udisk/result.log
else
echo "Entry already exist, skipping" >>/mnt/udisk/result.log
fi
else
echo "$\"SCRIPT\" not found!" >>/mnt/udisk/result.log
echo "Your file might use a different filename" >>/mnt/udisk/result.log
echo >>/mnt/udisk/result.log
echo "init.d contents:" >>/mnt/udisk/result.log
ls /etc/init.d/S* >>/mnt/udisk/result.log
fi
Recovering takes only 4 seconds, much better than rebooting the whole system, until Hantek fixes the bugs.
The procedure is as simple as copying "do_other_update" and "3kb_do_other_update.upk"(In Gdrive folder) to the usb and run a system update.
-
Bravo! :clap: :clap: :clap: :clap:
DavidAlfa,
Amazing work and way beyond hacking, at this stage you should offer your services to Hantek, to fix their broken firmware. You could teach more than a few lessons to their programmers. . :-+ :-BROKE
BTW per your suggestion, I moved my post about the usbtmc.ko module from the main thread to this hacking thread.
The usbtmc.ko module is the driver for the USB test measurement and control protocol that is used by the DSO Hantek program to interface to a PC through the rear USB port. Loading it probably loads some other USB drivers in the USB stack that enable the front USB port, and the update command does the same.
The best way is to check what modules are loaded before and after insmodding the usbtmc.ko module and comparing. lsmod is the command to check which modules are loaded.
More information about the USB Test and Measurement Class protocol can be found here: https://github.com/dpenkler/linux-usbtmc
-
I'm struggling with something that migh be pretty stupid for linux users.
I have this script:
while true; do
sleep 1
if [ -f /mnt/udisk/doom/fbdoom ] && [ -f /mnt/udisk/doom/doom1.wad ]; then
pidof phoenix | xargs kill -9
cat /dev/tty0
fi
done
After this, I can see the output of the keypad.
If I try to read tty0 while phoenix is running, I get nothing, and tty0 stops working, I need to reboot after that.
The system drops messages to the kernel log like this:
[ 464.270101] dso keyboard: key (code 0x15) pressed.,20
[ 464.920075] dso keyboard: key (code 0x15) released.,20
So, in the script, I tried to check if the Start/Stop was pressed by reading the last line of dmesg.
But that also hangs tty0. Very very strange. I don't undertand why, since I only read dmesg!
while true; do
sleep 1
if [ -f /mnt/udisk/doom/fbdoom ] && [ -f /mnt/udisk/doom/doom1.wad ]; then
while [ -z "$(dmesg | tail -1 | grep -Eo '(0x15)')" ]; do
sleep 1
done
pidof phoenix | xargs kill -9
cat /dev/tty0
fi
done
It's driving me crazy |O |O |O
Edit: I gave up. Made the Doom package, but there's no key to trigger it, it will run whenever the doom files are present.
-
Hello everyone, I just registered and I want to ask a question, I have the DSO2D15 but I have not used it yet, what I want to know is if to read the SPI memory it is necessary to desolder it or can you connect it directly with wires to the programmer, the programmer that I have It is the RT809H.
Thanks
Regards
-
Don't worry, there's no need to do so.
We have all hardware version firmare to flash the whole system.
And there're methods to restore you serial number.
It's unbrickable, you can always flash it.
-
I'm struggling with something that migh be pretty stupid for linux users.
...
DavidAlfa,
As I wrote in the main thread, the problem is when the update process starts the shell with "sh -c <string>", it doesn't take the input from the keyboard but from the <string> argument.
What you could do about this is at least in theory very simple: kill the shell process and restart it, then it will accept commands from the keyboard (tty0) again.
-
Hello everyone, I just registered and I want to ask a question, I have the DSO2D15 but I have not used it yet, what I want to know is if to read the SPI memory it is necessary to desolder it or can you connect it directly with wires to the programmer,
...
Neither is required. Thanks to the amazing work of DavidAlfa, and as he explained, there is a switch underneath the scope that puts it into FEL mode. Check his repository for more information.
-
Please read my post carefully. I'm running it from the console. The issue is not related to the "sh -c" thing.
Anyways, when your update script is called, it's executed inside that shell.
Guess what happens when you kill the opened sh? Yes, your script is killed too...
The only workaround I found was to add a file to /etc/init.d, so it gets called at boot start and runs the doom monitor script as a daemon.
It works nicely, except whenever I read dmesg while phoenix is running.
I found the culprit of everything!
Running this:
pidof phoenix | xargs kill -9
cat /dev/tty0
- Booting the system, not touching any key, works!
- Pressing any key before killing phoenix, hangs tty0 |O |O
I found some code that opens and debugs dev/input devices.
Indeed, it shows data when no key was pressed while running phoenix.
Otherwise, it shows nothing.
Checking inside libanolis, it seems to open /dev/input/event0.
Thus, I guess killing it leaves the device open/busy.
We're getting close!
-
I cross-compiled ltrace to trace librarycalls and hopefully see the calls to libanolis.
But ltrace doesn't support arm for new kernels since long time ago! |O
Any other way to spy library calls?
I sucessfully cross compiled strace. It works nicely.
Attach the binary for anyone wanting to hack around!
Easy as copying to the usb an running it.
I'm analyzing the endless output after tracing phoenix! Looooots of calls
If anyone wants to look (18MB for barely 10 second run!): https://drive.google.com/file/d/1VTvxoUMlnpno_Ax5hFIcQDQiDj4zq0JI/view?usp=sharing
I Saw:
181 00:01:03.494214 open("/dev/input/event0", O_RDWR) = 8
181 00:01:03.501070 ioctl(8, EVIOCGNAME(128), "afg3050_kbd\0") = 12
-
I grabbed the strace, and looked at the things I'd look first: accesses to character devices and pseudofiles. (Essentially variants of grep -ne /dev/ -e /proc/ -e /sys/ 'strace phoenix.txt', where the -n option enables line numbers, so I can refer to those easily.)
Running ldd binaryname would reveal the dynamic library dependencies directly. It obviously uses FreeType for rendering text, but the libanolis.so.0 got me stumped. I wonder if it is Hantek's internal GUI library or what. Other than that, the lib references I see are typical compression and image format stuff, SQLite3 for file-based database stuff, C++ standard library 6.0.21, libsigc++, expat XML library, and so on.
Lines 187-190 show that the process opens the raw framebuffer, and memory-maps 768000 bytes of it, after getting the framebuffer information. I'd wager it's a 16-bit truecolor (R5G5B5 or R5G6B5) 800×480 framebuffer; the numbers match.
Around line 1292, we can see the /dso/etc/load_fpga_kb.sh script is used to ensure the FPGA kernel module is loaded. At lines 1369-1370, we see that the FPGA character device driver /dev/tn652_fpga_cfg is only used to tell it which firmware file to load, by writing the firmware file name (psram_board_test.fs.bin) and nothing else.
From line 1584 onwards, you can see that the process uses configfs (another pseudofilesystem like sysfs and procfs, dedicated for kernel stuff) to configure the USB gadget /sys/kernel/config/usb_gadget/g1, so that the system will appear as an USB device when connected to another host, using the standard Linux USB gadget driver.
Note that seems to use musb_hdrc, Inventra Highspeed Dual Role Controller, as used on e.g. Allwinner SOCs.
From line 1906 onwards, we can see how GPIO pins are configured and used. Another set continues at line 2873.
At and after line 1998, we can see that the process opens /dev/input/event0, which happens to be an afg3050_kbd type Linux Input device (https://www.kernel.org/doc/html/latest/input/input_uapi.html). As I understand it, AFG3050 is an FPGA, so the afg3050_kbd driver obviously implements an event device for the "keyboard" on the device. Normally, events (https://www.kernel.org/doc/html/latest/input/input.html#event-interface) (16 bytes per struct input_event) are only read from the device (the uinput device being special one, allowing one to create input event devices in software), but there are a LOT of writes to this device... intriguing.
At and after line 2859, we can see that the /dev/spidev1.0 character device is used a lot. This is a Linux spidev (https://www.kernel.org/doc/html/latest/spi/spidev.html) device node, controlling a SPI bus; this part also mixes in some GPIO pin stuff. Poor gpiochip0 pin gpio135 seems to be pulsed at 33Hz for a while.
To get any further, one would need to know what to look for. For example, see what the process does when stuff is manipulated; or see how different bootups differ.
-
@NominalAnimal
Good work! Yes, libanolis is probably an internal Hantek GUI library, as you won't find any references to it except in other Hantek products.
Also the AFG3050 FPGA is used in other Hantek DSOs, my guess it's just an 8-bit MCU+FPGA to debounce/process the various LEDs, buttons and rotary controls on the front panel of their DSOs.
-
Hello. With the firmware of the platform versions 3000, 3101, everything works normally for me, and in version 3102 the rear USB connection icon does not disappear, and when the flash drive is connected, it is not detected until you start the update. My version is determined not by 3000, but by b000 (b101). I was flashing the original platform, there is version a015.
I also want to ask if someone connects PhoenixSuit_CN to the oscilloscope? I have no connection.
-
Yeah I spent some hours doing the same :-DD.
Remember that strace is done with -ff argument, so ALL child process are shown there too!
You forgot the lines where it calls check_sys_inf to retrieve the system config model, serial, pcb... ;)
libanolis uses /dev/fb0, which is a 800x480 16bit framebuffer, so yes, its size is exactly 750KB.
The system starts in /etc/init.d/S31local.sh, it calls /dso/app/boot.sh
boot.sh calls /dso/app/app (also a bash script).
app opens /dso/app/phoenix (executable)
Then phoenix / libanolis call these scripts among others:
[/dso/etc/]: load_fpga_kb.sh, insmod_usb_driver, S30dbus, usb_bord_mount.sh
-
If you run
LANG=C LC_ALL=C objdump -T path-to-dynamic-library | awk '$2=="g" && $4==".text" { printf "%s (%s)\n", $7, $6 }' | sort | uniq
you get a list of dynamic symbols in the code section (the part in parentheses is the version each symbol). Since this is just a list of symbols in alphabetic order, it is neither functional nor creative, and is therefore not protected by copyright.
Then, you can create an interposing library that is loaded by specifying the path to the interposing library in the LD_PRELOAD_LIB environment variable (multiple ones can be specified if separated by colons, :.) If the binary uses setuid bits to stop this functionality, you can rename the actual library and use an wrapper library instead. (On read-only mounts, you can do this via bind-mounts or overlays.)
Problem is, we cannot really write the interposing/wrapping (and tracking) functions themselves in C, because we don't know their prototypes. All the functions know is the current registers, the address where it was called from, and obviously the address of the function it is to interpose/wrap. It has to preserve all registers to do anything meaningful, so a hardware-specific inline assembly wrapper can be used via macros to define the interposers (via a call to a C function to log it, perhaps using a single logger C function); the interposed symbol addresses are looked up using <dlfcn.h> dlsym(RTLD_NEXT, "symname") call for each one in an ELF constructor function (which are run when the library is loaded, automatically, by the dynamic run-time linker) and stored in variables the interposer functions use to call. There is some overhead, but this is a purely userspace implementation.
So, tracing interesting function calls is quite doable even without ltrace, but without function prototypes, we cannot gather much information. Although, I wonder if just updating ltrace (https://gitlab.com/cespedes/ltrace)'s arm sysdeps (https://gitlab.com/cespedes/ltrace/-/tree/master/sysdeps/linux-gnu/arm) would suffice it to get it working on current kernels; I wasn't even aware it had bit-rotted enough to not work on arm on current kernels.
I wonder how interesting objdump -d /dso/lib/libanolis.so.0.0.0 would be...
Almost as interesting as modinfo /dso/etc/*.ko would be, especially those that have a license: GPL line, I think.
-
Oh, I forgot. Here (https://github.com/therealsaumil/static-arm-bins/blob/master/ltrace-arm-static-0.7.91) I found an already compiled ltrace that worked.
Dumbest thing in my life. Searched "ltrace arm support", "ltrace armv5", "ltrace arm fix" and a thousand more.
But never something simple as "ltrace arm". Bang, first google result. Made me feel kinda stupid :-DD
Worked with it 2 days go, but is excruciatingly slow and crashes often, in the end I got tired and left it for other moment...
-
Dang it's hard to post pictures here...
I promised an update when I upgraded my DSO2C15 to a DSO2D15 by installing 3 missing components on the motherboard.
It was a hairy install as I have soldering skills but not of surface mount and the DAC is horrendously small pitch.
However, it works...
The missing parts were easy to find:
DAC : DAC902E (Arrow)
OpAmp : LMH6702 (Arrow)
Relay : FD4/4.5-S |428||282| XA0920A (EBay)
Total incl. shipping was under $27
Thank you very much for the references list and pictures. Brilliant!
I purchased all the parts in Aliexpress and yesterday they arrived and I did the population of my DSO2C10 board. Everything works and I have a functional enough DSO2D15.
I guess going for the cheapest components have compromised a bit the quality. The signal is quite noisy compared with the calibration signal, but enabling the BW 20MHz fixes the issue completely.
edit: d'oh! I missed the quote
-
@Josepsp did u find all components in ali?
Can u share link maybe in pm. I don't want to pay Digi or arrow 20 for the shipment... Thanks!!!
-
@Josepsp did u find all components in ali?
Can u share link maybe in pm. I don't want to pay Digi or arrow 20 for the shipment... Thanks!!!
Sure, I'm sending you a PM with the links, although they should be easy to find just by searching the references that @Boyeen shared.
If anyone is in the same boat the tricky one was the relay FD4/4.5-S , which appeared only with the search term "relay HDF4".
BTW, checking the datasheet the S refers to "smd", but there's also a DIP variant with the same exact dimensions without the S in the code, which I was about to search too, as it looked suitable just bending and clipping the legs. I finally found the proper one so no need. The units with an L in the code are latching ones and I assume those will malfunction.
-
When I was reading about FEL mode for the Allwinner, there is a section on a page that suggests that you can u-boot over USB to either boot into the internal software, or boot the entire system over USB by loading your own initramfs:
https://linux-sunxi.org/FEL/USBBoot#Boot_the_system_over_USB
If this was used to start miniroot (the linked busybox initramfs) it might be possible to then mount other internal bits of flash filesystem for inspection.
Or potentially decompose the firmware upgrade into the parts needed to entirely boot externally from USB.
It looks like there is a lot that could be played with :)
-
Yes, you can boot anything you want, of course compiled first (another fun party).
But meh, not having FPU cripples the performance by a factor of 20 or more... it's a bad base from the start.
I don't feel it worths the time anymore.
-
As I posted in the main DSO2X1X thread, there is a software tool that allows access to the Allwinner F1C200s SOC in FEL mode through the USB connector on the back of the scope: sunxi-fel, which is part of sunxi-tools.
I am using Ubuntu 20.10 on my laptop, and it has available a packaged version of sunxi-tools (unfortunately not the latest version, but that can be compiled easily).
Just a quick test with booting the DSO in FEL mode and connecting it to my Linux laptop:
andrew@andrew-ThinkPad-T420:~$ sunxi-fel version
ERROR: You don't have permission to access Allwinner USB FEL device
andrew@andrew-ThinkPad-T420:~$ sudo sunxi-fel version
Warning: no 'soc_sram_info' data for your SoC (id=1663)
AWUSBFEX soc=00001663(unknown) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000
Two things:
1. You must run sunxi-tools as root or give permission to user.
2. The packaged sunxi-tools in Ubuntu 20.10 works but does not identify the F1C200s, but the latest version of sunxi-fel does.
Note that this FEL mode is before u-boot has started, so the actions available are very limited, but for example one should be able to tell the SOC to load the u-boot SPL binary from a file and run it, then starts u-boot proper (see the uboot <file-with-SPL> command below). (SPL = Secondary Program Loader which load the main u-boot binary into RAM)
So at this point I should be able to run any sunxi-fel command:
Usage: ./sunxi-fel [options] command arguments... [command...]
-v, --verbose Verbose logging
-p, --progress "write" transfers show a progress bar
-l, --list Enumerate all (USB) FEL devices and exit
-d, --dev bus:devnum Use specific USB bus and device number
--sid SID Select device by SID key (exact match)
spl file Load and execute U-Boot SPL
If file additionally contains a main U-Boot binary
(u-boot-sunxi-with-spl.bin), this command also transfers that
to memory (default address from image), but won't execute it.
uboot file-with-spl like "spl", but actually starts U-Boot
U-Boot execution will take place when the fel utility exits.
This allows combining "uboot" with further "write" commands
(to transfer other files needed for the boot).
hex[dump] address length Dumps memory region in hex
dump address length Binary memory dump
exe[cute] address Call function address
reset64 address RMR request for AArch64 warm boot
readl address Read 32-bit value from device memory
writel address value Write 32-bit value to device memory
read address length file Write memory contents into file
write address file Store file contents into memory
write-with-progress addr file "write" with progress bar
write-with-gauge addr file Output progress for "dialog --gauge"
write-with-xgauge addr file Extended gauge output (updates prompt)
multi[write] # addr file ... "write-with-progress" multiple files,
sharing a common progress status
multi[write]-with-gauge ... like their "write-with-*" counterpart,
multi[write]-with-xgauge ... but following the 'multi' syntax:
<#> addr file [addr file [...]]
echo-gauge "some text" Update prompt/caption for gauge output
ver[sion] Show BROM version
sid Retrieve and output 128-bit SID key
clear address length Clear memory
fill address length value Fill memory
Note that when you boot in FEL mode the DSO buttons light up but the screen stays black (no backlight). This is as expected since the buttons LEDs are controlled by an FPGA but the screen and its backlight are controlled by the SOC.
-
I have just built the version of sunxi-tools patched by Icenowy for the F1C100s (identical to the F1C200s, except different DRAM size). Now sunxi-fel correctly identifies the SOC:
$ sudo /usr/local/bin/sunxi-fel version
AWUSBFEX soc=00001663(F1C100s) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000
As DavidAlfa found out recently, the latest version of sunxi-fel can be used to read the SPI flash to a file, but the version of sunxi-tools patched by Icenowy doesn't.
So I tried the sunxi-fel which I compiled from source:
$ sudo sunxi-fel spiflash-info
Warning: no 'soc_sram_info' data for your SoC (id=1663)
SPI support not implemented yet for 0 ((null))!
But then I remembered that George Hilliard had merged Icenowy patches with the master sunxi-tools, his version of sunxi-tools can be found here: https://github.com/thirtythreeforty/sunxi-tools
Which I compiled (it takes 30 seconds) and tested: success! 8)
$ sudo /usr/local/bin/sunxi-fel spiflash-info
Manufacturer: Unknown (00h), model: EFh, size: 1024 bytes.
$ sudo /usr/local/bin/sunxi-fel spiflash-read 0 1024 flash.bin
The resulting flash.bin renamed to flash.txt is attached below and yes, it does seem to be u-boot and Linux kernel related code.
So in principle it should be possible to examine/read/write/backup the SPI flash (in other words, the DSO firmware) using sunxi-fel amd the USB OTG port on the back of the DSO. I still have to check how to make the Winbond SPI chip get properly recognized by sunxi-fel.
-
This is all fascinating progress, which leaves me itching to fiddle with the innards of mine. But mine is working OK for me (aside from the awful triggering on slopes) so I'm reluctant to mess it up since I'm actually using it for work.
The comments about lack of a FPU, as an ex-Ti DSP algorithm optimiser I'm like, "these kids and their floating point... back in my day we used fixed point and were forced to love it!" lol
-
This is all fascinating progress, which leaves me itching to fiddle with the innards of mine. But mine is working OK for me (aside from the awful triggering on slopes) so I'm reluctant to mess it up since I'm actually using it for work.
The comments about lack of a FPU, as an ex-Ti DSP algorithm optimiser I'm like, "these kids and their floating point... back in my day we used fixed point and were forced to love it!" lol
;) I would suggest waiting until there is a 100% fool-proof, simple way to backup the firmware and restore it, and to test communicate with the Linux kernel using the USB OTG interface (the USB port on the back).
Yeah, no FPU, but there are DSP instructions. :D
I think people who are complaining about the lack of FPU or overclocking are missing the point: does this $1.40 (!) SOC perform adequately for the intended purpose at the default settings? It seems yes, and the programmers at Hantek should focus first on fixing the remaining bugs in future firmware updates.
Make it work, make it right, make it fast.
-- Kent Beck
-
I have recompiled again sunxi-tools, this time by editing fel-spiflash.c which is the program that read and writes to SPI flash; I have added the parameters for the Winbond W25N01GV which is found inside the Hantek DSO. Unfortunately I have ascertained that the original code is buggy and does not read or write correctly to flash, and I am not sure it ever did with the F1C200s SOC, no matter the SPI flash chip used. To debug that code would require many hours of investigation and programming, a 200MHz logic analyzer with an SPI protocol decoder and some surgery on the DSO mainboard, and I am just not going to do that, also I don't have the logic analyzer.
So that path to backup the DSO firmware is closed for the moment. Imo the best option is still to boot a functional u-boot + DTB + Linux kernel + root filesystem over USB OTG and use that to examine/read/write/backup the SPI flash.
I'll be quite busy this week so perhaps next weekend I'll dive into George Hilliard's Buildroot GitHub repository and try to make something out of it for the Hantek DSO. :-BROKE
-
Dude :palm:. Don't take it too bad, but adding the chip ID is simply useless. The read/write algorithm is pretty different for spi nand.
Not a bug problem. For the SPI nor, you simply throw the read command and the address, and get the data.
For nand, you must fetch the nand page to the output buffer, wait for it to complete, then read the buffer.
Same for writing, for NOR you erase the block and write the data.
For NAND you have to erase the block, send data to the buffer, and send the programming command. And again wait.
That's what I've been doing. Almost working but there are strange bugs with the internal handler, sometimes it doesn't like sending comands.
I guess if it's a timing issue. I don't know but it's driving be mad!
Also, the spi nand as an OTP area. 10pages x 2048Bytes. I didn't check it the contents, but who knows.
As its name says, it's only one-time programmable. Who knows if hantek wrote some unique data there, like calibrations and such.
Other thing I've been trying is to buiild u-boot with usb support. But no way. The documentation is null, so guess what the *** is going on.
Why the hell they added options for sunxi/suniv, if when you enable them you get all kinf of "not defined" or "not implemented" errors
Edit: And now it seems the spi flash os gone. No matter what flash, the dso is dead. Will put the original memory back and bye!
I'm out of here. Burn all that chinese crap down!
-
Dude :palm:. Don't take it too bad, but adding the chip ID is simply useless. The read/wrire algorithm is pretty different for spi nand.
Not a bug problem. For the SPI nor, you simply throw the read command and the address, and get the data.
For nand, you must fetch the nand page to the output buffer, wait for it to complete, then read the buffer.
Same for writing, for NOR you erase the block and write the data.
For NAND you have to erase the block, send data to the buffer, and send the programming command. And again wait.
That's what I've been doing. Almost working but there are strange bugs with the internal handler, sometimes it doesn't like sending comands.
I guess if it's a timing issue. I don't know but it's driving be mad!
Yes, SPI NOR and NAND use different algorithms, but the JEDEC ID command is the same.
I was trying to get the chip ID recognized as a start. but not even that works, so at this stage sunxi-fel definitely cannot be used to read/write the SPI chip in this DSO.
And as I wrote, debugging the sunxi-fel code would require more work than I have the time for, and a good logic analyzer (that I don't have).
Also, the spi nand as an OTP area. 10pages x 2048Bytes. I didn't check it the contents, but who knows.
As its name says, it's only one-time programmable. Who knows if hantek wrote some unique data there, like calibrations and such.
Other thing I've been trying is to buiild u-boot with usb support. But no way. The documentation is null, so guess what the *** is going on.
Why the hell they added options for sunxi/suniv, if when you enable them you get all kinf of "not defined" or "not implemented" errors
Edit: And now it seems the spi flash os gone. No matter what flash, the dso is dead. Will put the original memory back and bye!
I'm out of here. Burn all that chinese crap down!
You don't need u-boot with USB support. What you really want is a kernel with USB-OTG support, and George Hilliard's GitHub repository already has that.
Well, I guess now you have two choices, either solder another SPI chip to replace the dead one, or solder back the original chip and be done with it, and it seems to have chosen the latter option.
I understand your frustration, but unfortunately this is what hacking is all about: lots of failures and few victories, but many bloggers only report their successes. At least you have been very honest about everything you have achieved and I am very grateful to you for that. :-+
-
Nope, the jedec response is different.
While the nor answers from the 1st bit, in the nand the first bit is dummy. The original sunxi-fel code doesn't handle this.
What I do is to read 1 extra byte, check the 1st, if not valid check the 2nd, and start parsing. It works perfect.
Well, "what I need" is relative.
If uboot USB worked, I could set the env to automatically backup the spi. Simple.
Building Linux for a obscure, badly documented soc is a lot of work.
Don't get me wrong, I like hacking.
But also I hate losing my time.
And when the Linux building storm starts, I prefer to spend my time elsewhere.
I'm not used yo compiling kernels, every little crappy code drops errores and I have to ask Google , the fu*** dependencies, or strange build flags, exports...
I'll take the sleep-forever pill thanks! :-DD
-
Nope, the jedec response is different.
While the nor answers from the 1st bit, the nand the first bit is dummy. The original sunxi-fel code doesn't handle this.
What I do is to read 1 extra byte, check the 1st, if not valid check the 2nd, and start parsing. It works perfect.
Actually if you check the datasheet what it says is that the JEDEC ID command is followed by 8 "dummy" clock cycles for the NAND. But you are right that the original sunxi-fel code does not handle this. In fact, it is missing most of the code to make reading/writing to SPI NAND possible, which is the reason I concluded that trying to use sunxi-fel and the BROM environment to read/write/backup the DSO firmware is NOT the right way.
Well, "what I need" is relative.
If uboot USB worked, I could set the env to automatically backup the spi. Simple.
Building Linux for a obscure, badly documented soc is a lot of work.
Don't get me wrong, I like hacking.
But also I hate losing my time.
And when the Linux building storm starts, I prefer to spend my time elsewhere.
I'm not used yo compiling kernels, every little crappy code drops errores and I have to ask Google , the fu*** dependencies, or strange build flags, exports...
I'll take the sleep-forever pill thanks! :-DD
Actually for embedded systems most people use BuildRoot to build u-boot, the DTB and Linux kernel and a root filesystem. which is why I suggested you take a look at George Hilliard's GitHub repository. I have since found two more GitHub repositories with BuildRoot configurations for the F1C100s.
BuildRoot actually even builds gcc and the needed libraries if configured to do so, it really simplifies the build process.
-
Following the datasheets:
W25Q64 (NOR)
[0x9F] [vendor] [model] [size]
W25N01GV (NAND)
[0x9F] [dummy] [vendor] [model] [size]
Sunxi-fel is simply old and poorly maintained, didn't implement the SPI NAND(These are relatively new memories, I didn't knew they existed).
At least in my version, it didn't gave a f*** aboot was actually connected, hardcoding the memory type in "default_spi_flash_info".
That was the first changes I made. Detecting the memory before any operation.
For now I stopped that path. It's very slow and messy to work with. At very best 150KB/s with NOR, but 1/3 of that with NAND since it needs for commands.
Now I'm looking into this: http://linux-sunxi.org/Miniroot (http://linux-sunxi.org/Miniroot)
That would be great. A simple miniroot environment, Build with the enought to support SPI and USB.
I don't know what happened with the SPI. It programmed ok with the CH341A. I guess I fucked something up while sending commands to the SPI.
I guess that the Hantek fastboot doesn't check write protection at all. WIl lsolder it back and try.
Does anyone have a nice camera? Would be great to have high resolution scans of the board. My phone camera freaks out with black pcbs...
-
...
Now I'm looking into this: http://linux-sunxi.org/Miniroot (http://linux-sunxi.org/Miniroot)
...
From the page you linked to:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- KERNEL_MODULES=/path/to/kernel/INSTALL_MOD_PATH
That won't work: wrong compiler. We have an ARM926EJ-S CPU, it doesn't have (as far as I know) hardware floating point.
I suggest you look into buildroot and base yourself on the previous work in three different github repositories that got buildroot working on the F1C100s / Lichee Pi Nano months ago.
You may find that this will save you hours of work and lots of headaches... :phew:
-
What's the problem? Use arm-linux-gnueabi.
arm-linux-gnueabihf is for lichee pi zero (Which has FP).
The memory programmed correctly and the dso is alive again.
I disassemble everything, I'm trying to find all gpio input/outputs.
I found the kernel modules in lib/modules/3.10.65/modules.builtin
kernel/fs/binfmt_script.ko
kernel/fs/mbcache.ko
kernel/fs/configfs/configfs.ko
kernel/fs/ext4/ext4.ko
kernel/fs/fat/fat.ko
kernel/fs/fat/vfat.ko
kernel/fs/jbd2/jbd2.ko
kernel/fs/nls/nls_base.ko
kernel/fs/nls/nls_cp437.ko
kernel/fs/nls/nls_iso8859-1.ko
kernel/fs/overlayfs/overlayfs.ko
kernel/crypto/crypto.ko
kernel/crypto/crypto_wq.ko
kernel/crypto/crypto_algapi.ko
kernel/crypto/crypto_blkcipher.ko
kernel/crypto/chainiv.ko
kernel/crypto/eseqiv.ko
kernel/crypto/crypto_hash.ko
kernel/crypto/aes_generic.ko
kernel/crypto/arc4.ko
kernel/crypto/crc32c.ko
kernel/crypto/rng.ko
kernel/crypto/krng.ko
kernel/block/cfq-iosched.ko
kernel/drivers/base/firmware_class.ko
kernel/drivers/base/regmap/regmap-i2c.ko
kernel/drivers/base/regmap/regmap-spi.ko
kernel/drivers/char/dump_reg/dump_reg.ko
kernel/drivers/char/sunxi-sysinfo/sysinfo.ko
kernel/drivers/dma/virt-dma.ko
kernel/drivers/dma/sun3i-dma.ko
kernel/drivers/gpio/gpio-pcf857x.ko
kernel/drivers/hid/hid.ko
kernel/drivers/hid/usbhid/usbhid.ko
kernel/drivers/i2c/i2c-core.ko
kernel/drivers/i2c/busses/i2c-sunxi.ko
kernel/drivers/input/input-core.ko
kernel/drivers/input/input-polldev.ko
kernel/drivers/input/evdev.ko
kernel/drivers/input/keyboard/sunxi-keyboard.ko
kernel/drivers/input/serio/serio.ko
kernel/drivers/input/serio/serport.ko
kernel/drivers/input/serio/libps2.ko
kernel/drivers/media/cedar-ve/cedar_ve.ko
kernel/drivers/media/v4l2-core/videodev.ko
kernel/drivers/media/v4l2-core/v4l2-common.ko
kernel/drivers/mmc/core/mmc_core.ko
kernel/drivers/mmc/host/sunxi-mmc.ko
kernel/drivers/mmc/host/sunxi-mmc-debug.ko
kernel/drivers/mmc/host/sunxi-mmc-export.ko
kernel/drivers/mmc/host/sunxi-mmc-v4p1x.ko
kernel/drivers/mmc/host/sunxi-mmc-v4p00x.ko
kernel/drivers/mmc/host/sunxi-mmc-v4p10x.ko
kernel/drivers/mmc/host/sunxi-mmc-v4p5x.ko
kernel/drivers/mtd/mtd.ko
kernel/drivers/mtd/sunxipart.ko
kernel/drivers/mtd/mtd_blkdevs.ko
kernel/drivers/mtd/mtdblock.ko
kernel/drivers/mtd/chips/chipreg.ko
kernel/drivers/mtd/devices/m25p80.ko
kernel/drivers/net/mii.ko
kernel/drivers/of/of_i2c.ko
kernel/drivers/pwm/pwm-sunxi.ko
kernel/drivers/rtc/rtc-cmos.ko
kernel/drivers/rtc/rtc-pcf8563.ko
kernel/drivers/scsi/scsi_mod.ko
kernel/drivers/scsi/sd_mod.ko
kernel/drivers/spi/spidev.ko
kernel/drivers/spi/spi-sunxi.ko
kernel/drivers/tty/serial/serial_core.ko
kernel/drivers/tty/serial/sunxi-uart.ko
kernel/drivers/usb/usb-common.ko
kernel/drivers/usb/core/usbcore.ko
kernel/drivers/usb/gadget/udc-core.ko
kernel/drivers/usb/host/ehci-hcd.ko
kernel/drivers/usb/host/sunxi_hci.ko
kernel/drivers/usb/storage/usb-storage.ko
kernel/drivers/usb/sunxi_usb/sunxi_usb_hcd0.ko
kernel/drivers/usb/sunxi_usb/sunxi_usbc.ko
kernel/drivers/video/fb.ko
kernel/drivers/video/cfbfillrect.ko
kernel/drivers/video/cfbcopyarea.ko
kernel/drivers/video/cfbimgblt.ko
kernel/drivers/video/sunxi/disp/disp/disp.ko
kernel/drivers/video/sunxi/disp/lcd/lcd.ko
kernel/sound/soundcore.ko
kernel/sound/core/snd.ko
kernel/sound/core/snd-timer.ko
kernel/sound/core/snd-pcm.ko
kernel/sound/core/snd-page-alloc.ko
kernel/sound/core/snd-compress.ko
kernel/sound/soc/snd-soc-core.ko
kernel/sound/soc/sunxi/sun3iw1_codec.ko
kernel/sound/soc/sunxi/sunxi_cpudai.ko
kernel/sound/soc/sunxi/sun3iw1_sndcodec.ko
kernel/net/ipv4/ip_tunnel.ko
kernel/net/ipv4/ipip.ko
kernel/net/ipv4/gre.ko
kernel/net/ipv4/ip_gre.ko
kernel/net/ipv4/tunnel4.ko
kernel/net/ipv4/tcp_cubic.ko
kernel/net/ipv4/netfilter/ip_tables.ko
kernel/net/ipv4/netfilter/iptable_filter.ko
kernel/net/key/af_key.ko
kernel/net/netfilter/x_tables.ko
kernel/net/netfilter/xt_tcpudp.ko
kernel/net/packet/af_packet.ko
kernel/net/unix/unix.ko
kernel/net/wireless/cfg80211.ko
kernel/net/xfrm/xfrm_algo.ko
kernel/net/xfrm/xfrm_user.ko
kernel/lib/bitrev.ko
kernel/lib/crc16.ko
kernel/lib/crc32.ko
kernel/lib/lzo/lzo_compress.ko
kernel/lib/lzo/lzo_decompress.ko
kernel/lib/xz/xz_dec.ko
-
Uni-T do meters with NCV? Dammit now I need to upgrade my old UT136B.
Oh and good progress, shame about the SPI flash failure. And a bit alarming that there is a OTP area.
-
OK revisiting my upgrade situation I realise I've been a bit thick/blind all along on the other thread about versions not installing...
The 20210601 update is a weird one. I don't know how I missed this, but the app update lines are commented out of the do_update.sh so that it ONLY replaces the FW with 3102 and nothing else. I've hacked it about such that it contains latest (to us) FW 3202 and re-enabled the app update.
Now, my system looks like this: software 20210517 firmware: 3202
No comment on stability/improvements yet - don't forget we're probably not supposed to have this version of phoenix at all, so it might be entirely untested - and they didn't bundle it with 3202 - I have.
I've put it (filename dso3kb_20210601_3202.upk) in DavidAlfa's writeable GDrive area if anyone wants to play at their own risk
-
The SPI issue was because I was trying to send low-levl commands to it modifying sunxi-fel.
People running normal operations shouldn't get any problem. So don't worry about that,
The OTP is likely unused.
So the FW is definitely linked to that file. Easy to make a script that backups and restores it!
-
Definitely seeing some stability improvements with the hacked together upk. Not crashed once all evening - when I used to fiddle with memory depth at the fastest capture rate it crashed quite often, but so far it has been really stable.
AWG still generates 1.8Vpp even though it's configured for 1.5Vpp (but then it did that out of the factory with 20210416 and FW 3200 so nothing new).
Calibration works OK, no errors.
Still has DC offsets when channels set to GND mode. No improvement to triggering.
-
The DC offset in GND coupling happened only when changing the FW version. Keeping the factory (3000) works.
I'm definitely out of the linux hacking. Everything around the f1C100s is broken. It's by far the AllWinner SOC with worst linux support.
You end downloading chinese u-boot forks that fix something, but only that "something". Still a lot of bugs or lacking features.
Anything you enable in uboot... bang! "Not defined" or "conflicts with....". I won't spend any more time!
-
They're also looking at booting Linux on the FNIRSI-1013D "100MHz" tablet oscilloscope (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/) thread which is also based on the Allwinner F1C100 SoC family, so they may have more luck.
Maybe rather than cross compile it is possible to build on the Orange Pi with the same processor directly. Though my experience of building OpenOCD for ESP32 on the Orange Pi was very slow going.
-
Cross compiling works perfectly. It's not the typical dependencies/libs problem, but the f1c100s code, lacking a lot.
The fnirsi has a 16Mbit flash, it probably runs some rtos, not Linux. What the matter on booting Linux on that?
Anyways, since It uses spi nor Flash, it'll be easy as flash something existing like the business card. Good luck with the display :-DD
-
I've tested every psram_board_test.fs.bin from the available update packages. Those were the results:
20201118 = FW2013
20201121 = FW2013
20201207 = FW2015
20201221 = FW3000
20210105 = FW3000
20210223 = FW3101
20210311 = FW3101
20210416 = FW3200
20210510 = FW3202
20210601 = FW3102
I made custom update packages that change the FW version, they're inside "FW changer".
Now you can change the FW version in a breeze! ;)
As I suspected, not every updates applies psram_board_test.fs.bin. Neither other contents present in the update itself.
20201118
cp $WORKPATH/package/help/help.db /dso/app/
cp $WORKPATH/package/font /dso/app/ -rf
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc
20201121
cp $WORKPATH/package/help/help.db /dso/app/
cp $WORKPATH/package/font /dso/app/ -rf
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc
20201207
cp $WORKPATH/package/help/help.db /dso/app/
cp $WORKPATH/package/font /dso/app/ -rf
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc
20201221
cp $WORKPATH/package/fpga/* /lib/firmware/psram_board_test.fs.bin -rf
cp $WORKPATH/package/help/help.db /dso/app/
cp $WORKPATH/package/font /dso/app/ -rf
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc
20210105
cp $WORKPATH/package/help/help.db /dso/app/
cp $WORKPATH/package/font /dso/app/ -rf
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc
20210223
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc
cp $WORKPATH/package/spi-fpga-tn652.ko /dso/etc
cp $WORKPATH/package/load_fpga_kb.sh /dso/etc
20210304
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc
cp $WORKPATH/package/spi-fpga-tn652.ko /dso/etc
cp $WORKPATH/package/load_fpga_kb.sh /dso/etc
20210311
cp $WORKPATH/package/root/* -rf /
cp $WORKPATH/package/fpga_i2c_kb.ko /dso/etc
cp $WORKPATH/package/spi-fpga-tn652.ko /dso/etc
cp $WORKPATH/package/load_fpga_kb.sh /dso/etc
20210416
cp $WORKPATH/package/root/* -rf /
20210510
cp $WORKPATH/package/fpga/* /lib/firmware/psram_board_test.fs.bin -rf
20210601
cp $WORKPATH/package/fpga/* /lib/firmware/psram_board_test.fs.bin -rf
-
That's very useful. Are you going to put that in a note on your GDrive (maybe alongside the .upk files) so it doesn't get lost on this thread (and can be updated with each Hantek release).
The other thing we could do with picking apart is the layout of /dso/etc/data/cali.dat (aka /cache/cali.dat). It would be useful to be able to adjust calibrate against known external sources and to fix offset problems that the auto calibration (app /dso/app/dso3000c_calibration) gets wrong. I was debating modifying the contents a byte at a time to see which ones affect which area but given the size of the file and all the copying, that would be beyond tedious.
BTW David you can get the Phoenix version from the app binary by looking for a string contained "2021" (or 2020 for earlier ones) which appears like this: ^@res/drawable/hantek.ico^@%d.%d.%s^@^@^@^@1.1.0(20210416.00)^@^@ or just use strings:
strings phoenix | grep 2021
1.1.0(20210416.00)
That'd be good in your list too.
-
I see you've removed my .upk from the Writeable dir, has that gone somewhere else as currently there is no other way to get phoenix at version 20210517 with firmware 3202, even using your list of firmware update upks. (The phoenix version was in 20210601, which as you observe does not copy the app to the scope - we're not supposed to have it yet!).
-
I did what I said 2 post ago. Run any update you want. Then run the desired FW changer.
I keep it simple, avoiding the trouble of combining SW + FW together.
-
There is no update that applies phoenix 20210517 - that's why I created that custom one.
-
I've put it back in your Writable, if you want to see why it's different to standard dso3kb_20210601.upk - it doesn't just apply the 3202 firmware but enables the installation of the bundled (but otherwise not deployed) 20210517 phoenix. As I said before, we're not supposed to have it yet, none of the .upks deploy it. It's working well on my scope in combination with the 3202 firmware.
-
Actually not strictly true that we're not supposed to have it, it's also in the platform-tools-20210517.zip file in images/rootfs.ubifs
$ python3 ubidump.py -l rootfs.ubifs | grep phoenix
-rwxr-xr-x 1 0 0 868144 2021-05-27 02:24:52 dso/app/phoenix
$ python3 ubidump.py rootfs.ubifs -c dso/app/phoenix > phoenix
$ strings phoenix | grep 2021
1.1.0(20210517.00)
( ubidump.py from https://github.com/nlitsme/ubidump )
-
Speaking of which, platform tools bundles uboot-with-spl-spinand.bin, Pre-made SPI NAND read/write, at a guess.
And in sunxi-tools, nand*.c/h implementation.
-
I don't remember deleting your file?. In fact, it's dated as yesterday. Checked the recycle bin, wasn't there either :-//
I also noticed that. After modifying the update so it applied all of its contents, the system did't like it and the dso interface broke completely.
Didn't investigate any further.
uboot-with-spl-spinand is what it is- Uboot compiled with spi nand support. But that image is build to be compatible with the AllWinner BROM loader (eGon), with a specific header and such.
uboot_fb is build to be loaded at ram, also with spi nand support but adding usb and fastboot. Don't ask me how, I guess Hantek did some crazy hacks there.
nand, spi and spi nand are all different things in u-boot and sunxi.fel. Nand is usually a parallel interface, while generic spi is NOR.
Hovewer this board uses spi nand. Sunxi-fel code lacks support for that. I started working on it but I got tired of the lack of documentation and other stupid time-wasting issues.
And, in the best case, it made 44KB/s, took 1 hour to read or flash. No thanks! The best way would be to compile a program that runs in the ram, avoiding all the u-boot and linux thing.
This SOC BROM doesn't init the DRAM by default, so a dirty hack is to let sunxi-fel to do it by loading u-boot into ram, but not executing it:
sunxi-fel spl uboot.binNow the DRAM is ready. I wrote a 8MB file to the memory, took 26 seconds:
sunxi-fel write 0x80000000 8M.binThen read it back, took 21 seconds:
sunxi-fel read 0x80000000 8388608 8M.bin
Made m5sums before and after, and they were the same.
So now, the loader. Shouldn't be that hard. SPI is easy to interface in low level programming.
The computer-side interface can be easily done by scripting sunxi-fel commands, reading/writing from/to known memory addresses.
Ex.:
0x80001000: Status (Ready, Execute, ,done, error)
0x80001004: Cmd read/write/erase/protect...
0x80001008: Start address
0x8000100C: Read / write length.
0x80002000: Scratchpad start address (buffer to store the data)
For example, you write the first chunk into the buffer. Write the address and length. Write "erase"comand. Execute. Write "program" command. Execute.
And repeat with the next chunks. That's what actually sunxi-fel does, but in a such way that I cannot understand completely, I don't know how why some work and others not. So it'll be better to do it myself!
Yet to know how to execute a program and return the control to the BROM loader.
-
Holding the "Default parameters" button for about 3 seconds brings up additional options in my oscilloscope.
[IMG_4193]
-
For some reason, it was not possible to insert an image in the next branch
-
DavidAlfa,
I cloned George Hilliard's F1C100s Buildroot project and compiled it with four trivial patches. I just uploaded to your Writable a folder which is the Buildroot/output/images folder, it includes u-boot, DTB, Linux kernel and small root filesystem, all compiled for the F1C100s.
The small root filesystem is configured to open a terminal on the Gadget Serial serial interface ttyGS0, so in principle connecting the back USB port to a Linux PC should have the PC detecting the DSO as a serial device /dev/ttyACM0. It also opens a terminal on ttyS0 where you have your serial to USB converter soldered, so you can investigate the included u-boot and kernel.
The Linux kernel in GH's image is 5.2.4, compiled with gcc 8.3.0. The Hantek kernel is 5.2.0, compiled with gcc 5.4.0, a very old version of gcc !
-
I don't remember deleting your file?. In fact, it's dated as yesterday. Checked the recycle bin, wasn't there either :-//
I've probably unfairly blamed you, looks like anyone can delete files from your Writable area. Someone else then!
Might be dated yesterday (file creation) but the history only shows today. Meh, anyway. Sounds like you have put a lot of effort into fighting unknowns on this scope, whatever way we look at it we know more about its inner workings than we did before!
-
Fixed. I removed permissions for files already uploaded there, so only me and owner can change them.
(The folder itself stays writable)
Just let me know when you uploaded something, to update the new files.
It's a shame that Google disabled advanced permissions on non business accounts.
-
I found the F1C100s low-level usb driver: https://github.com/RT-Thread/rt-thread/issues/3648
They even say it's the same as the stm32, so it seem to follow a known standard for the register structure? (EHCI, OHCI, UHCI and such?)
That migh explain why there's nothing about it in the datasheet.
Then I found this bit hack to enable USB High speed mode: https://github.com/linux-sunxi/sunxi-tools/issues/146
However the F1c100s addresses are different. After some diging in the header files I got the correct address.
Effectively, the speed increased. In this case, it doubled.
I wrote 64M (Filling the entire DRAM) in 1m50s. Read in 1m38s. Md5 matches, so it's working.
Now I'm figuring out how to modify sunxi to use it.
The spi program is a low-level arm binary code, inside the file "fel-remotefunc-spi-data-transfer.h"
My idea is to make a new program specifically for the hantek HW, keeping it simple, mostly hardcoded.
Ex. "spinand read [file]", "spinand write [file]". Perhaps adding a hash for error detection.
-
Properly hacking the DSO2X1X
As I wrote in a previous post, I have used Buildroot to compile uboot, a Linux kernel and a root filesystem for the SOC inside the Hantek DSO2X1X scopes. The Linux kernel and the root filesystem are setup so that the back USB port when connected to a PC makes the DSO appear as a Linux machine accessible through a serial terminal, and a USB mass storage device with the contents of the root filesystem. Many thanks to George Hilliard who developed this small Linux distribution for his F1C100s-based business card. I am going to properly fork his project, rename it and reupload it to GitHub with the small modifications I have made.
The next step is to boot this newly compiled Linux kernel and root filesystem from a USB key plugged into the front USB port. This can be achieved by pressing the FEL button underneath the DSO while turning it on, in principle. I hope to have this going this weekend.
The first and main advantage of hacking the Hantek DSO in this way is that the contents of the SPI nand chip remain untouched, in fact there is no need to even open the back of the scope. So there is zero risk of "bricking" the DSO, and/or damaging any internal component, and/or voiding the warranty.
The second advantage is that this is a much more efficient way to debug / decompile / reverse engineer or just understand the original Hantek firmware and the inner workings of this little DSO.
The third advantage is that this "gentle hacking" method can provide more useful and detailed feedback to Hantek about the issues with their firmware, compared to "your DSO doesn't work" style comments. If you have ever been in support for just about any software or hardware project, you know exactly what I mean. :-BROKE
-
Good luck! You'll need it! The Business Card project doesn't boot from USB so you'll need...black magic!
The usb module is very broken and/or incomplete.
Some hints (Or how Hantek should have done it in first place):
- PE11(input):
If 1 it means the back usb port is connected. Disable power from OTG port and set usb phy in device mode.
If 0 it means the back usb port is disconnected. Enable power on the OTG port and set usb phy in host mode.
Hantek powers it all the time, no matter what. So when both usb are connected, nothing works. Very clever!
- PA0(output): Set to 1 to enable power for the OTG, 0 to disable.
- Also, the usb module seems to need to be set either in device or host manually
# Set Host mode
echo host > /sys/devices/platform/soc/1c13000.usb/musb-hdrc.1.auto/mode
# Set Device mode
echo peripheral > /sys/devices/platform/soc/1c13000.usb/musb-hdrc.1.auto/mode
Phoenix does it in the background. Killing it leaves the usb phy in the last mode.
From pinctrl-sunxi.h, the kernel GPIO name is calculated as: (GPIO group * 32) + pin number.
GPIO groups: PA(0), PB(1), PC(2) ... PF(5).
Ex.:
PA0 = (32*0)+0 = GPIO0
PC5 = (32*2)+5 = GPIO69
PE11 = (32*4)+11 = GPIO139
To set everything from the shell:
# Export GPIO0
echo 0 > /sys/class/gpio/export
# Set GPIO0 as input
echo in > /sys/class/gpio/gpio0/direction
# Set GPIO0 as ouput
echo out > /sys/class/gpio/gpio0/direction
# Set GPIO0 to 1
echo 1 > /sys/class/gpio/gpio0/value
-
- PE11(input):
If 1 it means the back usb port is connected
If 0 it means the back usb port is [disconnected]
So that was the reason the phoenix log showed the GPIO139 (=PE11) being polled, heh!
-
It seems you didn't read the pin assignment list in the page 5? ;D
-
Good luck! You'll need it! The Business Card project doesn't boot from USB so you'll need...black magic!
The usb module is very broken and/or incomplete.
...
DavidAlfa,
Yes, I know George Hilliard's F1C100s project boots from SPI NOR. But then he uses the USB port in OTG mode and the USB OTG Linux kernel driver works 100% fine as both a serial-over-USB port and as emulating a USB mass storage device.
So which USB "module" are you talking about? The long proven sunxi USB driver in the Linux kernel works fine in both USB and normal mode, as evidenced by the fact that right now you can connect the Hantek DSO to a PC using the back USB port in OTG mode, or in USB master mode, connect a USB key to the front USB port to run the updates. Obviously you can't and shouldn't use both ports / both modes simultaneously.
So, what makes you say it is "very broken and/or incomplete"?
-
Just read what I put there. At least in the Hantek fw the usb module can't work on it's own, it needs a daemon to set the correct mode. If you think that's a normal behavior...
What's next? Using switches to enable GPIOs like in a 50s computer? Potentiometers to adjust the LCD backight? :-DD
I organized my GDrive folder. Enhanced some scripts. Added my build/extract scripts for the updates, using a single-step command.
I accidentally discovered something. The update packages don't need the file "upend" or "special". Only "do_update.sh" and "Manifest.xml".
After deleting these files, the updates are much faster! They only take 2-3 seconds.
I guess if they triggered some extra step, like computing checksums or anything cpu-hungry like that.
-
It seems you didn't read the pin assignment list in the page 5? ;D
Of course I did, I just didn't realize PE11 == gpio139. Reason being, I'm not used to pin labels actually matching the hardware numbering!
-
Just read what I put there. At least in the Hantek fw the usb module can't work on it's own, it needs a daemon to set the correct mode. If you think that's a normal behavior...
...
Yes, that is the correct behavior. The Linux kernel is not supposed to decide what a user-space program should do, in this case switching the USB OTG interface from Master to Slave/Gadget mode.
Also, you have not answered my question. Which "USB module" are you saying is "very broken and/or incomplete" and why?
-
I have found another repository with a Buildroot configuration for the F1C100s / F1C200s:
https://github.com/aodzip/buildroot-tiny200
There is a very interesting script in the buildroot-tiny200/flashutils/linux/ directory: fel-linux.sh
It contains the FEL command to boot the Linux kernel and a root filesystem entirely through FEL:
#!/bin/bash
sunxi-fel -p uboot output/images/u-boot-sunxi-with-spl.bin write 0x80000000 output/images/zImage write 0x80700000 output/images/devicetree.dtb write 0x80708000 output/images/rootfs.cpio.uboot
In other words, no need the use a USB key plugged into the front panel USB port.
I think this is the best and simplest option for hacking these Hantek DSO2000 series: build u-boot, the kernel, DTB and root filesystem on a development PC, connect this PC to the DSO using the USB cable, poweron the DSO with the FEL button pressed, and run this script, then open a terminal on the PC and if everything is setup correctly, you should have a root shell.
-
David is actually waiting for the ram linux method! :popcorn:
DavidAlfa, since you are the only one with a serial connection to the DSO UART0, could you please post the serial terminal output of running the following FEL command:
sunxi-fel -p -v uboot u-boot-sunxi-with-spl.bin write 0x80000000 zImage write 0x80700000 businesscard.dtb
where the three files are from the folder I uploaded to your GDrive Writable?
It's possible u-boot will complain about not finding the kernel image, but at this stage I just want to know if the u-boot binary that I compiled loads through sunxi-fel and runs correctly.
So it would be a big step forward if you could test this. Actually that's the first stage to getting this "load Linux from sunxi-fel" method going.
The second stage will be to configure u-boot to find and load the Linux kernel zImage from RAM, which shouldn't be too difficult. That should give us the Linux kernel messages on the serial terminal.
The third stage is to get the Linux kernel to find the root filesystem compressed file in RAM, decompress it and mount it.That means creating a cpio file from the root filesystem which is a bit tricky but doable.
And the final stage is to configure that root filesystem, once mounted, to open a session on the ttyGS0 (USB gadget serial port) making the UART0 soldered connection redundant. That final stage is actually trivial because it just involves a small edit of the /etc/inittab file, as far as I know.
-
sunxi-fel -p -v uboot u-boot-sunxi-with-spl.bin write 0x80000000 zImage write 0x80700000 businesscard.dtb
Stack pointers: sp_irq=0x00002000, sp=0x00005E08
MMU is not enabled by BROM
=> Executing the SPL... done.
Writing image "U-Boot 2019.04 for sunxi board", 224366 bytes @ 0x81700000.
100% [================================================] 1598 kB, 318.6 kB/s
100% [================================================] 8 kB, 305.1 kB/s
Starting U-Boot (0x81700000).
U-Boot SPL 2019.04 (Jun 15 2021 - 13:20:07 +0200)
DRAM: 64 MiB
Trying to boot from FEL
U-Boot 2019.04 (Jun 15 2021 - 13:20:07 +0200) Allwinner Technology
CPU: Allwinner F Series (SUNIV)
Model: George Hilliard's business card
DRAM: 64 MiB
In: serial@1c25000
Out: serial@1c25000
Err: serial@1c25000
Hit any key to stop autoboot: 0
unrecognized JEDEC id bytes: 00, ef, aa
Failed to initialize SPI flash at 0:0 (error -2)
Could not find a valid device for spi-flash
Partition rootubi not found!
Error, no UBI device selected!
Error, no UBI device selected!
=>
-
Check this:
https://github.com/aodzip/buildroot-tiny200
-
Wow, many thanks! That was fast!
As expected, GH's u-boot is configured to load the kernel from SPI NOR flash, which it can't find. That's why it displays an error.
-
Anyways, you can't just boot the kernel, it needs a a filesystem! And you're not uploadign anything else.
You need to setup a ramdisk and then launch the kernel with the proper args.
That buildroot looks great. Apparently USB works.
Uboot also support USB gadgets, like mass storage devices.
-
I created a GitHub repository for this. And the README file references this thread.
https://github.com/AndrewBCN/Hantek_DSO2x1x_Linux
It's pretty much empty right now, but I think I'll just populate it with the Buildroot configuration files for building a Linux distribution for this DSO, and document how to build the distribution and load and run it using sunxi-fel.
Now I have to choose which u-boot, kernel and dts I am going to be using, there are three choices (see README). The root filesystem is going to be similar to what George Hilliard decided, minus the games, and plus a few tools to help reverse engineering phoenix.
Note there is a wiki and anybody is more than welcome to contribute.
-
Sadly, it seems the layout is hardcoded in Phoenix.
Changing this part in utility_menu.xml
<item id="@+id/utility_system_update" text="@string/update" type="menu_button"/>
<item id="@+id/utility_pass_fail" text="@string/pass_fail" type="menu_button"/>
<item id="@+id/utility_system_info" text="@string/sys_info" type="dialog_swi"/>
<item id="@+id/utility_calibrate" text="@string/calibrate" type="menu_button"/>
<item id="@+id/utility_fpst" text="@string/front_panel_self_test" type="button"/>
<item id="@+id/utility_law" text="@string/legal_info" type="dialog_swi"/>
To:
<item id="@+id/utility_system_update" text="@string/update" type="menu_button"/>
<item id="@+id/utility_system_info" text="@string/sys_info" type="dialog_swi"/>
<item id="@+id/utility_pass_fail" text="@string/pass_fail" type="menu_button"/>
<item id="@+id/utility_calibrate" text="@string/calibrate" type="menu_button"/>
<item id="@+id/utility_fpst" text="@string/front_panel_self_test" type="button"/>
<item id="@+id/utility_law" text="@string/legal_info" type="dialog_swi"/>
Yes,it changes the menu labels. But clicking on "sys info" opens "pass/fail", and "pass/fail" opens sys info.
In fact this still works, in only shows "fail" in all menu entries.
<item id="@+id/it" text="@string/fail" type="seems"/>
<item id="@+id/that" text="@string/fail" type="people"/>
<item id="@+id/at" text="@string/fail" type="hantek"/>
<item id="@+id/did" text="@string/fail" type="some"/>
<item id="@+id/crappy" text="@string/fail" type="job"/>
<item id="@+id/here" text="@string/fail" type="lol"/>
Definitely, Phoenix only reads the string entry. Doesn't give a **** at the ID or type.
-
I found the colors to use a lookup table. Yes, they're hardcoded!
I think I found the wave drawing function. It seems to be able to draw 9 waves?
The passing variable to "anolis_wave_plot_set_chn_wave_color" came from a previous function (I called it get_wave_color?) based on a value that I assumed to be the wave index number.
That function uses pointers+offset to return a value. Knowing the start of the table, it was just matter of time patching these values and trying.
However the color processing is weird. White or black are drawn as grey. If R=G=B, the colour will be always be the same shade of grey.
Patching can be done easily. Phoenix offsets change between versions, but searching "wave_plot_helper" will quickly reveal the table position.
# Patch CH1
printf "\x80\xf0\80'" | dd bs=1 count=3 seek=765256 conv=notrunc of=/dso/app/phoenix
# Patch CH2
printf "\x80\xf0\80'" | dd bs=1 count=3 seek=765224 conv=notrunc of=/dso/app/phoenix
# Patch MATH
printf "\x80\xf0\80'" | dd bs=1 count=3 seek=765246 conv=notrunc of=/dso/app/phoenix
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1229627)
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1229629)
-
Hello,
I have just uploaded to DavidAlfa's GDrive a second set of files to test booting Linux through sunxi-fel/USB. I would be grateful if you guys could test them (it takes a few seconds for each test) and post the output on the serial terminal.
1. Test 1: In Writable/AndrewBCN_DSO_Buildroot/sunxi-fel test uboot env, there are two files to test whether sunxi-fel can set environment variables in u-boot. The test is very simple:
- copy the two files to your PC with sunxi-tools installed.
- Boot the DSO or Lichee Pi Nano in FEL mode.
- send the following sunxi-fel command: ./sunxi-fel uboot u-boot-sunxi-with-spl.bin write 0x43100000 my.env
- If all goes well, the DSO / Lichee Pi Nano should print out a "Hello World" message on the serial port (UART1)
The test above is straight from this page: https://linux-sunxi.org/FEL/USBBoot#Example
2. Test 2: In Writable/AndrewBCN_DSO_Buildroot there are three files to test whether u-boot finds the kernel image that we load in RAM using sunxi-fel. Again, the test is quite simple:
- copy the three files (u-boot, dtb, uImage which has kernel and compressed filesystem) to your PC with sunxi-tools installed.
- Boot the DSO or Lichee Pi Nano in FEL mode.
- send the following sunxi-fel command: sunxi-fel -p -v bootm u-boot-sunxi-with-spl.bin write 0x42000000 uImage write 0x42700000 businesscard.dtb
- If all goes well, the DSO / Lichee Pi Nano should load the kernel and print the kernel messages on the serial port (UART1)
Thanks a bunch!
-
Write 0x4xxxxx? RAM in these starts at 0x80000000
Also you're missing RAM not initialized in fel mode.
"unxi-fel -p -v bootm " there's no such bootm command in sunxi-fel.
This will init the ram. You don't really care what or where it writes, because after this you can write anything to the whole ram.
sunxi-fel spl u-boot-sunxi-with-spl.bin
Fixed addresses for the sunxi memory map. You must adjust that offset, the default 0x200000 is wasting the first 32MB of ram!
sunxi-fel write 0x80500000 uImage write 0x80c00000 businesscard.dtb
Boot u-boot:
sunxi-fel uboot u-boot-sunxi-with-spl.bin
Also the env variables are wrong:
bootcmd=setenv bootargs console=ttyS0,115200 bootm 0x42000000 0x43300000 0x43000000This is wrong. It does nothing but this:
bootargs=console=ttyS0,115200 bootm 0x42000000 0x43300000 0x43000000Also, why 3 memory addresses after bootm?
kernel_addr_r=0x80500000I guess this does nothing.
Where's the root? Ramdisk? Initrd? Since you're booting from ram, shouldn't it be something like this?
bootargs root=/dev/ram0 rw console=ttyS0,115200n8 initrd=0x80600000,8M ramdisk_size=8192
Oh, you're discovering the reality vs theory to be much harder? :-DD
Even fixing the address, it doesn't work because it seems the kernel is expecting 0x42000000...?:
sunxi-fel spl u-boot-sunxi-with-spl.bin
sunxi-fel write 0x80500000 uImage write 0x80c00000 businesscard.dtb
sunxi-fel uboot u-boot-sunxi-with-spl.bin
=> setenv bootargs 'console=ttyS0,115200'
=> setenv bootcmd 'bootm 0x80500000'
=> run bootcmd
=> setenv bootargs 'console=ttyS0,115200'
=> setenv bootcmd 'bootm 0x80500000'
=> run bootcmd
## Booting kernel from Legacy Image at 80500000 ...
Image Name: Linux-5.2.4
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6613592 Bytes = 6.3 MiB
Load Address: 42000000
Entry Point: 42000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
undefined instruction
pc : [<80000140>] lr : [<83fb9b8f>]
reloc pc : [<7d747140>] lr : [<81700b8f>]
sp : 83ead4c0 ip : 83fb9e33 fp : 81700020
r10: deadbeef r9 : 83eb0eb0 r8 : 83fb92a0
r7 : 00000000 r6 : 42000000 r5 : 83fe8bf4 r4 : 00000000
r3 : 83fe8bf4 r2 : 80000100 r1 : fffffff0 r0 : 00000000
Flags: Nzcv IRQs off FIQs off Mode SVC_32
Code: 3d656c6f 53797474 31312c30 30303235 (7e2b6200)
Resetting CPU ...
resetting ...
-
Hello everybody. who tried to open up to 200 MHz?
-
Write 0x4xxxxx? RAM in these starts at 0x80000000
Thank you DavidAlfa! :-+
I am recompiling the kernel / uImage so that it starts at address 0x80500000 as you suggested. And will upload it as soon as recompiled.
Done:
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
GZIP arch/arm/boot/compressed/piggy_data
AS arch/arm/boot/compressed/piggy.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-5.2.4
Created: Wed Jun 23 15:09:03 2021
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6613360 Bytes = 6458.36 KiB = 6.31 MiB
Load Address: 80500000
Entry Point: 80500000
Kernel: arch/arm/boot/uImage is ready
The (large) uImage includes the initramfs filesystem CPIO appended to the kernel, it should be automatically decompressed by the kernel.
Did you try the small sunxi-fel test to see if it can set u-boot env variables? Did it work? (it should print "Hello World" and return you to u-boot prompt.
-
I want to connect a serial console via bluetooth. will bluetooth interfere?
-
So I reuploaded uImage to DavidAlfa's GDrive Writable folder.
This uImage is configured with load address 0x80500000 and same entry point. It includes (?) the compressed initramfs image.
So the sunxi-fel commands to load it into memory should be:
sunxi-fel spl u-boot-sunxi-with-spl.bin
sunxi-fel write 0x80500000 uImage write 0x80c00000 businesscard.dtb
sunxi-fel uboot u-boot-sunxi-with-spl.bin
Followed by the u-boot commands:
setenv bootargs 'console=ttyS0,115200'
setenv bootcmd 'bootm 0x80500000'
run bootcmd
This should definitely boot the Linux 5.2.4 kernel, and we'll see if the kernel finds the root filesystem in the initramfs image, and jumps to the init program. :phew:
-
uboot envs are still wrong:
bootcmd=setenv bootargs console=ttyS0,115200 bootm 0x42000000 0x43300000 0x43000000
Anyways, doing:
setenv bootargs 'console=ttyS0,115200'
setenv bootcmd 'bootm 0x80500000'
run bootcmd
## Booting kernel from Legacy Image at 80500000 ...
Image Name: Linux-5.2.4
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6613360 Bytes = 6.3 MiB
Load Address: 80500000
Entry Point: 80500000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
And nothing else comes out!
About the "hello world" test, I didn't try, loading the envs to 0x43100000 won't work.
-
First, many many thanks! :-+ :-+ :-+
uboot envs are still wrong:
bootcmd=setenv bootargs console=ttyS0,115200 bootm 0x42000000 0x43300000 0x43000000
Yes, I didn't recompile u-boot, only the kernel (uImage). My bad!
Anyways, doing:
setenv bootargs 'console=ttyS0,115200'
setenv bootcmd 'bootm 0x80500000'
run bootcmd
## Booting kernel from Legacy Image at 80500000 ...
Image Name: Linux-5.2.4
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6613360 Bytes = 6.3 MiB
Load Address: 80500000
Entry Point: 80500000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
And nothing else comes out!
There seems to be a kernel panic before the UART is initialized. I am going to try the kernel config earlyprintk setting, hopefully that will tell us where things go wrong.
About the "hello world" test, I didn't try, loading the envs to 0x43100000 won't work.
Could you please try:
sunxi-fel uboot u-boot-sunxi-with-spl.bin write 0x080500000 my.env
That should display the "Hello World" message and confirm that we can set u-boot env variables from sunxi-fel. That will make it much easier for later tests.
From the above it seems that something is wrong with the kernel uImage that I compiled. It does get started by u-boot but then (probably) there occurs a segfault, as I wrote probably before the UART is initialized, since nothing is sent on the serial port.
I am compiling a new set of files (u-boot, kernel, root fs image) with the default Lichee Pi Nano configuration, with earlyprintk enabled and will upload them ASAP.
-
Nah, In that report I had already set the earlyprintk in the bootargs...
Why are you writing the envs with a 5MB offset? U-boot usually have them few 100s KB away.
Check CONFIG_ENV_OFFSET and CONFIG_ENV_SIZE:
https://www.digi.com/resources/documentation/digidocs/90001546/reference/u-boot/r_environment_variables.htm (https://www.digi.com/resources/documentation/digidocs/90001546/reference/u-boot/r_environment_variables.htm)
Dropping the envs to a random memory address will do nothing!
-
Finally, the small ESP-01 modules arrived.
I was using the big nodeMCU board as serial bridge!
-
Hello,
I compiled the Widora mangopi-r3 buildroot Linux from their github repository here: https://github.com/aodzip/buildroot-tiny200
This uses a much more recent kernel (5.4.99), u-boot and buildroot and builds almost the same files as George Hilliard's businesscard project.
The sunxi-fel command to load the files and start the kernel is:
sunxi-fel -p uboot output/images/u-boot-sunxi-with-spl.bin write 0x80000000 output/images/zImage write 0x80700000 output/images/devicetree.dtb write 0x80708000 output/images/rootfs.cpio.uboot
The rootfs.cpio.uboot file was created using mkimage (in uboot-tools):
mkimage -A arm -T ramdisk -C gzip -d ./rootfs.cpio.gz rootfs.cpio.uboot
DavidAlfa, could you try these? Btw this u-boot apparently supports NAND flash, so you can possibly read/write the onboard-flash chip.
-
Yeah, but don't mix NAND and SPI-nand. Very different things!
You last u-boot does absolutely nothing. Only uploading the uboot, nothing.
And the're no environment variables inside it...
-
I also screwed it yesterday, well, it doesn't work here to place a photo.
firmware esp-link
https://4pda.to/forum/index.php?showtopic=1018961&st=200#entry107605161
-
...
You last u-boot does absolutely nothing. Only uploading the uboot, nothing.
When you say u-boot does nothing, do you mean you never get any u-boot messages on the serial port? What are the messages that show up on the serial port before u-boot get started (from BROM)?
And the're no environment variables inside it...
In fact if you examine the u-boot-sunxi-with-spl.bin file, you'll find the entire uboot.env file in there, starting at address 0x004951D.
In the u-boot config file, I have this:
...
CONFIG_USE_DEFAULT_ENV_FILE=y
CONFIG_DEFAULT_ENV_FILE="../../../board/allwinner/generic/uboot.env"
...
The uboot.env file is quite long, it's attached (with a txt extension added).
-
When I mean nothing, I mean absolutely nothing, dead. Not a single char out of the serial port.
Yes, I had checked the uboot file. My mistake, I searched BOOT but I had selected case sensitive option from a previous search, so nothing was found :palm:
-
When I mean nothing, I mean absolutely nothing, dead. Not a single char out of the serial port.
...
OK, I found the problem. The uboot-defconfig file for the Widora MangoPi r3 defines CONFIG_CONS_INDEX=2, meaning it selects UART1 as the serial console, and we need UART0.
So I need to recompile u-boot and select UART0 by changing CONFIG_CONS_INDEX=1. :-/O
OK done, and re-uploaded the corrected u-boot-sunxi-with-spl.bin. This one should display messages on UART0 as intended.
DavidAlfa, sorry to ask you again, but can you give it a try when you have some time? Thank you very much as always.
-
Haha do you really withstand the waiting?
I would have opened mine long time ago!
U-Boot SPL 2020.07 (Jun 26 2021 - 08:49:36 +0200)
DRAM: 64 MiB
Trying to boot from FEL
And nothing else comes out. Tried loading only uboot, same results.
sunxi-fel -p uboot u-boot-sunxi-with-spl.bin write 0x80000000 zImage write 0x80700000 devicetree.dtb write 0x80708000 rootfs.cpio.uboot
I looked at that buildroot. Seems they did a great job patching and adding support for the F1C100s!
I'm trying it. I'm using the default allwinner cfg, which seems to be closer to hantek's cfg than the others.
The screen cfg is almost the same, but hantek uses 16bit, this is the correct LCD config:
CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:16,pclk_khz:33333,le:35,ri:201,up:25,lo:10,hs:20,vs:10,sync:3,vmode:0"
-
Hi,
Am I the only one facing issues with getting PhoenixSuit to connect to the DSO in Windows 10?
I believe I have followed the instructions in the help file diligently, i.e. instructions 1,2 and 3. Unfortunately item 4 of the help file is not readable to me so I don't know what it is intended to do.
Zadig installs the driver correctly and returns the display in Item 2 exactly. Windows Device Manager also reports correct driver installation.
However PhoenixSuit still is not able to see the DSO.
Any suggestions?
-
Suggestion: Read. Where did you see that Phoenix was used to connect to the scope?
-
The 2C10 and 2C15 are now the same price on the Hantek "Official" Store. :-DD
-
I'm arguing with the seller. He offered me a partial refund. I'll see... :-DD
-
Haha do you really withstand the waiting?
I would have opened mine long time ago!
U-Boot SPL 2020.07 (Jun 26 2021 - 08:49:36 +0200)
DRAM: 64 MiB
Trying to boot from FEL
And nothing else comes out. Tried loading only uboot, same results.
This is expected: the long .env file which I posted earlier is incorrect and the default command is wrong too. I am going to fix them and also add the correct LCD parameters which you kindly posted below and we'll see if that works.
Do you know what the backlight pwm control pin is for the DSO?
I looked at that buildroot. Seems they did a great job patching and adding support for the F1C100s!
I'm trying it. I'm using the default allwinner cfg, which seems to be closer to hantek's cfg than the others.
The screen cfg is almost the same, but hantek uses 16bit, this is the correct LCD config:
CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:16,pclk_khz:33333,le:35,ri:201,up:25,lo:10,hs:20,vs:10,sync:3,vmode:0"
-
Yes, already said before, PE12.
But needs to be pwm, can't be set low or high, the backlight driver is ac-coupled with a series capacitor.
The default allwinner f1c100s config has the PWM pin correctly configured.
Read boards/allwinner/f1c100s.../uboot defconfig
-
Thank you again, DavidAlfa.
OK, so I recompiled u-boot-sunxi-with-spl.bin and reuploaded it to your G-Drivein Writable/widora. I has the LCD parameters and backlight pin information corrected.
I have edited the uboot-defconfig file and I am attaching it. Also, I have completely changed the uboot.env file. It should load the kernel now. And the kernel should print something on the serial port... hopefully.
The sunxi-fel command must be changed because I have changed the addresses for the kernel, dtb and initramfs images (see uboot.env file):
sunxi-fel -p uboot u-boot-sunxi-with-spl.bin write 0x80500000 zImage write 0x81500000 devicetree.dtb write 0x81800000 rootfs.cpio.uboot
Before this u-boot attempts to start the Linux kernel it should print a message with "DSO2x1x" in it.
Also it should now be possible to display a splash screen loaded through sunxi-fel/USB on the DSO screen from u-boot, but I am leaving that for later.
As usual, DavidAlfa when you have the time, if you can try this... many thanks!
I am thinking about ordering a Lichee Pi Nano but that would take a month or so to arrive. :-\
-
I built uboot, and the usb download gadget works!
So now we can start talking... with proper uboot patches and hw support it's a different story! :-+
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1230925)
-
Well done! :-+
Did you try reading/writing to SPI NAND?
-
Not yet, trying to make dfu work...
The issue is that uboot doesn't support device reenumeration (or at least by default), so if you unplug the usb it won't work again unless you reset it.
So passing the usb device to the Ubuntu VM kills it....
If usb download gadget worked, nothing else would be needed!
-
Suggestion: Read. Where did you see that Phoenix was used to connect to the scope?
I could not see any other help file besides the one provided with the zip. As I said item 4 is not clear to me. I could not read even one character in the screenshot provided. I opted to try out PhoenixSuit because it seemed logical after being requested to installation item 1.
Reading the exchange of messages between you and AndrewBCN it seems obvious that you know this subject in depth. What may be obvious to you when reading that help file may not be obvious to a newbie such as me. Sorry if I wasted your time.
-
I mean, read the forum! :-DD
You don't download files and start doing random things.
Platform-tools usage have been explained a lot of times.
When you download that file there's a readme inside..
Check the FAQ down here, in my signature!
-
Arrrggh PWM in uboot was still broken for suniv! (F1cxxx family) After while I managed to fix it....
However, buildroot uses a patch to fix uboot source, and I don't know how to commit these changes.
Edit: AFter a lot of failures, errors, losing hair... I made a full patch for the new settings.
https://github.com/aodzip/buildroot-tiny200/pull/8/commits/4403b79eba010e330516523b0e2532a4394e3aa9
Not easy, probablybecause I'm not used to such in-depth details and git commands...
But now the PWM is working, because the screen is lit! Althought empty... for now!
-
DavidAlfa,
I noticed you also add two lines to dram.h, but you don't explain why. I would suggest you add a comment for that and resubmit the pull request,
-
Where? I think you read wrong... Those are the already existing patches.
This u-boot no longer uses sf / spi-nand method for accessing the spi nand, instead it's directly attached to mtd, so mtd is used to read it.
SPI flash modules can be disabled in device drivers...
I could boot the flash correctly, added this line in the default bootcmd entry:
setenv bootargs 'earlyprintk console=ttyS0,115200 ubi.mtd=4 ubi.fm_autoconvert=1 root=ubi0:rootfs rw rootfstype=ubifs'; mtd read spi-nand0 0x80500000 0xf00000 0x300000; mtd read spi-nand0 0x80c00000 0xd00000 0x5000; bootm 0x80500000 - 0x80c00000
-
Ah, so perhaps the u-boot I sent you works also for booting the kernel and initramfs from sunxi-fel? Could you try that, please?
-
The best you could do is to a separate test branch in your GitHub and commit all these changes.
Will try later
-
And that's all it does. What are you doing to crew up u-boot so much? :-DD:
U-Boot SPL 2020.07 (Jun 26 2021 - 17:34:12 +0200)
DRAM: 64 MiB
Trying to boot from FEL
Try the attached file. Updates the uboot patch (Adding the said pwm fix) and has separate configs for hantek (make hantek_dso2000_defconfig).
Kernel is untouched for now. But uboot works right away.
You're using a zImage. So uboot bootm command doesn't work (Kernel image not found), instead use bootz.
I still see you are not providing root argument for the kernel? Is that correct??
I ran my own uboot and this bootcmd:
setenv bootargs 'earlyprintk console=ttyS0,115200n8 root=/dev/ram0';\
setenv kernel_addr_r '0x80500000'; setenv fdt_addr_r '0x81500000'; setenv ramdisk_addr_r '0x81800000';\
setenv ram_boot 'echo \"Booting DSO2x1x Linux from FEL...\"; bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}';\
run ram_boot'
But fails. Hmm.... Load address 0? Entry point 0? Looks wrong.
U-Boot SPL 2020.07 (Jun 27 2021 - 17:06:20 +0200)
DRAM: 64 MiB
Trying to boot from FEL
U-Boot 2020.07 (Jun 27 2021 - 17:06:20 +0200) Allwinner Technology
CPU: Allwinner F Series (SUNIV)
Model: Allwinner F1C100s Generic Device
DRAM: 64 MiB
MMC: mmc@1c0f000: 0, mmc@1c10000: 1
Setting up a 800x480 lcd console (overscan 0x0)
In: serial
Out: serial
Err: serial
Allwinner mUSB OTG (Peripheral)
Hit any key to stop autoboot: 0
Booting DSO2x1x Linux from FEL...
## Loading init Ramdisk from Legacy Image at 81800000 ...
Image Name:
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 8910156 Bytes = 8.5 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 81500000
Booting using the fdt blob at 0x81500000
Loading Ramdisk to 80f80000, end 817ff54c ... OK
ERROR: image is not a fdt - must RESET the board to recover.
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
-
DavidAlfa, excuse me, but I still could not figure out how to change the color of the rays. :palm: |O I saw that you did it! For you, apparently it's easy. But not everyone has this knowledge. Could you publish a ready-made patch with the UPK expansion in your GDrive? Sorry for the trouble I'm causing you)
-
No worries! But first I need to find a way to automatically find the offset in the file before patching it, because the app binary changes between updates...
I'll have a look... :-+
-
I programmed a bluepill with Jean Thomas's DirtyJtag firmware:
https://github.com/jeanthom/DirtyJTAG (https://github.com/jeanthom/DirtyJTAG)
After that I compiled openFPGALoader:
https://github.com/trabucayre/openFPGALoader/releases/tag/v0.4.0 (https://github.com/trabucayre/openFPGALoader/releases/tag/v0.4.0)
And urjtag:
https://sourceforge.net/projects/urjtag/files/ (https://sourceforge.net/projects/urjtag/files/)
It seems that jtag I/O uses the same level as Vcore (1.1V). So I had to use a level converter.
I had few TXS108, and as I'm cheating (1.35V for the overclocking), the converter worked (Vmin 1.4V).
However none of them recogniced the device:
openFPGALoader:
./openFPGALoader -c dirtyJtag --detect -v
write to ram
Jtag frequency : requested 6000000Hz -> real 6000000Hz
JTAG init failed with: Unknown device with IDCODE: 0x081b
urjtag:
jtag> cable dirtyjtag
jtag> detect
IR length: 8
Chain length: 1
Device Id: 00000000000000000000100000011011 (0x0000081B)
Unknown manufacturer! (10000001101) (/usr/local/share/urjtag/MANUFACTURERS)
Reading the programming specifications, Gowin ID is 0x81B (Manufacturer ID)
http://cdn.gowinsemi.com.cn/TN653E.pdf (http://cdn.gowinsemi.com.cn/TN653E.pdf)
0x0000081B ID seems to be a GW2A(R)-18.
The Lemontree 2090 might be just a relabeled version, or could be modified for Hantek's needs.
Here's the Gowin FPGA ID table:
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1452235)
-
Hi.
https://youtu.be/CKMDma6xilY
what parameters of ocmanager did you set?
-
Read the instructions. You have to find yourself.
Every chip will overclock different. Default is 648MHz.
From the script:
# DSO2x1x overclocking script by DavidAlfa
# Effective frequency is (BASE_FREQ*(N+1)*(K+1))/(M+1)
# Possible values:
# PLL_N: 1-31
# PLL_K: 0-3
# PLL_M: 0-3
# ------ USER ADJUSTABLE ------
# This example: (24*(17+1)*(2+1))/(1+1) = 648MHz
CPU_OC_PLL_N=17
CPU_OC_PLL_K=2
CPU_OC_PLL_M=1
MEM_OC_PLL_N=12
MEM_OC_PLL_K=0
MEM_OC_PLL_M=0
DEFAULT_DELAY=15
The default CPU K and M settings provide 36MHz steps.
So you CPU speed is (CPU_OC_PLL_N+1)*36
If you set K and M to 0, you'll have 24MHz steps (CPU_OC_PLL_N+1)*24
Memory overclock is usually unstable, you can try changing CPU_MEM_PLL_N, but 15-16 seems to be the limit.
Memory PLL K and M are 0, so the steps are 24MHz.(MEM_OC_PLL_N+1)*24
Remember to first run the test mode package.
-
Thank you.
-
Every chip will overclock different. Default is 648MHz.
Hi David, what do you mean with the default is 648MHz? I read that the default startup frequency of the F1C100s is 408MHz. In the FNIRSI 1013-D they crank it up to 600MHz (24MHz * 25)
I did not try to go above that yet, but it would be interesting to see what is possible. :)
-
The default overclocking frequency
-
The default overclocking frequency
So it is an arbitrary value you choose to set in your script, and not some known save limit of the F1C100s?
I bought a Lichee nano and on their product page they state up to 900MHz :-DD
https://www.seeedstudio.com/Sipeed-Lichee-Nano-Linux-Development-Board-16M-Flash-WiFi-Version-p-2893.html (https://www.seeedstudio.com/Sipeed-Lichee-Nano-Linux-Development-Board-16M-Flash-WiFi-Version-p-2893.html)
-
It's a value that I consider stable. I got 720MHz out of the box, so I think most will get 648MHz easily.
I currenly have it at 792MHz with a slight overvoltage of 60mV (1.16Vcore). Going over that the ram didn't like to overclock, so I prefer more ram speed and less CPU.
Also, to save costs, the Vcore is also used to power the fpga PLL, which is 1.05V max, Hantek is slighly overvolting it.
Some might get 720,other more, who knows. But they must find by themselves.
Overclocking depends on the chip fabrication quality. Dies coming from the center of the wafer are usually the best, maybe some could reach 900MHz, but those made in the sides won't.
That's why they are 408MHZ by default, by they sell them as "up to 900MHz".
I made the scripts, but I don't give any support. Always at your own risk!
-
More news. The i2cbus module works correctly and can be accessed by i2c-tools.
Check my statically compiled busybox binary, which includes it.
Scanninf reveals two devices, one used by the driver (For sure the fpga keyboard inteface)
# ./busybox i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
The on-board eeprom can be dumped easily (address 0x50):
# ./busybox i2cdump 0 0x50
i2cdump: WARNING! This program can confuse your I2C bus
Continue? [y/N] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0...............
10: ff ff ff ff ff ff ff ff ff 01 01 00 00 ff ff ff .........??.....
20: ff ff ff ff ff ff ff ff b2 08 00 00 55 55 00 00 ........??..UU..
30: 99 59 00 00 dd 5d 00 00 ee 6e 00 00 77 77 00 00 ?Y..?]..?n..ww..
40: 77 77 00 00 aa 6a 00 00 aa 6a 00 00 44 84 00 00 ww..?j..?j..D?..
50: 00 80 00 00 92 08 00 00 99 59 00 00 55 55 00 00 .?..??..?Y..UU..
60: 99 59 00 00 aa 6a 00 00 33 73 00 00 ee 6e 00 00 ?Y..?j..3s..?n..
70: aa 6a 00 00 aa 6a 00 00 00 80 00 00 00 80 00 00 ?j..?j...?...?..
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
-
Successfully overclocked, CPU-900 MHz, RAM - 336 MHz, with an overvoltage of 1.2 V, radiators on the CPU, FPGA, ADC and an added fan in the area of the power supply. It works stably for 4 days for 4-5 hours a day.
-
NOTE: This message has been deleted by the forum moderator Halcyon for being against the forum rules and/or at the discretion of the moderator as being in the best interests of the forum community and the nature of the thread.
If you believe this to be in error, please contact the moderator involved.
An optional additional explanation is: Please keep all posts in English. Most people here can't read Russian.
-
Remember that you're overvolting the FPGA too. You can buy a new F1C200s if you break it, but good luck finding the Hantek custom fpga.
Also, the ram overclocks worse with higher Vcore. That's why I stayed at 1.16V, I can run the ram at 408MHz.The system uses 16-bit ram bus, so it's pretty slow.
Moreover, the ram bus is shared with the CPU instruction fetching (Kernel runs from ram) and the LCD panel (800*480*2(16bit)*60Hz=43.9MB/s ).
Even at 408MHz RAM, it's pretty slow: 315MB/s. Stock is 224MB/s!
# time dd if=/dev/zero of=/dev/null bs=1M count=8192
8192+0 records in
8192+0 records out
real 0m 26.22s
user 0m 0.02s
sys 0m 26.18s
-
Do you think Hantek uses Gowin GW2 series FPGA, not GW1?
-
I don't think it's any gowin device you can buy.
https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg3598420/#msg3598420 (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg3598420/#msg3598420)
-
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
-
You're right, I missed that entry when checking the IDs!
It might be a normal version then?
-
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 (https://www.gowinsemi.com/upload/database_doc/342/document/5df0660d4cf09.pdf)
-
Great find Poogo! :)
The FPGA GW2AR18 costs less than €10 on Taobao!
-
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:
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.
-
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!
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:
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1224756)
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1224758)
Monitor patch:
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1224765)
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1224767)
-
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!
-
Update package ready. Check mods/patcher (https://drive.google.com/drive/folders/16-hZj74FZDVptKgl1mYVUX6LLiIRL3b1).
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! :-DD
-
Any chance of updating the first post with all instructions, or a link to the Google drive location, and a full doc in there?
-
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!
-
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.
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1235800)
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?
-
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.
-
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!
-
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.
-
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.
-
So your are doing things backwards? Modifying first? :palm:
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 (https://www.eevblog.com/forum/testgear/upgrading-the-hantek-dso4072c-osciloscope-bandwidth-from-70mhz-to-200mhz/?action=dlattach;attach=848068)
-
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 :)
-
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.
-
Make your do_other_update script and execute it with script launcher.
cp -rf /mnt/udisk/icons/* /dso/app/res/drawable/
No need of chmod-ing anything.
-
Yay, did it! Although I changed the "voltage2.ico" the small voltage arrow was not replaced... gonna investigate a bit more :)
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1235937;image)
Thanks David!
-
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.
-
It did it! I've posted the modified patcher package and the magenta icons into the public folder of your drive.
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1235969;image)
-
Not bad, but you could do it in a single package. Simply copy "icons" into package folder.
Then in the script:
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.
-
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.
-
Just dropped the cyan math icons into my writable "icons" folder.
-
Nice, updated :-+.
-
BTW carlosedp, you also missed the decoder icons! :-DD
It would be great to find a way to quickly preview them without having to manually import each one in Gimp.
I've been digging into the strings and the pointers to them, modifying the addresses so I can put my own strings without overwriting existing program code.
Seems to be working well, that way I can ex. make longer custom printf strings. For example:
-
You mean the small "S" beside the decoder name (that is currently magenta)? I'll look for it and change to Cyan as soon as I can :)
Changing the decoder to show Hex and Ascii chars is awesome! Is it already updated in the patcher pack? Can't wait to try!
-
Is not as easy. The original printf is "%02X", so I can simply patch it with "%c" to show ascii, as there's enough space.
But to show more, there's no space. So I have to find "caves", empty spaces in the binary where to insert my strings.
Then find the pointer and change it. Very tedious and not easy to automate, if that's possible at all.
These programs help a lot. Only cavefinder worked for me.
https://github.com/Antonin-Deniau/cave_miner
https://github.com/jacopodl/CaveFinder
Also it wouldn't be easy (at least for me) to modify the printf calls to add more variables, so I took a linux advantage.
The "$" parameter allows to use any input variable multiple times or in any order.
1$ means "Use the first input parameter". That way I can print the same value in HEX, Char, Decimal... But strings become much longer.
"%1$02X\t%1$c" does "41 A"
"%1$02X\t%1$03u\t%1$c" does "41 065 A"
-
Regarding the terrible english fonts. I disassembled lan_english.ko. It has 3 fonts, and exports 4 font pointers.
- Arial 13. For?
- Arial black 22. For Wavegen label text
- Arial black 20. For Measures and cursor text
- Arial black 20. For Gui, menu, decoders...
- Arial 25. For??
I patched the ldr instructions to load arial 13 instead arial 20 black, worked.
Much cleaner interface, although a bit small. Regular Arial 20 would be perfect.
The proper way would be to patch phoenix where it configures the fonts. Yet to be discovered!
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1236505)
-
That is pretty cool and much better looking. Maybe Arial 13 black would look good too if possible to be replaced.
Also what about having the UART decode hex values in parenthesis.. like: "H (48)" or prefixed as "H (0x48)".
-
Don't take it bad! But I'm not taking personal suggestions when doing my own research. Specially "It would be nice" and "I'd like" ones.
Also, such obvious one. So I spent hours reversing the binaries, trying a lot of things, and don't you think I already tried that? :-DD
The field size is not linked it's contents, so it's always the same. Larger strings simply overlaps over the next field.
-
Hey, sorry. I never meant to ask or suggest anything in any way... just giving out some pointers to improvements that could or not be done by people that know it like you do and would make the scope a better product... things that "should" be done by Hantek themselves.
I'm trying to contribute with the best I know and be part of the community.
Again, sorry...
-
Oh, I said don't take it badly! Maybe I'm not expressing correctly as english is not my native language.
Not angry in any way, I was just saying something lik "really??" ironically.
I mean, why do I lose my time hacking these things if not for trying to replace the fonts and improve things? :-DD
-
Wow, there's been quite a lot of progress since I last came here.
Kudos to DavidAlfa and all the other participating in improving that scope.
Now I have a question : how safe/recommended/advisable is it to update the firmware ?
My 2C15 (so no AWG) is currently running FW 3000.
Same question about the platform tools. Is it safe to use any platform tools version ?
-
...
Now I have a question : how safe/recommended/advisable is it to update the firmware ?
My 2C15 (so no AWG) is currently running FW 3000.
...
I started a thread that answers very specifically this question: https://www.eevblog.com/forum/testgear/hantek-dso2x1x-firmware-updates-and-best-use-practices/ (https://www.eevblog.com/forum/testgear/hantek-dso2x1x-firmware-updates-and-best-use-practices/)
If you don't feel the need to update your firmware I would suggest waiting until Hantek publishes an official update that works well on all hardware versions. If you decide to go ahead I would suggest reading David Alfa's post in that thread, as it condenses all the points spread around various different posts.
-
Some details I forgot and could be useful:
To make modprobe working:
mkdir /lib/modules/5.2.0-licheepi-nano
Kernel debug is unmonted by default, it gives a lot of valueable info:
mount -t debugfs debugfs /sys/kernel/debug
To make it permanent, edit /etc/fstab and add this line:
debugfs /sys/kernel/debug debugfs defaults 0 0
-
Compiling the kernel.
Initial steps
Don't use Ubuntu newer than 18.x or Debian 10.x
arm-gcc cross-compiler works right away from apt-get in these versions. In newers, all you'll get is problems.
Install required dependencies (Linux crashes/breaks so easily that I have this saved in a text file :D)
sudo apt update
sudo apt install -y wget unzip build-essential rsync git bc swig libncurses-dev libacl1-dev libpython3-dev libssl-dev python3-distutils git cmake autoconf u-boot-tools bison flex linux-headers-$(uname -r)
The image names may change depending on the buildroot used. I'm using buildroot-tiny200 (https://github.com/aodzip/buildroot-tiny200)
(Remove [ url] tags, it's a forum error)
git clone --recursive [url]https://github.com/aodzip/buildroot-tiny200[/url]
Download hantek.tar.gz.zip (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1659562) (Rename to .tar.gz):
cd buildroot-tiny200
tar -xvf hantek.tar.gz
Building steps
Also run this command whenever any of the upper files are modified.
(This will overwrite any custom config, ex. in menuconfig)
make dso2c10_defconfig
make menuconfig
make uboot-menuconfig
make linux-menuconfig
make -sj9
Default rootfs files can be found here: (They complement each other)
board/allwinner/generic/rootfs
board/allwinner/suniv-f1c100s/rootfs
board/hantek/dso2c10/rootfs (This is what you should modify to add you custom stuff)
Avoid using "make clean" when possible, as it will re-build everything, taking ages.
So after the initial and slow build, you should only need this:
rm -rf output/target
find output/ -name ".stamp_target_installed" | xargs rm -rf
make -sj9 uboot-rebuild linux-rebuild all
Helper script
I made a very simple script to provide some aiding, so much typing is tiresome!
[ "$1" == "clean" ] && (echo "Cleaning"; make clean >/dev/null)
([ "$1" == "clean" ] || [ "$1" == "init" ] ) && (echo "Reloading config";make sipeed_lichee_nano_defconfig)
rm -rf output/target
find output/ -name ".stamp_target_installed" | xargs rm -rf
make -sj9 uboot-rebuild linux-rebuild all >/dev/null
./build.sh clean -> Cleans everything, reloads the config and builds
./build.sh init -> Reloads the config and builds
./build.sh -> Re-builds
RAM Booting
- Download sunxi-fel (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1465063).
- Copy these files from output/images and place them in sunxi-fel folder:
- devicetree.dtb
- uImage
- rootfs.cpio.uboot
- u-boot-sunxi-with-spl.bin
Boot the system in FEL mode (Check the FAQ (https://www.eevblog.com/forum/testgear/hantek-dso2x1x-firmware-updates-and-best-use-practices/msg3590160/#msg3590160) for more info)
sunxi-fel -p uboot u-boot-sunxi-with-spl.bin write 0x80008000 uImage write 0x80C00000 devicetree.dtb write 0x80D00000 rootfs.cpio.uboot
Moments later, you should see the system booting:
U-Boot SPL 2020.07 (Jul 24 2021 - 21:03:14 +0200)
DRAM: 64 MiB
Trying to boot from FEL
U-Boot 2020.07 (Jul 24 2021 - 21:03:14 +0200) Allwinner Technology
CPU: Allwinner F Series (SUNIV)
Model: Allwinner F1C100s Generic Device
DRAM: 64 MiB
MMC: mmc@1c0f000: 0, mmc@1c10000: 1
Setting up a 800x480 lcd console (overscan 0x0)
In: serial
Out: serial
Err: serial
Allwinner mUSB OTG (Peripheral)
Hit any key to stop autoboot: 0
## Loading init Ramdisk from Legacy Image at 80d00000 ...
Image Name:
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 4514773 Bytes = 4.3 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80c00000
Booting using the fdt blob at 0x80c00000
Loading Ramdisk to 813b1000, end 817ff3d5 ... OK
Loading Device Tree to 813aa000, end 813b098d ... OK
Cannot setup simplefb: node not found
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.4.92 (user@user-VirtualBox) (gcc version 8.4.0 (Buildroot -g9c78493)) #1 Sat Jul 10 09:35:14 CEST 2021
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] OF: fdt: Machine model: Sipeed Lichee Nano
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] cma: Reserved 16 MiB at 0x83000000
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16256
[ 0.000000] Kernel command line: console=ttyS0,115200 earlyprintk rootwait init=/preinit root=/dev/mtdblock2 rootfstype=squashfs overlayfsdev=/dev/mtdblock3 net.ifnames=0 vt.global_cursor_default=0
[ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 34324K/65536K available (6144K kernel code, 248K rwdata, 1676K rodata, 1024K init, 225K bss, 14828K reserved, 16384K cma-reserved)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] random: get_random_bytes called from start_kernel+0x254/0x444 with crng_init=0
[ 0.000050] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[ 0.000138] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[ 0.000866] Console: colour dummy device 80x30
[ 0.000973] Calibrating delay loop... 203.16 BogoMIPS (lpj=1015808)
[ 0.070260] pid_max: default: 32768 minimum: 301
[ 0.070798] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.070841] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.072792] CPU: Testing write buffer coherency: ok
[ 0.074917] Setting up static identity map for 0x80100000 - 0x80100058
[ 0.076236] devtmpfs: initialized
[ 0.087878] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.087943] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[ 0.092204] pinctrl core: initialized pinctrl subsystem
[ 0.094874] NET: Registered protocol family 16
[ 0.098652] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.101131] cpuidle: using governor menu
[ 0.145398] SCSI subsystem initialized
[ 0.145764] usbcore: registered new interface driver usbfs
[ 0.145921] usbcore: registered new interface driver hub
[ 0.146119] usbcore: registered new device driver usb
[ 0.146601] mc: Linux media interface: v0.10
[ 0.146732] videodev: Linux video capture interface: v2.00
[ 0.146847] pps_core: LinuxPPS API ver. 1 registered
[ 0.146865] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.146954] PTP clock support registered
[ 0.148036] ion_parse_dt_heap_common: id 4 type 4 name cma align 1000
[ 0.149068] Advanced Linux Sound Architecture Driver Initialized.
[ 0.151717] clocksource: Switched to clocksource timer
[ 0.183917] thermal_sys: Registered thermal governor 'step_wise'
[ 0.184680] NET: Registered protocol family 2
[ 0.186251] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 0.186328] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.186387] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.186443] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.186768] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 0.186832] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 0.187383] NET: Registered protocol family 1
[ 0.189565] Unpacking initramfs...
[ 1.679161] Freeing initrd memory: 4412K
[ 1.679789] NetWinder Floating Point Emulator V0.97 (double precision)
[ 1.681852] Initialise system trusted keyrings
[ 1.682507] workingset: timestamp_bits=30 max_order=14 bucket_order=0
[ 1.704906] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 1.705536] jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
[ 1.822323] Key type asymmetric registered
[ 1.822363] Asymmetric key parser 'x509' registered
[ 1.822554] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[ 1.822579] io scheduler mq-deadline registered
[ 1.822598] io scheduler kyber registered
[ 1.825305] sun4i-usb-phy 1c13400.phy: Couldn't request ID GPIO
[ 1.837907] suniv-f1c100s-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver
[ 1.863557] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[ 1.869824] suniv-f1c100s-pinctrl 1c20800.pinctrl: 1c20800.pinctrl supply vcc-pe not found, using dummy regulator
[ 1.871225] printk: console [ttyS0] disabled
[ 1.891564] 1c25000.serial: ttyS0 at MMIO 0x1c25000 (irq = 27, base_baud = 6250000) is a 16550A
[ 2.339563] printk: console [ttyS0] enabled
[ 2.349332] suniv-f1c100s-pinctrl 1c20800.pinctrl: 1c20800.pinctrl supply vcc-pd not found, using dummy regulator
[ 2.369983] panel-simple panel: panel supply power not found, using dummy regulator
[ 2.379683] SCSI Media Changer driver v0.25
[ 2.385619] suniv-f1c100s-pinctrl 1c20800.pinctrl: 1c20800.pinctrl supply vcc-pc not found, using dummy regulator
[ 2.398485] spi-nor spi0.0: unrecognized JEDEC id bytes: ff ef aa 21 00 00
[ 2.406077] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 2.412716] ehci-platform: EHCI generic platform driver
[ 2.418346] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 2.424662] ohci-platform: OHCI generic platform driver
[ 2.430389] usbcore: registered new interface driver usb-storage
[ 2.438101] i2c /dev entries driver
[ 2.442385] suniv-f1c100s-pinctrl 1c20800.pinctrl: 1c20800.pinctrl supply vcc-pd not found, using dummy regulator
[ 2.456546] sunxi-wdt 1c20ca0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0)
[ 2.466510] suniv-f1c100s-pinctrl 1c20800.pinctrl: 1c20800.pinctrl supply vcc-pf not found, using dummy regulator
[ 2.504629] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB
[ 2.514070] usbcore: registered new interface driver usbhid
[ 2.519644] usbhid: USB HID core driver
[ 2.523921] sunxi-cedar 1c0e000.video-codec: sunxi cedar version 0.01alpha
[ 2.531127] sunxi-cedar 1c0e000.video-codec: cedar-ve the get irq is 20
[ 2.537848] random: fast init done
[ 2.546507] debugfs: Directory '1c23c00.codec' with parent 'F1C100s Audio Codec' already present!
[ 2.560372] sun4i-codec 1c23c00.codec: Codec <-> 1c23c00.codec mapping ok
[ 2.577004] NET: Registered protocol family 17
[ 2.581565] Key type dns_resolver registered
[ 2.587141] Loading compiled-in X.509 certificates
[ 2.607167] sun4i-drm soc:display-engine: bound 1e00000.display-frontend (ops 0xc073b278)
[ 2.616228] sun4i-drm soc:display-engine: bound 1e60000.display-backend (ops 0xc073aab8)
[ 2.625829] sun4i-drm soc:display-engine: bound 1c0c000.lcd-controller (ops 0xc0739658)
[ 2.634410] sun4i-drm soc:display-engine: bound 1c0a000.tv-encoder (ops 0xc073a378)
[ 2.642187] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 2.648790] [drm] No driver support for vblank timestamp query.
[ 2.656940] [drm] Initialized sun4i-drm 1.0.0 20150629 for soc:display-engine on minor 0
[ 2.665989] [drm] kms: can't enable cloning when we probably wanted to.
[ 2.722238] Console: switching to colour frame buffer device 60x34
[ 2.745448] sun4i-drm soc:display-engine: fb0: sun4i-drmdrmfb frame buffer device
[ 2.754648] usb_phy_generic usb_phy_generic.0.auto: usb_phy_generic.0.auto supply vcc not found, using dummy regulator
[ 2.766637] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[ 2.772615] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1
[ 2.783000] hub 1-0:1.0: USB hub found
[ 2.786923] hub 1-0:1.0: 1 port detected
[ 2.793566] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 2.851892] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 2.858633] ALSA device list:
[ 2.861615] #0: F1C100s Audio Codec
[ 2.865892] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 2.874644] cfg80211: failed to load regulatory.db
[ 2.884546] Freeing unused kernel memory: 1024K
[ 2.889446] Run /init as init process
Starting syslogd: OK
Starting klogd: OK
Running sysctl: OK
Populating /dev using udev: [ 3.398494] udevd[81]: starting version 3.2.9
[ 3.407856] random: udevd: uninitialized urandom read (16 bytes read)
[ 3.416644] random: udevd: uninitialized urandom read (16 bytes read)
[ 3.423696] random: udevd: uninitialized urandom read (16 bytes read)
[ 3.477705] udevd[82]: starting eudev-3.2.9
[ 4.961875] tsc2007 0-0048: i2c io error: -6
[ 4.966174] tsc2007 0-0048: Failed to setup chip: -6
done
Saving random seed: [ 5.617278] random: dd: uninitialized urandom read (512 bytes read)
OK
Starting haveged: haveged: listening socket at 3
OK
Starting network: OK
Starting uMTPrd: [ 7.073858] file system registered
[ 7.308165] read descriptors
[ 7.311118] read strings
OK
Welcome to Hantek DSO2x1x f1c200s
Hantek-dso2x1x-f1c200s login:
Misc
The decompiled DTB from the original system is also attached.
-
Just received a Lichee Pi Nano, probably the smallest and cheapest (€9 shipping included) Linux development board in the world, and which uses the F1C100s SOC (the same as in the Hantek DSO but with 32MB instead of 64MB RAM).
I'll be working on it in the coming weeks, to develop a small Linux distribution for the DSO2X1X series.
-
Hi all,
First of all Thank You for sharing all this precious information.
I just received my DSO2D10. It came with SW 20210416.
I've gone to the Hantek site and the latest SW at their site is exactly the same version that I already have. However, I downloaded it and applied the procedure for hacking the DSO to 150MHz.
Everything looks OK but the hack doesn't work. Looks like even when showing the update progrress and reaching 100% nothing is done because the versions are the same. So no upgrade is done.
Is there any other way to apply the hack? Would the script launcher from @DavidAlfa do it?
Is it enough to run the script "do_other_update(Edit Model-Serial-Hardware)" renaming it and putting the right data inside?
Thanks in advance.
EDIT: I used DavidAlfa script launcher and it looks like it worked. At least the model shown in the sysinfo is 2D15. Serial number and PCB version are correct also.
-
Hi,
Just a quick update on my tests using the Lichee Pi Nano: I have managed to compile and boot u-boot and the Linux kernel using FEL mode on the Lichee Pi Nano and the Nano provides a console through the USB OTG serial (ttyGS0), in other words, the same cable that is used by FEL mode to load u-boot and the kernel in RAM can also be used to communicate with the host machine, there is no need for a separate serial interface. My last remaining hurdle is creating a root filesystem small enough that it will fit in the very limited 32MB RAM of the F1C100S of the Lichee Pi Nano and still leave enough space for the kernel to do its work. That of course should be less of a problem in the DSO2X1X since it uses an F1C200S with 64MB RAM. I can already load the root filesystem from SD card on the Lichee Pi Nano, but that is not an option on the Hantek DSO without some surgery which I have been avoiding until now. :-BROKE
In the coming days I should be able to shrink a minimal root filesystem and when this works on the Lichee Pi Nano DONE!, I'll begin testing on my Hantek DSO2C10. I'll upload the files to DavidAlfa's repository when this is ready and of course I'll update the GitHub repository too.
-
OK, so I am beginning testing my minimal Linux distribution on my Hantek DSO2C10.
These are the steps:
1. Install the sunxi-tools-f1c100s package on your Linux laptop/PC/workstation host. I have not tested this on a Windows host, but similar steps apply.
2. Connect the supplied USB cable from the Hantek DOS2X1X to your Linux laptop/PC/workstation host.
3. Press and hold the FEL button on the bottom of your Hantek DOS2X1X and power it on. All the buttons should light up but the DSO will not boot, because it is actually booted in FEL mode at this stage.
4. On your host machine, execute the following command which will transfer the bootloader (u-boot), the Linux kernel, the device tree and the minimal root filesystem to the DSO:
andrew@andrew-ThinkPad-T420:~/Development/Hantek_DSO_hacking/buildroot-tiny200$ sudo sunxi-fel -p -v uboot ./output/images/u-boot-sunxi-with-spl.bin write 0x80008000 ./output/images/zImage write 0x80700000 ./output/images/devicetree.dtb write 0x80800000 ./output/images/rootfs.cpio.uboot
Stack pointers: sp_irq=0x00002000, sp=0x00005E08
MMU is not enabled by BROM
=> Executing the SPL... done.
Writing image "U-Boot 2020.07 for sunxi board", 398730 bytes @ 0x81700000.
100% [================================================] 3552 kB, 358.7 kB/s
100% [================================================] 15 kB, 348.9 kB/s
100% [================================================] 1310 kB, 359.5 kB/s
Starting U-Boot (0x81700000).
After the files are transferred, Linux boots in two seconds!
5. At this stage a new ACM serial device is detected by your host machine, we can connect to the DSO using any serial communications program (minicom, screen, etc). I am using screen: sudo screen /dev/ttyACM0
Welcome to Sipeed Lichee Nano
lichee-nano login: root
Password:
# dmesg
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.4.92-andrew-04 (andrew@andrew-ThinkPad-T420) (gcc version 9.3.0 (Buildroot -g9c78493-dirty)) #1 Sun Aug 29 01:42:24 CEST 2021
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] OF: fdt: Machine model: Sipeed Lichee Nano
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] cma: Reserved 16 MiB at 0x83000000
[ 0.000000] On node 0 totalpages: 16384
[ 0.000000] Normal zone: 128 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16256
[ 0.000000] Kernel command line: console=ttyS0 earlyprintk net.ifnames=0 vt.global_cursor_default=0
[ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 38512K/65536K available (5120K kernel code, 226K rwdata, 1420K rodata, 1024K init, 215K bss, 10640K reserved, 16384K cma-reserved)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] random: get_random_bytes called from start_kernel+0x258/0x458 with crng_init=0
[ 0.000047] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[ 0.000138] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[ 0.000813] Console: colour dummy device 80x30
[ 0.000915] Calibrating delay loop... 203.16 BogoMIPS (lpj=1015808)
[ 0.070256] pid_max: default: 32768 minimum: 301
[ 0.070776] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.070818] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.072660] CPU: Testing write buffer coherency: ok
[ 0.074655] Setting up static identity map for 0x80100000 - 0x80100058
[ 0.075900] devtmpfs: initialized
[ 0.086291] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.086353] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[ 0.090451] pinctrl core: initialized pinctrl subsystem
[ 0.092982] NET: Registered protocol family 16
[ 0.096178] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.098310] cpuidle: using governor menu
[ 0.138588] SCSI subsystem initialized
[ 0.138955] usbcore: registered new interface driver usbfs
[ 0.139104] usbcore: registered new interface driver hub
[ 0.139250] usbcore: registered new device driver usb
[ 0.139759] pps_core: LinuxPPS API ver. 1 registered
[ 0.139784] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.139845] PTP clock support registered
[ 0.142312] clocksource: Switched to clocksource timer
[ 0.172778] thermal_sys: Registered thermal governor 'step_wise'
[ 0.173510] NET: Registered protocol family 2
[ 0.174927] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 0.175009] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.175066] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.175114] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.175401] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 0.175462] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 0.176022] NET: Registered protocol family 1
[ 0.176817] Unpacking initramfs...
[ 0.523103] Freeing initrd memory: 1280K
[ 0.523395] NetWinder Floating Point Emulator V0.97 (double precision)
[ 0.525131] Initialise system trusted keyrings
[ 0.525799] workingset: timestamp_bits=30 max_order=14 bucket_order=0
[ 0.663186] Key type asymmetric registered
[ 0.663225] Asymmetric key parser 'x509' registered
[ 0.663397] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[ 0.663424] io scheduler mq-deadline registered
[ 0.663441] io scheduler kyber registered
[ 0.666046] sun4i-usb-phy 1c13400.phy: Couldn't request ID GPIO
[ 0.677941] suniv-f1c100s-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver
[ 0.701279] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[ 0.707448] suniv-f1c100s-pinctrl 1c20800.pinctrl: 1c20800.pinctrl supply vcc-pe not found, using dummy regulator
[ 0.708778] printk: console [ttyS0] disabled
[ 0.729097] 1c25000.serial: ttyS0 at MMIO 0x1c25000 (irq = 27, base_baud = 6250000) is a 16550A
[ 5.608822] printk: console [ttyS0] enabled
[ 5.664525] suniv-f1c100s-pinctrl 1c20800.pinctrl: 1c20800.pinctrl supply vcc-pd not found, using dummy regulator
[ 5.798082] panel-simple panel: panel supply power not found, using dummy regulator
[ 5.891737] SCSI Media Changer driver v0.25
[ 5.944574] suniv-f1c100s-pinctrl 1c20800.pinctrl: 1c20800.pinctrl supply vcc-pc not found, using dummy regulator
[ 6.070256] spi-nor spi0.0: unrecognized JEDEC id bytes: ff ef aa 21 00 00
[ 6.153405] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 6.231773] ehci-platform: EHCI generic platform driver
[ 6.294867] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 6.369090] ohci-platform: OHCI generic platform driver
[ 6.432382] usbcore: registered new interface driver usb-storage
[ 6.505683] udc-core: couldn't find an available UDC - added [g_serial] to list of pending drivers
[ 6.613609] i2c /dev entries driver
[ 6.656182] suniv-f1c100s-pinctrl 1c20800.pinctrl: 1c20800.pinctrl supply vcc-pd not found, using dummy regulator
[ 6.783119] sunxi-wdt 1c20ca0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0)
[ 6.879126] suniv-f1c100s-pinctrl 1c20800.pinctrl: 1c20800.pinctrl supply vcc-pf not found, using dummy regulator
[ 7.030208] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB
[ 7.116266] usbcore: registered new interface driver usbhid
[ 7.183183] usbhid: USB HID core driver
[ 7.229929] NET: Registered protocol family 17
[ 7.283398] Key type dns_resolver registered
[ 7.335961] Loading compiled-in X.509 certificates
[ 7.408854] sun4i-drm soc:display-engine: bound 1e00000.display-frontend (ops 0xc063f118)
[ 7.507821] sun4i-drm soc:display-engine: bound 1e60000.display-backend (ops 0xc063e95c)
[ 7.606328] sun4i-drm soc:display-engine: bound 1c0c000.lcd-controller (ops 0xc063d4fc)
[ 7.702941] sun4i-drm soc:display-engine: bound 1c0a000.tv-encoder (ops 0xc063e21c)
[ 7.794886] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 7.874233] [drm] No driver support for vblank timestamp query.
[ 7.947471] [drm] Initialized sun4i-drm 1.0.0 20150629 for soc:display-engine on minor 0
[ 8.045493] [drm] kms: can't enable cloning when we probably wanted to.
[ 8.174791] Console: switching to colour frame buffer device 60x34
[ 8.265939] sun4i-drm soc:display-engine: fb0: sun4i-drmdrmfb frame buffer device
[ 8.357380] usb_phy_generic usb_phy_generic.0.auto: usb_phy_generic.0.auto supply vcc not found, using dummy regulator
[ 8.488277] g_serial gadget: Gadget Serial v2.4
[ 8.542756] g_serial gadget: g_serial ready
[ 8.599424] Freeing unused kernel memory: 1024K
[ 8.654103] Run /init as init process
[ 8.863744] random: fast init done
[ 9.118443] g_serial gadget: high-speed config #2: CDC ACM config
[ 9.191595] gs_console_connect: port num [0] is not support console
[ 9.397083] random: dd: uninitialized urandom read (512 bytes read)
[ 38.882382] vcc3v0: disabling
[ 38.918018] vcc3v3: disabling
[ 38.953638] vcc5v0: disabling
# free
total used free shared buff/cache available
Mem: 57200 4536 49836 2828 2828 48796
Swap: 0 0 0
# uptime
00:10:24 up 10 min, load average: 0.00, 0.01, 0.00
(the password is nano)
I achieved my initial objective: to boot non-destructively a Linux distribution through the USB interface on the back of the DSO, and communicate with it using the same USB interface. :phew:
Of course this does not in any way void the warranty on the DSO. :-BROKE
I'll be uploading UPLOADED the binary files to DavidAlfa's Drive repository (in Writable/AndrewBCN_Linux_binaries) and the source files to the GitHub repository (soon, as I am still cleaning up the code/configuration files). https://github.com/AndrewBCN/Hantek_DSO2x1x_Linux
This minimal Linux distribution is intended as a tool to explore the Hantek DSO2X1X hardware and software, but right now I have just included the minimal BusyBox utilities. I can add MicroPython, strace, ltrace and many other programs, so suggestions are welcome.
-
The main reason of this was to read/write the flash for backup/restore purposes.
But what gives booting a system with just a console? You either want:
- Enable the console in the original system
- Enable flash access in the ram boot system.
I dropped this due few reasons.
My intention was to provide direct access to the host, so it would see it as a storage device, allowing simple access with dd, fdisk and such tools.
After adding spi-nand partitions in the kernel DTS, it recogniced it. But that was the easy part.
The usb storage gadget can't directly access storage devices, you can only bind files to it. So it's a shame.
MTP can't access system devices either.
Also I found that it doesn't allow multiple gadgets at once.
So you can run MTP, mass storage, ECM, ACM... but not two at the same time.
However you can make multiple instances for the same type, ex. 2x serial ports, or 2 mass storage devices.
The linux theory says it's possible, the ***** Allwinner kernel support seems to say the opposite.
The only workaround coming to my mind is using a daemon-based method and MTP.
So you write anything to /tmp, ex. "boot.bin", and after that a "run.sh" file with the commands to be remotely executed by the daemon.
But got more more issues. dd was extremely slow and didn't write correctly.
mtd was much faster, but also gave some problems which I don't remember. Furthermore, it can't write applyong an offset, so you can't write to big partitions in multiple chunks..
A workaround would be to split the nand in 16MB partitions (in DTS config), so you'll have 8 partitions, and no problem to that size in the ram.
You don't really care about the partitions (They will not be mounted), it's just a cheap method to split the nand in more manageable sizes.
But I lost my patience some weeks ago. Maybe I'll give another try some day...
I've also used Z-modem extensively with this system, to transfer small files when compiling or testing patches, much faster than removing the drive/plug into the host, copy the file, plug back...
The serial port works nicely up to 3Mbit. But my ESP8266 serial-wifi bridge loses packets at that speed when you flood it with data.
When stopping the phoenix process, it works nice up to 2Mbits, which is actually pretty fast (10MB takes 1minute), but when it's running, the hantek can't keep up with the incoming data, in that case only 460.800bps works reliably.
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1415104)
The screen is another crap from hell thing!
So good luck! :-DD
-
Also I found that it doesn't allow multiple gadgets at once.
So you can run MTP, mass storage, ECM, ACM... but not two at the same time.
...
Actually, yes you can. I have tested having the serial and mass storage gadgets combination enabled, and it works fine. It's called composite gadget in the Linux kernel, check it out.
And you can easily transfer files to/from the host and read/write them from/to the onboard NAND flash.
-
Libcomposite was deprecated some time ago, usb gadget use configfs now.
Maybe your kernel has better support, maybe I did something wrong.
But if I enabled any gadget, the others would drop a busy error when trying to enable them.
Spent some days trying every example over internet. No way!
Also, Hantek is not including ECM support in their kernel, so it sucks. A new kernel is needed.
-
Libcomposite was deprecated some time ago, usb gadget use configfs now.
...
You are confusing two things. I never mentioned libcomposite and never used it. Composite gadgets are defined inside the kernel and can be configured at kernel module load time (by just passing the configuration parameters to the kernel module) or through configfs (if configfs is enabled in the kernel). I tested configuring the composite serial + mass storage gadget at module load time and that method works fine.
...
The usb storage gadget can't directly access storage devices, you can only bind files to it.
...
:palm:
Of course it can.
-
I received my DSO2C15 today (Aug 2021) from an Australian supplier and I checked the mainboard, which had printed on it "DSO2D15_V1.7 2021.1.14", so its a fairly recent board, and not only is it named a DSO2D15 it also had all components on it including the ones noted in this thread, U18, U35, X1. So I attempted the hack and I am delighted to say that it worked fine, the Wave Gen now lights and is functional and the System Info shows it as a DSO2D15.
See attached picture of the unit with the system info. So many thanks to everyone in this thread for this information, its very much appreciated, if i can buy you a beer or a coffee then please let me know how.
cheers
NicW
-
Libcomposite was deprecated some time ago, usb gadget use configfs now.
...
You are confusing two things. I never mentioned libcomposite and never used it. Composite gadgets are defined inside the kernel and can be configured at kernel module load time (by just passing the configuration parameters to the kernel module) or through configfs (if configfs is enabled in the kernel). I tested configuring the composite serial + mass storage gadget at module load time and that method works fine.
...
The usb storage gadget can't directly access storage devices, you can only bind files to it.
...
:palm:
Of course it can.
Then I'm waiting! :-DD
-
...
Then I'm waiting! :-DD
From the Linux kernel documentation:
https://www.kernel.org/doc/html/latest/usb/mass-storage.html (https://www.kernel.org/doc/html/latest/usb/mass-storage.html)
The mass storage gadget accepts the following mass storage specific module parameters:
file=filename[,filename…]
This parameter lists paths to files or block devices used for backing storage for each logical unit. There may be at most FSG_MAX_LUNS (8) LUNs set. If more files are specified, they will be silently ignored. See also “luns” parameter.
Is there something you still don't understand?
-
Oh I didn't meant that. I'm no longer losing my time with this, so I'm waiting for you do do it! :popcorn:
Yeah I read all that, tried hundreds of examples... no way.
Just good luck!
-
Oh I didn't meant that.
Really? This is what you wrote: "The usb storage gadget can't directly access storage devices, you can only bind files to it." Perhaps you didn't read the documentation? It specifically says that the USB storage gadget can access files and block (storage) devices, and I have tested it and it works exactly as described in the documentation.
I'm no longer losing my time with this, so I'm waiting for you do do it!
Yeah I read all that, tried hundreds of examples... no way.
Just good luck!
It's not a matter of luck, just a matter of knowing what you are doing.
-
The next steps I'll be working on, in my spare time, when I have some:
1. Compiling an as good as possible Linux kernel, with better performance compared to the Hantek one.
2. Testing the LCD screen and writing a few example programs.
3. Loading the FPGA access module from the original firmware, to enable access to the FPGA RAM and the buttons, LEDs, etc.
4. Testing the various FPGA calls using MicroPython.
5. Long-term, start reverse-engineering the phoenix binary.
Eventually, I will ask Hantek to consider open-sourcing the phoenix binary, so that this becomes a (partially) Open Source community project for an Open Source DSO. Personally I see this as a win-win situation, as Hantek would be able to dedicate their firmware engineers to other projects and the community would gain access to the first Open Source DSO.
-
Sure, I tested attaching /dev/mtd0, also mtdblock0, both failed saying invalid device.
I think you're still getting it wrong.
I'm not saying you must do anything, or it's your obligation.
I just said I'm done with it, lost my pacience, and I'll wait to see how your work is going.
-
You woke my curiosity again and tried again...wtf?.
Same files I already had from the last time, changed nothing, and worked at first try :palm:.
This is my msg init.d script:
#!/bin/sh
CONFIGFS="/sys/kernel/config"
GADGET="$CONFIGFS/usb_gadget"
VID="0x1f3a"
PID="0xefe0"
SERIAL="0123456789"
MANUF="Hantek"
PRODUCT="DSO2C10"
case "$1" in
start)
echo "Starting the USB gadget"
if [ -d $GADGET/g1 ]; then
echo "Gadget already running!"
exit 1;
fi
if [ -z "$(mount | grep configfs)" ]; then
echo "Mounting configfs..."
mount -t configfs none $CONFIGFS
fi
mkdir -p $GADGET
mkdir -p $GADGET/g1
if [ ! -d $GADGET/g1 ]; then
echo "Error creating gadget!"
exit 1;
fi
cd $GADGET/g1
mkdir functions/mass_storage.0
mkdir functions/acm.0
echo 1 > functions/mass_storage.0/stall
echo "/dev/mtdblock0" > functions/mass_storage.0/lun.0/file
echo 1 > functions/mass_storage.0/lun.0/removable
echo 0 > functions/mass_storage.0/lun.0/cdrom
mkdir configs/c.1
mkdir configs/c.1/strings/0x409
ln -s functions/mass_storage.0 configs/c.1
ln -s functions/acm.0 configs/c.1
echo $VID > idVendor
echo $PID > idProduct
mkdir -p strings/0x409
echo $SERIAL > strings/0x409/serialnumber
echo $MANUF > strings/0x409/manufacturer
echo $PRODUCT > strings/0x409/product
echo "$(ls /sys/class/udc)" > UDC
echo "OK"
;;
stop)
echo "Stopping the USB gadget"
if [ ! -d $GADGET/g1 ]; then
echo "Gadget not running!"
exit 1;
fi
cd $GADGET/g1
echo "" > UDC
rm -f configs/c.1/mass_storage.0
rm -f configs/c.1/acm.0
rmdir functions/mass_storage.0
rmdir functions/acm.0
rmdir strings/0x409
rmdir configs/c.1/strings/0x409
rmdir configs/c.1
cd $GADGET
rmdir g1
cd /
if [ -d $GADGET/g1 ]; then
echo "Failed to delete gadget!"
exit 1;
fi
echo "OK"
;;
*)
echo "Usage : $0 {start|stop}"
esac
-
...
Same files I already had from the last time, changed nothing, and worked at first try :palm:.
...
Cool. 8) :clap:
Sometimes when more than one person works on the same problem, you get better results.
Btw I got a very nice email from a third hacker who wants to join in the fun, so I would suggest we share the results using the GitHub repository I already created (which I have to update urgently, and I am late in doing so, of course). :P
So please feel free to add any pull requests for your excellent work. And I really hope you don't give up on hacking your Hantek. :-BROKE
-
The storage device is having issues...
- Writing will throw lots of page errors unless I first do "mtd erase" in the console. Why? Shouldn't it manage sector erase by itself?
- After restoring my original image, the kernel will gave a lot of ubi errors, ending in kernel panic.
- Restored the scope with platform-tools, booted correctly. Dumped the flash, but restoring it back screws up the ubi partitions again.
- Wrote a 128MB file with random data, wrote to the nand, restarted the system just to be sure, then I read it again.
The md5sum matches for both files, so the transfer is correct.
Speed is just ~1MB/s reading, 1.3MB/s writing.
Doing dd if=/dev/zero of=/dev/sdb bs=128k achieves the fastest speed, 3.3MB/s.
All transfers are done in 128KB blocks to match the flash sectors.
-
I uploaded the Live Linux to the Writable folder (Hantek DSO2C10 Live Linux.zip (https://drive.google.com/file/d/1fDXPFPizl6Gm33-gCbrXe2PDB0S9_IcN/view?usp=sharing)).
It seems there's an old tradition in the forum of downloading and running things without reading... Be careful!
It has the mass storage and the acm serial port attached to the system console.
-
I made a very expensive FAT32 128MB drive, filled it with data, unplugged to bypass cache, read back... 100% correct.
But restoring the system image keeps failing.
Boot and kernel works, it's only related to Data/Root. I suspect the problem is related to the ECC.
You can't directly write or read the ECC data, everything is done by the hardware.
To check if the data is ok, after reading a block you have to check Status Register 3 ECC bits (ECC-0, ECC-1).
If (0,0) it means everythign was ok. If (0,1) it means there was a recoverable error. And so on.
So my thoughts is that original FW enables ECC, and also the SPI programmer? But not this Linux, thus the ECC is not updated when writing data.
So, althought the data is valid, the ECC isn't, and the UBI driver fails.
There're references to the internal ECC in drivers/mtd/nand/spi/winbond.c and drivers/mtd/nand/spi/core.c
I've been searching a way to enable or disable it, but this was all the documentations I found : Documentation/devicetree/bindings/mtd/spi-nand.txt
SPI NAND flash
Required properties:
- compatible: should be "spi-nand"
- reg: should encode the chip-select line used to access the NAND chip
The current DTS code related to the spi nand:
&spi0 {
status = "okay";
spi-nand@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "spi-nand";
reg = <0>;
spi-max-frequency = <100000000>;
status = "okay";
partition@0 {
label = "spi-nand";
reg = <0x000000 0x8000000>;
};
};
};
BTW a very nice Windows alternative to dd is usb image tool (https://www.alexpage.de/usb-image-tool/), been using it for years, for me it's the best for making disk images.
A truly lifesaver when I worked at fixing computers, the USB drives with utilities/proghrams/stuff failed very often (viruses, bad removals...).
I could plug 8 drives and restore all in a shot, take a 6-7 minutesa break and back to the work with new USBs!
-
Are you copying also ECC or not? Were you able to disable it?
-
Read my edited post. You don't read or write the ECC directly, it's transparently done by the hardware.
You simply enable it, then any writes to the user data will update the ECC.
After reading the data, check the ECC flag bits to find out if the data is valid.
Edit: I edited drivers/mtd/nand/spi/core.c and forced ECC always off.
Wrote the system image, after rebooting uboot dropped hundreds of ECC errors.
So ECC seems to be enabled system-wide.
It's really weird, the dso is able to boot sometimes, even it's outputting a lot of errors, missing serial/model...
If it was the ECC, it wouldn't load anything, every single sector would report bad ECC.
-
Read my edited post. You don't read or write the ECC directly, it's transparently done by the hardware.
You simply enable it, then any writes to the user data will update the ECC.
After reading the data, check the ECC flag bits to find out if the data is valid.
Edit: I edited drivers/mtd/nand/spi/core.c and forced ECC always off.
Wrote the system image, after rebooting uboot dropped hundreds of ECC errors.
So ECC seems to be enabled system-wide.
It's really weird, the dso is able to boot sometimes, even it's outputting a lot of errors, missing serial/model...
If it was the ECC, it wouldn't load anything, every single sector would report bad ECC.
Why don't you force the ECC on when you write your data? If it continue to throw errors than that is a problem/config with the ECC checking HW.
Another question: are you sure you don't have to previously "format" the flash in any special way in order for it to accept the new programming and calculate the new ECC info?
-
Obviously I tried that too. ECC is used by default.
Meh, same *** again, can't lose my time this way with this crappy product, I'm flying away :horse:
-
Hi Poogo,
can you give us some details of the added fan? Standard size mounted on the existing bracket? Powered by what, +8v ? Is there enough power for a 12v/140mA fan?
Thanx
Luigi
-
Hi Poogo,
can you give us some details of the added fan? Standard size mounted on the existing bracket? Powered by what, +8v ? Is there enough power for a 12v/140mA fan?
Thanx
Luigi
One of the advantages of these Hantek DSO2X1X is that they run cool and in total silence. Why would you want to add a fan that they absolutely don't need? That will take the PSU out of specs, add electrical noise to the DSO inputs, add the annoying fan buzz to your workplace, kill your warranty, and gain you strictly nothing. :palm:
Would you also add a fan to your multimeter?
-
Hi Andrew,
fair point, but I'm thinking small room, no A/C, hot summers.. OTOH, I do have a small AC desk fan I could place next to the scope if/when needed.
lm
-
Hi Luigi!
The biggest heating is at the electrolytic capacitors of the power supply and this can be felt from the outside of the housing in the area of the power supply. The fan in the regular place does not help much from this heating, so I used to install the fan under the power supply and power it from +8v. Now I have made my own linear power supply instead of the original one and it has a special voltage for the fan. I agree with AndrewBCN and if I had known this in advance, I would not have changed anything.
-
Cool... spossiba Poogo!
I will leave it alone and use my external fan if the room temp gets more than 26-28DegC, too easy!
ciao,
lm
-
Yesterday I opened it and added a ton of tantalum caps to everything, replaced almost 20 "0 ohm" chokes with real chokes, also modded the PSU, adding additional chokes for the +8/-8V rails, and replaced the electrolytic caps with better low esr ones.
Don't bother, made absolutely zero difference, I get exactly the same noise.
I think the noise comes from coupling of digital nearby digital signals, so it'll be really hard to remove.
Or it's the ADC converter itself, by design...
-
Hello! I have a question for David Alpha. I installed the latest firmware (.... 1108) and after that decided to apply the color theme. The theme was installed, but the firmware rolled back to ... 0714. For the sake of interest, I began to install other versions of updates, but after installing the color theme, the system information of the device always displays ... 0714 firmware. How can I fix this? Thanks)
-
I see you did some improvements which unfortunatelly didn't help.
What noise you try to eliminate in this DSO?
The noise often come from the layout of the board which you could do nothing with...
So my question is that what do you think if we replace the OPAMP and the D/A converter could it help anything or they are only part of the signal generator function?
-
Hey All,
Been watching this as I was torn between the Siglent 1104 that I was going to upgrade and these DSO2000 series which seem pretty nice. I think I'll go with the Siglent due to the 4 channels but some things that I found really cool were the fact that it was built on Linux - I used to hack on the kernel in grad school and the ability to upgrade. I may try to get involved on the Siglent side ...
Enough about my interests - I thought you might be interested to know that it appears that on 12/30/2021 a new firmware was uploaded at Hantek - http://www.hantek.com/download?key=zxgj&sid=3&pid=17182&word= (http://www.hantek.com/download?key=zxgj&sid=3&pid=17182&word=)
-
I have a question about the UART patch.
Is it normal that after applying the patch the same old firmware version is always displayed? Can I ignore this?
e.g.:
Update Firmware --> Displays new firmware in the system information. --> Install Patch --> Displays the old version again.
-
Let me guess: You had the patch applied, updated the firmware, patch was gone, so you applied the patch again and found this problem.
The issue happens because the patch makes an internal backup of the binary to restore it at any time when uninstalling, but also when applying a new patch.
If it finds trhe backup it assumes the system is patched, because that's the only way the backup exists.
I don't use offsets for patching, that would be hard and very time consuming, every update would be different.
Instead, I search for patterns. You can't find the original pattern if the file is already patched, that's why it must restore the backup first, then apply your patch.
As the backup already existed, it overwrote the newer file with the older backup.
Nothing to worry about: Run the patch uninstaller, update the firmware, then apply the patch again.
Do this whenever your system is patched and want to update the firmware.
-
Testing latest firmware update, at 2mv/Div .. Change the channel's DIV adjustment to FINE and you can zoom further, right into 1.02mv/div .. yay bugs (features?)
Heavy aliasing from the ADC, so no additional real resolution to be seen looking beyond the scope's usual 2mv/div limit.
-
@ DavidAlfa:
I have now uninstalled the patch, applied the update, re-patched, and lo and behold, it works! :-+
Thanks David!
-
Hi, I just got my DSO2C10 and checking board confined I received a fully populated 2D15 :) even did the relay check to make sure and it’s there! So I’d like to go ahead with the hack, after 1st backing everything up, but before anything I wanted to ask if this procedure was still up to date? I only read the 1st and last pages of the thread, and last time the main/first post was March2021 I think? I’m pretty sure Hantek just released some updates a few weeks ago, so is this up to date or is there a thread that is more to date, has more info, etc?
Side note I read there’s a cool change theme download as well??? I’m colorblind and one of the biggest “cons” is the 2 waveforms look the exact same to me, is there an “all inclusive hack”? Just curious, also if I were to apply both the hack and color themes in which order? I’m just finding out about the color themes so I’m going to do more reading but mainly wanted to ask if the hack was still up to date and if not is there an updated thread, hoping the hackers are still working on this/the Linux kernel as being able to enhance/change/add options, even aesthetic ones, would be awesome :)
Thx!
EDIT: So I went through and downloaded Alpha’s files, make both my main backups, and am now getting ready to convert my 2C10 to 2D15, I had a question before I do as I wasn’t able to find the answer, I apologize in advance if I missed it, but should I update to latest software update before or after conversion? It was shipped to me as FW 3202, software 20210726, I guess just double checking. Excited to make this conversion, ty for any/all insight/advice!
-
The update and the conversion can be done in any other, doesn't matter.
FAQ is updated, yes.
-
Awesome, Ty Alpha! And ya I saw it has the latest FW and updates, although I noticed that Hanteks file is larger then the one you have listed on repository, is there any specific reason it’s different (not by much but it is) also I should have read over everything before diving into a long winded simple question, but after going through it all I also should have asked about the “2D15 conversion” folder in the Mod/Hack section, is that a different process versus the one listed on the 1st post of this thread? Do they each have the same outcome? If not what is the difference and which should be ran 1st? Also the process listed on 1st post says to have latest firmware update on USB, even if I already have 3202? I just wanted to clarify the difference between everything and in what order would be best if all is needed, main goal is to turn my 2C10 with fully populated and marked 2D15 board into a fully functional DSO2D15.
Thx again bro, looking forward to an OpenSource if Hantek agrees and what you and the others can do with this Oscope 🦾🤓🎛
-
I prolly should have just posted a new comment vs modifying my last reply, but figured I was already writing so much but trying to keep the thread “clean” lol 😅 but I think many would also benefit from the answers to the questions I just edited in, almost like a double check on what’s what and the order to install it in, unless I’m just overthinking it, lol. I’m going to go through thread as well to get some insight on them
-
I guess I’m going to assume the latest FW is still required even if the machine is already updated to latest FW to install additional software that was left out when it was originally installed as a lower version, my main question tho is the difference between Updates (size difference usually means a difference in files right? Unless I’m missing something) and if anyone else tried installing the file listed in Mod/Hack as “2D15 conversion” on DavidAlpha’s repository? Anyone else know the difference between that and the conversion process listed on the 1st post in this thread and if they are related? And if not what is it and why is it there? Any answers to the other above questions would be greatly appreciated, I’m not one to just “wing it” when there seems to be more then one process, unless I’m overthinking this and missing something, lol, sometimes my caution can spark that 😅 hence all the questions on what might seem like a simple process.
I know this may seem a little “over clarifying” but I’ve assumed wrong in the past and just want to make sure, even if I’ve taken the precautions of backing up everything in case something goes wrong, would like to just do 1 run, no mistakes, in the best order possible that releases all features, hoping someone has at least some experience with that “2d15 conversion” file listed in repository.
Thx and best to all!
-
The 2D15 conversion mod does the same thing, it's just more direct, simple, doesn't require editing or copying multiple files and can coexist with any other upk files, while the "do_other_update" method would require to edit the file everytime.
Fw and sw version aren't modified by the conversion.
The mod is never modified by any update.
If FW version is showing 3102 or 3202, you're on the latest already.
Very small number of updates change it.
Don't change between 3102 or 3202.
All this is explained in the FAQ.
-
Ty Alpha, I must have totally missed the FAQ, I apologize, going to read it now. Ty for clarifying, I really do appreciate it 🖖🏼
-
This prolly goes without saying, ALWAYS backup jic, but wow Alpha that couldnt have been easier. After reading FAQ I used the "2d15 conversion" method found in "hack/mods" and it literally took 1 file 15 seconds to get a fully working DSO2D15 unit ...youre a genius, ty :)
-
:-+ That's the idea.
Initial work was made by Mark5, I just made it simpler, removing hassle, risks and danger of corruption from a bad copy, as upk files are encrypted, then checked by the scope software.
-
Bought a DSO1C10 some week ago directly from Hantek via aliexpress, (don't really need anything faster or more advanced) but after playing around with it for a few hours (it was shipped with 20210724) found some minor issues and hoped those would be fixed in a later firmware and decided to update to the latest firmware (20200210) well unfortunately the shape of the software seems worse than it was with the factory supplied one (scope was basically stuck at lowest memory depth and trying to use anything higher caused it to lock up), at that point I decided to open it up to and found that I had a fully populated board, and decided to hack it and reinstall the latest firmware, so now it's a DSO2D15 :)
Not going to use the signal generator anyway (but it's at least fun that all the buttons on the scope works now, but it seems mostly useless on my scope at least perhaps lacking calibration or so the voltage setting etc is almost a volt of peak to peak compared to the setting however, but frequency and waveform seems accurate)
---
Edit: N/m I'm stupid and didn't read past the first post... I've redone the patch now using Davids packages and installed the calibration values as well- the wave generator is pretty decent now.
-
After installing the “2D15 conversion” upk in “Mods/Hacks” auto range rapid fires off the relays to autoset (I have auto range on), which it never did that I noticed with my limited use, also the DVM and voltage readings in general seem to be off, more then usual. Also most of the settings revert, like memory depth, etc. is that an issue or just the way this scope works, always having to set settings between each probe? I know a lot of the problems are the initial software itself and that Hantek has some work to do with this Oscope. I’ve calibrated twice but am I missing something? Did I forget to do anything? I was under the impression that 1 file was enough for a proper conversion, I know this machine still has its bugs, etc but is there anyway to correct these “problems” or maybe fix what Hantek hasn’t yet with any other additional software? Performance wise it’s almost worse and I’m worried that rapid relay clicking will damage something, I don’t know what’s what so my worries may be unfounded. I’m new to oscilloscopes and modifying them so I apologize for being such a newb at this, I’m going to go through entire thread and reread the ReadMes and FAQs jic to see if I can find a similar issue and a fix to them, or worst case scenario revert to stock until either Hantek works out more bugs or you amazing ppl work out fixes of your own :) Any insight or advice would be greatly appreciated.
Edit: Again i apologize for my newbness and the amount of questions/help being sought, any problems I’m having I’m sure are my fault and/or lack of knowledge, I’m new to the field by only weeks but trying to soak in as much as possible by reading/watching/etc and this community is by far the most understanding and helpful towards new learners, I’ve had some bad experiences being a “newb” to this field when asking for help and have not received any of that negative here so when I say I appreciate it I mean it bro, I value that a lot. Just putting that out there since I’m asking for so much help/info.
Thank you 😅
Video of “symptoms”
https://imgur.com/a/aLpk2Gg
-
No idea, I haven’t noticed any significant difference in my scopes behavior after 2D15 conversion… but then again I did not really test it a lot before I converted it.
I also updated to 20220210 and thought the relays was clicking more frequently than before when using auto set etc (did not test with autorange), didn’t take a long time before I got the scope in some locked up state (it froze everytime it was booted), contacted hantek and was sent platform tools; followed the instructions and the scope was back to functional again however this time with software 20210814.
I’ve since noticed that it seems they pulled the 20220210 firmware now and the latest offered is 2021090901, I did not try it though as so far the 20210814 revision seems to work fine for me- and since I don’t really care about the signal generator anyway (the FAQ states there is a bug in the DC offset in this firmware revision) it doesn’t bother me much to update for now.
But regardless perhaps it’s worth testing another software revision and see if it fixes or at least change the behavior your seeing, otherwise I suppose it would be a good thing to reach out to Hantek, they responded fairly quickly (within a day) and while the communication was brief it was effective, just don’t forget to give them your serial number and probably a given but it’s probably not helpful mentioning that you been tinkering around with the software already :)
-
I think you modded it so fast that you didn't have enough time to know your scope :D
Restore your backup (Did you make it before modifying anything, right?) and compare.
The accuracy of display measurements aren't very precise.
The autorange is disabled by default, autoset adjust everything, but only once.
The relay click happens in the 200mv<->500mv transition.
This is what happens when you enable autorange:
- You touch the probe, inducing ac noise from mains, it'll usually switch to the 5-10V/div range (click).
- Then you leave the probe unconnected, now the scope reads 5mV noise and switches to the 10mv/div setting (Another click).
- Any movement causing the signal amplitude to change will trigger the autorange.
Do you get it? It's annoying as hell :-DD
My advice is to leave autorange disabled, it will increase relay wear and make you mad due so much clicking noises.
-
Naiw: As embarrassing as this is to admit I didn’t even consider the software version, which mine shipped with 20210726.00 so I def need to address that, I think after reading doing some reading and seeing what software revision seems to be the most stable/accurate I’ll update mine today. Good to know 20210814 seems to be running good, wondering if 20210909.01 would be even more accurate tho, if/when I try it I’ll update :) Ty for the heads up, can’t believe I didn’t even consider it, I’ve been going full speed on all of this completely skipping steps without even knowing most of the steps ...ya def embarrassing 😅
DavidAlpha: You sir are completely 100% spot on correct ...I do not know how to properly run an Oscilloscope, let alone my specific model. I was just so excited to get going and dig in (repairing class d car amplifiers) and I’m realizing I need to slow tf down, lol. Since making that last post I’ve reverted my machine with my (Full) backup, calibrated, and all seems to be running as shipped, which I’m realizing is a few software levels behind, it was shipped with the latest firmware tho, 3202. Like mentioned above I’m going to try updating software version on my 2C10 after researching what software seems to be the most stable/accurate. Also Since realizing I’m moving way to fast I’ve gone back to basics, treating this like school, taking notes, drawing diagrams, etc as I want to learn this right. I was digging into amps (main reason for converting was for signal generator to diagnose/test amps without having to hook up a car radio setup to run a signal to amp) way to fast as well, I’m realizing this is going to take a lot more time then I want it too, a lot more but I’m good with that, I want to learn it right so I do it right. I really appreciate the explanations and advice bro ...here I am thinking I broke my scope and I don’t even know what I’m doing lol 😅
Thank you fellas, your input has helped a lot and given my a good direction on where to go from here 🤓 if anyone has experience with the last few software versions and what seems to run the most stable/accurate on DSO2C10 that is a fully populated board marked “DSO2D15” with Firmware 3202 please chime in, I do eventually plan on converting my DSO2C10 to DSO2D15 after updating software, so anything in respects to that would help a lot and be much appreciated 🖖🏼
-
All boards are marked as "DSO2D15".
Just the "C" versions might not have the wave generator generator parts.
There're two main different versions regarding the FPGA:
- FW B0xx/B1xx/30xx/31xx
- FW B2xx/32xx
Installing the wrong FW version (Not the scope software, it's the internal fpga firmware) it'll break the calibration, not a big issue, all it needs is reverting to the correct one.
So if your scope came with 32xx, ensure it's always in that version (latest update is 3202).
If it came with 3000/31xx, latest update to 3102.
FW can be updated using "FW changer" or the Hantek update called "auto_update_fpga".
About the software: You're free to test as you want. Check the FAQ, avoid those enforcing FW upgrade.
This week I'm using 2021.01.05, seems stable so far. Later versions seems to have broken zooming and few other parts.
As long as you have the original backup, it's undestructible, there's no way to brick it ;)
You can mod your DSO2C10 to DSO2D15 without any issues. Software and firmware will be unaffected.
The only difference will be the waveform generator being enabled.
-
Ok, awesome! I’ve never changed FW and it’s always been 3202 so good there, and I do have all the parts for the AWG too so def got lucky on my buy. Ya I have all my backups and have used them once already so I’m def in the green, good to know I can always revert it and never brick it :) Another quick Q, when would I use the EEPROM backup? I’ll try finding it on threads. When I reverted models back to 2C10 I just used my backup marked FULL, I think im going to back update to the version you posted as 0726 DVM and Vpp readings never match up, just seems to always be off, and like you said I can always revert again :) After finding a good software in going to run the 2D15 conversion UPK again as I want to be able to use the AWG for a simple signal source, is the shield grounded on the AWG?
Thank you for all the help and advice David, really appreciate it man. I’m trying to learn a few diff hobbies all at once and man some days it feels so overwhelming but with help from good people it makes it so much easier and actually enjoyable, ty :)
-
Please don't report bugs here, use the main thread (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/) for that, this one is for hacking only, let's keep it tidy :-+
-
Will do, I thought it may be the place to report the bug since I hacked the feature to work, I’m going to cut, repost there, and delete above bug. 🖖🏼
So for hacking I’m thinking can we change/hack features right? This may be a new user experience thing but is there a way to hack/run a script to change the Trigger button press from zeroing out to 50%? Maybe I’m lazy or that I see other instruments have a 50% button but having to press 2 buttons to trigger @ 50% while holding probe trying not to slip kinda sucks? Is that a big deal? When would I use trigger Zeroing vs 50% more? Since learning my scope I’ve never had a real reason to zero my trigger but I am constantly reaching to 50%, it’s gotten to the point where it’s easier when probing small precise “don’t slip or you’ll cause a short” situations where I just spin the trigger dial up into whatever range to get the waveform to stop rolling.
I also had a few questions/wondering son theme changes, such as colors, etc. are all changes/hacks like that made with scripts? I’ve never used scripts but from what I can tell the 1 theme hack I see to change 2nd waveform color is done through running a script? Wondering if it’s that easy and I can do it on top of my already hacked and updated Scope, don’t want to break how well it’s working right now lol 😅 I may also be asking the wrong question in the wrong way, my bad if I am but hopefully
You get what I’m trying to say 🤓
Thoughts?
Btw really enjoying using my scope now, AWG is great as well, everything seems to be working great. Ty David :)
-
This is nothing personal against you, just shows my current point of view on this subject.
These modifications are not that easy, patching the binaries require tons of hours of reverse engineering to find out what to change.
Looks easy because someone (me) spent a lot of time in that and made a simple installer for everyone.
But I lost interest long time ago, also the fact that, with very small exceptions, I was doing it all alone, helped a bit. Most people here is just lazy, everything is "give me", "I want", "please do"...
Sorry, hacking is not begging at someone to do all the work for you.
How to patch the trigger? I have no damn idea, but I won't sit for days finding how to do it.
My last try was to make a nice bug report, as everyone was complaining, but nobody cared to make any proper testing. Neither will I.
All I can say is to read the FAQ because that's another thing it took my time, yet it seems lots of people can't read.
I have no problem answering something when it's not been said 2000 times already or in the FAQ.
You can extract any of my upk packages using Dso Builder and see what it does.
To reverse engineering, take /dso/app/phoenix and /dso/lib/libanolis.so.0.0.0 and disassemble them using guidra.
And yes, you'll find it gets that complicated :-DD
-
I second that :clap:
Just take a look in the FNIRSI 1013D thread on what you run into reversing something like this. It took ~10 months to get something running that is similar to the original. Sure it fixed a lot of errors and I learned from it. But still it takes a lot of time and knowledge.
-
I get it man, must be frustrating as fuck, especially with all the time you've put in, which seems countless atp. Seems like you are literally the only tech carrying this device on a "should be paid" level, tbh it seems like you are doing more for this unit then even Hantek is. Sucks to see someone so skilled get so burned out cuz of shitty\lazy ppl, happens to everyone though and shitty\lazy ppl hit the hardest, to the point of "why bother", I do get it. Huge loss for this platform, and even though I'm newb af and prolly somewhat guilty myself sometimes, I appreciate everything you've done David, seriously. I know that amounts to shit really cuz im just some new user whos just getting into the O-Scope\Electronics\DIY scene, but seriously if you didn't put out what you have in the way you have I wouldn't have saved the money I have, and even learned some about my scope and scopes in general, means alot to me actually. I know I've thanked you in the past for specific help but seriously bro, thank you for everything. If I knew what I was doing or could help in anyway I would, never coded before and reverse engineering sounds like some engineering level type of sorcery to me right now, I didn't even know thats what it takes for what seems like a "simple" request to a layman, just wow thats alot of work, maybe in the future as I learn and whatnot, but ya I'm basically a monkey with a stick when it comes to that atm, but I am actively trying to use my stick better\proper lol 😅
And hey look, I'm not trying to gas you up or float your boat or whatever, just being real. I know jackshit when it comes to this so I am truly appreciative af, seems most ppl almost expect\act entitled lately in all communities and that is not me, just needed to put that out there, I can appreciate the straight forward no candy coated reply as well, I try to live life that way. But ya man again thank you, hopefully you don't completely abandon this unit, huge L for all if so, but like I said I get it.
Take care and stay safe dude 🖖
-
No worries! Modifying the trigger would need a lot of work.
I have no idea how the keyboard is read ( I suspect from libanolis), how the status is processes, where's the trigger level or how is it expressed.
As you say, it's kinda a burnout. I spent a crazy lof of time with the same projects during the covid lockdown.
So, at least for a while, I'll be barely flying around these subjects.
-
I made some measurements:
+5V: 1A
+8V: 240mA
-8V: 600mA (After boot, it lowers to 240mA)
TR: 3.3V square signal from mains (50/60Hz)
A 2-series 5000mAh LiPo battery (7.4-8.4V) should do a good job, requiring:
- Battery positive directly connected to +8V
- Negative voltage inverter (For the -8V).
- 5V buck converter.
- Additional 9-12V power supply to recharge the batteries.
- TR signal generation, since someone in the forum reported the scope didn't boot properly without it.
This is my current basket:
- Mains 12V 3A adapter (http://www.aliexpress.com/item/4001227124388.html) (Main power source for battery).
- 8.4V 2A charger (http://www.aliexpress.com/item/32979418361.html) (Charging current/voltage control).
- 2S BMS (http://www.aliexpress.com/item/1005001636432977.html) (Protection and balancing).
- 4X 18650 3000mAh batteries (http://www.aliexpress.com/item/32835679557.html).
- Dual ±5V 3A converter (http://www.aliexpress.com/item/1005002966287139.html) (Will modify the circuit to generate ±8V output instead ±5V).
Other/Pending:
- TRC generation.
- Circuit for battery disconnection when mains power is used.
- Circuit to power the PSU for battery charging, while keeping the scope off.
-
Hello, DavidAlfa.
I just received my DSO2D10 from Banggood last Friday and, as I'm also interested in the battery power hack, I opened it up and sketched the attached power supply simplified schematic.
As you can see, it is based on a +-8V flyback type around a DK124 (https://grupoautcomp.com.br/wp-content/uploads/2016/11/Specification-IC-DK124.pdf)IC. The main regulated output of this stage is +8V, which is then converted to +5V with a buck converter based on the XL1509-5.0E1 (https://datasheet.lcsc.com/lcsc/1809050422_XLSEMI-XL1509-5-0E1_C61063.pdf) IC.
The measured voltages in my case were +7.25 V (+8), -8.24V (-8), and 4.97V (5V)
On the other hand, the +-8V outputs are converted to +-5V via linear regulators in the mainboard (to reduce noise, I imagine) and, apparently, aren't used for anything else, so their value isn't critical, as long as they are high enough to provide the required voltage drop at the linear regulators, and low enough not to overheat them.
So maybe the simplest form of feeding this from a battery would be to use a 2S (7.4V nominal) connected directly to the +8V output (+5V would be generated by the existing buck converter) and use an inverting DC/DC converter (like this one (https://www.aliexpress.com/item/4001122667086.html), for example) to generate approx. -8V, also connected to the -8V output of the AC power supply (D4 and D5 would avoid shorts through the transformer secondary winding). When feeding from AC, these connections should be removed to avoid charging the battery from the scope's power supply (probably overloading it) and/or powering the inverting converter from the output (maybe a diode in series would be enough to prevent this)
What do you think?
I also liked cristy's idea (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg4035421/#msg4035421) of simply feeding the main input capacitor with a 12V to 250V converter because of its simplicity but, as you said, this implies double conversion and more losses. But if I went that way, I wouldn't connect the converter to the capacitor, but directly to the AC input (a bit more losses on the rectifier bridge, but no need to even open the oscilloscope!)
-
As for the TR signal, it's generated with a simple circuit around an optocoupler; probably could be simulated with a 555 oscillator. I don't think it's necessary, but cristy seemed to have problems with this (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg4041589/#msg4041589). Anyhow, I tried shorting the TR signal to ground (no danger in this if you see the schematic) and booting several times with no problems.
I'm attaching a picture of the TR signal recorded with my DSO138mini (which doesn't seem to measure frequency very well in one of the scales...)
EDIT: Added the same signal but recorded by the DSO2D10 (scope scoping its own internals)
-
Hello all, I've come to a dead end trying a "mini hack" (my Linux knowledge is very poor), so I'd like to ask for help from the Linux experts out there :'(
From the naming scheme of the screen capture files (dso_01_01_xx_yy_zz.bmp, where xx, yy and zz change with time) is easy to deduct that it's somehow based on an internal system real-time clock.
With this in mind, and using David's Script launcher (https://drive.google.com/drive/folders/1imofCvzxdDA4FUOlcZTVqnFjfsoJKvhs), I wrote a simple script to read and alter the internal clock settings. After several iterations (some forms of the standard syntax of the date command didn't seem to work) I came to the following simple script, also based on one of David's example scripts:
# Delete existing time folder
rm -rf /mnt/udisk/Time
# Create new time folder
mkdir /mnt/udisk/Time
# System time before
date >/mnt/udisk/Time/date_old.txt
# Set time and date MMDDhhmmYYYY (month-day-hour-minute-year)
date 032918452022
# System time after
date >/mnt/udisk/Time/date_new.txt
#reboot was added to avoid power cycling
# If not included, the scope stops anyway and asks for resetting after "upgrade"
reboot
The output files date_old.txt and date_new.txt show that the script worked OK:
before
Thu Jan 1 00:10:51 UTC 1970(this shows the system starts on 00:00:00 01/01/1970, start point of Linux epoch)
after:
Tue Mar 29 18:45:00 UTC 2022
The problem comes at the end as, if I don't include the reboot, the scope stops there and asks for a system restart anyway, so the setting is lost and reset to 00:00:00 01/01/1970 |O
So the question is: Is there a way to exit the "upgrade" process without rebooting, or calling the reboot process at a point where the clock is not restarted?
You may ask: Why am I interested in this? Well, apart from the sake of it, I think it would be interesting to have the captures properly labeled, maybe not always, but maybe it's handy if you are going to document a testing process with a good number of them. Also, as you can see in the attached images, the file and folder properties (date) created or modified before the date and time setting appear as empty, while those created afterward have this information. This information also helps when searching the captures that, otherwise, would appear always at the end of date-sorted listings
Thank you very much!
P.S: Maybe with the PC "remote control" software is possible to set scope's internal time/date, but I haven't yet installed it
-
You can try this:
# Kill scope processes
pidof phoenix dbus-daemon | xargs kill -9
# Your commands here
date 032918452022
# Restart scope process
/dso/etc/boot.sh &
exit
That should restart the scope software (But not the system), avoiding the post-update lock.
Don't run the reboot command at the end of the script!
As far as I know there's little to do about it. The RTC is not implemented, so the system always starts at epoch time.
-
Thank you, David.
It works a little better, as the scope continues to work after running the script, but the keyboard does not respond (curiously, it beeps when keys are pressed, but does nothing else, neither when knobs are turned).
Maybe another process (or processes) needs to be restarted?
-
Ah, I forgot.
Yes, the software locks the keyboard when updating.
I was never able to overcome this...
Better to use a boot script running in the background that reads the date from the USB.
Will this update later.
-
Edit: Final version?
- Final version
- Created UPK packages, Date daemon (https://drive.google.com/drive/folders/1F2hfntbKf6JStxfPLoUNvkpkkmr2pnR5)
- Store system and date file timestamps
- Force date update only when date file timestamp changed
- Update non-volatile system date every 1 minute to prevent excessive flash wear
- Restores last system date on boot
Date file:
Linux (Remember to run "chmod +x date.sh" to allow execution):
touch date
Windows:
type NUL > date
Or just create a file called "date" in any other way.
-
Perfect!
Tested the "volatile" one. As you can see in the attached picture, the file "date" and the .bmp have the same date, and the name of the .bmp correspond to it (the capture was done seconds after the pen drive was mounted).
Just in case somebody falls in the same mistake as I did, I had to think for a minute about how to include the information in the "date" file, until I realized that it can be empty, as the daemon takes the info just from its attributes... you only have to create it, for example with David's scripts, but notepad is also useful (just open it, save it and the time and date attributes get refreshed).
Thank you very much, David!! I think this can help when documenting tests with several captures, but it's also interesting, for example, for having logs with their correct time and date attributes, so you don't have to remember when they were extracted. Not something you need to run every time you use the scope, but convenient under certain circumstances.
EDIT: the one I tested was the "volatile" one of the first version
-
Yes, just create the file in any way you want, the contents don't matter!
Made some modifications, as I realised you couldn't set an older date if for any reason you wanted so.
Now it also tracks the timestamp of the date file, updating the system date when it changes.
Made UPK packages and update FAQ.
-
I've been using the first volatile version and it is working perfectly but, after installing the remote control program (2022 version at Keysight's web), I thought there might be a way to set time and date with SPCI commands.
After some googling, I found that the command SYSTem:TIME?, which doesn't appear in the SCPI manual for DSO2000 series (http://www.hantek.com/uploadpic/hantek/files/20211231/DSO2000%20Series%C2%A0SCPI%C2%A0Programmers%C2%A0Manual.pdf), worked in my DSO2D10. But the proposed syntax for setting time with this comad, like SYSTem:TIME hh,mm,ss that I found in those searches didn't work. After a more specific Google search, I found the SCPI Remote communication control manual for DSO4000BC (http://www.hantek.com/Product/DSO4000BC/DSO4000BC_SCPI_EN.pdf), where SYSTem:TIME? was explained on page 78, along with the SYSTem:SET:TIME command. So I tried SYSTem:SET:TIME yy;MM;dd;hh;mm,ss; (the latest semicolon is mandatory) and it worked also for my DSO (see attached capture).
Later I saw these commands were included in the list posted by David in this thread (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg3581870/#msg3581870), so if there are more commands in that list that are not documented for DSO2000 series, the DSO4000 manual might be of help.
-
The "little" issue is that you need a computer to fix the time everytime you boot the dso...
-
Totally true... although you also need a computer to create the "date" file, but at least you don't need to launch the IO libraries and connect the rear USB.
Really, the best solution would be to add one of those el-cheapo I2C real-time clocks (https://www.aliexpress.com/item/32874845756.html) connected to the I2C bus (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg3602372/#msg3602372) (maybe the best point to attach it would be to pins 5 and 6 of U9 (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg3581953/#msg3581953), as the MCU and FPGA pins are too small), read it on startup and set the clock accordingly.
I've used those modules in the Arduino environment, but I don't know if the onboard Linux would have the resources to read it, or if a small program would have to be written specifically for that... I have some of those on hand, so I could try and report if somebody else can provide the software part (I don't have the knowledge to do it myself :'().
-
Perfectly possible, the i2c bus can be accesed from the shell.
Edit:
I ordered a DS1307 (http://aliexpress.com/item/32585872245.html) for testing.
Hardware-wise, all it should require is soldering VCC/GND/SDA/SCL.
The module EEPROM might need removal or modding if matching the in-board EEPROM address.
-
Hello!
I already have that module (http://aliexpress.com/item/32585872245.html), and also this one (https://www.aliexpress.com/item/1005003439552727.html) and this one (https://www.aliexpress.com/item/4001134327562.html), these two based on a different chip (DS3231, supposedly more precise), but for this application, I imagine all of them are equally valid.
As you said, the first one also has a 24C32N EEPROM. Pins 1-3 are attached to GND, so EEPROM's address is 0x50, the same as the DSO's EEPROM, so definitively it'll be necessary to remove it or modify the module connecting some of them to Vcc to change the address. The second one listed before also has EEPROM, but A0-A2 are pulled up (0x57) and provides solder bridges in the PCB to change the address easily Anyway, if had to buy specifically for this application, I'd probably go for the third one, with the smallest footprint, without EEPROM, and with a rechargeable battery. DS3231 also provides an internal temperature sensor readable from I2C (maybe we could also monitor MCU temperature for overclocking?).
Yesterday I opened the scope (again...) and took the opportunity to solder the wires for the I2C bus (attached photo). I had already soldered R49 and R52 for the serial port as you can see.
I ran your i2cdetect with the RTC connected and it was properly detected:
# cd ..
# cd mnt/udisk/Binaries
# ./i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
I see the existent Busybox has the hwclock command that maybe we can use to read the RTC after proper configuration. Crude test of the command shows where it's expecting missing configuration data:
# hwclock
hwclock: can't open '/dev/misc/rtc': No such file or directory
# hwclock --help
BusyBox v1.26.2 (2020-06-08 11:06:44 CST) multi-call binary.
Usage: hwclock [-r|--show] [-s|--hctosys] [-w|--systohc] [-t|--systz] [-l|--localtime] [-u|--utc] [-f|--rtc FILE]
Query and set hardware clock (RTC)
-r Show hardware clock time
-s Set system time from hardware clock
-w Set hardware clock from system time
-t Set in-kernel timezone, correct system time
if hardware clock is in local time
-u Assume hardware clock is kept in UTC
-l Assume hardware clock is kept in local time
-f FILE Use specified device (e.g. /dev/rtc2)
# ./busybox hwclock --help
BusyBox v1.33.1 (2021-06-06 18:01:19 CEST) multi-call binary.
Usage: hwclock [-swul] [--systz] [-f DEV]
Show or set hardware clock (RTC)
-s Set system time from RTC
-w Set RTC from system time
--systz Set in-kernel timezone, correct system time
if RTC is kept in local time
-f DEV Use specified device (e.g. /dev/rtc2)
-u Assume RTC is kept in UTC
-l Assume RTC is kept in local time
(if neither is given, read from /etc/adjtime)
(as you can see, "native" hwclock and the one in your statically compiled busybox have different options)
I found this Adafruit's tutorial (https://learn.adafruit.com/adding-a-real-time-clock-to-raspberry-pi?view=all) to install an RTC in the raspberry py where they use hwclock, but I'm afraid it'll not be easy to me to apply it to this case. As I said before, I'm not very skilled with linux... If you can help me with the configuration now that I have the hardware installed, in the meantime your module arrives, I'm willing to do any tests!
-
The command is there, but the kernel module isn't.
Would require a least a custom kernel device tree.
Suddenly I had some Vietnam flashbacks... :-DD
Hopefully there'll be an application capable of doing so over the raw i2c bus, by no way I'll be messing with the kernel, first because there's no source code and everything around Allwinner stinks.
Hantek should release the GPL sources, but of course they won't.
-
I don't know if this is orthodox, but I tried i2cget and got the following:
# ./i2cget -y 0 0x68 0x00
0x00
# ./i2cget -y 0 0x68 0x00
0x05
# ./i2cget -y 0 0x68 0x01
0x06
# ./i2cget -y 0 0x68 0x02
0x01
# ./i2cget -y 0 0x68 0x03
0x01
# ./i2cget -y 0 0x68 0x04
0x11
# ./i2cget -y 0 0x68 0x05
0x04
# ./i2cget -y 0 0x68 0x06
0x22
#
According to the datasheet (https://datasheets.maximintegrated.com/en/ds/DS3231.pdf), address 0x00 is seconds, 0x01 minutes, 0x02 hours, 0x03 day of the week, 0x04 day of the month, 0x05 month and 0x06 year, The former dialog was today, Monday, April 11th at 01:06, so everything seems to correspond...
The RTC had been previously set on time with an Arduino.
Maybe a script to be called at boot could convert these data into the appropriate format to set the internal clock with "date". Not very elegant, but it might work :)
-
I don't know if this is orthodox, but I tried i2cget and got the following:
You have already provided enough information for someone to take the existing i2cget (https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/tree/tools/i2cget.c) and i2cset (https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/tree/tools/i2cset.c) sources to get and set the system clock from such an I2C module. You'll be limited to GPL2+ licensing, though, but I assume it is not a problem here?
(If I had hardware to test, I'd have posted an implementation here; it's such a simple thing. I'd recommend setting the I2C address, and individual register numbers, as compile-time options, overridable at run time, for best results. Compile it statically, so it can be run very early in the boot process. Use clock_settime(CLOCK_REALTIME, &struct_timespec) (https://man7.org/linux/man-pages/man2/clock_settime.2.html) to set the system clock.)
Do remember to set the RTC to UTC, and not local time. Until we get rid of the Daylight Savings Time mess, that will make a huge difference. Oh, assuming the installation does include the Timezone database. If the device is ever connected to internet, you can use the NTP protocol and NTP pool servers (say, countrycode.pool.ntp.org) to obtain a very good approximate time (to within a small fraction of a second).
In Bash/Dash/Busybox sh,
#!/bin/sh
I2CGET="/bin/i2cget -y 0 0x68"
DATE="/bin/date"
Year=$[2000 + $($I2CGET 0x06)]
Month=$[0 + $($I2CGET 0x05)]
Day=$[0 + $($I2CGET 0x04)]
Hour=$[0 + $($I2CGET 0x02)]
Minute=$[0 + $($I2CGET 0x01)]
Second=$[0 + $($I2CGET 0x00)]
$DATE -u --set "$(printf '%02d%02d%02d%02d%04d.%02d' $Month $Day $Hour $Minute $Year $Second)"
although you might need to adjust the paths on the first three lines.
-
Thank you very much, Nominal Animal!
Sorry for taking so much time to answer, but I've been struggling with it... Seems like the syntax in the DSO's linux is a bit different from what you proposed, it must be a simplified and/or non standard one. Here is what its finally working:
#!/bin/sh
I2CGET="/bin/i2cget -y 0 0x68"
DATE="/bin/date"
Decade="0x20"
Year=$($I2CGET 0x06)
Month=$($I2CGET 0x05)
Day=$($I2CGET 0x04)
Hour=$($I2CGET 0x02)
Minute=$($I2CGET 0x01)
Second=$($I2CGET 0x00)
$DATE -u --set "$(printf '%02x%02x%02x%02x%02x%02x.%02x' $Decade $Year $Month $Day $Hour $Minute $Second)"
#
You were proposing MMDDHHmmYYYY.ss for the "date" argument, and according to the help in the command it should work:
# date -?
date: invalid option -- '?'
BusyBox v1.26.2 (2020-06-08 11:06:44 CST) multi-call binary.
Usage: date [OPTIONS] [+FMT] [TIME]
Display time (using +FMT), or set time
[-s,--set] TIME Set time to TIME
-u,--utc Work in UTC (don't convert to local time)
-R,--rfc-2822 Output RFC-2822 compliant date string
-I[SPEC] Output ISO-8601 compliant date string
SPEC='date' (default) for date only,
'hours', 'minutes', or 'seconds' for date and
time to the indicated precision
-r,--reference FILE Display last modification time of FILE
-d,--date TIME Display TIME, not 'now'
-D FMT Use FMT for -d TIME conversion
Recognized TIME formats:
hh:mm[:ss]
[YYYY.]MM.DD-hh:mm[:ss]
YYYY-MM-DD hh:mm[:ss]
[[[[[YY]YY]MM]DD]hh]mm[.ss]
'date TIME' form accepts MMDDhhmm[[YY]YY][.ss] instead
But, although if you issue the command manually it's OK, when doing it from the script it only seems to accept YYYYMMDDhhmm.ss |O
Also, I had to find a workaround for another problem I found when using your script:
# Year=$[2000 + $($I2CGET 0x06)]
/bin/sh: +: not found
#
Apparently, it doesn't like the "+" sign in the definition... I don't know if all these issues are my fault for not understanding well the environment or if they were due to particularities of this specific linux implementation, or a mix of both |O
Finally, I had to use %02x in the format instead of %02d; this is because, although the registers are i2cget like hexadecimal, in fact, according to the datasheet, "The contents of the time and calendar registers are in the binary-coded decimal (BCD) format", so when i2cget returns 0x22 for minutes it doesn't mean the actual minutes are 34, but 22.
After I got a working script, now I had to get it running at boot time. The tutorials I found on internet (update-rc.d scriptname defaults after copying the script in /etc/init.d) didn't work, as update-rc is not a valid command here... Finally, studying David's example (https://www.eevblog.com/forum/testgear/?action=post2;start=325#postmodify) and the existing scripts in /etc/init.d, I could make it work creating a script named "RTC_Script" with the code at the beginning of this post in /usr/bin, and another script in /etc/init.d calling it with the following content:
#!/bin/sh
/usr/bin/RTC_script &
And now finally the scope gets the correct time and date from the RTC module after booting!!
Thanks a lot to all of you for your help!
Now I'll try to do the opposite: setting the RTC module from the USB pen drive in case it lost time, probably with a similar approach as David's in the aforementioned post (disconnecting it from the scope and setting it with an Arduino doesn't seem an easy method...)
-
Try
Year=$(( 2000 + $($I2CGET 0x06) ))
-
I wanted to drop in just to say THANKS for everyone who has worked on this hack. I just received my 2C10 today which I purchased from Amazon. My intent was to at least upgrade to 2C15 if the AWG parts were not installed. But much to my excitement, we have a fully populated board. So the upgrade to 2D15 was accomplished.
The board's data was like the others I have seen:
DSO2D15_V1.7 2021.1.14
Utility screen showed:
Model: 2C10 (now 2D15)
Serial: CN213...
Software: 1.0.1.1.0(20210726.00)
Hardware: 003.002.001.000.000.000.000.000
Firmware: 3202
As per upgrade instructions I did a backup first before doing anything else. After the backup was done, I ran the script to upgrade the unit to 2D15 without upgrading the software (best not to tempt fate).
I am not a power user for O'scopes. As a Ham Radio Operator, my area of concern centers around using Spectrum Analyzer (TinySA) and Vector Network Analyzer (NanoVNA). Both have the ability to act as a signal generator up to 950MHz (TinySA) and 350MHz (NanoVNA), sine wave only. Other than that, the majority of the content in this thread is way above my pay grade.
I doubt that I will be adding any value to the discussion. However, I do have a few questions.
1. Since doing the upgrade, do I need to do another backup?
2. Should I upgrade to a higher level of software from the 2021.7.26? And if so, what would be the recommended version.
3. I read of a "dot test". How is that performed?
Again, thanks, kudos, bravo-zulu.
Brian D
KF6BL
-
Try
Year=$(( 2000 + $($I2CGET 0x06) ))
Thank you, David. Although the script works well with the $Decade trick, I tried your suggestion so I could learn the correct syntax in this case. It doesn't give an error as before, but gives a weird result instead:
# Year=$(( 2000 + $($I2CGET 0x06) ))
#printf $Year
2034
#printf '%04d' $Year
2034
# printf '%04x' $Year
07f2
#Year=$(( 1986 + $($I2CGET 0x06) ))
# printf $Year
2020
printf '%04x' $Year
07e4
Probably it has to do with the mixing of decimal and HEX in the sum. I'm not sure if the workaround of using 1986 instead of 2000 would work after 2029 (the return of i2cget would change from 29 to 30 instead of 2A), so as I don't think the scope is going to survive past 2099, my trick with $Decade will be enough (and, even if it survives, it won't be the case for myself :-DD).
Thank you for the correct syntax, in any case, I hope it'll avoid me stumbling over the same stone again .
-
I got lost. What's exactly the issue there? None?
BTW, Bash also can work with hex by adding "0x" to the number, ex.
Year=0x16
Year=$(( $Year + 2000 ))
echo $Year
> 2022
-
...
And now finally the scope gets the correct time and date from the RTC module after booting!!
...
No issues, David, the script at the beginning of that post is working OK, the comments were just to explain the things I had to change from Nominal Animal's code. I also managed to get it running at boot time, as I explained at the end of that (maybe too long) post, thanks to the example of your daemon.
I don't know if anybody else, apart from you and me, is willing to install an RTC in the scope, but I'll document it and add the info to the writable directory of your disk, so you can add it to the collection if you like. It's not anything you can't live without, but given the low cost of the module, might be attractive for somebody else.
Again, thank you and Nominal Animal for the help.
-
...
And now finally the scope gets the correct time and date from the RTC module after booting!!
...
No issues, David, the script at the beginning of that post is working OK, the comments were just to explain the things I had to change from Nominal Animal's code. I also managed to get it running at boot time, as I explained at the end of that (maybe too long) post, thanks to the example of your daemon.
I don't know if anybody else, apart from you and me, is willing to install an RTC in the scope, but I'll document it and add the info to the writable directory of your disk, so you can add it to the collection if you like. It's not anything you can't live without, but given the low cost of the module, might be attractive for somebody else.
Again, thank you and Nominal Animal for the help.
Hi, I'm interested on install the mod.
-
I've just uploaded the scripts and document for RTC installation to David's disk. They are here (https://drive.google.com/drive/folders/1ucj2Dd50x7-YIvcKkrbVnl9zPgxXtmcO?usp=sharing) now, but I imagine David will move them to the appropriate directory later.
-
Thanks, it's great to not be the only one around this, it's really boring!
Will check the files for nudes before moving them!
And I'll change the credits: "Made by David Alfa from EEVblog" :-DD
-
I've uploaded a new version of the document, as I had forgotten to say that David's statically compiled i2ctools had to be copied in the scope. I have also updated the "do_other_update" script to do it. I'm copying them to /bin, maybe it would have been better to copy them to /usr/bin, the same place as the scripts... David, if you think it should be done like that, please tell me or modify them yourself.
Also, I've tried the following script to set the RTC from the system time and date:
#!/bin/sh
I2CSET="/bin/i2cset -y 0 0x68"
DATE="/bin/date"
echo
echo "Setting RTC time and date from system clock"
$DATE
$I2CSET 0x06 "$(printf '%s%02d' "0x" $($DATE +%y))"
$I2CSET 0x05 "$(printf '%s%02d' "0x" $($DATE +%m))"
$I2CSET 0x04 "$(printf '%s%02d' "0x" $($DATE +%d))"
$I2CSET 0x02 "$(printf '%s%02d' "0x" $($DATE +%H))"
$I2CSET 0x01 "$(printf '%s%02d' "0x" $($DATE +%M))"
$I2CSET 0x00 "$(printf '%s%02d' "0x" $($DATE +%S))"
echo
It seems to work OK, but I'm not still sure about the best way to call it. Probably, including it into David's date daemon (https://drive.google.com/drive/folders/1F2hfntbKf6JStxfPLoUNvkpkkmr2pnR5?usp=sharing) would be the best option, but in this case the daemon would also have to be modified to remove the writing to EEPROM, as having the RTC it's not needed (I still keep David's first "volatile" version).
-
The RTC script is finished, working great. Supports both DS1307 and DS3231.
DS1307 uses the RTC SRAM for timestamp.
DS3231 uses a flash file for timestamp.
# RTC selection
RTC="DS1307"
#RTC="DS3231"
# RTC common
DATE_FILE="/mnt/udisk/date"
I2C_ADDR="68"
RTC_REG="0x00"
RTC_BYTES="7"
# For DS1307
SRAM_REG="0x08"
SRAM_BYTES="7"
# For DS3231
STAMP_FILE="/etc/date_stamp"
I2C_GET="/usr/bin/i2cget -y 0 0x$I2C_ADDR"
I2C_SET="/usr/bin/i2cset -y 0 0x$I2C_ADDR"
I2C_DETECT="/usr/bin/i2cdetect -y 0 0x$I2C_ADDR 0x$I2C_ADDR"
DATE="/bin/date"
BOOT=1
# Read RTC and update date
read_rtc () {
[ "$RTC" == "DS1307" ] && STAMP="$($I2C_GET $SRAM_REG i $SRAM_BYTES)"
[ "$RTC" == "DS3231" ] && STAMP="$($DATE -r "$STAMP_FILE" +"0x%02S 0x%02M 0x%02H 0x%02u 0x%02d 0x%02m 0x%02y")"
$DATE -us "$($I2C_GET $RTC_REG i $RTC_BYTES | awk '{printf "20%02X%02X%02X%02X%02X.%02X", $7, $6, $5, $3, $2, $1}')" >/dev/null
[ $BOOT -eq 0 ] && (echo "Date daemon: RTC updated to $($DATE)" >/dev/kmsg)
[ $BOOT -eq 1 ] && BOOT=0 && (echo "Date daemon: RTC date is $($DATE)" >/dev/kmsg)
}
# Update RTC and STAMP area
write_rtc () {
$I2C_SET $RTC_REG $NEW i
[ "$RTC" == "DS1307" ] && $I2C_SET $SRAM_REG $NEW i
[ "$RTC" == "DS3231" ] && touch -r "$DATE_FILE" "$STAMP_FILE"
read_rtc
}
# Detect RTC
[ -z "$($I2C_DETECT | grep " $I2C_ADDR ")" ] && (echo "Date daemon: RTC not detected!" >/dev/kmsg) && (exit 1)
read_rtc
# Monitor "date" file, update if timestamp changed
while true; do
if [ -f "$DATE_FILE" ]; then
NEW="$($DATE -r "$DATE_FILE" +"0x%02S 0x%02M 0x%02H 0x%02u 0x%02d 0x%02m 0x%02y")"
[ "$NEW" != "$STAMP" ] && write_rtc
fi
sleep 5
done
#!/bin/sh
case "$1" in
start|restart|reload)
pidof date_daemon | xargs kill -9 2>/dev/null
/usr/bin/date_daemon &
;;
stop)
pidof date_daemon | xargs kill -9 2>/dev/null
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
Tested using the DS1307:
[ 5642.284836] Date daemon: RTC date is Thu Apr 28 01:55:42 UTC 2022
(Inserted USB drive)
[ 5677.630590] Date daemon: RTC updated to Thu Apr 28 01:56:20 UTC 2022
Booting:
System Normal start ...
Welcome to phoenix
[ 4.839277] Date daemon: RTC date is Thu Apr 28 02:01:35 UTC 2022
phoenix login:
-
Bit more expensive, but what about a USB RTC that wouldn't require an internal modification besides loading a script to read it, though suspect it's likely a bit too much to expect support from the allwinner's kernel..
https://shop.sb-components.co.uk/products/usb-rtc-for-raspberry-pi-1?
-
You're talking like there was a good support for this SoC, like rPI does.
There's no official linux support for this, all you have is few semi-patched repos.
I spent days just figuring out why PWM didn't work, then discovering the code was a mess mixing a lot of Allwinner socs, the PWM was completely wrong, writing to the I2S peripheral address.
Submitted a patch, loss half of my hair and flew away.
So, messing with the *kernel*? Suicide is a better solution :-DD
Nope, nope, nope, nope....
Also, carrying the usb RTC everywhere? Does that make any sense?
Edit:
The story repeats again.
Wasn't maintained for years, now buildroot it doesn't compile anymore because glibc was modified in 2021 breaking a lot of stuff... I've seen packages from 2014 :palm:
It's impossible to work with this kind of crap.
What I don't understand is why Hantek used this SoC, while the V3s costs just a little more, running at 1.2GHz, 64MB DDR2, FPU, Linux support...
-
Apart from the difficulties to implement it, I find it too expensive for this purpose (35€ vs 2€ approx) and not as convenient as a permanently installed RTC...
If you don't want to mess inside the scope, you can still set the time with Davids's method (https://drive.google.com/drive/folders/1F2hfntbKf6JStxfPLoUNvkpkkmr2pnR5?usp=sharing), just install the daemon and then you just need to plug in a USB drive with a freshly created or touched (open-save-close) "date" file when you need to set the clock. Or you can also use the corresponding SPCI command (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg4097584/#msg4097584) from the remote control program.
Edit: I don't know why that device is so expensive... just a DS3231 RTC (the same as the $2 module) and an MCP2221 USB to i2c bridge, also worth a few $. OTOH, if the RPi has its own i2c bus, why use this bridge, instead of the existing one?
-
I've worked with a few modules from DFRobot. They often have slightly better quality modules than what is usually available from other sources in China. They've got a nice rechargeable RTC, Digikey often stocks DFRobot's Products.
https://www.dfrobot.com/product-1600.html (https://www.dfrobot.com/product-1600.html)
-
...
Now uses the RTC SRAM to store the "date" file timestamp, instead the system flash.
...
Wow, interesting approach, and now everything in just one script
The problem is that DS3231 doesn't have RAM in that area, so it wouldn't be compatible with that chip... Could the unused space in the EEPROM be used for that purpose? I understand that this stamp is written only when the RTC is set with the "date" file trick (something that won't happen often with an RTC in the system), so no worries about writing the EEPROM too frequently. Is this true? Or maybe it's easier to keep it again in system flash?
-
Ouch, a DS3231? Saw DS1307 somewhere and spent quite a while working on the script :-DD
Luckly the date registers are the same, so the important part is the same.
Anyways, as you said, for the very few times it's going to be updated, the flash will do fine, or even better, as UBI filesystem provides wear leveling.
-
Ouch, a DS3231? Saw DS1307 somewhere and spent quite a while working on the script :-DD
Luckly the date registers are the same, so the important part is the same.
Thank you, David. In fact, we were talking about both chips, I'd been experimenting with the DS3231 and you had ordered the DS1307, that I also have in my collection but, as you say and I had written in the document I uploaded to your disk, the first 7 registers are the same so it's easy to make that the script works for both, as with my "rudimentary" versions (although by now I've only tested DS3231).
I'll update that document, so it refers to your script instead of mine.
Also, I want to include in the document a reference to the mods that the modules need when used with a non-rechargeable battery; except for the compact version (which has a rechargeable cell and is designed for RPi at 3.3V), the other two modules I cited here (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg4110793/#msg4110793) can work with 5 V and include a circuit to charge the battery, supposing you install a rechargeable coin cell instead of a "normal" lithium one. See here (https://forum.arduino.cc/t/tiny-rtc-i2c-module-issue/173162/57) and here (https://www.onetransistor.eu/2019/07/zs042-ds3231-battery-charging-circuit.html). Really, in the latter one may be no mod is needed when feeding from 3.3V; the forward drop of the diode would prevent charging a 3V battery unless very discharged, while in the DS1307 module would be advisable at least to short R6 to make full use of the battery.
Apart from that, in the DS1317 the EEPROM removal or modding is mandatory, as its address is the same as the DSO's EEPROM. Yesterday, in order to be able to test it, I modded mine as in the photo, I lifted pin 1 and pulled it up to Vcc with 10k (in the limit of the recommended value, but I had it on hand).
-
Hold on, you're talking about the DS3121, DS1317(I guess it's a typo), while the picture is from a DS1307 :-DD
I gave another try to the kernel...
Updated building steps here (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg3613934/#msg3613934).
After a lot of work, I got something:
» Configure, compile and flash the kernel.
» Patch the existing uboot, because the bootcmd only reads 3MB, while there new kernel is larger. The kernel partition is 10MB so there's plenty of room available.
» Boot using the original flash rootfs.
However, there're still lots of issues:
» Screen needs fixing. I have no idea what configuration Hantek is using, but seems to be a simple framebuffer, not using the graphics engine at all, drawing everything by software.
But it looks like the framebuffer is passed from u-boot, so no special config is needed?
» This kernel is 5.4.92, while original is 5.2.0. Hantek uses several custom kernel modules for scpi, keypad, fpga... which will refuse to load because the kernel version doesn't match.
Additionally, I found a more recent kernel, 5.4.140 (https://github.com/bbenchoff/linux/tree/licheepi-nano-v5.4.140), sadly we're tied to 5.2.0 for the same reasons.
I might try using "modprobe -f" to force loading, will be great if it works instead exploding or something :D
Luckly for us, the original kernel is still available here (https://github.com/Lichee-Pi/linux/tree/nano-5.2-flash), and there're great instructions here (https://linuxtut.com/en/550370b4129c0afdda68/), so I'll keep working on it.
(Remove [ url] tags, it's a forum error)
git clone [url]https://github.com/Lichee-Pi/linux[/url] -b nano-5.2-flash
cd linux
touch .scmversion # Required to prevent build from appending a "+" sign to the kernel LOCALVERSION, or it'll make "licheepi-nano+"
export ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
make licheepi_nano_defconfig
make menuconfig
make -j8
» Current status: System dies after "Booting kernel...""
That 5.2.0 kernel has no DMA support, pretty crappy support overall, things that 5.4.92 fixed.
If at least I manage to boot it, I might try porting the patches from 5.4.92...
It's a shame that nobody with linux knowledge joins the business! :(
-
Ouch, a DS3231? Saw DS1307 somewhere and spent quite a while working on the script :-DD
Luckly the date registers are the same, so the important part is the same.
Sure, using the eeprom is really easy to do, just use different addresses.
This example uses 0x50 (Internal EEPROM), but you could use any other, ex. from the RTC module EEPROM.
.....
Anyways, as you said, for the very few times it's going to be updated, the flash will do fine, or even better, as UBI filesystem provides wear leveling.
Hello again, sorry for reporting so late, but I've been doing some more experiments before doing so...
First of all, tested your EEPROM script, and worked OK. Then tried and tested two or three approaches to use flash instead, starting from the RAM version. The latest one, that seems to work OK is the following:
#!/bin/sh
# Variables
DBG=0
DATE_FILE="/mnt/udisk/date"
STAMP_FILE="/etc/date_stamp"
I2C_ADDR="68"
RTC_REG="0x00"
RTC_BYTES="7"
# SRAM_REG="0x08"
# SRAM_BYTES="6"
I2C_GET="/usr/bin/i2cget -y 0 0x$I2C_ADDR"
I2C_SET="/usr/bin/i2cset -y 0 0x$I2C_ADDR"
I2C_DETECT="/usr/bin/i2cdetect -y 0 0x$I2C_ADDR 0x$I2C_ADDR"
DATE="/bin/date"
# Detect RTC presence
detect_rtc () {
DETECTED="$($I2C_DETECT | grep " $I2C_ADDR ")"
if [ -z "$DETECTED" ]; then
echo "Date daemon: RTC not detected!" >/dev/kmsg
exit 1
else
echo "Date daemon: Found RTC at address 0x$I2C_ADDR" >/dev/kmsg
fi
}
# Read RTC SRAM area used for stamp.
#read_stamp () {
# STAMP="$($I2C_GET $SRAM_REG i $SRAM_BYTES)" #0xss 0xmm 0xhh 0xDD 0xMM 0xYY
# [ $DBG -eq 1 ] && echo "Date daemon: Read RTC stamp: $STAMP" >/dev/kmsg
#}
# Read file used for stamp.
read_stamp () {
STAMP=$(date -r "$STAMP_FILE" +"%s") #epoch
[ $DBG -eq 1 ] && echo "Date daemon: Read date_stamp date: $STAMP" >/dev/kmsg
}
# Write RTC SRAM area used for stamp
#write_stamp () {
# $I2C_SET $SRAM_REG $NEW_STAMP i
# [ $DBG -eq 1 ] && echo "Date daemon: Write RTC stamp: $NEW_STAMP" >/dev/kmsg
#}
# Write file used for stamp
write_stamp () {
touch -d @$NEW_STAMP "$STAMP_FILE"
[ $DBG -eq 1 ] && echo "Date daemon: Updated date_stamp with NEW_STAMP time" >/dev/kmsg
}
# Read RTC and update date; calls read_stamp
read_rtc () {
read_stamp
NOW="$($I2C_GET $RTC_REG i $RTC_BYTES)"
YYYY="$(printf "%04X" $(( 0x2000 + $(echo $NOW | awk '{print $7}') )))"
MM="$(printf "%02X" $(echo $NOW | awk '{print $6}'))"
DD="$(printf "%02X" $(echo $NOW | awk '{print $5}'))"
hh="$(printf "%02X" $(echo $NOW | awk '{print $3}'))"
mm="$(printf "%02X" $(echo $NOW | awk '{print $2}'))"
ss="$(printf "%02X" $(echo $NOW | awk '{print $1}'))"
$DATE -us "$YYYY$MM$DD$hh$mm.$ss" >/dev/null
echo "Date daemon: Date retrieved from RTC: $YYYY-$MM-$DD $hh:$mm:$ss" >/dev/kmsg
}
# Extract date and write to RTC; calls read_rtc which, in turn, calls read_stamp
write_rtc () {
#Extract fields
YY="$(echo $NEW_DATE | awk '{print $1}')"
MM="$(echo $NEW_DATE | awk '{print $2}')"
DD="$(echo $NEW_DATE | awk '{print $3}')"
#DAY="$(echo $NEW_DATE | awk '{print $4}')"
AA="$(echo $NEW_DATE | awk '{print $4}')"
hh="$(echo $NEW_DATE | awk '{print $5}')"
mm="$(echo $NEW_DATE | awk '{print $6}')"
ss="$(echo $NEW_DATE | awk '{print $7}')"
# As AA is obtained with %u (day of week NUMBER), this is no longer needed
#case "$DAY" in
# "Mon")
# AA="1"
# ;;
# "Tue")
# AA="2"
# ;;
# "Wed")
# AA="3"
# ;;
# "Thu")
# AA="4"
# ;;
# "Fri")
# AA="5"
# ;;
# "Sat")
# AA="6"
# ;;
# "Sun")
# AA="7"
# ;;
#esac
#Update RTC
$I2C_SET $RTC_REG 0x$ss 0x$mm 0x$hh 0x$AA 0x$DD 0x$MM 0x$YY i
write_stamp
read_rtc
echo "Date daemon: Updated RTC date: $DAY $YY-$MM-$DD $hh:$mm:$ss" >/dev/kmsg
}
# Script execution start
# Create date_stamp if missing
if [ ! -f "$STAMP_FILE" ]; then
touch "$STAMP_FILE"
fi
detect_rtc
read_rtc
# Monitor "date" file, update if timestamp changed
while true; do
if [ -f "$DATE_FILE" ]; then
# NEW_STAMP="$($DATE -r "$DATE_FILE" +"0x%S 0x%M 0x%H 0x%d 0x%m 0x%y")"
NEW_STAMP=$($DATE -r "$DATE_FILE" +"%s") #epoch
[ $DBG -eq 1 ] && echo "Date daemon: OLD STAMP: $STAMP" >/dev/kmsg
[ $DBG -eq 1 ] && echo "Date daemon: NEW STAMP: $NEW_STAMP" >/dev/kmsg
if [ "$NEW_STAMP" != "$STAMP" ]; then
# NEW_DATE="$($DATE -r "$DATE_FILE" +"%y %m %d %a %H %M %S")"
# Adding 20 secs to the date (time from PC to scope), Day of week with %u
NEW_DATE="$($DATE -d "@$((20 + $NEW_STAMP))" +"%y %m %d %u %H %M %S")"
write_rtc
fi
else
[ $DBG -eq 1 ] && echo "Date daemon: Date file \"$DATE_FILE\" not found" >/dev/kmsg
fi
sleep 5
done
I've left the code for RAM, commented out, before my code for flash, so you can track easily the mods in case you want to revise it before uploading it to your drive. Another simplification I made is using "%u" instead of "%a" when extracting the day of week (I found on the internet that option gives the number of the day directly and happens to work also in or reduced Linux), so the "case" statement is no longer needed. I also included adding 20 seconds to the date of the "date" file before writing to the RTC, to compensate for the time you need to extract the pendrive from the PC (after "touching" it), plug it in the scope, and the time the scope needs to mount the unit and read it.
Apart from other advantages you commented on before, I think it's better to use the flash rather than the EEPROM as, although improbable, maybe in future versions HANTEK wants to use the now unused zone of the EEPROM, with unpredictable results...
The EEPROM and flash versions should work OK with DS3231 and DS1307 (with the appropriate EEPROM mod in case it exists in the RTC module and is mapped in 0x50, thus conflicting with the DSO's EEPROM).
EDIT: I still have to update the instructions document I uploaded to your disk after all these changes...
-
Now, a different problem I've found while experimenting with the RTC daemons: When we unplug the pendrive from the scope we are not unmounting it properly, so when you plug it in a Windows PC it complains about problems with the pendrive and asks for repairing it. Not very important, in principle, but a tad annoying, and there's also a risk of data corruption. I think Hantek should have provided an option in the menus for properly unmounting the pendrive before extracting it, so I've opened a thread for that on the "official forum" (https://www.eediscuss.com/forum.php?mod=viewthread&tid=16033&fromuid=38794) (not very confident they take it into account, but nothing is lost for trying ;D).
BTW, in fact, if you unplug and plug it in the scope with the serial console opened you can see Linux also complains:
#
# [ 2998.818192] usb 1-1: USB disconnect, device number 4
[ 2999.853749] FAT-fs (sda1): unable to read boot sector to mark fs as dirty
0:Got Signal with value umount
0:Got Signal with value umount
# [ 3011.622598] usb 1-1: new high-speed USB device number 5 using musb-hdrc
[ 3011.826582] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 3011.885068] scsi host0: usb-storage 1-1:1.0
[ 3012.964435] scsi 0:0:0:0: Direct-Access Generic USB Flash Disk 7.76 PQ: 0 ANSI: 4
[ 3012.977692] sd 0:0:0:0: [sda] 15974400 512-byte logical blocks: (8.18 GB/7.62 GiB)
[ 3013.094479] sd 0:0:0:0: [sda] Write Protect is off
[ 3013.102202] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 3013.139709] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 3013.199958] scsi 0:0:0:1: Direct-Access Generic USB Flash Disk 7.76 PQ: 0 ANSI: 4
[ 3013.216202] sd 0:0:0:1: [sdb] Attached SCSI removable disk
[ 3013.344367] sd 0:0:0:1: Attached scsi generic sg1 type 0
[ 3013.466786] sda: sda1
[ 3013.535570] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 3014.402269] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
0:Got Signal with value mount
In the meantime, Do you think there could be a "hacker solution" for this? AFAIK, it's not possible to add new options to the menus (e.g., a menu option to launch custom scripts).
From the console, I've tried "umount /mnt/udisk", and it effectively avoids the error message in windows, but the USB icon in the scope's screen remains lit, so I'm not doing everything needed. I've also tried "eject /dev/sda1", which makes the USB icon disappear, but doesn't seem to unmount properly, as Windows still complains. Also tried one after the other, both possible sequences, without success.
Any suggestions?
-
Just hope the system knows it's a removable drive and flush the cache often.
Whenever I write something there, I wait 10-20 seconds before removing or manually run "sync".
It'll still complain but didn't have any issues that way.
The menu is what it is, I'm not having the desire of a delightful experience of spending weeks looking at Guidra disassembly code ::)
-
Please help-me with my DSO2D10 with freezing after booting.
The buttons no longer react, have only beep sound.
I connected to the serial console, and have this messages with error:
SPI-NAND: W25N01GV is found size: 128MB.
*** Warning - bad CRC, using default environment
Welcome to phoenix
phoenix login: anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
I can restore full backup from memory("_FULL.upk" file) on the front USB with command from serial console?
Thanks in advance!
-
This indicates something weird with your data, shouldn't be there.
SPI-NAND: W25N01GV is found size: 128MB.
*** Warning - bad CRC, using default environment
Follow the platform-tools procedure described in the FAQ, then you can restore your backup.
-
I've opened a thread for that on the "official forum" (https://www.eediscuss.com/forum.php?mod=viewthread&tid=16033&fromuid=38794) (not very confident they take it into account, but nothing is lost for trying ;D).
Huh, you could also ask them for the kernel sources, otherwise they're violating the GPL.
-
....
I connected to the serial console, and have this messages with error:
...
I'm also having those messages from the first time I attached the serial port, but as everything seems to go well I didn't pay them much attention. I also made a backup before installing the serial console, I'm not sure if, in my case, restoring the backup would remove them, as maybe they were there from the very beginning (just I didn't have the console to see them). Here is what I get with a bit more context:
U-Boot SPL 2018.01 (May 25 2021 - 08:44:03)
DRAM: 64 MiB
Trying to boot from sunxi SPI
U-Boot 2018.01 (May 25 2021 - 08:44:03 +0800) Allwinner Technology
CPU: Allwinner F Series (SUNIV)
Model: Lichee Pi Nano
DRAM: 64 MiB
show_dram_config:82ea5bc0, 82ea7ee8, 0, 82fc8000
SPI-NAND: W25N01GV is found size: 128MB.
*** Warning - bad CRC, using default environment
cfg_video_init:in:e59ff014
Setting up a 800x480 lcd console (overscan 0x0)
SPI-NAND: W25N01GV is found size: 128MB.
sunxi_lcdc_backlight_enable_user pwm 80
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
SPI-NAND: W25N01GV is found size: 128MB.
SPI-NAND: 3145728 bytes @ 0xf00000 Read: OK
SPI-NAND: 20480 bytes @ 0xd00000 Read: OK
## Booting kernel from Legacy Image at 80500000 ...
Image Name: Linux-5.2.0-licheepi-nano
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3071416 Bytes = 2.9 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80c00000
Booting using the fdt blob at 0x80c00000
Loading Kernel Image ... OK
Loading Device Tree to 816fa000, end 816ffee3 ... OK
add fb mem rsv ok, 83f44000, bc000
Starting kernel ...
Welcome to phoenix
phoenix login:
[ 3.966128] Date daemon: Found RTC at address 0x68
[ 4.586737] Date daemon: Date retrieved from RTC: 2022-04-25 10:03:26
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
anolis_picture_width:21 picture!=NULL failed.
util_thread_start_with_sched_priority:thread 0xa15a18 is running
[ 7.344970] spi_fpga_tn652: loading out-of-tree module taints kernel.
[ 8.719567] input: afg3050_kbd as /devices/platform/soc/1c27000.i2c/i2c-0/0-0037/input/input0 CNxxxxxxxxxx
[ 9.030971] Mass Storage Function, version: 2009/09/11
[ 9.036275] LUN: removable file: (no medium)
[ 9.093118] dual speed tmc: IN/ep1in, OUT/ep1out, INTep2in/
[ 9.099344] phy phy-1c13400.phy.0: Changing dr_mode to 1
I'll take the opportunity to comment on another thing: When I switch on the scope with the serial to USB converter plugged into the scope but not to the USB port it stays frozen at the boot screen (the one with the QR). Of course, the first time it happened I thought I had bricked it, but later I realized that this happened because it stops at the bootloader menu, the one that you should get at the beginning when it shows "Hit any key to stop autoboot: 0", BTW, something I had tried before without success, seems like you have to be pressing keys continuously from the very beginning to get it. These are the commands it would accept in that menu, and the help for one of them (spi_nand) that might be interesting to explore:
=>
=>
=>
=> help
? - alias for 'help'
bootm - boot application image from memory
clrlogo - fill the boot logo area with black
env - environment handling commands
exit - exit script
false - do nothing, unsuccessfully
fdt - flattened device tree utility commands
gpio - query and control gpio pins
help - print command description/usage
printenv- print environment variables
reset - Perform RESET of the CPU
setenv - set environment variables
showvar - print local hushshell variables
spi_nand- SPI NAND flash sub-system
test - minimal test like /bin/sh
true - do nothing, successfully
version - print monitor, compiler and linker version
=>
=> spi_nand
spi_nand - SPI NAND flash sub-system
Usage:
spi_nand probe [[bus:]cs] [hz] [mode] - init flash device on given SPI bus
and chip select
spi_nand read addr offset len - read `len' bytes starting at
`offset' to memory at `addr', skipping bad blocks.
spi_nand write addr offset len - write `len' bytes from memory
at `addr' to flash at `offset', skipping bad blocks.
spi_nand erase[.spread] offset [+]len - erase `len' bytes from `offset'
`+len' round up `len' to block size
With '.spread', erase enough for given file size, otherwise,
'size' includes skipped bad blocks.
spi_nand update addr offset len - erase and write `len' bytes from memory
at `addr' to flash at `offset'
spi_nand bad - show bad blocks
spi_nand markbad offset - mark block include `offset' as bad block
=>
=> version
U-Boot 2018.01 (May 25 2021 - 08:44:03 +0800) Allwinner Technology
arm-linux-gcc.br_real (Buildroot 2017.02.5) 5.4.0
GNU ld (GNU Binutils) 2.26.1
=>
Probably, all of this is obvious, but I hadn't seen it reported anywhere on this thread or the main one...
-
This indicates something weird with your data, shouldn't be there.
SPI-NAND: W25N01GV is found size: 128MB.
*** Warning - bad CRC, using default environment
I've seen this in many different devices/brands. Not a direct sign of problems BUT agree that, if things were done properly, it shouldn'd be there.
See here (https://forum.openwrt.org/t/solved-u-boot-crc-warning-at-boot/35576).
-
Huh, you could also ask them for the kernel sources, otherwise they're violating the GPL.
Maybe we could open a thread for that at eediscuss.com and, if we get a lot of people from the threads at eevblog supporting it, maybe they would publish them. Not very confident in that, from what I read, Chinese manufacturers tend to be extremely reluctant to open source their products even though, in a good number of the few cases it has happened (or when the open-source community has created alternatives to the official FW), it has meant a boost in sales of the affected products...
OTOH, AndrewBCN said a long time ago he was considering doing so:
...
Eventually, I will ask Hantek to consider open-sourcing the phoenix binary, so that this becomes a (partially) Open Source community project for an Open Source DSO. Personally I see this as a win-win situation, as Hantek would be able to dedicate their firmware engineers to other projects and the community would gain access to the first Open Source DSO.
Don't know if he finally did it, but I think a public request in their forum with enough support from people posting there might get a better response than individual requests
-
....
See here (https://forum.openwrt.org/t/solved-u-boot-crc-warning-at-boot/35576).
Thanks!
Could this mean Hantek is using a hacked u-boot ::) ::)?
Not very professional of them!!
-
Edit: I said nothing, didn't notice before, but it's also happening in mine.
That could be also caused because there's no environment (There's no saveenv cmd), and it always fallbacks to defaults. Not sure, but nothing to worry about.
It's just the u-boot, loads the kernel, end of story. You can modify the booting commands and kernel arguments but not much more.
I've done that, for example, when manually patching the original uboot to boot larger kernels, or stream the output to a different serial port before finding the actual UART0 location.
I gave another try, nope, not for me, I'm really tired of this device.
crysti, probably you had the same bug as me few days ago, where it suddenly freezed, and nothing fixed it until I reinstalled the system.
-
It might be that, possibly, they're using a patched u-boot...
David, Do you also get the "anolis_picture_width:21 picture!=NULL failed." messages?
Also, Did you explore the u-boot environment commands?
-
Thanks for your help, now it's OK.
Frozen when I used the cursor for measurements.
-
Yes, these errors has always been there.
-
I find with google translate, a similar forum, with the same tools
https://4pda.to/forum/index.php?showtopic=1018961 (https://4pda.to/forum/index.php?showtopic=1018961)
(https://i.ibb.co/Cvg4rBJ/hantek.jpg)
-
Yes, I know that forum for a very long time.
Information is free, right? There's nothing wrong doing so, also english is not friendly for slavic countries.
All the available information over the net should be free to use, the only ethical aspect is to show some respect by giving credits to the author, whch they're doing, so everything is great.
I already said lots of times, most of my work was only possible thanks to Mark5, he's the one who already made a lot of hacking on other Hantek scopes, figuring out how upk files worked, and the decryption password.
-
I received the DS1307! Made few mods to it:
- Removed the charging diode/resistor as Im using a CR2032.
- Replaced the 500K in-series resistor between battery and Vbat pin with a solder jumper (there's no need of that)
- Removed the really stupid 1M5 pull-down resistor whose function is just to drain the battery faster.
- Lifted 24C32 pin 1 and connected to VCC to change address to 0x51.
Everything was detected at the first try:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
Then I updated the RTC script (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg4120645/#msg4120645).
Much cleaner, now it supports both DS1307 and DS3132 in a single file.
Very nice, now I have timestamps, no longer scratching my head while trying to figure out when the screenshots were made :D
So, nice for Hantek. They really needed to save $1 in parts ::)
-
Perfect!
Mine is also working OK since a few days ago with a DS3132 module and the script I posted here (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg4135555/#msg4135555), modded from your old RAM version to work with flash. I'll try your new version also.
Still have to make the permanent installation, for the moment I have it provisional to experiment with different modules.
Definitely, for the cost, it's a worthwhile modification, especially for those who take screenshots on a regular basis.
-
Yes, the script is doing the same thing, just a lot more tidier and better formatting, removing a lot of intermediate steps.
-
Wtf is fel mode?
-
Wtf is reading the f. FAQ? :wtf:
-
Wtf is fel mode?
Although a bit blunt David is right. Reading seems to be a lost skill, but to make is simple for you FEL is a state Allwinner MCU's can be put in. When in this state the USB port is set to slave mode and allows for a host to control the MCU. It is possible to read and write peripheral registers and load code to memory (not the DRAM though because that needs initialization first) or a FLASH chip when connected to the MCU.
To do this dedicated software is needed on the host. sunxi-fel to be specific. Not sure about the platform tools frequently mentioned in the Hantek threads, because I have not used these yet.
-
Sorry, I can't stand lazy people.
While I made a quite big effort on documenting everything, but it's easier to ask and wait! While simple forum search provides it all.
SEARCHING FAQ:
-Enter your subject in the searching box, placed at the top right corner.
-Click search
-Read
-If still not clear, you may ask.
-
Please help-me with my DSO2D10 with freezing after booting.
I forget there was a factory reset command, if it happens again, try that.
Connect the computer to the rear port, open the scpi console and send "PRIVate:FACTORY:RESET" as described here (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg3581870/#msg3581870).
-
I received the DS1307! Made few mods to it:...
Hi, David.
After these new versions, I've updated the folder for the RTC mod on your disk (https://drive.google.com/drive/folders/1ucj2Dd50x7-YIvcKkrbVnl9zPgxXtmcO?usp=sharing) with your new scripts. The folder also contains your i2c binaries and the "do_other_update" scripts needed to install them in the scope (although I doubt anybody installing an RTC would need them, as they'd probably also install the serial port and make the installation from the console).
There's also a "readme" file and a detailed document for the mod (also attached here) If you want the editable version, I'd send it to you also.
You could just move the entire folder to the appropriate place on the nonwritable part of the disk, but I imagine you'll like to revise it first ;)
Thank you for all your work with this mod!
EDIT: Typo in attachment
EDIT2: new version of the document, including David's requests
-
Edit:
RTC packages done, placed in RTC clock mod (https://drive.google.com/drive/folders/1F2hfntbKf6JStxfPLoUNvkpkkmr2pnR5) folder.
Please make a cut-down version of the RTC installation guide, removing the script details, as they're not required?
Also, it would be better to add the RTC circuit/eeprom modification details instead linking to the forum, as you never know what could happen, tomorrow the server could break down and everything get lost.
-
Thanks guys, I installed the hack and works like a charm.
I used an DS3231 module with DavidAlfa's dso3kb_rtc_DS3231_install.upk package.
:-/O
-
...
Please make a cut-down version of the RTC installation guide, removing the script details, as they're not required?
Also, it would be better to add the RTC circuit/eeprom modification details instead linking to the forum, as you never know what could happen, tomorrow the server could break down and everything get lost.
Ok, I'll do it
-
Thanks guys, I installed the hack and works like a charm.
...
Congrats!
Could you please add a photo of the place where you connected the wires to the mainboard?
From your second picture, it looks like you soldered them to the EEPROM, as I did. I think this is the best alternative, as the pins are much larger than other possibilities.
Also, I discovered yesterday that the I2C bus is present at the mainboard to LCD connector, which would be also an alternative. Pins 8 and 9 are SDA and SCL, GND is at pins 11-12-14-16-18-20-22-28-30-32-38-45 and 3.3V at 25-26.
I2C bus is also routed to (unmounted) P2 connector in the LCD-keyboard PCB. Could be a good alternative if you have or can find a connector or ribbon cable that fits there (very fine pitch). From left to right, P2 is: MCU pin 28-3.3V-GND-MCU pin 29-SDA-SCL. Maybe that connector was there for a touch pannel...
EDIT: Didnt see well the photo in the first version of the post
-
I wouldn't solder to the plastic lcd connector under any circumstances, it's just too easy mess up something!
Interfacing the 24c02 pins is, by far, the best and safest option.
Yes, there're traces of the Goodix GT911 i2c touch controller everywhere, but I guess it didn't made it to the final production version.
-
...
Please make a cut-down version of the RTC installation guide, removing the script details, as they're not required?
Also, it would be better to add the RTC circuit/eeprom modification details instead linking to the forum, as you never know what could happen, tomorrow the server could break down and everything get lost.
Ok, I'll do it
Done and uploaded to the Google drive and the previous post (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg4146673/#msg4146673).
-
The RTC script is finished, working great. Supports both DS1307 and DS3231.
....
# Monitor "date" file, update if timestamp changed
while true; do
if [ -f "$DATE_FILE" ]; then
NEW="$($DATE -r "$DATE_FILE" +"0x%02S 0x%02M 0x%02H 0x%02u 0x%02d 0x%02m 0x%02y")"
[ "$NEW" != "$STAMP" ] && write_rtc
fi
sleep 5
done
Not really very important, as a few seconds' difference is not relevant in this application, but for future versions you might consider this modification to the last line:
[ "$NEW" != "$STAMP" ] && NEW="$($DATE -d "@$((20 + $($DATE -r "$DATE_FILE" +"%s")))" +"0x%02S 0x%02M 0x%02H 0x%02u 0x%02d 0x%02m 0x%02y")" && write_rtc
It simply recalculates $NEW, after comparing to $STAMP, adding 20 seconds before calling write_rtc. This is to compensate for the time you need to extract the pendrive from the PC (after "touching" it), plug it in the scope, and for the time the scope needs to mount the unit and read it. I've tried it in my scope and seems to work as intended.
I had also added this compensation here (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg4135555/#msg4135555), but the idea probably got lost in the (too long) post. I tend to "enrollarme" more than necessary...
-
Is there any document about the serial console mod?
All I found is a JPG file in the 'Mods/hacking' folder.
Can I control my scope using a terminal window in normal operation or only in FEL mode?
Is the serial mod a normal RS232 port? So I can use console commands and the front USB at the same time?
-
That JPG is all needed from the hardware point of view, you get a 3.3V level serial port (not RS232 levels). To connect it to a PC, you'd need a serial to USB adapter compatible with these levels (maybe it's 5V tolerant, especially if you use the suggested resistors, but I haven't tried).
This serial port gives access to a console terminal for the scope's embedded Linux, very good for hacking but, AFAIK, not useful to send SPCI commands.
It's possible to use it simultaneously with the front USB.
I just gave a try to connect Keysight's utilities via the serial port but, as expected, they didn't work. They seem to reproduce the dialog for user logging (see attached pictures, the 3rd one is what you get in Putty, for example). Maybe there's a command or executable to set the scope listening for SCPI on that port, but I don't know it :'(
-
I don't think so, scpi is handled by Hantek's Phoenix binary itself (The one running the main app, gui, functions...).
FEL is just a low-level boot mode for Allwinner devices, nothing related to controlling the scope.
No RS232 levels, it's 3.3V.
There's an unpopulated max232 that could be added if required, I guess they thought on adding rs485 but didnt' in the end.
I used a esp8266 with Jeelabs firmware, it's very convenient to have console access wirelessly.
-
Thanks guys, if it is only for hacking Linux I'll pass.
Not quite on that level yet.
Might be useful for running different scripts though, instead of constantly moving the USB dongle between the PC and the scope ..... hmm.
-
Could you please add a photo of the place where you connected the wires to the mainboard?
From your second picture, it looks like you soldered them to the EEPROM, as I did. I think this is the best alternative, as the pins are much larger than other possibilities.
I solder the wires to the eeprom, as suggested, I used the connector and the buzzer as strain-relieve :-+
-
I wanted to patch the UART (again) but with better formatting, the original string was too small and couldn't be done by simply patching it.
So I've revisited something I had already done: Finding empty spaces in the binary, inserting a new string and replacing the pointer addresses.
I hadn't documented any details, so I had to start from zero, last time I did this (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg3607460/?topicseen#msg3607460) I was recovering from the surgery, had a lot of sleep deprivation and pain for months, so now I didn't remember anything!
Start with a working linux system with python3 and python3-pip installed, and your prefered HEX editor. I'm using HxD (Windows).
First steps
Get some basic file information:
file phoenix
phoenix: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.10.0, stripped
LSB means the file uses little-endian, that is, less significant bytes first, or reversed.
Ex. the number 0x11223344 would be encoded as 0x44332211.
Install cavefinder
sudo pip3 install cavefinder
Check you new string requirements
In this example I'll be adding a larger string for the UART decoder, so it outputs HEX+char.
Remember you need a termination (null) char, also it's better to ensure the preceding byte is 0 in case there's a string there
For [%02X '%1$c'] , the decoder output for 0x41 would be: <41 'A'>, and requires at least 13 bytes.
Find empty space
I recommend specifying slightly bigger size for future changes, ex. in this case 32 bytes should be more than enough.
cavefinder --size 32 phoenixYou'll get a lot of results, take any size matching your requirements.
There'll will be much bigger zones, but it's better to preserve them for other future purposes that really require larger sizes.
Section name: .rodata
Cave begin: 799690 - 0xc33ca
Cave end: 799722 - 0xc33ea
Cave size: 32 bytes
Virtaddr: 0xd33ca
info: Type: SHT_PROGBITS, Flags: SHF_ALLOC
So we have a good one at 0xC33CA. Note that the virtual address has an offset of 0x10000 (0xd33ca), remember this!
Better to align it to 32-bit, just in case, so our string will start at 0xC33CC.
Opening phoenix in the hex editor and jumping to the address:
/ Start
|
0C33C0 19 80 19 80 19 80 19 80 19 80 00 00 00 00 00 00 .€.€.€.€.€......
0C33D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0C33E0 00 00 00 00 00 00 00 00 00 00 03 30 03 30 03 30 ...........0.0.0
|
\ End
Insert the string:
0C33C0 19 80 19 80 19 80 19 80 19 80 00 00 25 30 32 58 .€.€.€.€.€..%02X
0C33D0 20 27 25 31 24 63 27 00 00 00 00 00 00 00 00 00 '%1$c'.........
0C33E0 00 00 00 00 00 00 00 00 00 00 03 30 03 30 03 30 ...........0.0.0
We're done with the first (easy) part.
Patching the pointers
Now we have to find the original string, the pointers to it and redirect them to the new one.
Because I already spent a ton of time testing different locations, I know the original string is "%02x", placed very close to another string, "UART DATA".
Searching "UART DATA" quickly finds the location at 0BAAAC:
0BAAA0 00 00 00 00 55 61 72 74 00 00 00 00 25 30 32 78 ....Uart....%02x
0BAAB0 00 00 00 00 25 30 34 78 00 00 00 00 52 00 00 00 ....%04x....R...
0BAAC0 25 73 3A 25 30 32 78 5B 25 73 5D 00 7E 41 00 00 %s:%02x[%s].~A..
0BAAD0 57 00 00 00 55 41 52 54 20 44 41 54 41 00 00 00 W...UART DATA...
Address size is 32-bit, so: 000BAAAC
Add the previous 0x10000 offset, and reverse it (Remember, uses little endian), the result is ACAA0C00.
Our string starts at 0x000C33CC, requires the same conversion: 0xCC330D00
Search ACAA0C00 pattern (hex), you'll find plenty of values.
Now it's matter of replacing one at a time with CC330D00, and testing the binary in the scope.
I've found the pattern at: 0x53550, 0x53AA0, 0x54050, 0x54488, 0x553B4, 0x9196C,
so I've made different files called phoenix_53550, phoenix_53AA0...
After testing, the pointer for the UART decoder was the first one, at 0x53550:
053550 AC AA 0C 00 10 D0 4D E2 F0 4F 2D E9 41 DF 4D E2 ¬ª...ÐMâðO-éAßMâ
053550 CC 33 0D 00 10 D0 4D E2 F0 4F 2D E9 41 DF 4D E2 Ì3...ÐMâðO-éAßMâ
And enjoy a better UART decoder!
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=1481377)
-
Lastly, I finally made a package for the small english font patch (https://drive.google.com/drive/folders/1J7FL_yq3dy7rTmCw6vkmukFyjnmrEM6d).
Although smaller, it's way better to look at.
-
Hi, David. I saw your post at eediscuss.com (https://www.eediscuss.com/forum.php?mod=viewthread&tid=16049&extra=page%3D1) asking Hantek to release the code, and replied supporting your request.
I think it would be good if all people monitoring this thread would do the same, so Hantek could consider doing so if they see there are many people interested. We should expose reasons such as increased sales or product improvement by volunteers, to try to convince them.
I don't have much faith that it will work, but it's worth a try... I'll also post this on the main thread
I had also suggested to them releasing the code in this other thread (https://www.eediscuss.com/forum.php?mod=viewthread&tid=16033&extra=page%3D1), but they didn't bother answering...
P.S: If it's possible for you to do so, I'd suggest changing the subject of the thread at eediscuss to include that you are asking for the code for DSO2x1x series, as that forum is general for all Hantek desktop scopes, not just this series
-
I don't have much faith that it will work, but it's worth a try... I'll also post this on the main thread
+1
-
Thanks to all the good information here I played around a bit with my DSO2D15.
The one thing that bothers me most is the very slow data transfer (via USB) to the PC, for 2 channels with 4MB each it takes about 5 minutes!! [1]
My plan is now to use a static GDB to set a breakpoint in the phoenix binary, so when I press "save to USB" gdb interrupts the process, fetches all necessary data from memory, and sends it via a quicker link to the PC.
For that it would be awesome if someone has the kernel build configuration available - with the g_android module (already on the scope, but for a different kernel version ;( ) it would be possible to use the same USB cable for a serial console, as network interface (rndis), and perhaps push the acquired data via PTP or similar (or just use socat on the network connection).
So... does anyone have more information about 5.2.0-licheepi-nano, perhaps even a g_android module
Thanks a lot!
Ad 1: https://github.com/phmarek/hantek-dso2000
-
Look at the work this guy did: https://www.thirtythreeforty.net/posts/2019/12/my-business-card-runs-linux/ (https://www.thirtythreeforty.net/posts/2019/12/my-business-card-runs-linux/)
I have played with a fork of his work on the FNIRSI-1013D which uses the F1C100s, which is the same as the F1C200s apart from the DRAM. 32MB vs 64MB.
No way to tell if it is the same code base. Forum member iscle https://www.eevblog.com/forum/profile/?u=685980 (https://www.eevblog.com/forum/profile/?u=685980) did some work on it and I believe he did it with a later kernel release. Maybe he can help you.
-
So... does anyone have more information about 5.2.0-licheepi-nano, perhaps even a g_android module
Sipeed has an Allwinner F1C100s development board with a few links on the page:
https://www.seeedstudio.com/Sipeed-Lichee-Nano-Linux-Development-Board-16M-Flash-WiFi-Version-p-2893.html (https://www.seeedstudio.com/Sipeed-Lichee-Nano-Linux-Development-Board-16M-Flash-WiFi-Version-p-2893.html)
GitHub for Lichee Pi, There is also the Wiki link from Seeedstudio
https://github.com/Lichee-Pi (https://github.com/Lichee-Pi)
Digikey sells the dev boards last time I ordered one. (still sitting on my bench collecting dust)
-
Aliexpress still seems to have stock: https://nl.aliexpress.com/item/4001150568609.html (https://nl.aliexpress.com/item/4001150568609.html)
There are also F1C200s boards to match the memory size. For instance the MangoPi R3 https://nl.aliexpress.com/item/1005002527296059.html (https://nl.aliexpress.com/item/1005002527296059.html)
Info on it: https://wiki.dfrobot.com/MangoPi_R3_SKU_DFR0780 (https://wiki.dfrobot.com/MangoPi_R3_SKU_DFR0780) shop: https://www.dfrobot.com/product-2274.html (https://www.dfrobot.com/product-2274.html)
Edit: A bit cheaper variant: https://nl.aliexpress.com/item/1005003625275029.html (https://nl.aliexpress.com/item/1005003625275029.html)
Makes tinkering with a linux kernel easier than using your scope.
-
Read few post back for that kernel (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg4123312/#msg4123312)
It's probable Hantek made modified the kernel, but they didn't release the sources.
pcprogrammer, 1 year ago there were F1C200s boards for $8. $26 now? What a rip-off!
Cheaper seller: www.aliexpress.com/item/1005003479943027.html (http://www.aliexpress.com/item/1005003479943027.html)
-
pcprogrammer, 1 year ago there were F1C200s boards for $8. $26 now? What a rip-off!
Cheaper seller: www.aliexpress.com/item/1005003479943027.html (http://www.aliexpress.com/item/1005003479943027.html)
Yes I know. Paid ~7 euro for my lichee nano boards and now ~14 euro. But that is what is happening in the world at the moment. Huge rise of prices. Luckily I live in France now where electricity prices did not go up that much. In the Netherlands they tripled, together with the gas prices |O
Petrol on the other hand is probably becoming expensive everywhere. :palm:
-
Hi David,
if you still have the build environment - would you please make menuconfig for the g_android module and put that in your Google drive?
Would save me quite a few hours trying to get the build env built....
With a bit of luck it's compatible (enough) to "just work".
Thanks!
-
I tried already, but that kernel makes the old libcomposite.ko, insmod fails...
-
Did somebody succeed in booting mtdblock images from the device via qemu, for quicker testing?
-
AFAIK, nobody did anything.
I've cleaned my VM and uploaded it here (https://drive.google.com/drive/u/0/folders/19QNPboqp83xhKXS-ei6BlSagNnOY1KdN).
Dependencies are installed, it's ready for building, only needing git clone-whatever.
There're lots of issues with newer Linux versions and older projects, this one works perfectly.
Of course, it includes the usual nude-stealing virus :-+.
-
OK, I got a few kernel modules that load on the scope... g_serial, usb_f_serial, and a few others.
My current plan is still to capture the "Save to USB" button via gdb, then dump the whole (up to 8MB) big data area somewhere, and either make that accessible via USB mass storage support (so just download via accessing the usb disk!) or via xmodem/zmodem/base64 or whatever to another serial USB port.
But trying to get that working via do_update_script, failing, rebooting, ... is awkward.
Would somebody be so kind and allow me (watched! eg. via gnu screen) serial console access to quicken the debugging process?
I'm hoping to get a software-only serial console via the USB port (to avoid soldering and using a 3V3 compatible RS232 converter); as soon as that is working, other niceties (like the GDB trick) should be fairly easy to do...
-
Were you really able to sucessfully load these modules? I only got errors!
Yep, that must be the most depressing way on earth!
My scope has a ESP-01 with Jeelabs's Esp-link firmware, runs great, it's basically a raw TCP connection.
I have no problem sharing it, the issue is with my ISP using CGNAT (Shares external IP between several customers), so any option requiring some sort of server from my side will not work.
Could get a unique IP by paying a small fee, but I never use that feature anymore!
Perhabs you could run a server where I could connect to? Being the client, it should work.
Don't know, reverse ssh perhabs?
I also have a small linux box, could be used for that.
BTW the system already includes the mass_storage usb widget! But not ACM or any other one.
Edit: Got it doing some reverse netcat. Check your pm.
-
Finally got it. I'm attaching this as it could be useful for a lot of situations.
Just keep in mind this method won't encrypt the traffic.
I'm behind a NAT, so I can't open ports.
Thus, for it to work, I need to initiate the connection.
On my side: Will run this script, starts a nc client to the ESP port (serial->tcp bridge), and another to your server, both bridged:
cd /tmp; rm -f a; mkfifo a
while true; do
cat a | nc ESP_IP ESP_PORT 2>&1 | nc -nv REMOTE_IP REMOTE_PORT -w5 >a
done
On your side: Linux machine, or Windows with cygwin and nc package installed.
Start a netcat server for my system to connect to, and another to open a local port where Putty can connect to, also bridged.
cd /tmp
rm -f a b; mkfifo a b
nc -lk REMOTE_PORT < b > a &
nc -lk INTERNAL_PORT < a > b &
printf "" > a
Only REMOTE_PORT needs to be open in the firewall/router.
Then putty connects to localhost and INTERNAL_PORT, which is the local netcat server.
This way, the shell works perfectly.
Took me several hours to find the correct commands!
Sending files: Login first, then exit the terminal (you can't have two concurrent connections) and run:
sz --tcp-client 127.0.0.1:9922 FILE
Also SecureCRT (paid) works well for this, you can download it on internet.
-
Good news!
Thanks to @phmarek, we finally got the usb console working! :-+
(All this time I was missing a dependency!... omg)
New package available:USB Console (https://drive.google.com/drive/folders/1B5mgsuO5OvIwT3gi_5n9HC6r_BxRoCuF).
Enjoy!
-
Hello,
I believe I have found the masters of the F1C100s. :box:
I have a DSO1511E+ (this model has the F1C100s) and unfortunately I bricked it due to an update, I forgot to unzip the file. :palm:
I would like to know if it would be possible to recover its functioning by copying the contents of the SPI memory of an oscilloscope that has its firmware intact.
Or if it would be possible to write the update file directly to SPI memory using a CH341 programmer.
This is the video about the update I should have been able to do:
https://m.youtube.com/watch?v=3QZC1mhwGlI
Thank you.
-
I believe I have found the masters of the F1C100s. :box:
I have a DSO1511E+ (this model has the F1C100s) and unfortunately I bricked it due to an update, I forgot to unzip the file. :palm:
I would like to know if it would be possible to recover its functioning by copying the contents of the SPI memory of an oscilloscope that has its firmware intact.
Or if it would be possible to write the update file directly to SPI memory using a CH341 programmer.
Yes if it is just the firmware that is corrupted, you should be able to restore it with a copy of firmware from a working scope.
Is that a SD card slot on the board next to the FLASH chip? If so you can make an SD card that boots the F1C100s into FEL mode. With the sunxi-fel utility you can then, via USB, check the system and read and write the FLASH. Way easier then trying to hook up a CH341 programmer.
Search the FNIRSI-1013D thread on how to do this. Lots of information about the F1C100s there.
-
I believe I have found the masters of the F1C100s. :box:
I have a DSO1511E+ (this model has the F1C100s) and unfortunately I bricked it due to an update, I forgot to unzip the file. :palm:
I would like to know if it would be possible to recover its functioning by copying the contents of the SPI memory of an oscilloscope that has its firmware intact.
Or if it would be possible to write the update file directly to SPI memory using a CH341 programmer.
Yes if it is just the firmware that is corrupted, you should be able to restore it with a copy of firmware from a working scope.
Is that a SD card slot on the board next to the FLASH chip? If so you can make an SD card that boots the F1C100s into FEL mode. With the sunxi-fel utility you can then, via USB, check the system and read and write the FLASH. Way easier then trying to hook up a CH341 programmer.
Search the FNIRSI-1013D thread on how to do this. Lots of information about the F1C100s there.
Really thank you for your answer, that's what I needed to conclude. :-DMM
Yes, it's an SD card slot, I just don't know if it's plugged into the correct port for boot to occur.
I could also conclude that it would be possible to use an sd card to boot, I read many posts about this F1C100s.
All the posts I read were of conversations between advanced people in the programming of this F1C100s, so I was not able to know how to start, I had seen about a tool to interact via USB port.
I'm just weird that the update vendor hasn't confirmed this to me. He said he would help me but after a few weeks of waiting he never came back. I hope he didn't die because of Covid there in China.
I'll look for the reference you gave me.
Thank you very much! :clap:
-
You are welcome. :)
The documentation and internet is not conclusive about the ability to boot from which devices. The first SD/MMC and SPI port do work for sure.
Take a look here for more info about FEL boot from the SD card: https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Linux/images/fel_boot (https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/Linux/images/fel_boot) The readme file shows the command on how to put the image on the SD card. It also gives info about where to get the sunxi-fel source code and how to build it.
It is targeted to Linux not Windows, which I don't do anymore, apart from occasional gaming. :D
A pre-build version of sunxi-fel is also there: https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/sunxi_stuff (https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/tree/main/sunxi_stuff)
Attach the device to the PC via USB, stick in the SD card, turn it on and see if the "Onda" device shows up in the USB device list ("lsusb" from Linux command line)
-
I thank you for your attention,
I was already viewing this same repository, I found it in this other post:
https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4195390/#msg4195390 (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4195390/#msg4195390)
I still think it might be easier for me to remove the SPI memory from the board, I work with hardware for a long time, just in the ARM programming part that I'm learning, I've already made program for STM32F4, so I'm venturing with this F1C100s.
But I thought about the following: If I used the compressed file, could I read the contents of the SPI memory, find where this file started to be written, then write the correct content from this address?
I still don't know if there is a specific address for the F1C100s to start running the firmware, but I'll look for it.
Thanks again!
-
It starts on address 0 in the FLASH. There should be a boot header (BROM) there.
The first four bytes are a branch instruction, followed by 28 bytes of information about the code. The boot loader starts with eGON.BT0. The actual firmware has eGON.EXE
And glad to see you did your homework :)
What ever works best for you. For me the FEL mode made live much simpler while working on the FNIRSI-1013D. 8)
-
It starts on address 0 in the FLASH. There should be a boot header (BROM) there.
The first four bytes are a branch instruction, followed by 28 bytes of information about the code. The boot loader starts with eGON.BT0. The actual firmware has eGON.EXE
And glad to see you did your homework :)
What ever works best for you. For me the FEL mode made live much simpler while working on the FNIRSI-1013D. 8)
Thanks for these clarifications!
In fact the update file (unzipped) has these instructions at the addresses mentioned by you.
I did the SPI memory dump (W25Q32FVSIG) and in fact the contents of the RAR file are present in memory, as can be seen in the image.
I was surprised that all Flash content is written. I didn't find any unused parts, I think maybe the update has looped and overwritten all of Flash.
I hope there isn't some address with calibration data in this Flash that has been overwritten.
Thanks for the help you gave me, I wish you the best!
-
I'm not sure what you were looking at with the hex editor, but the data you marked (37 63 C7 73 CE) is not proper data to be found at location 0x00000000 in the FLASH. This is simply why your system does not boot.
The file that needs to be loaded to the FLASH might be the one inside the .rar file (dso1511e_v1.2.2.bin) but it may well be that this is just the firmware and not the whole FLASH content. Start a new post either in the repair section or the test equipment section and ask if someone is willing to extract the FLASH from it's device.
The reason I say this is to no longer be off topic in this thread and that the .bin file starts with
06 00 00 EA 00 00 00 00 00 00 00 00 00 00 00 00 00 FE 06 00 52 F0 01 00 00 00 00 00 00 00 00 00
which is a BROM header but not for a boot loader since there is no eGON marker. For as far as I know the BROM checks on this marker and the length and CRC fields.
So you need a new copy of the proper boot loader.
Edit: see here for more info: https://linux-sunxi.org/EGON (https://linux-sunxi.org/EGON)
And I think this scope is just as big a lie as the FNIRSI-1013D. 120MHz BW and 500MSa/s. Looks like the ADC is the same 2 x 100MSa/s chip used in the FNIRSI. Even if they push it to 125MHz per ADC it is still half what they advertise.
-
Yes, I merged the contents of the update file at the start of flash, but it didn't work.
Only Flash power is performed when the power button is pressed, but nothing else happens.
The Flash content was overwritten every 0x1000 block, with the same incorrect content.
I did some tests with the bootloader of STM32F4 and at the time I only loaded files with a bin extension, it's a pity that this was not the case with this F1C100s, which accepted any file without any filter.
I'm going to program myself to buy another one of this oscilloscope, I already tried to ask someone to make a copy of the firmware but I didn't have any answers, maybe people who are buying these handheld models don't have enough knowledge to perform the flash dump.
I thank you for providing me with some knowledge about this F1C100s!
-
Is it a spi nand flash? Then DsoFlash should work.
-
The picture of the PCB shows it is a Winbond 25Q32, so NOR type.
-
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 (https://github.com/xboot/xfel) (Download latest release (https://github.com/xboot/xfel/releases/tag/v1.2.9)), 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:
xfel spinor
xfel spinor read 0 0x400000 backup.bin
xfel spinor erase 0 0x400000
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.
-
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)
-
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)
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;
}
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:
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:
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:
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? :-DD
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:
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.
-
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!
-
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.
-
Does anyone have a full nand w25n01g memory dump for dso2d15???
-
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.
-
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 :) :-+ :-BROKE
-
Overclocking improves that (Check the FAQ for this), the CPU is rather limited.
https://www.youtube.com/watch?v=CKMDma6xilY (https://www.youtube.com/watch?v=CKMDma6xilY)
https://www.youtube.com/watch?v=VRHXwlwrJMQ (https://www.youtube.com/watch?v=VRHXwlwrJMQ)
-
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.
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
[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.
:-+
-
All that is unnecessary, check the faq, there's a package to do that in a very simple way (2D15 Conversion), same for overclocking.
-
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 :-+
-
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?
-
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.
-
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.
-
Try Zebra CDC driver, it's signed:
https://www.zebra.com/us/en/support-downloads/software/drivers/usb-cdc-driver.html (https://www.zebra.com/us/en/support-downloads/software/drivers/usb-cdc-driver.html)
-
Wow, works like a charm, many thanks!
-
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 (https://drive.google.com/drive/folders/1B5mgsuO5OvIwT3gi_5n9HC6r_BxRoCuF) folder.
Also updated 2D15 converter (https://drive.google.com/drive/folders/1GkQ58OpYthIJsy-mMDN6FkS06qFK5u2J) to modify the Hardware number, only replacing the last ".000" with ".001".
-
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 (https://drive.google.com/drive/folders/1B5mgsuO5OvIwT3gi_5n9HC6r_BxRoCuF) folder.
Also updated 2D15 converter (https://drive.google.com/drive/folders/1GkQ58OpYthIJsy-mMDN6FkS06qFK5u2J) 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
-
Great! Enjoy :-+
-
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 😕
-
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.
-
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 ?
-
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 (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.
-
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 (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.
-
Please lets keep this problem in your own thread you started about it.
For others it is here: https://www.eevblog.com/forum/testgear/is-my-hantek-dso2c10-badinaccurate/?topicseen (https://www.eevblog.com/forum/testgear/is-my-hantek-dso2c10-badinaccurate/?topicseen)
-
Does anybody know what firmware version 2022-07-27 does differently?
I haven't seen any changelog.
-
Hantek never makes changelogs... Go figure.
-
Found something funny while playing on the console...
I issued a poweroff command to shut down the system and, after its completion, saw that some key LEDs remained on. Nothing strange so far, the correspondent GPIO or buffer might be stuck at that state. But when I pressed the keys, the "beep" still sounded, with the system off. This must mean that the keyboard PCB generates it autonomously, or maybe (more probable) it's the FPGA that generates it (and it doesn't shut down when de MCU does)
-
The keys, leds and the beeper are connected to the FPGA, so it might well be the case that it does work without the MCU.
The thing I wonder is how the MCU gets the information about a key press or a rotary dial change. There are two interfaces between the FPGA and the MCU. SPI and I2C.
SPI is used for loading the bit stream into the FPGA, and the sample data will be read via this channel too, but I don't know if the user interface signals are also transferred via this channel.
-
The keyboard scanning / beep is autonomously handled by the fpga, the cpu access it using i2c.
It doesn't beep on booting because the fpga firmware is loaded at the very end, just when the thing starts clickign and flashing.
Clearly, there's some configurable bits through i2c, on the fpga side.
-
Just received my DSO2C10 with Firmware 3205 and Software 1.0.2.0.0 (220831.00)
-
Just received my DSO2C10 with Firmware 3205 and Software 1.0.2.0.0 (220831.00)
Thanks for the info!
Seems like we have a new FW version, the latest one listed in the FAQ (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3559217/#msg3559217) is 3203, and a new SW version also (last one listed is dated 220517).
They don't appear yet on Hantek's website (http://www.hantek.com/products/detail/17182) downloads, though...
Can you also report your hardware version?
-
Just received my DSO2C10 with Firmware 3205 and Software 1.0.2.0.0 (220831.00)
Yes, I was aware of FW3205, someone at 4PDA uploaded it recently to my Drive.
Could you make and upload a backup using Backup Builder from the FAQ (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3559217/#msg3559217)?
That way I could extract the software and the FW and make new update packages.
-
Just received my DSO2C10 with Firmware 3205 and Software 1.0.2.0.0 (220831.00)
Could you make and upload a backup using Backup Builder from the FAQ (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3559217/#msg3559217)?
Made. Of the two backups, do you need to full one?
BTW. I realised that that the 2C10 refuses to read big USB thumb drive. Is there a size limit? Couldn't find in the manual.
-
Just received my DSO2C10 with Firmware 3205 and Software 1.0.2.0.0 (220831.00)
Thanks for the info!
Seems like we have a new FW version, the latest one listed in the FAQ (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3559217/#msg3559217) is 3203, and a new SW version also (last one listed is dated 220517).
They don't appear yet on Hantek's website (http://www.hantek.com/products/detail/17182) downloads, though...
Can you also report your hardware version?
Just received my DSO2C10 with Firmware 3205 and Software 1.0.2.0.0 (220831.00)
Yes, I was aware of FW3205, someone at 4PDA uploaded it recently to my Drive.
Could you make and upload a backup using Backup Builder from the FAQ (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3559217/#msg3559217)?
That way I could extract the software and the FW and make new update packages.
003.002.001.000.000.000.000.000 I have not opened the back to look at the PCB yet...
-
For me it works without issue with any USB drive, just make sure it's formatted in FAT32 and not ntfs or exfat.
I need the full one!
-
003.002.001.000.000.000.000.000 I have not opened the back to look at the PCB yet...
Curious! Being much older (in theory), mine is 003.002.001.000.000.000.000.001
PCB marking is "DSO2D15_V1.7 2021.1.14"
-
003.002.001.000.000.000.000.000 I have not opened the back to look at the PCB yet...
Curious! Being much older (in theory), mine is 003.002.001.000.000.000.000.001
PCB marking is "DSO2D15_V1.7 2021.1.14"
.000 - 2C10
.001 - 2D15
-
The last pcb field is another method to indicate the presence of the function generator.:
AWG not present = .000
AWG is present = .001
Hantek uses two methods OR'ed together:
- Reading the model 2Dxx/2Cxx
- The pcb bits
Any of them will enable the generator, in fact you can leave the model as 2C10, set the pcb to .001, and the generator will work.
-
I wasn't happy with system screen closing when taking a screenshot.
So I just wasted another 20 minutes of my life in doing nothing useful but "Steps to make a very complicated screenshot"
Dump the framebuffer to the usb drive
cat /dev/fb0 >/mnt/udisk/picture.raw
Image is in raw Big endian bgr565 format (Yes, R and B are swapped)
Convert to png using ffmpeg, swapping the colours in the process.
(This was a PITA to find out and took a lot of trial and error, the outputs were better than the famous Andy Warhol drawings :-DD)
ffmpeg.exe -vcodec rawvideo -f rawvideo -pix_fmt rgb565le -s 800x480 -i picture.raw -filter:v colorchannelmixer=rr=0:rb=1:br=1:bb=0 -vcodec png image.png
And here's the proof I can have a DSO2C10 with generator enabled!
(Somehow this PNG format breaks the forum thumbnail and shows always in large mode)
-
Just received my DSO2C10 (purchased 17/10/22) with Firmware 3204 and Software 1.0.2.0.0 (220210.00)
Not opened it up yet, but did try to save the system infomation but failed asking to insert udisk even though it was already plugged in?
Tried two different usb drives and also reformatted both using both windows and sd card formatter to make sure both were Fat32... :o
Read that FW3204 can mess up the USB... So tried installing the PC Software instead but having an issue with visa32.dll missing... ???
Not a great start! |O
So went old skool = Pen & Paper! :-+
Anyone got any ideas on the USB issue or missing visa32.dll
-
I'm toying with the idea of buying one of these just so I can get in on the fun. It seems to me that owning one of these would be kind of like ticking a polar bear. Always wanted to do that.
-
Ensure there's nothing at the back USB port, then go yo Tools and push Update several times.
If that wakes the USB, it's a common issue, apply the USB fix :)
It seems to me that owning one of these would be kind of like ticking a polar bear.
It's more like taking a leprous to a roller coaster.
-
Ensure there's nothing at the back USB port, then go yo Tools and push Update several times.
If that wakes the USB, it's a common issue, apply the USB fix :)
I've been messing about and deliberately connected both back and front usbs to see if it would beep, it did... and alternated between usb lead and usb drive icons.
Turned it off, unplugged the rear usb lead... back on... and the usb drive started working! ::)
Ah, USB fix... completely forgot about that... Thanks for the reminder @DavidAlfa. :-+
EDIT ~
USB Fix added... Working as it should now!
Small Font Added... A little small, but looks 100 times better than before... Is the small font available in bold?
Run out of time, so will open it tomorrow... see if it has the awg components populated or not. :-BROKE
-
It seems to me that owning one of these would be kind of like ticking a polar bear.
It's more like taking a leprous to a roller coaster.
Now that's a cracking analogy :-DD
-
EDIT ~
USB Fix added... Working as it should now!
Small Font Added... A little small, but looks 100 times better than before... Is the small font available in bold?
Run out of time, so will open it tomorrow... see if it has the awg components populated or not. :-BROKE
Opened it up and...
X1, U18, U35 all present! :o
Board is V1.7 2021/01/14...
I've run the Backup Builder and have the two Files saved. :-+
So I should just be able to run the dso3kb_2D15_conversion.upk, right? ???
Not sure it's worth the hassle of changing the FW... Or does that happen with the conversion anyway?:-//
-
No other better fonts available.
Yeah just go straighforward.
The fw isn't related to the generator, handles everything.
Old versions tend to crash, just follow the faq instructions, updating it isn't a hassle at all, takes 10 seconds.
-
No other better fonts available.
Yeah just go straighforward.
The fw isn't related to the generator, handles everything.
Old versions tend to crash, just follow the faq instructions, updating it isn't a hassle at all, takes 10 seconds.
No problem on the font...
Any idea what if anything, 3205 improves/fixes... over 3204, can't seem to find any info or peoples findings on it?
Will report back once I've done the D15 conversion!
Appreciate yours and everyone elses time and work on figuring all this stuff out! :-+
-
3205 is just a week old. Apparently it fixes rhe decoder (UART decoding and possiblyothers didn't work on 3204).
In any case of having issues, 3202 is a safe bet.
What about sending me your backup so I can make a software update with 2022.10.02? ;-)
Still, this is the hacking thread, for support please use the main thread (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/) instead!
-
3205 is just a week old. Apparently it fixes rhe decoder (UART decoding and possiblyothers didn't work on 3204).
In any case of having issues, 3202 is a safe bet.
Only a week, no wonder I can't find anything yet then! :palm:
I downloaded 3202 and 3205 ;)
What about sending me your backup so I can make a software update with 2022.10.02? ;-)
Of course, you will want the FULL... attach it here or prefer I send it?
Still, this is the hacking thread, for support please use the main thread (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/) instead!
Yes, I asked as it popped into my head while typing my last reply... will keep an eye on the other thread to see peoples thoughts and opinions. :popcorn:
-
Yeah I need the FULL, that's the one containing the software.
Better upload it to anonfiles and send me a PM!
-
Yeah I need the FULL, that's the one containing the software.
Better upload it to anonfiles and send me a PM!
PM Sent... :-+
-
What about sending me your backup so I can make a software update with 2022.10.02? ;-)
I think, its 2022.02.10
-
Yep it was 22.02.10 ;)
-
Tried to do the 2D15 Conversion, but get an Error... :wtf:
What am I doing wrong? :palm:
-
OK, I've no idea why, but... deleting and transfering the file to the root of the usb drive again worked! 8)
Just wanna say Thank you to @DavidAlfa and everyone else that has spent their time and effort working all this out! :-+
-
Perhabs you copied the file and removed the USB drive too fast?
Better to always use the safe removal method.
Does the generator amplitude match the settings?
Allow about 100mv error, this isn't a high precision generator, but if you get ex. 4V when setting 3V, or an excessive offset, then try the calibration tool.
-
Perhabs you copied the file and removed the USB drive too fast?
Better to always use the safe removal method.
I always eject usb before removing... probably just a glitch in the matrix! :-\
Does the generator amplitude match the settings?
Allow about 100mv error, this isn't a high precision generator, but if you get ex. 4V when setting 3V, or an excessive offset, then try the calibration tool.
I've been hunting for a bnc patch lead to test... can never find anything when you actually want it! ::) |O
-
For testing the amplitude you're ok with 1KHz, so just touch the bnc core with the probe tip and attach the alligator clip to the ring? Not nasa science :-// ;)
-
For testing the amplitude you're ok with 1KHz, so just touch the bnc core with the probe tip and attach the alligator clip to the ring? Not nasa science :-// ;)
I'm still reading and learning how to use a scope! :-[
I'm a complete newbie when it comes to scopes basically... You want a 55ft long articulated HGV (Lorry) reversing up your 10ft wide drive way without wrecking your garden walls or destroying your garage, house... I can do that! <---- voodoo to alot of people ... although driving a car forward seems to confuse some people!! :palm:
Check the pics, want me to do something more specific... let me know! :-+
-
Looks good to me! :-+
-
Dear all,
I'm new mem here, just going to order DSO2C10 but wonder if new mainboard revision has AWG hardware or lacking ?
Thanks ! :)
-
I would avoid purchasing this for now. Did you read this (and other) thread(S) on these scopes? Despite having wonderful specifications for their price, they are not good. They seem to deliver more "grief" than "great". When I first saw their specifications and price I was excited, but that soon passd after reading the experiences of the poor people that bought these sad pieces of junk. Save about 50% more and get a Siglent or Rigol scope.
Hantek make fairly decent USB scopes for the price, but they missed the mark so far on their stand-alone scopes.
-
Hi people,
if you're not happy with the long delays when writing data to an USB stick, or sending via USB SCPI, I've got a script for your PC and a firmware patch for you: https://github.com/phmarek/hantek-dso2000-quick-fetch
Instead of waiting 5 minutes to get a 2*4 MSamples download, on my notebook it completes in ~15 secs.
It requires the USB console to be activated (see DavidAlfa's patch directories, https://drive.google.com/drive/folders/1B5mgsuO5OvIwT3gi_5n9HC6r_BxRoCuF); to install, put a shared object (pre-build in the releases part of github) into the DSO's /root and a small change (to LD_PRELOAD that) to /dso/app/app, and run a (Perl) script on the PC side.
Currently it only exports CSV files - but if you have any other wishes, I can also add an signed 8 or 16bit binary dump etc.
I only tested on Linux.
There's no upk file (yet); when I've got a bit more feedback (and perhaps did some more changes) I'll create one, but I guess David will overtake me anyway ;)
Good luck!
-
I would avoid purchasing this for now. Did you read this (and other) thread(S) on these scopes? Despite having wonderful specifications for their price, they are not good. They seem to deliver more "grief" than "great". When I first saw their specifications and price I was excited, but that soon passd after reading the experiences of the poor people that bought these sad pieces of junk. Save about 50% more and get a Siglent or Rigol scope.
Hantek make fairly decent USB scopes for the price, but they missed the mark so far on their stand-alone scopes.
Not sure if you own one of these or are just basing your assertions on what others are saying?
Now, as an actual owner, my experience is once you account for the lack of support, shitty SW, noise issues, poor triggering, memory depth limitations, measurement limitations, barely functioning protocol decoding, a whole bunch of frustration etc etc it's still a reasonably functional and useful piece of test equipment for occasional hobby use. For the all in price of CA$264 that I paid for my 2C10 -> "2D15" I believe it's a pretty solid deal. Even the current price of CA$300 to your door is fair but to be clear I wouldn't be shelling out over CA$400 for the 2D15 as the awg just isn't worth the upgrade price.
Sure, if your budget is up there and/or you have a more serious use case then the DS1102Z-E has got to be a contender. Of course once you're up in that price range, why not just spring for a DS1054Z to get an additional 2 channels! See where I'm going here? Next stop $3k on a TEK :)
-
Not sure if you own one of these or are just basing your assertions on what others are saying?
A bit of both. I had one for about 2 days and then retuned it to Amazon. I ran into a load of the issues mentioned in these forums right out of the gate. While I admit my actual experience is (very) limited, it was not a great experience. Instead I bought the Siglent SDS1104X-E and while it is not without some small issues, they are very small indeed. Plus their support it 2nd to none. Sure it was nearly twice the price and lacks the AWG, but it is more than twice the scope. For an AWG I also got a Siglent SDG1032X. So yes, I ended up spending 3.5 times the price of the Hantek, but I have much more capability, flexibility and quality and I spend my time using the equipment rather than just trying to keep it going. :-DD
-
For the all in price of CA$264 that I paid for my 2C10 -> "2D15" I believe it's a pretty solid deal. Even the current price of CA$300 to your door is fair
As a fellow Canadian who's looking for a cheap hobby scope, I'm curious where you purchased one for $264 and where they're currently available for $300?
-
I can see some on Aliexpress: https://aliexpress.com/item/1005001869976988.html is the 2D15, for example.
-
For the all in price of CA$264 that I paid for my 2C10 -> "2D15" I believe it's a pretty solid deal. Even the current price of CA$300 to your door is fair
As a fellow Canadian who's looking for a cheap hobby scope, I'm curious where you purchased one for $264 and where they're currently available for $300?
I got mine from Banggood but I notice they've gone up to around $350 in the last few weeks.
Next best would be Aliexpress as @phmarek noted.
If you're not used to using AE, I normally search for the item then sort by orders. This will yield the sellers that have the highest number of sales and will in turn give you the best selection of reviews and best chance of success.
this https://www.aliexpress.com/item/1005001632872336.html (https://www.aliexpress.com/item/1005001632872336.html) for $266.80 free shipping
or this https://www.aliexpress.com/item/1005001940591637.html (https://www.aliexpress.com/item/1005001940591637.html) for $266.10 + $24.76 shipping
-
Cannot belive you paid $350 for this scope.
I got mine only $125 with shipping included. Bought directly from taobao. Of course brand new in sealed box.
-
Taobao is a gift but mostly only applicable to people living in China
I ordered from here personally: https://www.banggood.com/en/Hantek-DSO2C10-Digital-Oscilloscope-2CH-Digital-Storage-1GS-or-s-Sampling-Rate-100MHz-Bandwidth-Dual-Channel-Economical-Oscilloscope-p-1765866.html?rmmds=myorder&cur_warehouse=CN (https://www.banggood.com/en/Hantek-DSO2C10-Digital-Oscilloscope-2CH-Digital-Storage-1GS-or-s-Sampling-Rate-100MHz-Bandwidth-Dual-Channel-Economical-Oscilloscope-p-1765866.html?rmmds=myorder&cur_warehouse=CN)
Currently listed at $209 + reasonable shipping. Got mine for $190 shipped a few months back.
-
Cannot belive you paid $350 for this scope.
I got mine only $125 with shipping included. Bought directly from taobao. Of course brand new in sealed box.
Good for you. I guess we all have different benefits associated with where we live.
-
Hello, today I have noticed that the firmware has not been updated since November 2022, my DSO2D10 has that version, so my question is: can I do this Hack without problems having that update?
-
What hack?
-
What hack?
If I had to guess it would be that he wants it to enable the 150MHz BW. :-//
Maybe?
-
All installable hacks work ok any fw version...
-
I mean the first message, turn DSO2D10, DSO2C10 and DSO2C15 into a DSO2D15
-
Hi, thanks, i have problems with this:
"Create a file named do_other_update in the root of the USB stick (no extension, no .txt just do_other_update)
Add the following two lines in the do_other_update file :
sed -i 's/DSO2.1./DSO2D15/g' /cache/system.inf >/mnt/udisk/sed.log
sed -i 's/DSO2.1./DSO2D15/g' /dso/app/sys_inf.new >>/mnt/udisk/sed.log
/!\ Make sure that the file is UNIX formatted (ie line breaks should be unix style, you can check that with notedpad++)"
I try it but don´t works for me, the model allways is DSO2D10 before the update ends :-// How i can create a file without extension at Windows 10 and how i can check the line unix style using notedpad++ ? :-//
-
Read the faq! You don't need all that ;)
-
DavidAlfa,
Thanks for the work you have put into scripts / firmware and software uploads, etc. I have 'upgraded' my DSO2C10 to a 2D15 equivalent with no issues thus far.
I'm confused on one item though....I've read your FAQ and searched the forum (perhaps using wrong search terms?) but can't figure out the difference between FPGA firmware and 'regular' firmware. They both have the same number designation...3202, 3205, etc....
Do you mind explaining the difference, if any? Or point me in the direction to find that information?
Thanks! -G
-
It's the same :-+.
Firmware ver. = FPGA.
Software ver. = Scope software (Linux process).
-
Hey I'm a bit late to the party and tried some earlier links to the tool to backup the Hantek DSO 2XIX SCOPES FIRMWARE. Does anyone have a good link for me to get the tool. Thanks for any help... Hank
-
Look at the post above yours. Follow the link to the FAQ, etc...
-
Hey BillyO, Shortly after I made my post I DID hit the "DRIVE" button-link- and found all the good stuff to mod my soon to be delivered C15.... The "do_other_update" script is understood to tell the FW that the scope is allowed to turn on the sig gen and now one question.... After the modded C15 to D15, what is the implication of having to perform a sig gen "calibration" that is also a script file to run. Since the newly turned on sig gen function has never been activated it seem that it will need to be calibrated? My forte is hardware and not so much software and anyone that can provide a list of "things to do" with ALL the steps to take to successfully mod a C15 to a D15 will be most appreciated.. Thanks, Hank
-
...After the modded C15 to D15, what is the implication of having to perform a sig gen "calibration" that is also a script file to run. Since the newly turned on sig gen function has never been activated it seem that it will need to be calibrated?.
I'd go ahead and test it as-is, you may not need to do anything. When I transitioned, the "default" AWG calibration the unit came with was pretty much was spot on. Maybe they do calibrate them all regardless? Since all 4 models are HW identical it's easier, more cost effective and more flexible to have a single production flow that treats them all the same and assigns the identity at the very end. Maybe someone here has already compared multiple Cxx units to see if they have the same or different AWG cal?
-
I had ordered the DSO2D15 way before receiving the 2C15 and while awaiting the delivery, I did run the backup builder on the 2C15. I noticed in the files generated that even though this model did not sell as AWG capable, there WAS a sig gen backup file generated anyway. This leads me to believe that the PCB was indeed populated and this cal file was at the ready if the FW allowed it - I did not open the case to check - but, question is: would the sig gen backup file be written IF there was no active parts on the board? OR, are all files written and if no data resides, the data is all "zeros"? Since the 2D15 was coming, maybe today, I did not want to dick around with the soon to be returned 2C15 and keep the 2D15.... During my 2C15 testing, I did find that the freq measurement would read and display sub 10Hz square wave signals and I read further that freq data is also displayed in/when the DVM "window" is open. As my hobby uses are not so much high freq related where the Siglent 1202X-E may be a "better" choice, this ability to read/display the low freq stuff will be the deciding factor to keep the 2D15 and the Siglent not so much....
P.S. Your question - ""Maybe someone here has already compared multiple Cxx units to see if they have the same or different AWG cal?""
seems to have been answered by my 2C15 unit HAVING a sig gen cal backup file written? As I did not transition this scope as the 2D15 was coming, I did not check if my 2C15 gen cal data was valid.
For others to compare, MY 2C15 DID have a sig gen cal file that was backed up
-
Yeah, lots have the parts populated, just run the 2D15 conversion and find out.
If not working, then no parts, simply restore the model with DSObackup generated files.
-
David, Thanks for the shout and the great info you have stored in your "DRIVE" ICON BUTTON, ESP the "backup builder".... I do not know who the author is, but, my sincere thanks for the developer who donated the time and effort in the writing of these utilities. As the DSO2x1x series availability was scarce, I had ordered both the 2C and 2D models to ensure I got one anyway. Today my 2D15 arrived and let me tell you,,,, this sumbiatch performs WAY beyond expectations. My scope needs, or more correctly, wants, do not require an advanced scope like that of a Siglent SDS1202X-E and this Hantek fills the bill nicely. Some of my projects are in the sub 10 Hz range and while the Siglent may "go fast" really well, this scope "goes slow" in a very accurate way. The sig gen will output an accurate sub 10 Hz signal very well, (as shown in the pix), per the reported accuracy of the scope anyway, but this scope is a keeper for sure. A 1.001 Hz signal outputs correctly with frequency increments of .001 obtainable, which is surprising for this entry level scope. I have not yet ran into any "lock up" issues and the operation is solid; a little bit slow, but, it will serve my purposes well. Again, my THANKS to the author of the bevy of back up scripts.... Hank
-
Hi,
I modified my Hantek DSO2x1x oscilloscope for a linear power supply. A detailed description of this work in the article https://cxem.net/izmer/izmer211.php (https://cxem.net/izmer/izmer211.php). I, as the author, am ready to answer any questions through the forum or e-mail.
The result was a device with galvanic isolation and noises have become less.
In the screenshots, the original switching power supply is on the left, and the linear power supply is on the right.
Input to GND (by menu)
The crocodile clip is connected to the probe needle.
The crocodile clip is connected to the probe needle, BW mode.
-
I modified my Hantek DSO2x1x oscilloscope for a linear power supply....
...The result was a device with galvanic isolation and noises have become less.
Nicely put together upgrade!
The original SMPS has a small high frequency transformer and I would typically expect that would provide galvanic isolation. Is there something you know that suggests this isn't the case?
There's no denying you've managed to reduce the noise floor but I think I'd find it hard to justify going to all that effort and expense for such a small improvement on a low spec 'scope.
-
Is there something you know that suggests this isn't the case?
Yes, there are two problems with the original power supply. The oscilloscope chassis is connected to the "PE" conductor. For galvanic isolation, this conductor must be disconnected. But even after that, we will observe a potential of several tens of volts on the crocodile clip. This potential is provided by the Y-capacitors of the switching power supply.
There's no denying you've managed to reduce the noise floor but I think I'd find it hard to justify going to all that effort and expense for such a small improvement on a low spec 'scope.
My main goal was to galvanically isolate the oscilloscope. Noise reduction is an additional bonus from the work done.
-
Yes, there are two problems with the original power supply. The oscilloscope chassis is connected to the "PE" conductor. For galvanic isolation, this conductor must be disconnected. But even after that, we will observe a potential of several tens of volts on the crocodile clip. This potential is provided by the Y-capacitors of the switching power supply.
Oh, I didn't think about the ground connection too much. My scope was delivered from Hantek with a non-grounded power lead but I didn't put 2+2 together and realise that the chassis wasn't grounded! Maybe not the smartest idea.
-
Some additional OS sources & docs for CherryPi and MangoPi (Allwinner F1C200) in case they can be used:
https://www.mediafire.com/file/n0nq21a0ye9pz50/LC-CherryPi-F1C200S_EN.zip/file (https://www.mediafire.com/file/n0nq21a0ye9pz50/LC-CherryPi-F1C200S_EN.zip/file)
Contains docs, schematics, buildroot and more. (90MB - dates around May 2021)
I just had a quick look, nothing more.
Hopefully, someone can make use of the info.
Source: https://www.cnx-software.com/2022/02/03/more-allwinner-f1c200s-arm9-boards-mangopi-r3-and-cherrypi-f1c200s/ (https://www.cnx-software.com/2022/02/03/more-allwinner-f1c200s-arm9-boards-mangopi-r3-and-cherrypi-f1c200s/)
-
Just wondering if anyone here has played with Hantek's TO1112/C/D portable scope?
http://www.hantek.com/products/detail/18191 (http://www.hantek.com/products/detail/18191)
I found TO1112C internal photos at: 4pda.to /forum/index.php?showtopic=1018961&st=2900
Since the DSO2X1X series has an unused touchscreen, it seemed that maybe some OS modules from the TO1xxx series might be able to be ported over and played-with.
...Just a thought.
-
Had successfully updated mine DSO2D10 i think the factory calibration is saved in the system and it's not covered during the update the language setting i changed remains and i checked AWG it's still working properly
-
Hello from Sydney,
I bought 2C10 for 250 AUD this week just for hobby stuff. It arrived with FW 3205 and SW 1.0.3. The mods worked successfully for me to get backup, convert to 2D15 and update the font. Mine too came with the wave generator, it can do 25 Mhz for sine, 10 Mhz for square wave and 1 Mhz for ramp. Attaching a screenshot.
Auto set, wave gen and overall noise is not perfect and came with a single 100 Mhz probe but quite good for this price, hard to beat, and it seems quite hackable. Overall I am pretty happy with it.
Thanks a lot..
-
So I had a moment to find the SPI init in Ghidra.
It seems do be done entirely in Phoenix, there're no calls to any libanolis SPI function.
Although the code calls for 50MHz, the devicetree has spidev limited to 1MHz!
spi@1c06000 {
compatible = "allwinner,suniv-spi\0allwinner,sun8i-h3-spi";
reg = < 0x1c06000 0x1000 >;
interrupts = < 0x0b >;
clocks = < 0x03 0x13 0x03 0x13 >;
clock-names = "ahb\0mod";
resets = < 0x03 0x06 >;
status = "okay";
#address-cells = < 0x01 >;
#size-cells = < 0x00 >;
pinctrl-names = "default";
pinctrl-0 = < 0x05 >;
spi_board1@0 {
compatible = "spidev";
spi-max-frequency = < 1000000 >;
reg = < 0x00 >;
};
spi_board2@1 {
compatible = "tn652_fpga";
spi-max-frequency = < 1000000 >;
reg = < 0x01 >;
};
};
I wonder if it could be as easy as setting a faster speed in the devicetree?
-
My scope is in pieces until the new encoders arrive, so I can't test anything.
If anyone wants to try, I'm attaching modified DTBs increasing the max SPI speed for the FPGA.
Download the platform-tools package, install the drivers, paste the contents of the attached file inside.
Connect the scope in FEL mode before running the script or it won't work!
Run dtb_test, choose the dtb and check the results.
There's no risk, if it stops working properly just flash the original dtb.
-
[..】
I also found a hardware way to increase the processor core voltage without increasing the FPGA supply voltage.
Could you give some info on what you did?
-
You're fine with the stock voltage for 650-780MHz, the performance isn't that noticeable except for some gui areas, the plots perform much the same, I tried up to 1GHz and went down to safer voltage levels and 784MHz for this reason.
Really, modifying the board doesn't worth it.
-
Read the faq! You don't need all that ;)
Hola, me parece que eres de España y hablas español como yo, yo en realidad no hablo ingles y traduzco lo que dice este foro usando Google, me puedes resolver unas dudas? Hago lo que dice el primer comentario de este hilo o lo que me siguieres es que hay otro método ahora mismo mas eficiente, he leído casi todo el hilo y no entiendo como hacer lo del archivo en formato UNIX dentro del pendrive. Ya lo intenté pero no comprendo esa parte. Gracias
-
Hi, what are you trying to do?
You don't need to make any hacky steps, there're lots of mods for almost anything, check the FAQ in my signature!
If still having questions, just ask!
Anyways, the difference between Windows and Unix text files lies in how a new line is made.
You can use Notepad++ (https://notepad-plus-plus.org) in Windows, open the text file, navigate to:
Edit->EOL Conversion->Windows/Unix
And save the changes.
Hola! Que es lo que quieres hacer? No necesitas hacer pasos complicados, hay muchos mods para realizas todo tipo de cosas.
Mira el FAQ en mi firma, si todavia te quedan dudas, pregunta!
En cualquier caso, la diferencia entre archivos de texto en formato Windows y Unix radica en el final de linea.
En Windows puedes usar Notepad++ (https://notepad-plus-plus.org), abrir el archivo que quieres convertir, navegar a:
Editar->Conversión fin de línea->Windows/Unix
Y guardar los cambios.
-
Hi, what are you trying to do?
You don't need to make any hacky steps, there're lots of mods for almost anything, check the FAQ in my signature!
If still having questions, just ask!
Anyways, the difference between Windows and Unix text files lies in how a new line is made.
You can use Notepad++ (https://notepad-plus-plus.org) in Windows, open the text file, navigate to:
Edit->EOL Conversion->Windows/Unix
And save the changes.
Hola! Que es lo que quieres hacer? No necesitas hacer pasos complicados, hay muchos mods para realizas todo tipo de cosas.
Mira el FAQ en mi firma, si todavia te quedan dudas, pregunta!
En cualquier caso, la diferencia entre archivos de texto en formato Windows y Unix radica en el final de linea.
En Windows puedes usar Notepad++ (https://notepad-plus-plus.org), abrir el archivo que quieres convertir, navegar a:
Editar->Conversión fin de línea->Windows/Unix
Y guardar los cambios.
Hola, gracias por responder tan rápido, yo tengo un DSO2D10 y deseo que sea un DSO2D15, he seguido lo que dice el este hilo en el primer comentario pero estoy atorado en 2 cosas principalmente al intentar el procedimiento: La primera es como crear un archivo llamado "do_other_update" sin extensión (.txt o alguna otra) y la siguiente es lo de hacer que este archivo esté con formato Unix (en lo cual creo que ya te entendí lo que me dijiste en tu respuesta anterior) ya que llevo muchos meses intentando el hack para tener 150Mhz como en el 2D15. Te pongo unas imágenes y así tal vez me puedes indicar que estoy haciendo mal al crear ese archivo. Muchas gracias.
-
Lee detenidamente lo que te he puesto, e insisto en que revises el FAQ aquí:
https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3559217/#msg3559217 (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3559217/#msg3559217)
Tienes paquetes automatizados para hacer todo eso y más.
-
Lee detenidamente lo que te he puesto, e insisto en que revises el FAQ aquí:
https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3559217/#msg3559217 (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3559217/#msg3559217)
Tienes paquetes automatizados para hacer todo eso y más.
Gracias, eso te iba a preguntar también, me da la impresión que haz desarrollado programas y herramientas que dejan ya obsoleto el procedimiento que yo estaba intentando, correcto? de ser así mejor haré tu tutorial. Veo ahí en una imagen que incluso tu investigación ha llegado al punto que hasta hiciste correr Doom en el osciloscopio. Entonces tu tutorial son todo ventajas por que tiene maneras de hacer backups y restablecer desde esos mismos backups, vaya eso es increible!
-
Si, antes de modificar nada haz backup con dsoflash y backup builder.
Luego simplemente instala dso2d15 conversion.
-
Si, antes de modificar nada haz backup con dsoflash y backup builder.
Luego simplemente instala dso2d15 conversion.
Muchas Gracias David, lo haré teniendo cuidado de respaldar como dices.
-
Si, antes de modificar nada haz backup con dsoflash y backup builder.
Luego simplemente instala dso2d15 conversion.
Hola muchas gracias, me fue un poco difícil después del DSOflash caer en cuenta que el Backup Builder y DSO2d15 Conversion se hacían desde un pendrive puesto en el mismo osciloscopio, pensaba que era en modo FEL como tenia que aplicarlos, pero ya pude y mi 2D10 se ha convertido en un 2D15 y tengo ambos backups en mi nube, muchas gracias por la ayuda que me haz dado. :-+
-
Does anyone know if this hack really works with the newest firmware? (2023-7-28)
I tried to do it myself but it doesn't really seem to work. All that happens is that it just updates normally.
Maybe I just did it wrong?
Also, it turns out my DSO2C10 has all the components populated for the AWG function.
-
Read the FAQ in my signature.
-
Thanks guys, i follow your procedure and my DCO2C have wave generator now. Thanks!!!!(http://)
-
Read the FAQ in my signature.
Thanks! After a while, I gained the courage to risk bricking my scope and turn my DSO2C10 into a DSO2D15. It worked without any problems on the first try! I first thought that I had to do a whole lot of shenanigans to hack it up to the DSO2D15, but after thoroughly reading your FAQ, I realized all I really had to do was make a backup, which was easy, and update it with the automatic updater!
-
So in your DSO2C10 the AWG circuits were populated? Have you purchased this recently?
If I purchase a DSO2C10 now what is the chance that it is not populated for AWG?
-
I have not seen anyone report the parts were missing reciently. Seems consistently the same production design on the inside.
Though it would be good to get some updated photos inside of a newer model, to see if there have been any significant hardware revisions.
-
My DSO2C10 I bought a year and a quarter ago from amazon. But looking online, it looks like not much has changed.
I also would think it would be cheaper to keep manufacturing one scope for 4 different types of scopes instead of 2 different scopes, one for one with AWG, and one with no AWG components. Keep the manufacturing process simple.
However, it also looks like some people have gotten scopes without the populated components for AWG, so not a 100% guarantee.
But now, I wouldn't quite recommend buying the Hatek, especially since the new Rigol DHO800 is only $100 more. It may not have AWG, but it's 12bit and you can probably hack it up to the better models as well.
With my experience, the Hantek is not very good. It's not very responsive to controls, but then again it costs less than $200 USD and you can hack it up to a DSO2C15 without the AWG if it doesn't have the AWG components.
-
by: BlownUpCapacitor \With my experience, the Hantek is not very good. It's not very responsive to controls,\\
The only problem is the cheap components, I installed decent encoders and all the problems disappeared https://www.arrow.com/en/products/pec12r-4220f-s0024/bourns (https://www.arrow.com/en/products/pec12r-4220f-s0024/bourns)
-
hello of the whole thread I read, but nowhere did I come across whether anyone tried to increase the AWG frequency set ?, generator, thank you for the answer
edit, does a man get a reply here? Or is the forum dead?
im sory im translate gooogle
-
I received my DSO2D10 (considering shipping to Brazil, it was the cheapest) a few days ago and was able to update to 2D15 without any problems. I also applied the mods for the conversion to png and small fonts. Thank you very much DavidAlfa and everyone who contributed to the improvements.
-
....I also would think it would be cheaper to keep manufacturing one scope for 4 different types of scopes instead of 2 different scopes, one for one with AWG, and one with no AWG components. Keep the manufacturing process simple.
Yes, it's not just the manufacturing cost. It can also be a huge benefit to inventory management. Rather than having to guess what's going to sell they can have a single scope on the shelf and assign its model at the last moment with a small file system change and the appropriate sticker on the front panel.
-
Greetings everyone!
Did a new year refresh on my DSO2C10 that I previously converted to a 2D15.
- Flashed 3205_B205 (file (https://drive.google.com/file/d/17OaAF9Q0a5JJPQIf9RJ-Dsh28hFiOTRn)from the FAQ (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3559217/#msg3559217))
- Flashed 2023.08.31 (file (https://drive.google.com/file/d/14v9AkTTr-HDbLTVIDO6USTtUriHS2J5a) also from the FAQ)
All went OK, no issues, hack is still there.
Additionally I performed the overclocking.
Where/how do we change the Vcore settings? The overclocking script (https://drive.google.com/drive/folders/18mhrIfJovlVe6pkEUpoOIDCQ6hmC-BEh) from the FAQ only offers PLL changes.
Here are the settings I used, a moderate overclock because I couldn't touch Vcore and also didn't want to have to add heatsinks etc.:
CPU_OC_PLL_N=28
CPU_OC_PLL_K=0
CPU_OC_PLL_M=0
MEM_OC_PLL_N=14
MEM_OC_PLL_K=0
MEM_OC_PLL_M=0
I initially changed the CPU to 720 MHz - it was stable (I turned FFT on to strain the CPU a bit), but I wanted to be extra safe, so I dialed it back one notch.
This changes the CPU to 696 MHz. I then overclocked the RAM to 360 MHz and did not try to go further.
I might have been able to go higher, but did not see the need to. This already makes the UI much more responsive! :-+
Hope this helps someone by providing an additional data point. Always test before installing the overclocking.
-
You can't in software, only by modifying the Vcore regulator in the board.
No need todo so, I went to 1GHz at 1.35V (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3597744/?topicseen#msg3597744) with no real performance gain in the scope software, it's the FPGA-CPU interface causing the bottleneck (And terrible software design).
Don't worry about going too high on cpu speed, system will simply crash, you can always recover following the instructions.
The CPU was barely warm to the touch even at 1GHz, maybe 50°C.
Ram has very little room for OC, mine freezes when cold, so I simply leave it at default speed.
-
@davidAlfa
Yes, just create the file in any way you want, the contents don't matter!
Made some modifications, as I realised you couldn't set an older date if for any reason you wanted so.
Now it also tracks the timestamp of the date file, updating the system date when it changes.
Made UPK packages and update FAQ.
Hi David,
As I'm waiting for a RTC module to hack the DSO with a "permanent" time-stamp, so may I have a copy of your UPK file for update the actual with a USB stick ? I want to start and learning trying this "volatile" way.
P.S. I searched for it but non found on FAQ, perhaps made useless by the RCT h/w modification.
Thanks
-
Yeah it existed for a short time, but completely replaced by the RTC mod.
The original mod was deleted, I don't have it anymore.
-
@morgan_flint
@david_alfa
Ok David I understand, may be morgan_flint (if still present on this forum) or someone else may have a copy of this.
Thanks again
-
@carlonb
I had this in my archive (attached file "Date daemon.zip"), but I'm unsure if it was the last version.
Another possibility to set the clock is via serial console, which can be accessed through the serial port (hardware mod required) or through the rear USB port (with the corresponding mod from DavidAlfa's drive (https://drive.google.com/drive/folders/17_FjyXQ8vsaD5K8ToU_6ASipgmaCOvNJ)). Regarding the first option, as DavidAlfa, I installed a serial to Bluetooth module, so now I can access it wirelessly.
Attached are the photos of my mods for the RTC and serial to BT (it's not very easy to see it in the photo, but the BT module is separated from the metallic sheet to avoid the antenna being affected by it)
-
@morgan_flint,
Thankyou very much, downloaded the "date_daemon" for usb_stick volatile method and worked fine.
I'm sorry but I did not saw the file attached in the previous post.
May be useful to have this in the FAQ of DavidAlfa helping the DSO Hantek users to have the correct date stamp also if they have not skills to do the HW mod with RTC module.
Ok, now as soon I will receive the RTC module I will do the HW mod that is the only one logic solution to the lack of date stamp updating.
Thanks again
Carlo
-
OK, I added it.
Doesn't make much sense since, as you said, the only one logic solution is to use a RTC, and the reason why it was removed when the RTC mod was done.
-
OK, I added it.
Doesn't make much sense since, as you said, the only one logic solution is to use a RTC, and the reason why it was removed when the RTC mod was done.
Tankyou DavidAlfa, but all you have done (in this case with the idea of morgan_flint) it's correct to be archived.
One more reason if some user can't do some HW mods.
Ciao
Carlo
-
I have successfully installed the RTC mod.
I decided to mount the DS1307 module like this:
[attachimg=1]
3D printer mount: https://www.thingiverse.com/thing:6428771 (https://www.thingiverse.com/thing:6428771)
If I had to do it again I would:
- Put a hole on the base plate of the mount and screw it from behind. I used double sided adhesive tape instead but it is not as good as a good old screw.
- Mount the module horizontally instead of vertically. The module as showed in the picture barely fits. It does work, but the clearances with the oscilloscope PCB and the frame are not as big as I would like.
I join the few others who complained about Hantek cheaping out on an RTC. What are they thinking? It's another situation of people designing test equipment and not using them. If they were using them the slightest bit, they would understand that it doesn't make sense to not have an RTC...
-
Hi,
I have already read all the posts in this thread and I must admit all your work.
But what I have not found and it will be great addon it's, if it will be possible to save screenshot with specific name.
Keyboard is already there, so the question is if it's available or is only somewhere within this binary blob from Hantek.
-
Everything, including the keyboard, is embedded in the Hantek binary.
What you're asking can be only made by Hantek.
-
I am trying to open ico files from your themes but i can't. What software should I use ? I am using Gimp in Linux but there is always an error opening the file.
Thanks
-
Everything, including the keyboard, is embedded in the Hantek binary.
What you're asking can be only made by Hantek.
Thank you.
-
I am trying to open ico files from your themes but i can't. What software should I use ? I am using Gimp in Linux but there is always an error opening the file.
Thanks
See here (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg3606590/#msg3606590).
-
I am trying to open ico files from your themes but i can't. What software should I use ? I am using Gimp in Linux but there is always an error opening the file.
Thanks
See here (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg3606590/#msg3606590).
I'm sorry David, I am really new to scopes and especially to Hantek, but I have seen this file, but I cannot open these files.
I am Linux user and I've tried GIMP in linux and also in windows but always get "Microsoft Windows icon plug-in could not open image".
And even when I open the file it's blured and I cannot see what's there on the image.
Do I need to install some extra plugin or something ?
I've Debian Testing and Windows 10 in virtual.
-
Did you read the pdf file in that post?
-
Is there a software to measure the frequency response via SCPI with the Hantek (like bode plot)?
I've played around a bit and think it's possible. You can determine the frequency/amplitude of the AWG via SCPI and read out the measurements of the device.
For example, here is some demo data that I measured via SCPI through the 6.5MHz BSF of the RF demo kit. Looks useful, doesn't it? VPP Ch1 is "Input", Ch2 the "Output".
Freq: 5952kHz
VPP Ch1: 0.648V
VPP Ch2: 0.488V
Phase: 180°
Freq: 6173kHz
VPP Ch1: 0.636V
VPP Ch2: 0.216V
Phase: 236°
Freq: 6494kHz
VPP Ch1: 0.628V
VPP Ch2: 0.02V
Phase: 0°
Freq: 6757kHz
VPP Ch1: 0.64V
VPP Ch2: 0.22V
Phase: 326°
Freq: 7042kHz
VPP Ch1: 0.64V
VPP Ch2: 0.548V
Phase: 30°
Am I making a mistake or is it relatively easy to get the data?
Is there already a ready-made solution for Hantek-SCPI bode plot?
I actually have no idea about the matter. :palm:
-
I'll answer my own question.
Yes, it works somehow.
I'm still tinkering to get more reliable measurements, but it's better than doing it "by hand".
It's slow, but at least you get some result.
-
Did you read the pdf file in that post?
Hi David.
Yes I did, but somehow I missed the part where it says to open the file in HEX editor and copy width and height:-)
Now all is ok, thank you very much.
-
How about doing a binary recursive analysis?
Ie. measure at 1MHz, at 9MHz, at 5MHz (left, right, center);
at 3 MHz and 7 MHz (new middle points);
at 2,4,6,8 MHz (next new middle points),
at 1.5, 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5 MHz (if needed, see below),
etc. -- then you get a successively finer picture, and if you detect a flat curve over 5 (numerically) consecutive measurement points you could also skip the ones inbetween.
-
How about doing a binary recursive analysis?
Ie. measure at 1MHz, at 9MHz, at 5MHz (left, right, center);
at 3 MHz and 7 MHz (new middle points);
at 2,4,6,8 MHz (next new middle points),
at 1.5, 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5 MHz (if needed, see below),
etc. -- then you get a successively finer picture, and if you detect a flat curve over 5 (numerically) consecutive measurement points you could also skip the ones inbetween.
I assume this refers to my question?
The problem is rather that the measurement takes quite a long time for such methods.
It doesn't fluctuate much and with more measuring points you also get a more detailed picture.
Averaging also means that you can miss peaks, especially if you have few measuring points.
Btw. the topic is now in the other thread (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg5338418/#msg5338418), actually it doesn't belong here (my mistake).
-
Hi DavidAlfa,
do you still have the Linux Kernel Sources? I can't find them in your Google Drive.
Would you try building a kernel that has the perf infrastructure? I'm pretty certain I can patch the software to use less CPU, but that would be easier with good measurement tools.
Thanks!
-
Still there! Drive / Hacking / Sources.
I have no idea, where's that option? In menuconfig?
Perf_events are enabled. Maybe only the perf binary is needed?
I can build perf in https://github.com/aodzip/buildroot-tiny200
But not in Hantek sources. It's in linux/tools/perf and can be compiled manually with make tools/perf, but my glibc version isn't matching.
Sorry, I can't spend more time in this.
-
Hi, I have made a new Power Supply PCB board for the oscilloscope that incorporates a 12 volt output to put the fan that Hantek should have originally placed. I will to share the gerber file with you here, i use JLCPCB, but you can use PCBWAY or any other PCB manufacturing service.
https://youtu.be/cv0wEgZCk1w (https://youtu.be/cv0wEgZCk1w)
[attach=1][attach=2]
Fan 12v: https://www.amazon.com/-/es/dp/B07FRPF8LY?psc=1&ref=ppx_yo2ov_dt_b_product_details (https://www.amazon.com/-/es/dp/B07FRPF8LY?psc=1&ref=ppx_yo2ov_dt_b_product_details)
Module HLK-PM12: https://www.amazon.com/-/es/dp/B0B63WP3LF?ref=ppx_yo2ov_dt_b_product_details&th=1 (https://www.amazon.com/-/es/dp/B0B63WP3LF?ref=ppx_yo2ov_dt_b_product_details&th=1)
Heatsink 20x20x16mm Black Color: https://www.amazon.com/-/es/gp/product/B07ZC65NJL/ref=ppx_yo_dt_b_asin_title_o07_s01?ie=UTF8&th=1&language=en_US (https://www.amazon.com/-/es/gp/product/B07ZC65NJL/ref=ppx_yo_dt_b_asin_title_o07_s01?ie=UTF8&th=1&language=en_US)
Note: I am not responsible if you damage your own oscilloscope by attempting to make this modification without taking proper precautions, make notes, take pictures and check and double check before proceeding. Make this modification only when your warranty period has expired. Qingdao Hantek Electronic Co., Ltd. is not affected in any way by you modifying your own device since you paid for it. I provide the PCB design for free to the community and I do not profit in any way from doing this.
-
Hi
Do you have problems with overheating?
Mine hardly gets warm and I like the fact that it has no fan and is quiet.
And I haven't had a single crash since the last SW/FW update.
-
Hi, on very hot days I notice that it gets a little slow and I better wait to use it at night, I don't have air conditioning, the fan is very quiet, yesterday it was on all day and it never got hot or slow, but yes You don't need to make this modification, it's fine too.
-
Doesn't make any sense, there's no cpu thermal throttling, it always runs at the same speed, most probably you're running different time scales.
-
Puedo preguntar para quien es dirigida esa opinión?
-
More photos of my upgrade.
-
Hi, I have made a new Power Supply PCB board for the oscilloscope...
Hi, jovan_quineas.
Are the schematic and components the same as those in the original power supply, or did you introduce other improvements (apart from the 12V output)?
AFAIK, there have been two versions of the power supply. I have the older one and some components, at least the main diodes, tend to run hot, so some people in this forum suggested changing them for better alternatives.
-
Hello, the truth is I don't know if there are more versions of the power supply pcb, at the moment in all the photos that I have seen of this oscilloscope I have seen that they are the same as mine, I don't have the diagram but I can do it and share it Since I dismantled mine and remade it to make this new one, I have photos and notes of the value of each component, I will get to the work of making the diagram.
I also took on the task of leaving each component in the same location and using the same screen printing.
-
Appart from some differences in the schematic (I'll try to find the posts), the first version had +-8V for the analog part, while the newest one is +-7V
-
Yes, there are at least 2 Versions. 8V and 7V. 7V is newer.
(https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/?action=dlattach;attach=1195740;image)
(https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/?action=dlattach;attach=2080535;image)
-
One of the differences is in the main rectifier; in the older version, D5 are two SMD diodes in parallel that tend to overheat (in fact, one of them in Aldo22's post is charred...), and in the newer version is a bigger through-hole device.
In the older version, there was additional filtering (L1-C7) in the +8V output (simplified schematic here (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg4085185/#msg4085185)), because the +5V output derived from there with a buck converter.
I remember somebody posted the schematic of the newer version, but I can't find the post. If I remember well, the +5V output comes from its own winding in the transformer (feedback to the primary from here), and +-7V has another center-tapered independent winding
The complete schematic for the older version is in the attached PDF I downloaded from another forum, but again I can't find the post (sorry for not giving credit to the author)
EDIT: I found the post (https://www.eevblog.com/forum/testgear/hantek-dso2xxx-schematics/msg4350379/#msg4350379) where the PSU schematic was posted
-
One of the differences is in the main rectifier; in the older version, D5 are two SMD diodes in parallel that tend to overheat (in fact, one of them in Aldo22's post is charred...)
I don't think the diode is charred.
I just linked the first photo of the 8V PSU that I found. He doesn't say anything about anything being charred.
https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3515614/#msg3515614 (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg3515614/#msg3515614)
The second photo (7V) is from my device.
-
Hello again, I didn't know there was such a version of the power supply, in any case my modification is for the first 8v version. since it's what mine had inside. Thanks for the diagram, I no longer need to go to the trouble of doing it.
-
...
I don't think the diode is charred.
I just linked the first photo of the 8V PSU that I found. He doesn't say anything about anything being charred.
...
Maybe it's just a bit overheated or just problem of light reflection in the photo...
Anyway, if you search D5 in the other thread (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/), you'll find some posts reporting problems with these diodes (for example, this one (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg4322731/?topicseen#msg4322731) or this one (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg4492357/#msg4492357)).
BTW, I found the posts with the PSU schematics; edited my previous post to include the link for the older version and here is the link (https://www.eevblog.com/forum/testgear/hantek-dso2xxx-schematics/msg4731224/#msg4731224) to the post with the schematic of the newer one (better design, in my opinion).
-
At my work I disassembled the Hantek DSO5202P that I have been using for almost 3 years and when I saw that its power supply did incorporate an output for a 12-volt fan, I decided to make a modification to the pcb of my DSO2D10 that I have at home. The Power Supply of this DSO5202P is a little larger but it seems to have fewer components, or perhaps not because the SMDs are soldered underneath since it is a single-sided pcb. This oscilloscope remains on 9 hours a day from Monday to Saturday. Whether it's hot or cold days, for 3 years it has worked well. I mean it has generated profits, I work in a company that only repairs macbooks and imacs. It is true that it is a little less noisy than the DSO2D10 but I like mine better. Of course there are better ones, like the Rigol 1054Z for example.
Sorry my bad english, i used Google Translator.
-
Hello,
I am a new owner of a DSO2C10 which, thanks to the great effort of DavidAlfa and many other people have selflessly dedicated many hours of their time, has easily become a DSO2D15.
The next thing I tried to do, but without any success, was to connect it to the PC.
There has been no way to get the USB recognized on any of the three computers I have tried it on. Neither with Win10 nor with Win7.
I have written to Hantek, but I have no confidence that they will respond.
So I'm trying all the solutions I can find on the forum and on the Hantek site, but so far no luck.
I changed the software version but that hasn't helped either. I followed the steps with Zadig 2.8 and it seems to recognize the device, even if it is as "unknown", but when I go on, it fails again, as if it was uninstalled.
I followed the steps with Zadig 2.8 and it seems to recognize the device, albeit as "unknown", but when I move on, it crashes again, as if uninstalling.
Has anyone else had this happen, any ideas on where to tackle the problem.
For reference, the software version is 1.03.00(230831.00); firmware 3205 and hardware 003.002.001.000.000.000.000.001 (000 before the "conversion").
Thank you all very much.
-
@Eula
Have you removed the USB stick on the front?
Have you tried PyVisa and/or Linux? https://pyvisa.readthedocs.io/en/latest/
-
Zadig can take a while to install on slow computers!
-
One of the differences is in the main rectifier; in the older version, D5 are two SMD diodes in parallel that tend to overheat (in fact, one of them in Aldo22's post is charred...), and in the newer version is a bigger through-hole device.
In the older version, there was additional filtering (L1-C7) in the +8V output (simplified schematic here (https://www.eevblog.com/forum/testgear/hacking-the-dso2x1x/msg4085185/#msg4085185)), because the +5V output derived from there with a buck converter.
I remember somebody posted the schematic of the newer version, but I can't find the post. If I remember well, the +5V output comes from its own winding in the transformer (feedback to the primary from here), and +-7V has another center-tapered independent winding
The complete schematic for the older version is in the attached PDF I downloaded from another forum, but again I can't find the post (sorry for not giving credit to the author)
EDIT: I found the post (https://www.eevblog.com/forum/testgear/hantek-dso2xxx-schematics/msg4350379/#msg4350379) where the PSU schematic was posted
In the diagram that you put C8, C10, C5, C4 and C2 do not have their values specified, which makes me think and doubt that the rest is correct, fortunately I still have my notes from when I dismantled my power source so I better do I myself the diagram based on it. Probably the person who made that diagram made the measurements with the components still soldered on the PCB, which is obviously not reliable, while I dismantled component by component to modify a new PCB.
-
@Eula
Have you removed the USB stick on the front?
Have you tried PyVisa and/or Linux? https://pyvisa.readthedocs.io/en/latest/
Thanks for the quick responses, but I comment:
@Aldo22: Thanks for the suggestions. Yes, there is nothing connected on the front USB, I have also tried on Linux Mint, without success. I'm going to try PyVisa, see if there is more luck.
I will continue to investigate and if I succeed, I will leave the results here.
Regards
-
Zadig can take a while to install on slow computers!
Thanks for the quick responses, but I comment:
@DavidAlfa: Same to you, thanks a lot for your great work. And yes, Zadig is installed correctly on the computer (both versions, 2.7 and 2.8). In fact, it seems that the DSO USB is recognized, but when trying to follow the steps it stops recognizing it again.
It is very frustrating.... because I have tried it on every computer I can get my hands on.....
I will continue to investigate and if I succeed, I will leave the results here.
Regards
-
What are you trying to do?
Zadig and fastboot drivers are only for FEL/recovery modes!
Read the FAQ Quick Glance section, there's a working driver for Win11 from R&S.
-
Thanks for the reply David.
The only thing I want is to be able to connect the DSO to the computer to manage it from there, without further pretensions, but the problem is that no computer recognizes it.
Nor does it work with any controller (Zebra, IO, etc).
As a curious thing, I have connected it through an old USB hub and then it identifies it as a measuring instrument, but it does not install or configure it, the error is the same. It is not "usable".
I will take a look at what you propose.
Thank you very much!!!
Edit:
Sorry David,
I didn't remember doing it, but my first step, after a lot of searching and reading the thread, to try to solve the problem was to go through that section and apply the patch that was supposed to fix it (I guess you mean this entry: ""If USB is not working properly (Drive not being recognized until pressing update), apply Hantek's USB fix."), but I was unsuccessful. |O
I'm still trying to solve the problem, because as expected, Hantek has not responded and the seller just asked me for a video and says he will deal with it with his technical support. :-DD
This is my first DSO and I would like to be able to see it on the PC monitor .... my old oscilloscope is a Hameg 203 which I am particularly fond of, but it falls short, but it has never given me any problems, something that can not be said of this one.... |O
-
I have also tried on Linux Mint, without success.
But what exactly did you try?
If you simply connect the Hantek to the Linux-PC via USB and enter "lsusb -v" in the Linux shell, don't you get something like this (among other things)?
Bus 001 Device 005: ID 049f:505e Compaq Computer Corp. DSO2D15
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x049f Compaq Computer Corp.
idProduct 0x505e
bcdDevice 5.02
iManufacturer 1 undefined
iProduct 2 DSO2D15
iSerial 3 CN2328029051205
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0027
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 3 Test and Measurement
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 2
(I don't know exactly why it identifies as Vendor "Compaq")
-
Good morning.
Thank you all very much for the help. Finally the problem was in the USB cable I was testing with. It works fine with my printer, but for some reason, it doesn't work with the DSO.
Using the original Hantek cable I was able to connect correctly. :phew:
I apologize for any inconvenience this may have caused. :-+
By the way, Aliexpress seller support and Hantek support have contacted me and suggested to try the original cable. :-/O :-+
Let's say that this is an "X-file".... :-//
Now what I have to try to solve is the response of channel 2 on square wave signals....
No matter which probe I try, it always shows the same.
Here are some screenshots at 1kHz and 20kHz.
Regards
-
No idea.
Did you compensate the probe?
What if you change the coupling from AC to DC?
What happens if you change the probe attenuation (1x -> 10x)?
-
No idea.
Did you compensate the probe?
Yes, it was the first thing I did. This channel does the same thing with any probe, even connecting the crocodile cable that Hantek delivers with the device. That's why I think it's a channel 2 problem.
What happens if you change the coupling from AC to DC?
Nothing changes, the signal shows the same
What happens if you change the probe attenuation (1x -> 10x)?
I have to adjust it again so that the signal shape is correct which is corrected, but when you go back to x1, you have to adjust again. It happens with any probe, with the cable, not needing calibration you can see the error perfectly, while on channel 1 it looks fine.
It is unquestionable that the problem is in channel 2 and has nothing to do with the probe.
Thanks for your help!
-
Did you compensate the probe?
Doesn't make sense when any probe works nice in CH1. Something seems wrong in CH2.
Try in different ranges, around 20mV/div (x1) or 200mV/div (x10) you'll hear the relay clicking.
Something might be wrong in the analog frontend, a component missing, or CX1 badly adjusted.
https://github.com/pecostm32/Hantek_DSO2000/blob/main/Schematics/Mainboard/Analog_Input_2.png
-
Doesn't make sense when any probe works nice in CH1. Something seems wrong in CH2.
All my questions don't really make sense. That's why I said I have no idea. ;)
I just thought he should check again before the diagnosis is that something is really broken on Ch2 of his new scope.
I mean after the experience with the USB cable... ;D
-
After reading the FAQ I am still unsure exactly what I will need to do to change my dso2d10 to a dso2d15 when it arrives next week. Other than the ASCII readout change , do I simply type in the command from the PC software or follow the instructions where I make a file and manually type it's contents, or am I missing something?
edit: @davealpha, I watch David on eevblog YouTube so much I read your posts in a high pitched Australian accent!
-
After reading the FAQ I am still unsure exactly what I will need to do to change my dso2d10 to a dso2d15 when it arrives next week.
This is the easiest way to do it (by DavidAlfa):
https://drive.google.com/drive/folders/1AbaHXFGgBeKaUuzLmC5P5jtotScjxTgf
Simply copy the .upk file to a USB stick and select it in "Utility -> Update" on the scope.
Make a backup beforehand.
-
edit: @davealpha, I watch David on eevblog YouTube so much I read your posts in a high pitched Australian accent!
We're different Daves! :D
Run backup builder first, then 2d15 conversion mod.
-
Hello Aldo,
Not at all, all questions make sense and are appreciated, sometimes the problem is an elephant in front of our noses but we are not able to see it.
And as you rightly say, more after the USB cable (by the way, I have tried with other cables, out of curiosity, and it gave me the same problem with 50% of them. could it be a shielding conductor problem, who knows....) ;D
-
David, Thank you very much for your reply,
Yes, that's my guess, that there is something wrong adjusted inside the oscilloscope.
The seller has "passed me on" to Hantek's technical service. I have sent them an email before touching anything internal, in case they give me the possibility to return it in exchange for another one.
I will look at that schematic, in case I finally have to do it myself.
Best regards
Edit:
David, I think you have "hit the nail on the head" again.
Although the electrical noise is very high and hardly visible at 20mV/div, the problem disappears when you change the range to 200mV/div and reappears at 500mV/div and above.
This is something I will be able to tell the Hantek technicians when they respond (if they do).
Thank you very much again "maestro" :-+ :clap:
-
edit: @davealpha, I watch David on eevblog YouTube so much I read your posts in a high pitched Australian accent!
We're different Daves! :D
Run backup builder first, then 2d15 conversion mod.
Lol, yes I know you are not him, but even that reply was in his voice to me! I have read through both fnirsi041d and now hantek 2d10 threads (yes, hundreds of posts!) and have watched your rise from enthusiast beginning to beaten down but still so informative and helpful and was afraid to make a poor first impression.
Thank you for all the effort you have put in here.
-
Has anyone tried this? Any meaningfull difference? Thank you
My scope is in pieces until the new encoders arrive, so I can't test anything.
If anyone wants to try, I'm attaching modified DTBs increasing the max SPI speed for the FPGA.
Download the platform-tools package, install the drivers, paste the contents of the attached file inside.
Connect the scope in FEL mode before running the script or it won't work!
Run dtb_test, choose the dtb and check the results.
There's no risk, if it stops working properly just flash the original dtb.
-
Of course I tried. No difference.
-
Did you compensate the probe?
Doesn't make sense when any probe works nice in CH1. Something seems wrong in CH2.
Try in different ranges, around 20mV/div (x1) or 200mV/div (x10) you'll hear the relay clicking.
Something might be wrong in the analog frontend, a component missing, or CX1 badly asjusted.
https://github.com/pecostm32/Hantek_DSO2000/blob/main/Schematics/Mainboard/Analog_Input_2.png
Thank you very much David for putting me "on track".
I have finally decided to adjust the channel myself, as Hantek has not responded to me in two days and for such a simple adjustment I doubt that they will offer me a change.
In order to adjust the variable capacitor Cx1, I had to file a few tenths of a screwdriver that comes with the oscilloscope because I didn't have any non-conductive material at hand, which would have been more suitable.
I put here some pictures in case someone who has a similar problem might find it helpful.
The result, as you can see in the screenshots, has been quite satisfactory compared to where it came from.
Best regards!
P.D.: It is not necessary to remove the shielding, but I was intrigued by the hiding place of the relay that is being listened to..... in fact, for the adjustment, this protection must not be removed!
-
more photos of my mod.
-
Since I am flush with oscilloscopes of all kinds I'm asking this question for a friend.
He is dead set on getting one of these and just sent me an email wanting to know what I thought. Well, having zero experience with these I can't really give him much advice. The specs on the DSO2D15 look pretty good and he says he's loves the look of it and he can currently get it for $279 shipped. I told him "looks" are not an important factor in choosing a scope, but I digress.
So, my questions here goes out to the experienced (David..)
Have Hantek addressed any of the issues? If he buy's this thing will he get a useful, working interment right out of the box? Or should he run in the direction of Siglent as fast as he can?
-
@BillyO:
That is far too expensive and the DS02D15 is not worth it. The DS02C10 is (mostly) technically the same, except for the probe.
If you want a DS02C10, you shouldn't pay more than ~$160 for it in my opinion.
E.g. here https://www.aliexpress.com/item/1005006350502458.html (https://www.aliexpress.com/item/1005006350502458.html)
(I don't know this store, I just want to show that you can get one for this price. I paid $130 for mine).
If you want a really cheap scope that can do quite a lot and of course has some weak points (according to the price), you can buy it if you can get it cheap.
I'm a little hesitant to "recommend" it, It's all about the price.
Of course Rigol or Siglent is much better, but I'm still happy with my Hantek, because I like cheap stuff and it's good enough for me. ;)
Have Hantek addressed any of the issues?
There are still FW updates. The last one (unofficial) in February:
https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg5366381/#msg5366381 (https://www.eevblog.com/forum/testgear/new-hantek-dso2x1x-models/msg5366381/#msg5366381)
If he buy's this thing will he get a useful, working interment right out of the box?
As a non-native speaker, I'm not sure what an "interment" is. The translator says "funeral". ;)
Do you mean instrument?
Yes, it works out of the box. However, a backup is recommended (follow DavidAlfa's FAQ)
-
Only the dso2c10 (Hacked later) for $150-170 does worth it.
For $280 no way! Spend $100 more and get a rigol DHO800, pretty new so still some bugs but nowhere close as Hantek.
-
The specs on the DSO2D15 look pretty good and he says he's loves the look of it and he can currently get it for $279 shipped.
I would like to express a general view on this.
The problem with the Hantek DSO2000 is that prices vary greatly.
Firstly, it is always the same hardware.
From the DSO2C10 to the DSO2D15, it's always the same.
What's different is the probe, whether the signal generator is unlocked and the label.
It's basically a, say, $150 scope.
And for that it's brilliant!
But if you pay $250 or even $400 for it and expect it to be a "Riglent" for less money, you can only be disappointed.
It's still a $150 scope.
It's certainly not a professional tool and even the ambitious amateur will want something better.
But for $150 it offers an incredible amount of features and as your first scope, it will keep you busy for quite a while and introduce you to almost all aspects of a modern DSO.
Compared to a Fnirsi 1014D, for example, I would even call it a serious tool.
You may not even want more for quite some time.
Just don't pay more than +-$160 and you'll be fine.
-
Thanks for your input guys.
He's not the kind of guy that will do the hack himself and I don't want to do it either as I don't have the time or inclination. I'm going to loan him a scope until he gets his income tax return payment then he's going to buy a Siglent SDS804. Quite a lot more, but it will work out better in the long run and the "hack" for it, if he wants to do it, is just entering some license keys.
-
He's not the kind of guy that will do the hack himself and I don't want to do it either as I don't have the time or inclination. I'm going to loan him a scope until he gets his income tax return payment then he's going to buy a Siglent SDS804. Quite a lot more, but it will work out better in the long run and the "hack" for it, if he wants to do it, is just entering some license keys.
Don't let the word "hack" put you off.
All you have to do is copy a file from DavidAlfa to the USB stick and then select this file as a system update in Hantek.
This is done in 2 minutes and is absolutely painless.
But well, the Siglent is certainly better if the price is right for you.
Good luck!
-
Thanks for your input guys.
He's not the kind of guy that will do the hack himself and I don't want to do it either as I don't have the time or inclination. I'm going to loan him a scope until he gets his income tax return payment then he's going to buy a Siglent SDS804. Quite a lot more, but it will work out better in the long run and the "hack" for it, if he wants to do it, is just entering some license keys.
Strange that you're asking this question in the "Hacking the DSO2X1X" thread for a friend that is "not the kind of guy that will do the hack himself and I don't want to do it either".
Anyway, for $150 and 10 minutes of your time you can end up with a piece of test equipment that offers a great value for money proposition if your expectations are set accordingly. Once you account for the lack of support, shitty SW, noise issues, poor triggering, memory depth limitations, measurement limitations, barely functioning protocol decoding etc it's still a reasonably functional and useful piece of test equipment for occasional hobby use. Mine has served me well for the 2 years I've owned it and has adequately handled just about everything I've thrown at it.
I wouldn't touch it at $279 however. In that case he'd be better putting his money towards something else.
-
Strange that you're asking this question in the "Hacking the DSO2X1X" thread for a friend that is "not the kind of guy that will do the hack himself and I don't want to do it either".
Don't be silly. If he or I don't want to hack something that is up to us. However, this is the perfect place to ask if the thing is serviceable out of the box because the people here have the most technical experience with it.
Once you account for the lack of support, shitty SW, noise issues, poor triggering, memory depth limitations, measurement limitations, barely functioning protocol decoding
And this would seem to indicate it is not really a very serviceable item.
He's a beginner, at least to the scope world, so having something that just works properly is the way to go. He can use my SDS1104X-E for a few weeks and he'll already have the UI down pat when his scope arrives.
-
Once you account for the lack of support, shitty SW, noise issues, poor triggering, memory depth limitations, measurement limitations, barely functioning protocol decoding
I don't quite agree with this rather unspecific list, but what I have never understood are the "noise issues".
Could it be that this affects older versions only?
I don't see any excessive noise here.
On the contrary, I am very surprised that it can still measure a frequency in the 500µVpp range (half a millivolt, 200µVrms ). That is very good for this price imo.
What do I have to do to see excessive "noise issues"?
-
still confused about the overclock, do i take the number 30 in the sh file and lower it till it crashes around 16? "/usr/bin/oc_manager 30 &" or do I modify the file with no suffix with separate cpu and mem sections?
-
still confused about the overclock, do i take the number 30 in the sh file and lower it till it crashes around 16? "/usr/bin/oc_manager 30 &" or do I modify the file with no suffix with separate cpu and mem sections?
You don't need to change the .sh file, just make the changes in the oc_manager file.
Mine looks like this (relevant part):
# ------ USER ADJUSTABLE ------
# This example: (24*(28+1)*(0+1))/(0+1) = 648MHz
CPU_OC_PLL_N=28
CPU_OC_PLL_K=0
CPU_OC_PLL_M=0
# This example: (24*(13+1)*(0+1))/(0+1) = 336MHz (168MHz DDR)
MEM_OC_PLL_N=13
MEM_OC_PLL_K=0
MEM_OC_PLL_M=0
-
Is a smaller number faster, Dave mentions 16 as the sweet spot.
EDIT: uploaded the latest firmware to the shared folder.
-
Is a smaller number faster, Dave mentions 16 as the sweet spot.
No, it's all in the info.txt
The system will execute the file overclock/oc_manager from the usb drive. If there's no drive, overclock won't be applied.
Now you can try rising the CPU_OC_PLL_N multiplier in that file, rebooting each time to apply the new settings.
When your system becomes unstable, lower the multiplier and try again.
After finding the stable CPU overclock, proceed with the memory overclock, increasing MEM_OC_PLL_N value.
This value have little adjustment, the limit is usually near 16.
I left MEM_OC_PLL_N at 13 because it doesn't help much and it can make it unstable.
-
You know I read that file a million times and this is the first time i noticed 16 was referring to mem! Thanks mate, so far I have backed up, patched from d10 to d15 and the small fonts. Now just want to get rid of the menu\button lag!
EDIT: YouTube clip of still not smooth 2d15 https://youtu.be/p-ngOAyKXiM?si=Z9k8l_1KVBx3a7Bt (https://youtu.be/p-ngOAyKXiM?si=Z9k8l_1KVBx3a7Bt)
-
EDIT: YouTube clip of still not smooth 2d15 https://youtu.be/p-ngOAyKXiM?si=Z9k8l_1KVBx3a7Bt (https://youtu.be/p-ngOAyKXiM?si=Z9k8l_1KVBx3a7Bt)
Try a smaller frequency difference. At your "speed" you can hardly see what is happening.
It looks smoother on my scope, but of course it has a limited update rate. What do you expect for $150?
-
It seems like using different sample rates has an effect on the trace thickness much more pronounced with the latest patch which makes me feel they reduced the smoothing algorithms for less load with the side benefit of increased accuracy or at least the same accuracy with less filtering.
Could someone else confirm or deny this for me please.
-
It seems like using different sample rates has an effect on the trace thickness much more pronounced with the latest patch
Can you describe the test setup in more detail?
The user cannot change the sampling rate directly afaik. It is set automatically by memory depth and s/Div.
-
Sorry, I should have said memory depth. Before I applied the latest patch I was following along with a YouTube video https://www.youtube.com/watch?v=Znwp0pK8Tzk&t=768s&ab_channel=EEVblog (https://www.youtube.com/watch?v=Znwp0pK8Tzk&t=768s&ab_channel=EEVblog)showing how the thickness of the trace can be seen to change going from 4k I to 8m, but I didn't see the same difference and put it down to filtering smoothing out the trace. Than Immediately after the latest patch the trace became noticeably thicker unless I used HR mode or a lower memory depth.
This made me wonder, as the reason they sent me the patch was I complained of laggy inputs and random lockups, if there was a change to the filtering to lighten the process load, with the added benefit of a more accurate display trace.
-
@OLderDan: I'm not sure. Maybe DavidAlfa understands your question (is it even a question? I'm not a native speaker).
As a general tip for the DSO2000, I would say: Don't look for a fly in the ointment, just enjoy what a great tool you got for $150 and explore everything you can do with it.
People often pay too much for this tool and are then rightly disappointed.
-
I agree with you entirely and I am happy to embrace all this bargain oscilloscope has to offer, including it's limitations. Through playing around, I have found great settings for trigger that have stabilized displays of unsynchronised waveforms, and through specifying the hex bit, triggering in useful parts of my uart streams etc.
Learning how to interpret the trace has taught me the real world differences of the acquisition settings and opened my circuit exploration far beyond what I was able to achieve before I bought this scope.
-
Hello, does anyone know how I can make the UART and I2C decoder show the letters instead of doing it by code? For example, I would like it to show an "A" instead of a "41" or at least show them together, my firmware is 3202 and Software 1.0.2.0.0 (221028.00), thanks[attachimg=1]
-
Hello, does anyone know how I can make the UART and I2C decoder show the letters instead of doing it by code? For example, I would like it to show an "A" instead of a "41" or at least show them together, my firmware is 3202 and Software 1.0.2.0.0 (221028.00), thanks (Attachment Link)
Install Patcher: https://drive.google.com/drive/folders/18kLCiv3E7FusO-ioO8oENj5oUiyYId_8 (https://drive.google.com/drive/folders/18kLCiv3E7FusO-ioO8oENj5oUiyYId_8)
Info: http://bit.ly/3I8CfAJ (http://bit.ly/3I8CfAJ)
-
Hi, Thank You, it works for me :-+[attachimg=1]
-
Please correct me if I'm wrong but the UART mod called "Patcher" makes i2C decoding stop working? That function no longer decodes me. The message "Please adjust the Triger" or "please adjust the base time" always appears, before it gave me the impression that it was half working.