Reverse engineering the FNIRSI 1014D

[pcprogrammer]

As announced in the original thread about the FNIRSI 1014D is here the new thread about the reverse engineering project.

I just finished coding the main functions for displaying most of the user interface objects. It was a lot of tweaking and looking for the bitmaps in the original code to write it all up and get the positions on the screen to be correct.

So far the following bits are coded:

• My logo 
• The basic display with the grid
• The run/stop text
• The fast/slow text
• The trigger information
• The channel information
• The time base information
• The trigger status (Waiting.../Triggered)
• The measurements in the six slots on the right side of the screen
• The main menu
• The channel configuration menu
• The measurements menu

There are still plenty of user interface items to code, like the generator menu and the file view screens, but my next step will be to code the controlling of the settings with the buttons and the knobs.

Once that is working I will try it on the actual scope, for which I have to write additional code, like setting up the clock synthesizer, serial interface and other initialization. This will give me a base project to build further on.

A lot of the code written by me for the 1013D can be used, but I have seen that there are some differences in how it works with the FPGA, so I have to figure that out and test things to see if actually needed.

After finishing with the scope functionality the bigger challenge lies in the function generator. That will require more looking into the original code with Ghidra.

So sit back and enjoy the ride.

 

[pcprogrammer]

Short update with a picture. 

First test of the screen setup code on the actual scope. It works without problems.

Next up is adding the code for getting the data from the secondary microcontroller, which is simple and already investigated by donwulff. Needs a bit of polish to rid the unneeded like setting it up for transmit interrupt and never have it handled by an actual interrupt handler. Is a straight copy from the original. Same as for using the FIFO, which is not needed since it is a request/response system based on a single byte.

A bigger part is setting up a state machine for handling the user input and allow the control of the settings. Will do that on a step by step approach.

So, wait for more to come. 

[pcprogrammer]

Things are coming together. 

Some of the basic functions are coded, like setting the trigger channel, run/stop control, channel sensitivity, etc. For the things that work with a menu more work has to be done. It needs handling in a secondary state instead of changing the one setting and continue with sampling.

The sample gathering and trace displaying is done with the 1013D code and needs more tweaking, but it is doing something.

It is promising, even though it still needs lots of work done.

[pcprogrammer]

Again a short update.

Since the size of the trace section on the 1014D is smaller than on the 1013D I had to tweak a lot of the positions and sizes in the code that displays the cursors and the traces. Implemented the movement of the trace positions, trigger horizontal position and the trigger level, and had to correct the limits of movement for these too. Did the cursor measurements display, which also needed tweaking of the dimensions and positions. Trying to make everything a pixel accurate copy of the original takes its time with taking screen captures and enlarging them in pinta to zoom in on the actual pixels.

Have to correct a textual error, but since it is based on a bitmap makes it a bit more work then just deleting a letter. The text in the lower right corner states "Waitting ..." 

All in all I'm having fun with it. But the tricky actual reverse engineering still has to come. My first goal is to have the basic scope functionality working, with the menus, calibration, sampling, etc. and release that for testing, while in the mean time do the code for the picture and waveform saving and viewing.

Also have to look into Atlan his work for the 1013D to improve on some things around the calibration.

And when all of that is done the signal generator is next on the list. Will also be quite the job.

[pcprogrammer]

Hit a bit of a wall. 

Working at implementing the main menu, after finishing the time and volt cursor handling, I thought it might be a good idea to do the USB connection first, because with that working it makes it possible to write and clear new firmware on the SD card.

But for some reason the SD card bit fails when started from the SD card. At least with the code loaded via FEL, for both the original scope code and my new code. When the scope is started from FLASH it works as intended.

Have to try it with my new code directly loaded from the SD card and see if that suffers from the same problem. If so, some debugging is going to be needed.

[pcprogrammer]

Well it turns out that one 4GB card I have has problems, because it does not work in the 1013D either, but the original 8GB card that came with the scope does work in the 1013D also via USB, and it starts on the 1014D but there the USB connection fails on al sorts of errors. It works with the original firmware.

To rule out that it is my hardware causing it, I wonder if anyone with a 1014D scope is willing to try it with the attached firmware file.

It won't brick the scope, but worst case you need to open it and put the SD card in a PC connected SD card reader/writer to clear sector 16.

To load the test code, having Linux would be the easiest.

Connect the 1014D to the PC, open the USB export function on the scope. Check on Linux to which device it is connected, i.e. /dev/sdb or so. (lsblk)

Then unmount the partition (not the drive), write the new code to sector 16 and reboot the scope. The .txt extension in the attachment is to be able to attach it here. Can be removed or add it to the line to copy the file to the SD card. Make sure to use the correct /dev/... in the commands given below.

Code: [Select]

sudo umount /dev/sdc1

sudo dd if=fnirsi_1014d.bin of=/dev/sdc bs=1024 seek=8

The PECOs sCOPE startup screen will flicker because it is meant for the 1013D and there is a slight difference in the FPGA, but after that the new 1014D code starts. Press the menu button, scroll to the USB export setting and press ok. See what it does and if it also fails with problems on the PC (dmesg shows errors in red like "I/O error, dev sdc, sector 24 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0" and commands in white like "reset high-speed USB device number 34 using xhci_hcd") you will have to open it up and stick the SD card in a PC connected reader/writer. In the other file more commands are listed on how to load and clear the SD card.

The new firmware is far from finished, but one can try if moving the traces, setting the sensitivity, setting the time per division, enable the cursors, etc. works as expected.

Please report back here on how it went.

[pcprogrammer]

A typical "Or you stick the power plug in the outlet" type of error. 

For testing in the emulator on the PC the mounting of the file system is disabled, and that also means that the mass storage driver has no active SD card to talk to. Enabled the mounting of the file system and now it works without problems, at least with the original card.

So don't bother with the code from the previous post unless you like to see what is up and running so far.

There is still a, probably speed, issue with the 4GB card, because it just won't work with that one. I'm able to use it to boot into FEL with DRAM enabled, but that is it. Something that needs to be looked at, but not now.

Back to implementing the code for the rest of the main menu items.

[pcprogrammer]

Back on track after the bit of a f..up. 

I copied the picture and wave file saving code from the 1013D and modified it to fit the differences with the 1014D, like only 6 measurements being displayed. The picture saving works fine and the images can be viewed on my Linux PC when connected via USB. The wave files are also there, but have no code to verify them. Has to be checked on the scope itself when the opening of the items has been implemented.

At the moment I'm working on that for the picture part, which can then also be used for the wave files. To make it look nicer than the original, and already more or less implemented on the 1013D, I made it look more like the real scope screen, as can be seen in the attached picture.

After that it is implementing the rest of the main menu items, the measurement menu, the channel settings menu, etc. Still lots of work to be done.

[pcprogrammer]

Another short update.

Basically I'm just as far as I was a couple of days ago, but with a completely rewritten state machine. I was not happy with the previous setup, which did not easily allow some functionality that was needed. So I thought about a better solution and implemented that.

All this still for the file viewing, which is working for a large part, but now needs the functionality for selecting and deleting items. When that is done it is back to the main menu to, for instance, fill in the setting of the brightness, and a very important part, the base line calibration.

After that the measurement select menu and the channel configuration menu needs to be implemented, which will conclude the basic functionality and allows for the release of a test version.

Hopefully some of you that have a FNIRSI-1014D are willing to do some testing.

[moffy]

Sorry I cannot help with the testing as I have Rigol, but I literally shake might head in mild disbelief at the amount of work involved and time spent on your project, amazing.
Is there a major issue with the FNIRSI OS or is this just something you want/need to do? I can understand either reason.

[pcprogrammer]

Sorry I cannot help with the testing as I have Rigol, but I literally shake might head in mild disbelief at the amount of work involved and time spent on your project, amazing.
Is there a major issue with the FNIRSI OS or is this just something you want/need to do? I can understand either reason.

There are several issues with the FNIRSI scopes, and I reversed the 1013D out of need due to a faulty touch panel when I got the scope. It turned into a bit of a hobby. 

For another project I want a scope user interface on the PC and thought the 1014D layout is suited for that purpose so I started programming. Then I thought "I might as well do the work for the actual scope too".

These projects do take time for sure, but as I wrote, it is a hobby.

[pcprogrammer]

Today I set up a simulator on the PC for the development and testing of the new firmware for the scope. I already had the emulator, but that uses the actual ARM based code for the scope and does not have support for the SD card and therefore does not help for the development anymore.

With the simulator the C code is compiled for running on the PC itself and makes debugging a lot easier. Already helped me with some of the problems I had while deleting files on the scope.

The file viewing is almost finished. Need to add some error handling when a file won't open or is no longer available. Since it is used for both pictures and wave forms, the latter is now also implemented to be accessed from the main menu.

It will most likely also fit the output capture file handling, but that is something new compared to the 1013D so needs looking into.

Still a long list to go through before everything is done.

[pcprogrammer]

Today I worked on some cleanup with replacing a lot of the same fixed values with global defines to make changing for instance the location of the trace window a lot easier and consistent. On the 1013D the position of the trace window is different and using the source code as a basis resulted in the traces to be in the wrong Y position due to not modifying a value in one location. With the global defines it now is tied together and can't cause this kind of problem anymore.

So not a lot of progress, but it will be more robust in the end.

[pcprogrammer]

Here is a first version that allows calibration and USB connection, making and viewing of picture and wave files.

Still a lot to implement like selection of the measurements, channel configuration and many other things. Also improvements in displaying the measurements to avoid flicker is needed, but it gives a first impression of what is to come. The traces also need re positioning to match the pointers because they are on the top instead of the center.

Feedback on problems found is welcomed, but only on already implemented stuff. No need for stating the obvious like "the generator is not working".

Edit: I forgot to mention that the settings are not yet stored, so base line calibration needs to be done on every startup to get it right. No need for it when just playing around with the controls.

[pcprogrammer]

Found a new FPGA command and its function used in the 1014D sampling code. Command 0x18 is used to read the trigger status and with this I can update the status on the display.

There is another command 0x29 that is written at the start of the sampling process with either 0 or 1 but I have to find out what this is used for. For the rest the sampling code looks the same.

Today I'm going to implement the brightness settings and see if I can get the other main menu options filled in.

My list with to do's is rather long and filled with things that needs checking or fixing, like the whole X-Y mode trace displaying that also needs to be re positioned due to the different origin of the trace window. And with every new thing implemented it seems to grow first as other issues come to light.

Ah well, one day it will be finished. 

[pcprogrammer]

The brightness settings are working and I improved on the scale (grid) brightness setting such that it changes it in the background while adjusting, so you can see the result directly and only not after closing the menu to find out you need to change it some more.

Learned something about the compiler for ARM I'm using (arm-none-eabi-gcc) in the process. I was using char for the settings and assumed them to be signed. It works that way in my simulator, but on the actual scope the limiting on < 0 did not work as intended. So a bit of thinking and debugging was needed.

Turns out by default the compiler assumes char to be unsigned.

Tomorrow onto the next bit.

[pcprogrammer]

To keep things interesting for myself I started looking at the function generator that is build into the scope. With my emulator I captured what is written to the FPGA and it luckily is not to complex. Only three commands are used.

0x47 sets the length of the buffer used by the generator. Form reverse engineering the FPGA I know that the function generator uses 1KB of memory, so the max would be 1024, but what I have seen in the software is that it uses a max of 1000 samples.

0x48 is not fully clear yet. Either a 0 or a 1 is written to it, so a bit of testing is needed to see what it does.

0x46 is used to write the data to the buffer.

The max clock that the clock synthesizer generates seems to be 200MHz, which leads to 200KHz if the 1000 samples ares used and hold a single period of the signal. For a square wave the scope allows a max of 2MHz on the output, and to make this frequency the scope only uses 100 samples.

For the sine wave the maximum is 10MHz and yes for that the number of samples is reduced to 20. So it depends heavily on the output filter to make it a nice wave.

A bit more research is needed for the clock synthesizer as to how it needs to be programmed to make the needed frequencies. I also have to look into the other wave functions the generator uses. It seems to do calculations to make them, instead of using a wave table, so for that the code in the Ghidra archive needs to be studied more.

[pcprogrammer]

Now that I have more things working it turns out that using the 1013D code for the sampling is not as straight forward as thought.

While working well on the 1013D for determining the signals frequency it fails at it on the 1014D, even though the signal on the screen looks ok.

Checking the FPGA command trace on the emulator shows that it always uses the same value for writing to command 0x0D, which in the 1013D is used to set the sample rate. The command 0x0E values seem to be the same for as far as I checked, so it might be that this is used in the FPGA to also select the sample rate, and not just some setting for the time per division, like in the 1013D.

Looking at the trace data did show the usage of the new command 0x29. When written 0 it only reads from one ADC per channel, and when written 1 it reads both ADC's for each channel. The latter is only done for the 10ns/div setting.

So more experimenting is needed to get a properly working scope.

Edit: I added command 0x29 to the code and now it shows some stable frequency reading, only way off what it should be. 100KHz reads as 19.2Hz. 

That does match with the trace shown on the screen. 10ms/div and ~5.2 divisions for a period. 

Edit 2: Ahum, that is due to aliasing. When the time per division is set to 2us/div it shows the correct frequency, but the signal on the screen has a lot of artifacts, not seen on the 1013D.

Edit 3: It has been to long since the reversal of the 1013D. 

I thought I had the special IC fully implemented in the 1013D emulator I wrote back then and used it with modifications for the user interface to make the emulator for the 1014D. But it turns out I did not do that and therefore the command 0x0D value it outputs to the FPGA trace file is not correct. Can't remember how I found the values for it when working on the 1013D, but need to do it again for the 1014D.

One thing I did notice, when looking through the code in Ghidra, is that the handling of the roll mode (long time base settings) is done differently. Just like when I did the 1013D, I'm going to skip that part.

Another thing is that the values used for command 0x0E are different except for the last one used for sampling at 200Msa/s. But these are easily copied from the code in Ghidra.

[pcprogrammer]

It is still a bit of a mystery as to why the distortion happens. 

I have been doing al sorts of tests with the differences found between the 1013D and 1014D code on the part of the sampling but failed so far to get a proper result. On the 1013D the signal is nice and stable but on the 1014D all sorts of distortion comes in. I took some screen captures on the scope and these show the different shapes that pass by.

The first image looks good and is what also shows on the 1013D.
The second image shows some small ripple in the bottom half of the first period.
The third image shows a lot of distortion.

Also an issue is that the center of the signal is not on the correct location, even though the zero line calibration has been done and without a signal connected the line is on the center of the trace pointer.

This calls for a better scope brought in and do measurements on the ADC inputs to see what is going on. Luckily I have a couple that I can use for that.

An so a, what was supposed to be a simple straight forward, reverse engineering job becomes more of a trouble shooting job.