New bench scope - Fnirsi 1014D, 7", 1GSa/s

[pcprogrammer]

Houston we have got a problem

I tried the firmware I patched with both the initialization and translate function disabled and it does continue into the normal scope screen. Used the wrong version needed for my scope because the screen is shifted down and to the right, but that is no biggie.

I can see that the translations are not performed because the traces are not where they supposed to be.

This means that there is either another problem messing things up or the patched firmware did not load correctly, and thinking of it, the normal firmware upgrade procedure can't work since the check bytes won't be ok anymore. Forgot all about those.

So I would like to suggest another way to go forward in testing what works on your system. It involves writing a special startup program to the SD card and then load the firmware to test via USB.

I hope you have a linux system. Attached is a file "fnirsi_1013d_startup_with_fel.bin.txt". This needs to be loaded onto a SD card with "sudo dd if=fnirsi_1013d_startup_with_fel.bin of=/dev/sdc bs=1024 seek=8". Make sure to check which block device your SD card is connected to. Use "lsblk" to list the devices. Don't forget to unmount ("sudo umount /dev/sdc1") the partition otherwise "dd" won't work properly.

Stick this card in the scope and it will start with FEL operational. Connect the scope via USB to the linux machine and check with "lsusb" if the following device is present: "ID 1f3a:efe8 Onda (unverified) V972 tablet in flashing mode"

Now it is possible to load the firmware directly to DRAM. Use the following command to load and execute it: "sudo ./sunxi-fel -p write 0x7FFFFFE0 1014D_no_special_ic_no_translate.bin exe 0x80000000"

Remove the .txt extensions from the files. These are needed for uploading to the forum. Make sure the "sunxi-fel" file is executable and in the same directory as the "1014D_no_special_ic_no_translate.bin" file.

Hopefully the scope does the same as mine.

In the mean time I will continue with patching the firmware to have it do the needed translations.

[joseph4511]

going to download virtual box for Linux, which version do you suggest for me ? And i can not switch the device to usb mode because it does not respond anything. Can you backup the partition of your SD card so i can recover from that .img file to my SD card without any issue. What do you say ?

[pcprogrammer]

I'm using linux mint 20 Xfce, but any linux will do.

I assume you are running windows 10 and are going to use virtualbox on it to run linux. Might give problems with the USB link through, but might be fine.

You can just take the SD card from the scope and use a card reader/writer directly connected to the PC. Check that the FSI-1014D.bin file is no longer on the card. An option is to just re-format the card with FAT32 as type. The scope does not need any files to be on the card. It will create the needed files when they are missing.

The startup program I posted needs to be loaded to sector 16 of the card. Check the readme here: https://github.com/pecostm32/FNIRSI_1013D_Firmware. It is for the 1013D but the same applies to the 1014D.

[joseph4511]

loaded the with fel file correctly but fnirsi logo flashing and nothing happens

[pcprogrammer]

Strange.

When I start the scope with the "FEL SD card" in there I also see the startup image (logo) flashing a bit, but when I load the actual program with sunxi-fel it starts the scope software with the shifted display.

I made a video of how it works with my system: https://youtu.be/BbTE62INYpE

If you performed the same actions and it does not work then it is less easy to solve and more might be broken. The question is what.

[joseph4511]

okay i can see the usb as tablet let me flash the sunxi-fel

Edit: It says ./sunxi-fel command not found. I renamed the files.

[joseph4511]

okay i uploaded something but screen is still flashing

[pcprogrammer]

Well at least the sunxi-fel seems to be working. See that you found the version command and that it responded the same as mine.

Since it does not act the same as here it is safe to say something else is broken that stops the scope from continuing.

Lets see if this program works when loaded with sunxi-fel.

command: sudo ./sunxi-fel -p write 0x7FFFFFE0 fnirsi_1014d_firmware_backup.bin exe 0x80000000

Edit: when it works and it is done the SD card needs to be reloaded with the FEL start program.

[morgan_flint]

Since there is no idea on which chip they used for this special ic it will not be easy to get to the bottom of it. It is also not needed because I know what the main cpu needs from it...

Hello! I've been reading through this thread and came over the "mystery chip" issue, and it remembered me of a similar problem with Jyetech's scopes (DSO150 and DSO138 mini specifically).

Could that chip be an ATSHA204A or something similar?

That is like an I2C EEPROM (in fact, includes 4.5 Kb) but with some crypto authentication features. Jyetech uses it to avoid their firmware running on counterfeit copies of their products, by reading the unique serial number on the chip and checking it against an activation code specific for each serial number. Some more info here and previous posts.

Maybe FNIRSI is using a similar approach, or just including the chip in case they detect counterfeits in the future (the initial versions of DSO150 ran on counterfeits also until Jyetech started to include the activation code)

[joseph4511]

i goes black screen when i load the program

[joseph4511]

i do not think they have such a vision for this particular protection. Peter managed to run the software discarding lines which related to that chip.

[pcprogrammer]

Hmm, it should show a screen like what you see in this video:  https://youtu.be/h-tdKPDocHI

I'm beginning to think that there is a problem with the FPGA.

[joseph4511]

Maybe but how they died without any damage, dropping, heat ?


Edit: Do we have datasheet for FPGA or VCC points ? Maybe it is not getting enough voltage or something else. Because first one died for no reason, i turned off from button and tomorrow morning it died

[pcprogrammer]

Since there is no idea on which chip they used for this special ic it will not be easy to get to the bottom of it. It is also not needed because I know what the main cpu needs from it...

Hello! I've been reading through this thread and came over the "mystery chip" issue, and it remembered me of a similar problem with Jyetech's scopes (DSO150 and DSO138 mini specifically).

Could that chip be an ATSHA204A or something similar?

That is like an I2C EEPROM (in fact, includes 4.5 Kb) but with some crypto authentication features. Jyetech uses it to avoid their firmware running on counterfeit copies of their products, by reading the unique serial number on the chip and checking it against an activation code specific for each serial number. Some more info here and previous posts.

Maybe FNIRSI is using a similar approach, or just including the chip in case they detect counterfeits in the future (the initial versions of DSO150 ran on counterfeits also until Jyetech started to include the activation code)

No it is nothing of that kind. The main processor sends data to the chip and it in turns sends some altered data back. I have no idea why they choose this solution because the main processor can do this altering of the data itself without all the overhead and errors the communication causes.

[pcprogrammer]

Maybe but how they died without any damage, dropping, heat ?

The special ic is connected to the FPGA and it might caused damage to it when that first special chip died. Did you try both chips with your USB to I2C interface? I'm curious to see if both are actually dead.

Tomorrow I will take another look at the code to see if I can find a point where it might hang. The processor and the screen are working because the startup image is being displayed and the FEL mode is working.

You having the FEL mode now makes it a bit easier to have you do tests on your boards.

If the FPGA is damaged it is possible to replace it since we know it is an Anlogic AL3-10. Not sure if it is easy to get one. Aliexpress does sell boards with them. https://fr.aliexpress.com/item/1005001774923333.html

[joseph4511]

they both seem to be dead its great to buy with boards but unfortunately its expensive for me.

[pcprogrammer]

Yes I have a datasheet for the FPGA. It is to big to attach here, so I uploaded it to the githup repo: https://github.com/pecostm32/Lichee_Nano/tree/main/Hardware/Dake_Elec_FA201

Also take a look here for a schematic of the board Aliexpress sels: https://github.com/pecostm32/Lichee_Nano/blob/main/Hardware/Dake_Elec_FA201/Schematic_Dake_Elec_FA201_2022-01-23.pdf

[pcprogrammer]

they both seem to be dead its great to buy with boards but unfortunately its expensive for me.

I know they are not to cheap. There are tests that can be done to see if they are the problem. But that is for later. I'm getting tired now.

[joseph4511]

Thank you for your effords and patient. It s great to have a mate like you

[pcprogrammer]

Hi Yusef,

lets see if we can probe the boards some more. Do you have a stm32f103 bluepill board lying around? If so it is possible to make a jtag programmer for the Anlogic FPGA. See: https://github.com/pecostm32/Lichee_Nano/tree/main/Hardware/Anlogic_JTAG_Programmer

With such a jtag programmer it is possible to see if the FPGA is still responding by using the Tang Dynasty IDE. Read the posts on this page: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3885164/#msg3885164 They give a lot of info on the FPGA and the needed software.

I think the motherboard has a connection for the jtag programmer. It is next to the FPGA FLASH, but have to verify this by opening my scope.

If you do not have a bluepill I will see if I can whip up a simple test to check the FPGA via the CPU connection on the motherboard. I'm also going to look at the original firmware to see if I can pinpoint the spot the system hangs on.

Cheers,
Peter

EDIT: The connecter on the board is indeed the JTAG connector. See attached image with the pin names.

[pcprogrammer]

I'm looking at the hardware to see how it differs from the 1013D and noticed that they changed the FPGA clock setup. Instead of a 50MHz crystal oscillator it has a 25MHz crystal and a MS5351M clock synthesizer chip. The MS5351M is controlled via I2C which bit banged by the F1C100s. It uses pins 65 and 66 of the CPU.

They use two outputs of the synthesizer to clock the FPGA. Pins 23 and 24.

I might as well do a full reverse engineering of the schematic now I have it lying open on my desk

[pcprogrammer]

Hi Yusef,

there is another test you can run to determine if the firmware passes a certain point. Remove the SD card and turn the scope on. It should give a black screen with red text "SD ERROR"

Cheers,
Peter

[joseph4511]

Hey Peter

i tried to launch without SD card many times, never ever passed Fnirsi logo. Could not managed to pass that screen. I do not have bluepill board but i have arduino IDE and Arduino Mega and USB005 for special Infineon IR pwm controllers and gate drivers. I found TD Dynasty last night. Found the pinout of AL3-10 checked voltages and found nothing.

[pcprogrammer]

Ok that narrows it down to the first bit of the code. Tomorrow I will look at it to see if I can find why this happens.

The problem with the JTAG of the FPGA is that there is no open source project that can be converted to an Arduino Mega, At least as far as I know. So this means another approach is needed.

[joseph4511]

i ordered the stm32 dongle, it arrives 4 days later.