FNIRSI-1013D "100MHz" tablet oscilloscope

[pcprogrammer]

Thanks Peter. I already had gnu-arm-none-eabi  of course or nothing would have compiled. Lots of modules compiled correctly just not the last. Doesn't the makefile determine the order of the build? The code already makes pretty good sense to me but the build process is not working due the error above...

There is no overall make file. Each project has its own make file. What is integrated in them is the copying of the output to the other project directory and the merging them together to make the needed single binary to load on the SD card.

With "project" I mean a set of .c and .h files that contain a single main function and other functions needed to make the compiled binary.

The only make file I see is the one in the directory with the .c and .h files. That isn't the make file for the "project"?

Look in the nbproject directory in each project. There are the dedicated .mk files for the different configurations like debug and release. These are called from the main make file.

[pcprogrammer]

PC: How is a specific PIN set in the processor, should it be input or output? Are the pins open collector?
If I want to set the MISO-61-PC2 pin as an input, how do I do it?
Or is it already set somewhere as an output?
How can I load it? (if pin==1) through which register?

I am considering connecting a pull-up resistor and an optocell there. It would serve as an external trigger (max 12V input). The BNC should be placed next to the power switch, at least for the glass version...

Sometimes it's good to have it. For example, when debugging uP, ext trigger, it is possible to see a specific part of the process, e.g. i2c code

Take a look at the user manual. Chapter 3.7 tells you everything you need to know.

[dfw_ee]

Did you see the picture? you have the complete path to the MAKEfile there.

Yes, the problem was never the Makefile. I did "make all" and that caused the problem. I don't know why I didn't just type make. Had been up way too long I guess  Anyway, I am able to build everything now including the TPx versions

Thanks for all the help Atlan and Peter!

[dfw_ee]

Finally the scope touch screen is working normally again. I used the TP1 executable and a hex editor to change the 0x8047 register to a 0xBD to reverse the axis. Ran the executable and all is good. I had tried setting values in registers 0xB7 to 0x80C4 with 0x8047 set to FD but could not get it to work completely right. The axis were correct but the touch points were about 1 square below what was printed.

Thanks Atlan for writing the various TP programs! I am able to build these but when loaded on the SDCard it isn't loaded but boots from the internal flash. This is what happened with your orginal TP4 version. Any idea what is causing this? I got around it by just hacking the TP1 file with a hex editor.

Thanks Peter for all the help and pointing me to the display programming manual.

[pcprogrammer]

Finally the scope touch screen is working normally again. I used the TP1 executable and a hex editor to change the 0x8047 register to a 0xBD to reverse the axis. Ran the executable and all is good. I had tried setting values in registers 0xB7 to 0x80C4 with 0x8047 set to FD but could not get it to work completely right. The axis were correct but the touch points were about 1 square below what was printed.

Thanks Atlan for writing the various TP programs! I am able to build these but when loaded on the SDCard it isn't loaded but boots from the internal flash. This is what happened with your orginal TP4 version. Any idea what is causing this? I got around it by just hacking the TP1 file with a hex editor.

Thanks Peter for all the help and pointing me to the display programming manual.

Sounds like the boot loader is missing. The first 32 bytes of sector 16 on the SD card need to be the eGON boot header for the F1C100s to start loading the actual boot loader into the internal SRAM. The boot loader is then executed and this will enable the DRAM and load the actual program.

The bytes need to be like shown below.

Code: [Select]

06 00 00 EA 65 47 4F 4E 2E 42 54 30 F7 6F 69 AE 00 3A 00 00 53 50 4C 02 00 00 00 00 00 00 00 00


[Atlan]

 download again, fixed
https://github.com/Atlan4/Fnirsi1013D/blob/main/TP%20write%20config%20v0.023x.zip

tp3 and tp4 work, TP4 contains all 4 data fields

firmware is:  fnirsi_1013d.bin

[dfw_ee]

download again, fixed
https://github.com/Atlan4/Fnirsi1013D/blob/main/TP%20write%20config%20v0.023x.zip

tp3 and tp4 work, TP4 contains all 4 data fields

firmware is:  fnirsi_1013d.bin

Thanks!

[Atlan]

Test firmware for Tokar.
Add DC offset auto settings for CH1. Try CH1.

[dfw_ee]

download again, fixed
https://github.com/Atlan4/Fnirsi1013D/blob/main/TP%20write%20config%20v0.023x.zip

tp3 and tp4 work, TP4 contains all 4 data fields

firmware is:  fnirsi_1013d.bin

There is still something I am missing. What is the process that converts from the fnirsi_1013d_scope.bin which is 258,048 bytes to the fnirsi_1013d.bin 0.023 TP1 write.txt which is 297,032 bytes and has the boot loader. The extra bytes I'm assuming is the boot loader but I don't know the process for getting there. Is it something post to the build or is it a make target or something else? The .txt versions boot from the sdcard and the .bin do not. My builds only produce the .bin that is the smaller size. These 2 versions were in the zip file you sent before I did any builds.

Sorry I haven't figured this out...

[Atlan]

Last uploaded TPczip. In it, all versions of bin, run alternative firmware

Do not change the names of the files in the working folder!!!
mksunxi and flashfilepacker and fnirsi_1013d_scope.elf They must be set in properties as executable.


If the names are correct, the program that is there will combine all 3 bins from the projects into one. fnirsi_1013d.bin

[pcprogrammer]

mksunxi is used to fix the checksum in the program header the boot loader uses. This is a tool written by the sunxi group.

flashfilepacker is the one who takes the separate bin files and sticks them together in the final bin file. This is a tool I wrote myself. Source can be found here.

[Atlan]

Small fixes, adding offset to both channels. Bit of a miscalculation of the shift. I will finish later. Firmware v0.024c

Modified instructions for the oscilloscope. FNIRSI 1013D  alternative firmware v0.024c ANG v1.doc

[dfw_ee]

Last uploaded TPczip. In it, all versions of bin, run alternative firmware

Do not change the names of the files in the working folder!!!
mksunxi and flashfilepacker and fnirsi_1013d_scope.elf They must be set in properties as executable.
(Attachment Link)

If the names are correct, the program that is there will combine all 3 bins from the projects into one. fnirsi_1013d.bin

I have used the latest TPczip. I extracted the files and made no changes whatsoever. I did a make in the TP1 directory and it built a .bin file that replaced the .bin file that was already in your directory. It did not replace the combined .txt file. It is the .txt files that actually work. Here is the last part of the build process which seems to match the picture you sent the other day:

arm-none-eabi-objcopy -O binary dist/Debug/GNU_ARM-Linux/fnirsi_1013d_scope.elf dist/Debug/GNU_ARM-Linux/fnirsi_1013d_scope.bin
./mksunxi dist/Debug/GNU_ARM-Linux/fnirsi_1013d_scope.bin
bootloader size= 3f000
The bootloader head has been fixed
./flashfilepacker -o dist/Debug/GNU_ARM-Linux/fnirsi_1013d.bin -i dist/Debug/GNU_ARM-Linux/fnirsi_1013d_scope.bin -l 0x9800

From above it looks like only the .bin file is the output and this file does not load on the sdcard. The .txt file that pre-existed in your directory does load. The pre-existing .bin file does not. It behaves the same as the new bin files that I build. No names have been changed nor anything else after the unzipping. How did the .txt files come about? It isn't a simple renaming of the .bin file.

[pcprogrammer]

The output file to look for is fnirsi_1013d.bin

the command "./flashfilepacker -o dist/Debug/GNU_ARM-Linux/fnirsi_1013d.bin -i dist/Debug/GNU_ARM-Linux/fnirsi_1013d_scope.bin -l 0x9800" takes the data from fnirsi_1013d_scope.bin and copies it to fnirsi_1013d.bin starting from location 0x9800.

There should already be a fnirsi_1013d.bin file in the directory with the boot loader and splash screen code in it, and then it adds the scope program to it. If there is no existing fnirsi_1013d.bin file it will create it and put zeros in the space before 0x9800.

When there is one with the scope program already in there it will be overwritten with the new data, so it can be reused over and over. No need to rebuild the boot loader and splash screen code as long as there is a valid fnirsi_1013d.bin file with these two in it.

[Atlan]

Look again at the last picture I put here, you must not have any other files there.  And no more files with a similar name to txt

I said TP4. No tp1 no tp2

[dfw_ee]

The output file to look for is fnirsi_1013d.bin

the command "./flashfilepacker -o dist/Debug/GNU_ARM-Linux/fnirsi_1013d.bin -i dist/Debug/GNU_ARM-Linux/fnirsi_1013d_scope.bin -l 0x9800" takes the data from fnirsi_1013d_scope.bin and copies it to fnirsi_1013d.bin starting from location 0x9800.

There should already be a fnirsi_1013d.bin file in the directory with the boot loader and splash screen code in it, and then it adds the scope program to it. If there is no existing fnirsi_1013d.bin file it will create it and put zeros in the space before 0x9800.

When there is one with the scope program already in there it will be overwritten with the new data, so it can be reused over and over. No need to rebuild the boot loader and splash screen code as long as there is a valid fnirsi_1013d.bin file with these two in it.

This was very helpful to understand the process of how the sdcard binary is built. The problem was the fnirsi_1013d.bin had all zeros at the top instead of the bootloader and splash screen. I grabbed one that had it and did a build and everything now works.

Thanks!

BTW, I saw your youtube video about the touch screen issue you originally had with it not responding in certain locations. I think I read that is what sent you down this whole reverse engineering path. This work that you did on the reverse engineering is very impressive! Did you get that particular unit to ever work?

[dfw_ee]

Look again at the last picture I put here, you must not have any other files there.  And no more files with a similar name to txt

I said TP4. No tp1 no tp2

Thanks, got it working. Many thanks for putting together the TPx programs!!

[Atlan]

Does TP work properly?

[pcprogrammer]

BTW, I saw your youtube video about the touch screen issue you originally had with it not responding in certain locations. I think I read that is what sent you down this whole reverse engineering path. This work that you did on the reverse engineering is very impressive! Did you get that particular unit to ever work?

Yes that is what started it all. I did get the unit working again, but with an acrylic screen so it looks a bit shitty.

It was a fun project and I learned a lot from it.

[Atlan]

PC:
In what range can the numbers be for setting the DC offset
#define HIGH_DC_OFFSET   500
#define LOW_DC_OFFSET   1200

Zero calibration is around 860 - 870

So what are the limits if I want to use it to shift the signal.  Thx

[pcprogrammer]

PC:
In what range can the numbers be for setting the DC offset
#define HIGH_DC_OFFSET   500
#define LOW_DC_OFFSET   1200

Zero calibration is around 860 - 870

So what are the limits if I want to use it to shift the signal.  Thx

The FPGA counts from 0 to 1999 clocked on 50MHz to make the carrier frequency for the offset. So 25KHz at the output. The setting for the pulse width is a 16 bit value but in this case the useful range is 0 to 1999 for 0% to 100%.

As it is running of 3.3V IO this would mean 0 to 3.3V. The used ADC input range is smaller than that due to the input opamps running on 2.5V.

The given high and low values probably come from the original code.

[Atlan]

According to me, there is a mistake in the scheme, at least my glass versions of the oscilloscope have 3.3V on the operands.

[tokar]

DC measurements for v0024b CH 1.
For v0024c the table is similar.

[pcprogrammer]

According to me, there is a mistake in the scheme, at least my glass versions of the oscilloscope have 3.3V on the operands.

It might well be that they have changed things. The version I used to draw up the schematics definitely has 2.5V on the opamps. Have measured it with a DMM.

[Atlan]

Tokar: does that mean it's good?
PC:The reference is 1.25v, so it doesn't matter if the device has 2.5 or 3.3V, because the downward shift from the reference is always the same.

Does anyone have firmware 0.0.  24c on a device that does not have embedded connectors.  That is, the first version of the oscilloscope.  Could you post a screenshot of the diagnostic screen?  (ideally calibrated) but it must be firmware 0.024c and must be after activation of the autorange without a connected signal on both channels.