Here is the tool plus the steps to make it work.
!! I take no responsibility if anything goes wrong !!
Steps for making the FNIRSI-1013D firmware backup on a Linux machine:
- Connect the scope to the computer via USB.
- Turn on the scope and start the USB connection via the main menu option.
- Wait until the file manager window opens. (Only if auto mount is working properly)
- Close the file manager window.
- Open a terminal window (ctrl + alt + t) and type the "lsblk" command (!do not use the quotes!) and check which device the scope is on. (~8GB disk)
- Copy the files from the card to have a backup on your computer.
- Un-mount the partition. ("sudo umount /dev/sdc1" in my case)
- Just to be more safe make a backup with dd. ("sudo dd bs=4M if=/dev/sdc of=sd_card_backup.bin" again in my case)
- Open gparted and check if the device is properly formated. (Use right mouse and information to see the sector info)
- If not delete the partition and make a new one leaving 1M free at the start. Format is fat32.
- When the partition remounts after the previous step un-mount it again.
- Use dd to place the backup package on the SD card. ("sudo dd if=fnirsi_1013d_fwb.bin of=/dev/sdc bs=1024 seek=8")
- This will re-mount the partition. Un-mount the partition again. ("sudo umount /dev/sdc1" in my case)
- Turn of the scope and turn it back on. This will start the backup process.
- Wait until it is done and the scope is mounted again. File manager window should open after a while.
- Copy the three files to the computer. (FNIRSI_1013D_full_flash_backup.bin, FNIRSI_1013D_tp_config.bin, FWB_FSI_1013.bin)
- Turn off the scope and turn it back on. It should start normally.
When the scope showed the "!! special touch panel detected !!" message please upload the "FNIRSI_1013D_tp_config.bin" file in this thread.
If your scope uses a smaller or bigger SD card be warned that this is not tested yet. Only 8GB cards have been tested.
See the attached image for info on the sd card sectors. Screen cap from gparted.
Remove the .txt extension from the firmware backup package file.
https://youtu.be/J_cZJTdngeQ?feature=shared
Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.
Thanks
https://youtu.be/-eb8TvmtihE?feature=shared
Part of the beam displays the current value, and part of the false one
https://youtu.be/J_cZJTdngeQ?feature=sharedThis also happens on my device, although to a lesser extent.
https://youtu.be/UYh5JF16DdE
Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.
Thanks
The original firmware writes a configuration to the touch panel that should make it work correctly, as long as the two where compatible with each other from the start.
The 1013D comes with different displays and touch panels and therefore also different firmware. After repairing my initial 1013D with a new touch panel, the coordinates were also reversed. That is why I started the reverse engineering. Somewhere in this thread there is more info about it. It has been to long for me to recall the exact details.
So ask yourself if you loaded new original firmware to the flash and with that messed it up, or swapped the top halves of the two scopes. It can be fixed, but for that you will have to read through this thread. Start at page 19 or so.
Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.
Thanks
The original firmware writes a configuration to the touch panel that should make it work correctly, as long as the two where compatible with each other from the start.
The 1013D comes with different displays and touch panels and therefore also different firmware. After repairing my initial 1013D with a new touch panel, the coordinates were also reversed. That is why I started the reverse engineering. Somewhere in this thread there is more info about it. It has been to long for me to recall the exact details.
So ask yourself if you loaded new original firmware to the flash and with that messed it up, or swapped the top halves of the two scopes. It can be fixed, but for that you will have to read through this thread. Start at page 19 or so.
I have not even taken the ribbon cable out of the displays let alone take out the displays. I had not loaded new original flash nor had I even run a flash operation. The closest I came was setting up an SD card with fnirsi_1013d_startup_with_fel.bin and running your code out of RAM. The first version I found of fnirsi_1013d_startup_with_fel.bin on github did not work and left the screen magenta and many pixels blinking and no allwinner devices found using lsusb. I found another version on github that worked as expected. It was after this that the display became reversed on the x coordinate. It seems maybe that the first version that didn't work correctly may have been the culprit but I wouldn't have thought this would be the case. At this point I had never flashed any code into the scope.
After your message above I tried re-flashing the code from the backup into the scope. It behaves the same with the reversed coordinates. Additionally, I have already read this whole thread and it did not look like anyone had this experience as I have made absolutely no changes to the HW.
Thanks for your reply. I hope there is some way to get this working again...
Is there a utility to restore the tp configuation after it is saved with this tool? Somehow one of my units now has the touch screen coordinates backwards. I was able to fix this running your code with the config file but this doesn't help with the original firmware of course. I didn't have to use your config file previously either before this issue cropped up. I don't know how this came about but I compared my original FNIRSI_1013D_tp_config.bin to one that I got from the fwb tool after this issue cropped up and there are a few bytes different between the files. I would really like to get this back working with the original firmware as well.
Thanks
The original firmware writes a configuration to the touch panel that should make it work correctly, as long as the two where compatible with each other from the start.
The 1013D comes with different displays and touch panels and therefore also different firmware. After repairing my initial 1013D with a new touch panel, the coordinates were also reversed. That is why I started the reverse engineering. Somewhere in this thread there is more info about it. It has been to long for me to recall the exact details.
So ask yourself if you loaded new original firmware to the flash and with that messed it up, or swapped the top halves of the two scopes. It can be fixed, but for that you will have to read through this thread. Start at page 19 or so.
I have not even taken the ribbon cable out of the displays let alone take out the displays. I had not loaded new original flash nor had I even run a flash operation. The closest I came was setting up an SD card with fnirsi_1013d_startup_with_fel.bin and running your code out of RAM. The first version I found of fnirsi_1013d_startup_with_fel.bin on github did not work and left the screen magenta and many pixels blinking and no allwinner devices found using lsusb. I found another version on github that worked as expected. It was after this that the display became reversed on the x coordinate. It seems maybe that the first version that didn't work correctly may have been the culprit but I wouldn't have thought this would be the case. At this point I had never flashed any code into the scope.
After your message above I tried re-flashing the code from the backup into the scope. It behaves the same with the reversed coordinates. Additionally, I have already read this whole thread and it did not look like anyone had this experience as I have made absolutely no changes to the HW.
Thanks for your reply. I hope there is some way to get this working again...
Of course there is. By the sound of it your version of the 1013D does not write the configuration to the touch panel and it then indeed got screwed up by using a wrong version of code I wrote.
A bit of background. I wrote lots of test code while working on the reverse engineering to get to the bottom of it all. At some point, after noticing that there are different hardware version of the scope out there, I decided to not write the touch panel configuration, like my first version of the 1013D did and use the touch panel as is to control the scope with the new firmware. To allow for touch panels with the coordinates swapped to still work I added a configuration option to tailor for the different hardware. Same as with the different displays.
So now back to your problem. The way to solve it is to write a correct configuration to the touch panel, and this can be done with any device that has an I2C interface. Keep in mind that the touch panel works on 3.3V, so when using a MCU running on 5V use some 100 Ohm serial resistors and 2K2 to 4K7 Ohm pullup resistors to 3.3V.
The programming guide for the touch panel can be found here.
In the touch panel configuration there are two ways to reverse the coordinates, but I only used the order of the scan lines to do the swap. The data in question starts on address 0x80B7 - 0x80C4 for the y direction and 0x80D5 - 0x80EE for the x direction. I might be mistaken which is for which. Doing this from memory.
When you have a bluepill lying around you can take a look at the project here.
Thanks for the info. Isn't it possible to use your bit banged I2C code on github to reprogam the touch panel configuration instead of connecting other hardware? It seems that is what happened in the first place. Once again thanks for the help!
PC:
Where do these numbers come from?
1800, //200ms/div 12
1800, //100ms/div
1800, // 50ms/div
1800, // 20ms/div (Was 800, but that does not yield enough samples)
1800, // 10ms/div
2500, // 5ms/div
2500, // 2ms/div
2500, // 1ms/div
Thanks for the info. Isn't it possible to use your bit banged I2C code on github to reprogam the touch panel configuration instead of connecting other hardware? It seems that is what happened in the first place. Once again thanks for the help!
Sure it is, but you have to write it yourself. The code can be small enough to do it in the bootloader. Just take that project and remove the loading of the next code and stick in the I2C bit with the needed touch panel configuration. All the needed bits and pieces can be found in what I wrote. It might even still be in the new firmware disabled with a define.
Those numbers are sent to the FPGA
//short time base
void fpga_set_time_base(uint32 timebase)
{
//Make sure setting is in range
if(timebase < (sizeof(timebase_settings) / sizeof(uint32)))
{
//Write the command to set the short time base data to the FPGA
fpga_write_cmd(0x0E);
//Table settings ranges from setting 0 (200mS/div) to 23 (5nS/div)
fpga_write_int(timebase_settings[timebase]);
const uint32 timebase_settings[35] =
{//long time base
1800, //50s/div
1800, //20s/div
1800, //10s/div
It worked until now, I don't understand why it broke. The numbers are always sent the same. It looks like the fpga has finished filling the magazine early. I don't know if they didn't feel the flood numbers because sometimes only 750 samples are taken. because 1500 samples are taken, the times are short and the collection is finished sooner. But again, it doesn't agree, so why does it somehow work when switching to a higher number and then back to sleep (however, some sampled data is still missing at the end.)
I increased the number, but that's a bad solution because I don't know where the problem actually is.
v0.023x