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

[pcprogrammer]

Maybe you have them lying around, but you also need a 74LVC125. This is really needed since the FPGA in the scope uses 2,5V and the STM runs on 3,3V, so the levels need to be matched.

[pcprogrammer]

They are probably not intended for actual connectors, but why oh why did they use to small a holes. I want to solder headers into these holes to be able to connect to the FLASH and FPGA more easily and only the JTAG one allowed me to stick a standard 2.54mm double row header into it. For the others I have to grind down the pins a bit. Don't want to drill out the holes to not ruin the through hole plating.

Also lifted the metal cans to be able to reverse the power and analog circuitry. Will post pictures and the schematics when I'm done.

[pcprogrammer]

Here are some pictures of the naked board and the front part of the case.

[pcprogrammer]

Sure i can upload. Also uploaded the image of special IC with marking

Hi Yusef,

I read the FLASH for the FPGA on my scope and compared it with yours. The files are the same, so no problem there.

Cheers,
Peter

[pcprogrammer]

Need some info on some SMD components.

There are two sot-23 components in the power supply part to turn the scope on. One has Y1 as marking and I found SS8050 as a possible candidate. The other one has R1 as marking. This one switches the 5V so needs to be a beefy transistor or fet.

I found this site https://www.hotenda.com/marking-code/search/list/R1.html but it lists a lot of components with this marking. Google did also gave PDTB1132T as a possible hit but it does not support more then 500mA, so might be to lightweight for the task.

[Kean]

"R1" marking could be CJ3401 P-Ch MOSFET 30V 4.2A
https://lcsc.com/product-detail/MOSFETs_Changjiang-Electronics-Tech-CJ-CJ3401_C13799.html

[dmitrkov]

https://www.s-manuals.com/smd/r1

[joseph4511]

yes its a p channel mosfet, 5v across drain to source

[pcprogrammer]

Hi Yusef,

I thought up another test to see if it is possible to load the first bit of the DRAM.

Use sunxi-fel to set the display engine to use the first part of the DRAM:

Code: [Select]

sudo ./sunxi-fel writel 0x01E60850 0x00000000
sudo ./sunxi-fel writel 0x01E60860 0x00000004

Then load the attached image data to the memory with:

Code: [Select]

sudo ./sunxi-fel -p write 0x80000000 scope_image.bin.txt

You should see the image building on the screen while it loads.

I also found the reason why the screen flickers when the boot with FEL option is used. The FPGA controls the brightness of the screen with PWM. For this to work the FPGA needs a clock, and that is what is missing. The F1C100s has to initialize the clock synthesizer for this. I'm still looking through the original code to find where this is done.

Another thing I discovered is that the GD32E230 is used to control the power. It generates a hold signal to keep the P-FET active. When the power button is pushed again it is signaled by the GD32E230 and it then releases this hold signal.

Most of the schematic is similar to the 1013D. One difference is that the MCU and FPGA use a separate 3V3 power source. Have done quite a bit already but still need to do the GD32E230 part, which is new since the 1013D just has a touch panel.

[pcprogrammer]

Schematics are done.

Did not check the capacitors and only gave them an identifier. Also not in a nice logical order since I used the 1013D schematics as a starting point.

There are some changes compared to the 1013D but nothing major. The FPGA connections changed a bit and the power supply setup is different. The analog input is mostly the same. They used 3,3V for the opamps instead of the 2,5V used in the 1013D.

The buttons on the front panel are scanned in a 6x6 matrix, but they did not use diodes so no usage of multiple buttons at once. No need for it so no problem. The rotary encoders all have separate connections on the GD32E230.

A bit of a shame that they did not add a battery and an extra diode and made use of the RTC that sits in the GD32E230. Would have given the saved files a proper time stamp. Due to the fact that the resistor networks used for rotary encoders are sourced from the GD32E230 3,3V supply it is a bit harder to make a modification. It would drain the battery at a higher rate then needed.

I'm going to rename the 1013D hack repository and upload the 1014D material there.

[pcprogrammer]

Since the PCB also has pads for a SWD connection with the GD32E230 I though lets give it a try and read the FLASH.

Did not work with the openocd version I had installed (0.10.0) but with the latest build from here: https://github.com/xpack-dev-tools/openocd-xpack/releases I was able to read the flash. Have not looked at it with Ghidra but with a hex editor it looks like vectors followed by code and then 0xFF till the end. It is a bit over 7KB of code.

So no protection by the looks of it.

Attached is the binary and a picture of the connector with pinout

[tv84]

Have not looked at it with Ghidra but with a hex editor it looks like vectors followed by code and then 0xFF till the end. It is a bit over 7KB of code.

AFAIK doesn't seem to have any visible ARM code...

[pcprogrammer]

AFAIK doesn't seem to have any visible ARM code...

Well I have looked at it and it is ARM code. I used ARM Cortex little and set the starting point on 0x08000000. This way it looses the awareness of the vectors but they are there. The first four bytes are the stack start address. The next four bytes hold the reset address. Formatting the data into a hex file where the actual code starts in the 0x08000000 region and the vectors in the 0x00000000 region can solve this.

Also found addresses of GPIO and USART0 in the code. A first glance makes me think it is not that complex a code.

Might be easier to reverse this to get to the inter MCU communication then plowing through the F1C100s code.

It is just playing around a bit. Satisfying my natural curiosity. Not planing on fully reversing the 1014D nor making new firmware for it.

[pcprogrammer]

I looked through the 1014D second program loader to see if I could find how they setup the FPGA clock synthesizer, but it turns out they don't. Instead they write 0x78 to the FPGA for the brightness command 0x38.

So I tried that in the 1014D firmware backup program I wrote and lo and behold it did the trick. The display no longer flickers. Also modified the boot with FEL code and uploaded both to the renamed hack repository: https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack

The initialization of the FPGA clock synthesizer is done in the main firmware but I have not looked for it. Did notice a difference in the FPGA_Init where it sets the according GPIO pins to outputs.

Curiosity satisfied for now

[pcprogrammer]

Go figure 

I did some searching on the web to find something about a newer AD1013D II scope in response to a question asked on the 1013D firmware repository. Did not find anything about it but I did find that the Aiteme ADS1014D is the top number 1 scope around

https://www.findthisbest.com/best-lab-oscilloscopes/metric

Makes you wonder where they based there conclusions on

Had not yet heard of the Aiteme brand but the scope looks just like the FNIRSI one.

[pcprogrammer]

It was a bit of a search and gathering of resources but I now have a .svd file for the GD32E230. The addon package for the GD32E230 from the GigaDevice site https://www.gd32mcu.com/en/download/0?kw=GD32E2 has a .svd file but it misses a lot of the core peripherals like the systick timer and Ghidra stumbled on an overlap between the SYSCFG and CMP peripherals.

Used data from the ATSAML11E16A.svd file I found on the net to complement the core peripherals. Not sure if it is all correct but it is also a Cortex-M23 device. Could not find documentation on the GD32E230 that has info about the core peripherals. Just the peripherals added by GigaDevice like USART, ADC, etc.

Now the de-compiled code in Ghidra shows the name of the peripherals and the registers being used. A very nice feature I must say. Wish I knew about that when I started the reverse engineering of the 1013D

All the ARM instructions used are thumb or thumb-2 since the Cortex-M23 does not support the full ARM instruction set. Jump addresses have the lowest bit set because of this.

Attached both files but had to add the .txt extension to upload them.

[mkstevo]

I don't seek to claim that Hameg should be worried by FNIRSI, the two are polar opposites, but for the life of me I can't understand the snobbery towards FNIRSI.

Despite your experience you have overlooked the most basic of scope requirements, input sensitivity and input ratings !

With a max sensitivity of only 50mV/div and 40V max at 1x input attenuation severely limits this scope for even basic use. Only by adding a 10x probe is the input rating increased to 400V, a rating that is standard at 1x for most other DSO's available however with a 10x probe max sensitivity becomes 500mV/div !

Snobbery, be buggered, practical usefulness is what really matters.

I'm not sure I did overlook that. I've never once needed to measure 0.0x Volts. The aircraft monitoring systems we used to manufacture used a pressure transducer that gave an output of nominally 30mV before amplification, that would certainly be visible when checking that a valid signal was being presented to the amplifier. In the industry I now work in everything has 5V, 3.3V or 1.8V logic. Would 50mV be enough to display that? Yes. At home where I use my FNIRSI, it is mainly used for tracing faults in valve (tube) audio and transistorised audio, vintage video equipment repairs and my personal designs for electronic clocks. All with voltages well above 50mV.

Is it not possible to accept that for some people, the FNIRSI is all that they might need? I accept not for people who need that bit more in the way of performance and have the budget to pay for that performance, but for a hobbyist, with limited requirements and limited funds the FNIRSI is a value alternative and eminently practical and useful.

[tunk]

Review by Kerry Wong, summed up as "oh man, this is bad":

[tunk]

Is it not possible to accept that for some people, the FNIRSI is all that they might need?

All tools have their uses, and if you know their limitations they may be good tools.
But I'm not sure if your 30mV transducer is a good example. The 50mV/div setting is
in software only, in hardware it's 100mV/div. The +/-5% accuracy and 1V full scale
gives 50mV inaccuracy, so your 30mV may drown in noise and inaccuracy.

[pcprogrammer]

Apparently not a lot of people find the postings about test equipment on EEVblog There is a lot of comments on the video stating how glad people are he did the review and that it is not a positive one.

All that is shown in the video was already known way back from the work done on the 1013D and the 1014D.

Around 8:50 in the video he even does not notice the sudden rise in amplitude when the signal goes from ~41MHz to ~42MHz, which is when the software starts to calculate the sine wave instead of using the actual points, just as it does in the 1013D.

Around 15:09 he assumes the firmware to live on the SD card, which we all know is not the case. He should have consulted this thread before doing his review. Have noticed this missing with other reviewers too. A bit of a shame because this blog is full with useful information.

It seems he has a later unit fitted with the F1C200s instead of the F1C100s, which we also already knew from joseph4511 his posts.

All in all "mosterd na de maaltijd" like the Dutch would say. (Literally translated "mustard after the meal" and meaning "too little too late")

[chupocro]

Quote from: pcprogrammer on May 05, 2022, 06:42:35 pm

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.

Hi, I've seen you've done an excellent job reverese engineering 1014D and I've been through all the posts (and briefly checked the github repositories) but still couldn't find out what exactly is the purpose of SD card in that oscilloscope.

I thougth the device needs the SD card to boot but you said everything would work even if SD card is formatted. What is the SD card then used for? A swap file or for some temporary files during the operation? What happens if the device is turned on without SD card?

Do you thing it would be possible to add protocol decoders (I2C, SPI, ...) to the firmware?

[pcprogrammer]

Hi chupocro,

the SD card is used for storing the screen capture (picture) and waveform files you can make with the scope. Without a card in the scope it will not startup. It will instead show an "SD ERROR" message.

I did not fully reverse engineer the 1014D, nor the 1013D for that matter. Did the schematics and partially the software for both. For the 1013D I wrote new firmware based on knowledge gained from the partial reverse engineering of the software, but thanks for your praise

Adding protocol decoders is not simple to do, because the sampling is not continues over time and the sample memory is to small. It would require a hardware implementation in the FPGA, and then still would not be so easy.

A bit of a problem with these two FNIRSI scopes is that there is no simple way to update the bit stream for the FPGA. For the firmware there is support in the original firmware to do updates, but not for the bit stream.

[chupocro]

Quote from: pcprogrammer on Yesterday at 07:01:20 am

Hi chupocro,

the SD card is used for storing the screen capture (picture) and waveform files you can make with the scope. Without a card in the scope it will not startup. It will instead show an "SD ERROR" message.

I did not fully reverse engineer the 1014D, nor the 1013D for that matter. Did the schematics and partially the software for both. For the 1013D I wrote new firmware based on knowledge gained from the partial reverse engineering of the software, but thanks for your praise

Adding protocol decoders is not simple to do, because the sampling is not continues over time and the sample memory is to small. It would require a hardware implementation in the FPGA, and then still would not be so easy.

A bit of a problem with these two FNIRSI scopes is that there is no simple way to update the bit stream for the FPGA. For the firmware there is support in the original firmware to do updates, but not for the bit stream.

I am going to buy that oscilloscope as I don't need bandwidth greater than a few MHz and even 100 mV/DIV is more than enough for the measurements I'll be doing. I like it boots very fast, is very lighweight and can be powered from the battery pack. For decoding protocols I can still use logic analyser and PulseView.

DSO2D10 might have better bandwidth and more memory for wave capturing but it costs $80 - $100 more and I don't like how trigger level is jumping when changing the time scale and besides it seems to be much slower than 1014D.

I can see you are an expert at reverse engineering, do you by any chance know which would be the easiest way of reversing the Motorola HC908 code? I'd like to reverse engineer parts of the code from MC68HC908AZ60 microcontroller and I could do that by disassembling the .hex and examining it but I wonder if I could use Ghidra with that instruction set. I once reversed the code form 12F629 which was under 1k but it took me a while to analyse the complete code and it was quite tedious. That's why I'd like to know if there is a better way of analsying HC908 code. I somewhere read there is IDA plugin for HC908 arhitecture but I couldn't find if Ghidra could be used as well.

[pcprogrammer]

Hi chupocro,

you seem to not be aware of the "Quote" button, judging by the way you quoted my previous post. Also there is no need to repeat someones text if there are no other posts in between. I'm just mentioning this because there was a lot of turmoil lately on the forum and unneeded quoting was mentioned as being annoying.

If the features of the scope are sufficient for your needs, then sure, it is usable. And since you mention having looked into the DSO2D10 you made a weighted decisions and that is the way to do it.

For the reverse engineering of HC908 code I have no idea if Ghidra can be used for it. I'm no real expert on reverse engineering. The FNIRSI was my first go at it and even with Ghidra it was difficult and tedious to get to the bottom of things. It depends a lot on how big and complex the code is of course, and also if you already have an understanding of what the target is doing.

The thread about the FNIRSI 1013D shows the whole process over time. It also shows that I wrote my own emulator to run the scope code on the computer, just to be able to trace what functions where doing. This because it used a lot of function pointers. These are almost impossible to figure out from just a dissembled piece of code.

[Rasz]

Review by Kerry Wong, summed up as "oh man, this is bad":

Fnirsi should perhaps rebrand to 差不多 (Cha bu duo)