FNIRSI-1013D "100MHz" tablet oscilloscope

[JordanW]

I understand that discussion around this cheap tablet scope has turned to hacking the firmware.

Taking a step back -- I'm looking at getting this scope for purely hobbyist purposes. I've used oscilloscopes before but have never had one of my own.

I've watched the review(s) and think I understand its limitations (I really only need about 20 MHz bandwidth). Space is at a huge premium for me and budget is also an issue, so it's between this and something like a USB scope (e.g. https://canada.newark.com/multicomp-pro/mp720016-us/pc-based-osc-2-ch-25mhz-100msps/dp/10AH2399) Which would you choose?

[pcprogrammer]

Both will have their uses. The advantage of the FNIRSI-1013D is that you can take it with you and don't need a PC (laptop) to do measurements. If the USB type is powered from the PC (I did not see a power plug) then it must have very good filtering in it to over come the noise on it, because USB power is rubbish.

There is always a risk with the FNIRSI that there is a problem with the touch panel. Don't know the stats, but it is one of the reasons the hacking game started. At least it is now known how to fix it and with what parts.

I myself would go for the FNIRSI.

[pcprogrammer]

Tested the 1st executable hack. It either is, or starts the FEL program. When connected to USB it shows up as the same "ID 1f3a:efe8 Onda (unverified) V972 tablet in flashing mode" device as when booted with the FEL SD card.

So nothing interesting there.

I will upload it to the repository just for the sake of it

[pcprogrammer]

While working on writing a copy of a bare metal bootloader for the scope, based on what is there now, but optimized, I decided to take a look at the bitmap.

Wrote a simple conversion program to make it into a windows .bmp file, and surprise surprise it is the FNIRSI logo seen at startup. Converted to a .png to be able to post it here. The bitmap and the original binary is in a .zip archive.

[Martin72]

Wow, this thread is grown...
Knowing only the first pages, too lazy to read all the pages after :
Is something interesting happen, new firmware, hacks ?

Martin

[pcprogrammer]

Working on it.

Found a lot of interesting things already. Managed to solve the touch panel reversed coordinates problem when replaced with one from aliexpress. (due to defects in the original touch panel) For this a patch has been made to the new version of the code. Also reversed engineered the schematics and have some knowledge about controlling the FPGA used in the scope.

Check out the repository here: https://github.com/pecostm32/FNIRSI-1013D-Hack

At the moment working on my own version of the bootloader to get a better understanding of the F1C100s. After that it is writing my own version of the scope software. Basically open sourcing the existing code with some cleanup.

When that is done it is time to make improvements.

But it will take some time

[pcprogrammer]

Too bad, A quick test of my new bootloader fell in the water. For some reason sunxi-fel times out when I try to load the ~8KB of program data to address 0x00000000. With small programs it works just fine.

So now I have to do a bit more work and make a flash-able image with at least the bitmap image in there. Or try to only write to the first part of the flash. Not sure about what sunxi-fel does when writing to flash. Have to do some experiments.

If the new code works it is at least 4KB smaller than the original

It still needs some polishing in the comment and defines sections to make it better maintainable. Especially in the DRAM section. The lack of documentation makes it a bit of a guess what is what. DRAM controlling is also new to me, so lots to learn.

For now it will stop after loading and displaying the bitmap image. Adding the loading of the main program is peanuts compared to the rest.

So again, the story continues

[vzgherea]

I've got a Chinese version of this device.
Flashed it with the English version - https://github.com/pecostm32/FNIRSI-1013D-Hack/blob/main/Binaries/Original%20files/W25Q16en.bin
Got the same result as it is shown here - https://www.youtube.com/watch?v=InCihC4Q1u8&ab_channel=%D0%94%D0%BC%D0%B8%D1%82%D1%80%D0%B8%D0%B9%D0%A1, it looks like the input and touch coordinates do not match.
My chip is W25Q16 and the initial firmware is different from https://github.com/pecostm32/FNIRSI-1013D-Hack/blob/main/Binaries/Original%20files/W25Q16cn.bin
Am I using a wrong firmware? Do I need to reset anything?
Thank you!

[pcprogrammer]

Looking at the video shows only the reversal of the x coordinate. This can be solved by modifying the parameters being written into the touch panel. To my understanding the English W25Q16 version of the firmware found in this thread is not sending any configuration to the touch panel, so you only need to write a modified configuration to your touch panel.

Get hold of a 6pin 0.5mm adapter (https://nl.aliexpress.com/item/4000099171451.html) for connecting the touch panel to either a 3.3V arduino (nano) or a STM32F103 based board. (Bluepill). Look at the STM code in my other repositories or the arduino code found in the thread. Read the config from your touch panel and make modifications for reversing only the x coordinates, and write them back. (Either the x2x bit or the order of the sensor assignments)

The programming manual of the touch panel chip can be found in the repository.

Should do the trick.

[Martin72]

By the way,

In periods of 2 month I´m writing to finirsi and ask for a new firmware....
And getting always the same answer:

Nothing.

[vzgherea]

Read the config from your touch panel and make modifications for reversing only the x coordinates, and write them back. (Either the x2x bit or the order of the sensor assignments)

My config for some reason is completely different from one I can see in post #712.
Executed the WRITE command from sketch in the same post, however after another reading I found that the config remained the same.

Is my config correct? What bit should I change in order to fix this issue?

[pcprogrammer]

I took a look at the sketch from post #713 (version with read / write action on request via serial) and there are two things that can go wrong and the configuration change in it is for both X and Y reversal.

The things that can cause problems is that register 0x8047 is not written to a value equal or higher to what is in the touch panel. (See picture of that part of the manual) and or the checksum is not correct for the new configuration. For this it is necessary that all the bytes from 0x8047 to 0x80FE are known to calculate it. There is code out there that does the calculations. (Not behind the computer I use for development, so can't check it right now).

In my conf writer the whole configuration string written by the scope (new 32Mbit firmware version) is given. When only the order of the sensor array bytes are changed the checksum will remain correct.

Data destined for register 0x80B7 - 0x80C4 for changing the Y direction, and register 0x80D5 - 0x80EE for changing the X direction. (It is all in the Goodix GT911 programming manual, except how the checksum is calculated)

Changing any of the other bytes in value needs a recalculation of the checksum.

[pcprogrammer]

For those interested an update on the getting to an open source and improved copy of the scope bootloader.

It took some research to get to a binary that can be loaded into the flash. It needs the BROM header and the correct startup code to set the MMU coprocessor. On a first try it did not start, since it needs a correct checksum in the BROM header. Found a program to make that right, so second attempt did start, but did not finish. Due to no easy debug possibilities I added my toggle port A test and connected the MSO5074 to see where the code failed. Found that I did not interpreted the SPI code correctly and it got stuck in reading the large part of the image data. Reading the header was not a problem. So it got stuck when reading more then 64 bytes (which is the FIFO size).

Managed to fix that, but still not a correct image on the display. Since I raised the clock to what the scope main program is running on (600MHz), it might be in the settings for the display and timing is off.

Doing separate tests now with small bits of code that can be loaded to the SRAM with the FEL tool.

Not happy with the way the SPI code works. Even on the 600MHz it takes almost 50uS to copy just 64 bytes to memory. The code now starts a read burst of 64 bytes (similar to the code I found and what is in the scope) waits till the FIFO is filled and then copies them to memory and starts the next burst. There should be a way to improve on this by either using DMA or skip the FIFO and do a byte per byte run.

It is a bit of a problem to verify with the MSO5074 what the original bootloader is doing, because at startup of the scope it loads the bootloader from flash with the SPI. So the MSO5074 is triggered directly and the loading of the image starts after the bootloader is loaded. To even see the beginning the MSO5074 needs to be on 200mS/div and then it is impossible to zoom in on the signal. The BROM runs the SPI on ~3MHz while the scope bootloader goes up to maybe 50MHz.

So I keep on experimenting and learning.

Edit: The image shows the reading of 250 bytes of data in 64 bytes bursts

[pcprogrammer]

I'm getting there. Had to hard code the image sizes to get it to work. With the previous version, where I get the image sizes from the header, it took almost 8 seconds for the display_bitmap function to complete, so there had to be something wrong. As the code itself looked ok, I decided to just put in the numbers directly and with that it just works.

Ok there is an issue of clearing the screen memory first. The background is some sort of yellow spotted pink. But that is just writing a block of memory. There is plenty of time before the FPGA is ready to do this task in.

Also have to figure out what goes wrong in getting the image x and y size from the header data. The length of the image data is also obtained from the header and is used for reading it from the flash, and that is spot on. (Was able to determine this by measuring the time the flash CS line was asserted for reading the data. Only ~50ms for the ~58K of the image, so the SPI optimization is not a big issue)

So almost there.

[pcprogrammer]

The bootloader is somewhat finished. Uploaded the code here: https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Test%20code/fnirsi_1013d_bootloader

There is still room for additional comments and maybe some cleanup in the dram control part.

But it works. The initial image is displayed and after that it takes ~1.6S to start the scope code.

The attached image shows the SPI clock and cs of the total startup sequence. The first messy bit is the BROM loading the bootloader. Then the small spike is the loading of the image. The large blob is the loading of the scope main program. The large amount of noise is due to the fact it is 50MHz signals connected via 20cm wires and then probed.

[serverror]

Really enjoying following your progress. Thanks for your efforts. Will those of us on the older/bulkier version of the scope with a W25Q16 need to make any changes before being able to use some of your work?

[pcprogrammer]

Really enjoying following your progress. Thanks for your efforts. Will those of us on the older/bulkier version of the scope with a W25Q16 need to make any changes before being able to use some of your work?

Nice to hear my work is appreciated.

Have not tried it myself, but others have used the W25Q16 version floating around in this tread in the new version of the scope, so looks like the basic hardware is the same. This means that once the main code has been opened up, it should be usable on the old version as well.

The only big difference is the flash size, but the new code will most likely be smaller due to removal of unneeded stuff.

Testing it on a old version scope once it is al done will be the proof of the pudding

[tv84]

Nice to hear my work is appreciated.

Sure it is.  Keep it coming.

[pcprogrammer]

Well here is some more stuff

it is going to be quite the job to get the main scope code opened up. Now working on the initialization section of the C variables and found that there are 2584 bytes initialized with a value other then zero. 7055620 bytes are being made zero.

Then there is something else done with the data, which I don't get just yet. In the startup code there is a loop that gets 4 registers filled with data from 0x80192e6c. r0 is used as source, r1 as destination, r2 as byte counter and r3 the address of the function to call. The first group is for the bytes with a value other then zero. The second group for the call I don't get, and the third groups is for the bytes that are set to zero.

I uploaded a new Ghidra zip to the repository with more function names filled in.

The functions used for the init are at address 0x8000008C for the looping through the three groups, 0x800000C8 for the special byte handling, 0x80000124 for the copying of the non zero data and 0x8000014C for the clearing of the variables set to zero.

Anyone any idea on this. I know that for C there is a data and a bss section, so what is the third.

Edit: the fog is lifting just a bit. The first data copy is to make room for the actual data. So it is basically moving the data to be used by the special routine, which writes back to the section it came from. It is "moving" 2584 out of the way and then does some formatting to copy it back to a much larger byte array. (42756 bytes) The third action overwrites the bytes "moved" in the first action. So I copied the bytes from the binary and put them in a C array and will write a test program to see what the special copy function does.

Edit2: It is a kind of run length encoding scheme. I outputted the expanded data to a binary file and I was able to find the touch panel configuration string (without the checksum, because that is calculated in the code) in it So yet another mystery solved. Attached the code and the output file. The tp config is at offset 41190.

[pcprogrammer]

Today the 1mm thick 200x200mm plexiglass I ordered arrived (https://nl.aliexpress.com/item/32833660352.html)

I made a new front for my scope. Left the protective film on until I fix it with some double sided tape. Then I have to mount the touch panel and display behind it.
Also still waiting for the new flash chips to arrive. Only then can I restore the scope to normal working order.

On the hacking front not a lot of progress. Got the clock initialization into a .c file. It is slightly different from the boot loader init. I am now working on the timer setup. It is using timer 0 on a 1ms interval. It is interrupt based. The function for setting up the interrupt is called from two other locations, so there are three things using interrupt. Have not identified the other two yet. The Ghidra file is getting more and more functions named, so tracking gets easier.

Edit: the three interrupts are: TIMER0, USB_OTG, PORTE. The latter is for the power monitoring pins.

But still a long way to go.

[Paul-H]

Sorry to resurrect and old thread

In the stripdown pics above there is what appears to be a SD or microSD card reader, anyone know what it's for, as there is no access to it with the case on.

Thanks

[pcprogrammer]

The micro SD card is used as storage for the pictures and waves one can save on the scope. Via USB the data can be retrieved. When the micro SD card is removed or it is defective on startup "SD ERROR" is shown on the screen.

It works with cards that are default factory formatted. I bought a 32GB card and stuck it in and the scope started normally. Did not test writing anything, but guess it will work.

[pcprogrammer]

Had an interesting experience

I put the scope back together and turned it on. Forgot that I had reloaded the original firmware, so the touch panel was reversed again. Since I now know where the touch panel config is in the init data, I decided to patch it there, so I could let the scope do the change itself. Flashed it to the scope and dammed it started with a "SD ERROR". Stuck another card in it and it started doing something again. It went into its self test mode, and it failed on the input relays capacitance. The touch panel was working correctly though.

Wrote my first hack with the touch panel config writing removed in the flash and now it works as it is supposed to.

Within the test procedure is a touch panel test where one has to touch the four corners and the center. It probably decides on this info that the touch panel is not working.

No idea how it went into this test mode though.

Edit: Tried it again with the version where I changed the touch panel configuration and it went straight into the test mode. So I messed something up. Luckily it still works with the other patch.

[pcprogrammer]

Found the reason why it went into hardware check mode. To make the modified touch panel configuration I had to add 3 bytes in between the init data section. This lead to shifting of data higher up in the flash. At flash address 0x001FE000 the code expects 0x9086. If it is not there it does the hardware checks. So I removed three bytes just after the init data and now it works normally.

There are more of these reads done, so maybe there is some configuration data in there and since that was also shifted my scope failed the hardware checks.

Uploaded the new hack to the repository, with a text file showing what changes I made. With this hack it is no longer needed to use separate hardware to write a new config to your touch panel.

The unpacking of the init data uses some interesting scheme. It can copy bytes from the init data to the target, add trailing zeros or copy data from a previous unpack.
Each packet has a variable header. The first byte holds information about how many zeros in the high nibble, how many bytes to copy directly in the low nibble lowest 3 bits. Bit 3 tells the unpacker to copy data from a previous unpack. If the low 3 bits are zero an additional byte is loaded as the byte copy counter. The actual count is -1. (A 1 means don't copy bytes) If the high nibble is zero an additional byte is loaded as the zero or copy previous counter. When bit 3 is set the last byte of the packet is used to point back to previous data. This also means no zeros are added.

Attached is a file that shows the location in the flash, the packet number, the packet bytes and in the last column the unpacked data for that packet.

[pcprogrammer]

Seems that my last post disappeared, so here it is again.

I found that the scope is loading data from flash at address 0x001FD000. (0x1F4 bytes)

Don't know what they are used for yet, but it might be some calibration data. So when one wants to flash new or hacked firmware make sure to backup the old one first and compare the data in that segment. Copy your own in when it is different.

Here is the data from my scope.

Code: [Select]

int8_t config_data[0x1f4] =
{
  0x01, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x06, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x01, 0x00, 0x0D, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00,
  0x0F, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x03, 0x00, 0xD3, 0x02, 0x00, 0x00, 0x00, 0x00,
  0x90, 0x01, 0x90, 0x01, 0x18, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x63, 0x01, 0x5F, 0x00, 0x2C, 0x01, 0x5F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3D, 0x00, 0x38, 0x00, 0x01, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0xDC, 0x00, 0x4D, 0x05, 0x45, 0x05, 0x54, 0x05, 0x4D, 0x05, 0x53, 0x05, 0x4C, 0x05, 0xD9, 0x00,
  0x5B, 0x05, 0x56, 0x05, 0x61, 0x05, 0x5B, 0x05, 0x60, 0x05, 0x5A, 0x05, 0x00, 0x00, 0x03, 0x00,
  0x01, 0x00, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x01, 0x00, 0x02, 0x01, 0x3A, 0x02, 0x00, 0x00, 0x5A, 0x00, 0xC1, 0x00, 0x05, 0x00,
  0x04, 0x00, 0x07, 0x00, 0x11, 0x00, 0x13, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x32, 0x14, 0x0F, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00
};