FNIRSI-1013D "100MHz" tablet oscilloscope

[pcprogrammer]

Strange. I wonder where this difference resides. Will know more when I capture the i2c communication. Already measured on it with a rigol mso5000 and saw it works at around 40KHz. They use bit banging in software, because there is no TWI (I2C) interface on the mcu pins where the touch panel is connected. They also do not work with the interrupt the panel generates. It is a polling system by reading the GT911 0x814E register. (Might be that an earlier version worked with a resistive touch panel since that is what the mcu pins are intended for, even though the mcu has three twi interfaces and external interrupt pins they could have used)

Basically you are lucky it works as is. And good tip about the cutting wire. Too late for me, but may be others can use it for needed repairs.

[iscle]

I'm looking for a 7 inch lcd for a lichee nano to do development for the scope but find it hard to obtain specifications of displays offered on aliexpress.
I asked the seller of this one (https://nl.aliexpress.com/item/32691414835.html) for a datasheet, but they don't have it
Searching on google does not render much info either.
I think it is a 50pin and might be the same as what is in the FNIRSI-1013D. If so I only need to make a converter from 50pin to 40pin.

Anyone any suggestions or a pointer to a cheap 40pin 7 inch 800x480 lcd compatible with the lichee nano. Preferably on aliexpress.

Any 800x480 RGB lcd should be compatible, only timing will change!

[pcprogrammer]

Any 800x480 RGB lcd should be compatible, only timing will change!

The problem is that I think this is not the case. LCD's can have a parallel ttl/cmos interface or one or more serial lvds interface(s). For the lichee nano it needs to be parallel. It is hard to find specifications on the net

[Melman]

How does this scope compare to the miniware DS203/213? Looking for a cheap scope that realistically will only get used a few times a year and can't justify spending $$$ on something nicer.

[pcprogrammer]

Al depends on your requirements. The FNIRSI-1013D has a AD9288 per channel so 200Msps and ~30MHz bandwidth. It lacks the signal generator though. The size factor is much nicer in my opinion. The 7 inch display is easy to read. I don't have a DS203 or DS213, but reading the specs and comparing the price made me buy the FNIRSI,  not long after I bought a jyetech wave 2

Unfortunately mine arrived with a defect in the touch screen, as you can read in this thread

[pcprogrammer]

Probably already tried by others, but just to share the information, it is possible to boot the scope into FEL mode (programmable via usb) by inserting a SD card with a special image on it. See: https://linux-sunxi.org/FEL#Entering_FEL_mode for more info. The scope then lists itself in linux (lsusb) as "ID 1f3a:efe8 Onda (unverified) V972 tablet in flashing mode"

Here is the bit about this specific procedure:
Through a special SD card image, included in our sunxi-tools repository, there is a small SD CARD boot image that does nothing more than jump to FEL.
Just install it on a sd card as you would with the u-boot SPL (be sure to change /dev/sdX to where your sd card is):
  wget https://github.com/linux-sunxi/sunxi-tools/raw/master/bin/fel-sdboot.sunxi
  dd if=fel-sdboot.sunxi of=/dev/sdX bs=1024 seek=8

So it should be possible to load a linux image on a SD card and boot it from there. The question is what is done on uart0. It is connected to the FPGA. I connected my MSO5074 to it and the signals do not look like serial communication. With the go to FEL SD card in it there is no signal at all. So the linux image should not have a tty connected to any of the uarts on the F1C100s. Maybe it is possible to use the usb interface for this purpose.


So the story continues

[pcprogrammer]

Started with analyzing the I2C from the touch panel. Made a breakout board for it with headers for a bluepill STM32F103C8 and ffc/fpc 0.5mm 6 pin conversion boards. This way it is easy to connect to the signals with either or both the STM and a scope.

At startup a blob of data is being written to the panel and after that it starts polling the panel to see if there is touch. Unfortunately I see errors in the communication where it looks like the SCL is being pulsed more than it should. Have to hook the scope up again to see what is actually going on.

Need to analyze the data being send to see what it is doing. It starts at address 0x8047 (config version) and writes a lot of bytes. Most are acknowledged by the panel, but some are nacked.
After I analyzed the data I will post the results here.

Also monitored the INT and RST lines to see what is happening there, because the device address can be set with these lines. What they do is not so nice. At the startup of the scope the RST line is set high and then the INT line is toggled with a 13ms/200us pulse width ratio for quite some time.

Have to search the disassembly files I made with Ghidra to see if I can find where port A is being controlled.

[iscle]

Started with analyzing the I2C from the touch panel. Made a breakout board for it with headers for a bluepill STM32F103C8 and ffc/fpc 0.5mm 6 pin conversion boards. This way it is easy to connect to the signals with either or both the STM and a scope.

At startup a blob of data is being written to the panel and after that it starts polling the panel to see if there is touch. Unfortunately I see errors in the communication where it looks like the SCL is being pulsed more than it should. Have to hook the scope up again to see what is actually going on.

Need to analyze the data being send to see what it is doing. It starts at address 0x8047 (config version) and writes a lot of bytes. Most are acknowledged by the panel, but some are nacked.
After I analyzed the data I will post the results here.

Also monitored the INT and RST lines to see what is happening there, because the device address can be set with these lines. What they do is not so nice. At the startup of the scope the RST line is set high and then the INT line is toggled with a 13ms/200us pulse width ratio for quite some time.

Have to search the disassembly files I made with Ghidra to see if I can find where port A is being controlled.

Don't worry about the touch panel I2C, the datasheet is available and I've written a driver for Goodix before (for a phone actually), it's pretty easy to use!

I think we should move our attention to the FPGA protocol since that's what controls the LCD backlight and everything else

PD: It's possible that they messed up the I2C implementation, since they're not using the peripheral but bit-banged it instead!

[DaneLaw]

How does this scope compare to the miniware DS203/213? Looking for a cheap scope that realistically will only get used a few times a year and can't justify spending $$$ on something nicer.

Don't have either Fnirsi1013 or DS203/213, though do have the Miniware scope, but the lesser DS212 (70US) and would not recommend these small Miniware DS200 series-scopes, unless you'r dead set on its main features, like very nice build-quality and extremely small form factor that wihtout probes can be in your jacket or backpocket and looks like a modern mobile.
The biggest con in my view on the MiniWare DS200series is handling the interface' and the lack of touch, and you need to rely on these clickable rollers, which for me became a pain in the azz.

Sure the Miniware DS scopes is better than the old and extremely small Fnirsi DSO188 here in the picture below beside the MiniwareDS212, but that doesn't say a lot as DSO188 is more proof of concept 30g 1.8" 5x3x1cm.  (FnirsiDSO188 also been rebranded as Daniu DSO188  great brief textreview¨of that model)
https://lygte-info.dk/review/Equipment%20Oscilloscope%20DANIU%20DSO188%20UK.html

.
DS203/210 or the Fnirsi1013D I would definately choose the Fnirsi1013D from what I have seen in this thread..the Miniware DS200series is great as secondary if you just need a small scope a secondary option that is very compact and can be in your back pocket.

There is also another new 7" touch scope model that has just been released with incl. 30MHz signal generator, I wrote about its spec here, it from the brand JINHAN who likely is most known for their rugged JDS-series handheld scope-line.. the new 7" touchscope' starts around 130USD but the 100MHz/1GSas is above 170US

https://www.eevblog.com/forum/testgear/new-2ch-handheld-touch-oscilloscope-from-jinhan-(smto502s)-with-1ch-signal-gen/msg3532694/#msg3532694

SMTO502S  60MHz 250MSas + 1ch. signal generator. 135USD.  (incl, EU VAT)
SMTO1002 100MHz 1GSas  175USD (excl. VAT)
SMTO1002S 100MHz 1GSas + 1ch. signal generator. 205USD (Excl. VAT)

[pcprogrammer]

I think we should move our attention to the FPGA protocol since that's what controls the LCD backlight and everything else

For sure, that is an important step in making new open source software for the scope, but for now I'm looking for a quick fix of my reversed coordinates problem. Hope that it can be fixed by patching a single byte in the code.

Getting the FPGA interface is more difficult since it needs to be done through reversing the software. It is rather a pain in the bum to attach a logic analyzer to the 11 interface pins. For me soldering wires to the pins is not a real option anymore. Pins are very small and aging f... ups the eyesight. Even with a microscope it is more a young mans game
Leaves getting an adapter like these spring ones to connect to sop ic's, but these are expensive and harder to find for 144pin lqfp or 88 qfn

Another option is reverse engineering the bit stream. I was able to find several bits of code for doing such a thing but not for this specific fpga (cyclone iv). There is a claim that it is done, but the software for it is not made public. To my understanding the bit stream is not encrypted, but still quite the job to get it done.

[pcprogrammer]

I now know why they using 10K pullups and added a capacitor across the SCL and SDA line. At some moments there is a large spike in the clock and data signal. It is very narrow and hard to see in the pictures, but they are there. The first picture is without the capacitor. The second is with added 2K2 pullup resistors. (RigolDS0.png) There it is much larger. In the third picture the capacitor is re soldered and the extra pullups removed. The spike is still there but not that big. I2C interfaces will probably filter these out with the builtin analog filters.

Still a crappy design trying to save one capacitor. They should have used one per line connected to ground. Better yet they should have used a build in TWI (I2C) of the MCU. Would also have allowed for UART1 to be used for terminal connection. (Iscle this might be an option for you. Disconnect the touch panel and connect your usb to serial adapter to the scl and sda pins. RX (mcu TX) on SCL, pin 6 and TX (mcu RX) on SDA, pin 5. This way you are not bound by the FPGA messing up UART0)

Without the capacitor the new touch panel does not respond, so it does help.

Adding more capacitance in a per line fashion does not solve the reversal problem, so it is not due to miscommunication. In the text file is the capture of the configuration data send to the panel. It starts writing on register address 0x8047 and sends 186 bytes. (S is start, A is ACK, N is NACK and P is stop)

According to the programming manual of the GT911 it sets the "Y2Y, X2X, Strech_rank 3, X2Y ,Software Noise Reduction, Falling Edge INT" in register 0x804D (Module_Switch1). So if it is possible to change this byte it sends it should be possible to reverse the coordinates of the panel.

[pcprogrammer]

Did several steps in the hacking process the last couple of day's. Used Ghidra to disassemble the code. Thanks to tv84 for pointing out the block structure in the flash image. Made separate binary files for the different parts and analyzed them in Ghidra. The ARM version is actually v5t little instead of v4t which was pointed out  earlier in the thread. The BLX instruction is used, which does not exist in v4t.

ARM assembly is new to me so the process is slow, but I'm working my way through the second program loader, since it already does some communication with the fpga in that part of the code.

Based on a quick scan of the code, I got the idea that for the touch panel the software it is getting settings from what I thought to be an I2C EEPROM, but it turns out it is not. Tried reading it with a CH341 programmer, but it does not respond to the slave address. It is an I2C ic, but it only responds to the slave address 0 which is the general call address. Monitored the signals with my MSO5074 and noticed it is running at ~800KHz. It does read and write sessions with the ic on address 0, and always in groups of 8 bytes on the bus (including the slave address). So the question is what is this ic? Is it a micro controller or some special storage ic?

Monitored a couple of read write actions with the following results: (All bytes are listed, first being the slave address)
write: 0x00 0x23 0x3C 0xD2 0x40 0xBF 0x45 0xFF
read: 0x01 0x68 0xCD 0x52 0xFE 0x01 0x91 0x58
write: 0x00 0xEC 0xA7 0x36 0xFE 0x01 0x0E 0x96

A read directly after startup of the scope: 0x01 0xEC 0xF5 0xAF 0x9B 0x9B 0x75 0x55
But a second time after startup the bytes were shifted: 0x01 0xF5 0xAF 0x9B 0x9B 0x75 0x55 0x01

After the write session a stop is send. The read session is terminated by a NACK of the host. No stop and a repeated start for the next write session.

Attached is a zip with a csv file from the MSO containing the two signals shown in the picture.

[ser8989]

Hello, I have results on disassembling firmware 1013d. You can reach me in telegram, find me there https://t.me/ser_8989

[pcprogrammer]

I don't have a telegram account. What do you have for us? Does it look like attached file below?

[ser8989]

There are addresses in the firmware dump of the values written in the registers of the gt910.
The thing is that the data structure itself has an incomprehensible structure, because part of the values of one structure is used in the other one.
Do you have any experience in calculating the data address used by the function writing values to the gt910 registers. There are 4 candidate functions(1da04, 1da8c, 2b96c, 4d164 In file FSI-1013en.bin) exchanging with gt910.
I made a primitive sketch for the arduino and read the configuration of the gt910.
0x804D register has no effect.

[ser8989]

The most important thing is that the touchscreen mirrors from the fact that the non-original touchscreen is gt915, and in registers 0x80B7 to 0x80C4(Sensor_CH0 to Sensor_CH13, Channel number on chip corresponding to ITO Sensor) and 0x80D5 to 0x80EE(Driver_CH0 to Driver_CH25, Channel number on chip corresponding to ITO Driver ) must be written upside down byte sequences. Original sequences
0x14,0x12,0x10,0x0E,0x0C,0x0A,0x08,0x06,0x04,0x02(0x80B7 to 0x80C4)
0x28,0x26,0x24,0x22,0x21,0x20,0x1F,0x1E,0x1D,0x0C,0x0A,0x08,0x06,0x04,0x02,0x00(0x80D5 to 0x80EE). That is, 0x80B7 to 0x80C4 should be written to 0x02, 0x04, 0x06, and so on. But at startup English version of the firmware will overwrite gt915 with wrong config and the touchscreen will mirror, but Chinese version doesn't overwrite gt915 and the touchscreen works fine.
I apologize for the bad English I wrote through the translator.

[pcprogrammer]

I came to a similar conclusion, but it turns out that the program I used to search the binary is not working properly on my linux mint version. wxHexEditor. Yesterday I tried searching for eGON as text, but it did not find it, while it is right there in the first page of bytes on the screen . So decided that I would write my own binary search program today to search for the config strings.

So thanks ser8989, you saved me some work.

There are many things that need to be done for getting to the bottom of this scope and trying to get linux to run. Found two promising buildroot setups for the lichee nano, which uses the same MCU. Started building one yesterday, but it was not finished when I turned in for the night so, need to start it again today and see what it does. Then need to switch the uart to 1 and check if it will work on the scope.

[pcprogrammer]

Unfortunately the LCD I bought on aliexpress (https://nl.aliexpress.com/item/32691414835.html?spm=a2g0s.9042311.0.0.27424c4dNyDqyg) does not work with the FNIRSI-1013D. The pinout looks the same and it did not wreck the scope, but when connected on power up it shows white fading and stabilizes in a blue bar on the right side of the display. So timing problem? or incorrect voltages on some of the power pins?

One of the buildroot configs I found did compile and works on the Lichee nano, but I was not able to change the default uart from 0 to 1 yet. Needs more reseach on how to do that The struggle continues

[pcprogrammer]

Took quite a bit of searching through the .dts and .dtsi files and there meanings to get something done. Also a change to one of these files leads to having to rebuild the whole bunch, so a day goes by quickly. On the lichee nano the kernel now uses uart1 as its default ttyS0 and uart0 is disabled. Unfortunately this does not affect u-boot. This part still uses uart0. Have to test this build on the scope to see what happens.

If it works on the scope I will post the steps I took to get it done.

It works , but too bad the display does not. The back-light did not turn on. At least linux is running. I can login (root/root) do cd.. and ls to see the directory list.

What I did:
I setup a virtualbox with linux mint 20.
Followed the instruction here: "https://hackaday.io/project/171402/instructions"  down to building the sunxi tools. (Used  sunxi-fel version to see what the scope returned)
After that I used the instructions here: "https://www.thirtythreeforty.net/posts/2020/01/mastering-embedded-linux-part-3-buildroot/"  to setup buildroot (used the latest date 2021.2) and tested it with the raspberry pi config
Then I followed te instructions here: "https://unframework.com/2020/05/27/setting-up-embedded-linux-on-lichee-pi-nano/" to build the linux with uart0 for the lichee nano
Had to resolve some errors due to missing packages. "sudo apt-get install swig python-dev libssl-dev" Also needed to change the defconfig to overcome legacy options.
Then to get uart1 in the picture I had to make modifications to some .dts and .dtsi files. The latter is found in several places and concerns these suniv-f1c100s.dtsi or suniv.dtsi. Not sure editing which did the trick.

I moved the files from unframework into the buildroot directory and modified them to work from there.

In the zip are the files I changed.
Place the board/licheepi_nano directory in the buildroot board directory (only the licheepi_nano directory ofcoarse)
Place the configs/licheepi_nano_defconfig in the buildroot configs directory (only the file)
Search for the other two files and replace them everywhere you find them. ( suniv-f1c100s.dtsi of suniv.dtsi)

Type in terminal in buildroot directory
make licheepi_nano_defconfig
make

This will make the needed image for the sd card.

With "sudo dd if=~/buildroot/output/images/sdcard.img of=/dev/sdb" I wrote it to my card and placed it in the scope.

Used a breakout board to connect the usb serial and putty on the linux mint machine et voila.

[pcprogrammer]

There are 4 candidate functions(1da04, 1da8c, 2b96c, 4d164 In file FSI-1013en.bin) exchanging with gt910.

Hi ser8989, the problem is that I'm working with the code of the new version. I did find the byte string in the code, but the addresses you mentioned do not lead to anything there.

I'm now looking at code that makes use of the port A address 0x01C20800 (config) and  0x01C20810 (data). The first one is found 12 times in the 2nd executable part. The second one is not found but indexing is used to get to that address. As I'm in the process of learning ARM assembly it is not the easiest task. Look at the code, look at the reference manual for the instruction, try to work out what the code does, etc.

I tried to attach the Ghidra result for this part of the code, but even zipped it is just to big for the forum. 121.2MB plain text and 5.1MB zipped. I will put it in github. Will update this post when it is done.

Made a repository for it: "https://github.com/pecostm32/FNIRSI-1013D-Hack"

Needed to zip the file, because github has a limit of 25MB

[iscle]

On the lichee nano the kernel now uses uart1 as its default ttyS0 and uart0 is disabled.

Holy sh*t, this is why I wasn't getting any UART output after U-boot then! Okay, I can try to get the LCD working, I'm sure the only issue is the timings, and fortunately the LCD which comes with the oscilloscope is already suported by mainstream Linux

Thanks for the mini guide, I'll try to follow it and report back.

[iscle]

I've been trying but for some reason I can't get it to boot... Not even the U-Boot uart works now... Strange

If you could share your image it would be nice

[pcprogrammer]

I have added a linux directory in the github repository with the images output of the buildroot build. Also added the files I changed and the instructions in a readme.txt file.

In the image directory I added a "readme.txt" and "location of uart1 connections.jpg" file.

Will try to change u-boot to use uart1 today and if it works I will upload the image and changed files to the repository. (https://github.com/pecostm32/FNIRSI-1013D-Hack)

Next step would be to move the communications to the USB port like thirtythreeforty did in his business-card, and disable all the uarts.
Might be a good idea to create a new board config for the scope with these options.
u-boot probably needs additional changes to handle initial communication with the fpga, but that still requires a lot of research.

My problem with the back-light not being on is a bit tricky to initially solve in the hardware. The fpga pin is directly connected to the enable pin of the back-light power converter. It is pulled low by a resistor and needs to be high to enable the converter. There is a risk of damaging the fpga when this pin is pulled high by connecting it to the 3,3V rail.

[pcprogrammer]

Tried to change uboot to use uart1 instead of uart0. Unfortunately it did not work. I found that the same type of .dts setup is used for uboot and also learned that buildroot on clean removes al the files and when it builds again the linux and uboot files are extracted from the tar.gz files and not copied from the /git directory, so needed to make the changes in the archives to get buildroot to use the changes

But after compiling and putting the image on a sd card the lichee nano did not start Reconnected uart0 to the usb serial adapter (only have one 3.3v type yet, so no monitoring both ports at the same time) and noticed uboot still outputs some initial data there.

U-Boot SPL 2018.01 (Apr 10 2021 - 11:45:10)
DRAM: 32 MiB
Trying to boot from MMC1

After that nothing happens on either port.

So need to do more research to get that resolved

[iscle]

I have added a linux directory in the github repository with the images output of the buildroot build. Also added the files I changed and the instructions in a readme.txt file.

In the image directory I added a "readme.txt" and "location of uart1 connections.jpg" file.

Will try to change u-boot to use uart1 today and if it works I will upload the image and changed files to the repository. (https://github.com/pecostm32/FNIRSI-1013D-Hack)

Next step would be to move the communications to the USB port like thirtythreeforty did in his business-card, and disable all the uarts.
Might be a good idea to create a new board config for the scope with these options.
u-boot probably needs additional changes to handle initial communication with the fpga, but that still requires a lot of research.

My problem with the back-light not being on is a bit tricky to initially solve in the hardware. The fpga pin is directly connected to the enable pin of the back-light power converter. It is pulled low by a resistor and needs to be high to enable the converter. There is a risk of damaging the fpga when this pin is pulled high by connecting it to the 3,3V rail.

Just tried it again with the sdcard.img you uploaded to github, and still no uart on any of the ports (tried uart0 and uart1)... Weird... However, by removing the sd card the oscilloscope boots normally, so it's not broken.

I also tried flashing the card with Win32DiskImager and with dd from Linux, same result. Very strange.