FNIRSI-1013D "100MHz" tablet oscilloscope

[pcprogrammer]

It is one big puzzle with millions of pieces.

I found some missing data in the decoded original database, that makes me wonder if prjtang can actually be used to generate a bitstream with the open source projects like nextpnr. The pin to pad list, which is needed to connect the outside of a package (lqfp or bga) to the actual io pads on the chip.

Within the bit files it shows names like IOL0.INCLKMUX or IOL3.MODE, which is an indication of the pad within the io tile, but no connection to the outside pin name. The data I found maps pins to names like pl22d or pt28a.
I guess it means pad left y22 io3 or pad top x28 io0.

Further more I have the idea that in prjtang the x and y coordinates for the bits are swapped. This is easily seen in the files for pib or plb. These tiles have 27*54 or 31*54 bits. The naming of the tiles suggests that the frame number is used as x coordinate and the bit position within a frame is mapped to the y coordinate. For this the direction is reversed. Bit 0 maps to tiles y37. I was able to verify this by looking at the chip viewer in the Tang Dynasty IDE. In the bit files the y data shows a range of 0-26 or 0-31 and the x data a range of 0-53.

Then there is the xoff and yoff data. I think this has to do with the fact that for instance top or bottom io blocks spread over three tiles. But in the data for these blocks the xoff only shows 0 and 1, so where does this leave the bits in the third block.

It is a way to learn about the real insides of a FPGA, but it is not easy.

Attached is a spread sheet with the missing data

[pcprogrammer]

Progress is slow but I took another step in solving the puzzle.

The data in the Tang Dynasty database for the AL3-10 is setup to go forward from a HDL description to a FPGA bit stream and not the other way round. This has to do with the tile offsets used in the bit description files. For an IO block in an edge tile there are some configuration bits that reside in one of the surrounding pib (programmable interconnect block) tiles.

To overcome this I first converted the json data to C structures and created a list for all the configuration bits by stepping through each tile and the belonging bit files. Based on this big list it is possible to find the meaning of every bit described in the database. Unfortunately this still shows bits being set that have no apparent meaning.

The question here is are these bits actually needed or is the Tang Dynasty IDE place and route code wrong.

My simple test design shows that it is setting bits for the other unused IO pins that reside in the same IO block. Again the question if this is needed or not. I'm not sure if it will damage the FPGA when these bits are made zero and the bit stream is recreated.

The data in the configuration database is getting more meaning now. For each bit there is an expression and a list of properties used in the expression. Based on the outcome the bit is set or not. For the IO this makes it a bit of a guess what the actual properties specified in the IO constraints are, but since the external hardware is know it is not to difficult to get that right.

Attached is a new listing and an improved bitmap of the bits in the original FPGA.

[pcprogrammer]

Unfortunately I have to admit defeat. There are to many missing pieces of the puzzle. 

Today I decoded the database of the Tang Dynasty 2018 version, which is 16 times as big as the current version, in the hope to get more or different information, but the basic parts are more or less the same. The size difference lies in ~500000 lines of numbers that have no direct meaning to me.

Below is an excerpt of the file. It might be some routing information from tile to tile because the first sets of two numbers on the first line run from 0 0 to 34 37, which is the range of tiles in the AL3-10. But what do the other numbers mean

Code: [Select]

34 34 34 34 105 0 0 1 1 16
253270 253271 253280 253281 253282 253283 253290 253291 253292 253293 253298 253299 253306 253307 253378 253380
34 34 34 34 106 0 0 1 1 18
253270 253271 253280 253281 253282 253283 253290 253291 253292 253293 253298 253299 253306 253307 253325 253335 253382 253384
34 34 34 34 107 0 0 1 1 18
253272 253273 253278 253279 253284 253285 253290 253291 253292 253293 253298 253299 253304 253305 253324 253326 253377 253379
34 34 34 34 108 0 0 1 1 16
253272 253273 253278 253279 253284 253285 253290 253291 253292 253293 253298 253299 253304 253305 253381 253383
34 34 34 34 109 0 0 1 1 18
253268 253269 253274 253275 253288 253289 253308 253309 253324 253326 253381 253382 253383 253384 253433 253434 253435 253436
34 34 34 34 110 0 0 1 1 12
253268 253269 253274 253275 253288 253289 253308 253309 253433 253434 253435 253436
34 34 34 34 111 0 1 1 0 0

34 34 34 34 112 0 1 1 0 0

34 34 34 34 113 0 1 1 0 0

34 34 34 34 114 0 1 1 0 0

34 34 34 34 115 0 1 1 0 0

34 34 34 34 116 0 1 1 0 0

The listings I can make based on the available database data contain EMPTY bits in the routing of the signal, which makes it impossible to connect the dots. Also the lack of documentation about the interconnect, and the other parts of the chip make it very difficult to come to some proper results. I have not even looked at the logic blocks yet, so that can hold some surprises too.

The only option left would be to reverse engineer the Tang Dynasty IDE, but that is a bit to much for me.

I wonder if anyone out there has used the prjtang stuff in combination with yosys and nextpnr to make a working FPGA configuration, but I have my doubts.

[frenky]

Don't be so hard on your self.
You have done incredible amount of work which can be seen in your great firmware.

Just brainstorming here:
Would it be easier to make new "code" for FPGA from scratch?
Could we replace this FPGA with some pin compatible that is easier to work with?

Anyway for me 1013D (with your firmware) is now perfectly usable DSO even if it gets no further updates...

[pcprogrammer]

Don't be so hard on your self.

Hi frenky,

that is my inquisitive nature, just want to know how it all fits together I can't help but wonder if the Tang Dynasty software has some trickery under the hood, where they swap the bits within the blocks of a tile to throw the hackers off. It would explain the empty bits I find in the listings.

Just brainstorming here:
Would it be easier to make new "code" for FPGA from scratch?
Could we replace this FPGA with some pin compatible that is easier to work with?

Sure it is, and that is what morris6 is working on. He already has something working, but getting the trigger right is a bit of a problem. I made some mods to the firmware for him to test with. The Tang Dynasty IDE is ok for doing this work, so no need for another FPGA, all though a Cyclone IV would fit, but reworking the circuit board is not that easy. The chip also has a ground pad underneath.

The only benefit would be more DSP tiles. Memory is the same. Not sure if a GOWIN device is pin compatible. Having 8MB of sample memory would be nice. The AL3-10S also has this, but availability seems to be a problem.

Anyway for me 1013D (with your firmware) is now perfectly usable DSO even if it gets no further updates...

Good to hear that the new firmware makes it a better scope. I might look into the measurements and FFT in a while. I guess these are the only parts missing in comparison with the original.

[pcprogrammer]

My brain kept on turning on the fpga thing and I managed to solve the problem I was running into. Not by reverse engineering the program, but by using it with IO properties I knew where they had to be located. The configuration data is packed in 1075 frames of 257 bytes, of which it only uses 2052 bits per frame. I assumed the unused bits to be at the end of each frame, but it turns out they are at the beginning. I was able to see this because the known bits were offset in the y direction by 4.

So with that out of the way I was able to get all the bits named correctly, so I went on to matching the IO pads to the pins, which was not to difficult.

Next I turned to the routing, and I did manage to find quite a bit of how it sticks together, but I fail to see the logic behind the interconnects. For each connect through a routing switch box it uses two bits and based on the bit names it is possible to pair them, but finding the connection between the different switch boxes is a mystery. I lack the knowledge for it and my searches on the net did not get me any further.

So the project is now parked on github: https://github.com/pecostm32/Anlogic_AL3-10_Analyzing were it is already discovered by people interested in it. Even during uploading it was cloned

I heard back from mmicko that I'm right in that it is not possible to make Anlogic FPGA designs with nextpnr and he has not had time to do more work on the project. He has fixed his tools for decoding the database to list the bits on frame and bit index instead of y and x. His focus was mainly on the Eagle-20 device, which has some differences apart from the number of logic cells.

Maybe when I have learned more about modern FPGA's I will return to the quest, because I'm convinced it is possible to get it done with the proper knowledge.

[pcprogrammer]

Turned back to the firmware and made the framework for the measurement displaying.

Deviated from the original and made it so that the measurements for a channel have their own location on the screen. Channel 1 measurements on the left and channel 2 measurements on the right.
Four rows of three columns max per channel, and only displayed when the channel and belonging measurements are enabled. The display order of the measurements is fixed and not as in the original where the order is dependent on the order in which they are enabled.

Also modified the menu to reflect the left right position of the data on the display. Channel 1 is now on the left of the menu.

Have to fill in the calculations for the major portion of the measurements. Only the frequency is done, since I already had that in the previous version.

So the easy part is out of the way

[pcprogrammer]

Added all the measurements and it seems to work. Only performed very short test on the actual device.

The Vrms is probably wrong. I based it on how it is done for a sine wave. Using the Vp as the base (maximum of the absolute min and max values compared to the ADC center and thus taking DC offset into account) and multiplying it by 0.7071.

At some point I have to add averaging over the measurements to make it a bit more stable, but as is will do for now.

This is version 0.003

The FFT has to wait. It is more work and I have to think about screen layout and functionality.

I'm going to look into morris6 his work as a new learning project. That is, what this whole expedition was and still is, about, learning

[Gustavo]

Hello everyone, just a bit busy but last week I replaced the 1013D CPU and now is running normal, at least for a so cheap oscilloscope. The only ugly thing is the huge jitter it has. Is there a way to do something about this issue?

Thanks in advance.

GUS

[pcprogrammer]

Hi Gus,

Nice job in getting the F1C100s replaced and reviving the scope back to live. Have you tried it with the new firmware?

It does solve a bit of problems the original firmware has. The jitter might be caused by communication errors between the mcu and the "special ic" connected to the fpga. This is not used in the new firmware and it makes it faster and more stable.

Just follow the link in my signature to go to the firmware repository. Instructions on how to load it onto the scope are in the readme.

Enjoy,

Peter

[Gustavo]

Thanks so much PCP, I´ll end some tasks related to my job and will turn on my raspberry and let you know the result, great if the toy become more stable.

BTW, yesterday I left the oscilloscope on and the battery is at exactly 0 voltys today, sad this toy has not an battery undervoltage protection. Thanks again.

[tunk]

BTW, yesterday I left the oscilloscope on and the battery is at exactly 0 voltys today, sad this toy has not an battery undervoltage protection.

Many batteries has a built in BMS which does this,
i.e. shuts it off when the cell voltage goes below 3V.

[Gustavo]

Thanks so much, seems like this batt has it.

[Gustavo]

Dear PCP, were can I find your latest 1013D .bin firmware, I gess this is what I must load to the SD card using the USB port. Thanks a lot.

[pcprogrammer]

Dear PCP, were can I find your latest 1013D .bin firmware, I gess this is what I must load to the SD card using the USB port. Thanks a lot.

See message: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg4022467/#msg4022467

The .txt is because the forum does not allow .bin files to be attached

It is also in the /dist folder in the repository.

[Gustavo]

Thanks PCP. After almost two hours I was able to transfer the new firmware (003) to the scope but sadly the touch screen is reversed. Is there something I can do?

Thanks a lot

GUS

[pcprogrammer]

Thanks PCP. After almost two hours I was able to transfer the new firmware (003) to the scope but sadly the touch screen is reversed. Is there something I can do?

Hi Gus,

you are welcome

How strange, because the whole quest of reverse engineering the firmware started with a reversed touch screen after replacement. The new firmware is using the touch screen as is and looks at the configuration to calculate some conversion factors, but it can't tell if the x and y are wrong

Luckily it is not a big problem and can easily be solved by writing a new configuration to the touch panel. But for this to be a success the configuration as is needs to be known.

See: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3808349/#msg3808349 and the messages before it on what to do.
The touch panel configuration is then written to the SD card. Post that on the forum and I will take a look at it.

Success,
Peter

[Gustavo]

Thanks again and again Peter.

Yesterday when I tested de 1013 with your 003 firmware y managed to operate it with the reversed TS and noted there was no trigger at all, this could give you more clues about my issue, unless my scope has another defective part.

Y noticed too that the scope boots from the SD card and uses the EEPROM no more. Am I right?

I´m a bit confused about the files I should transfer to de Oscilloscope´s SD card, can you please clarify that?

Thanks Peter

GUS

[pcprogrammer]

Hi Gus,

What does the scope do with the original firmware? Does it work normally? The thing is that there are different models of the scope with different FPGA's in them. The one I work with has an Anlogic FPGA instead of an Altera. I don't think there is a difference between them firmware wise, but you might have something different.

For the use of my firmware there are two possibilities.
1) Standard device only needs the fnirsi_1013d_v0.003.bin
2) Devices with a different display need a display configuration file.

This is explained in the readme files in the repository.

To make a backup of the original firmware including the touch panel configuration you need the fnirsi_1013d_fwb.bin of page 45 of this thread. This is a standalone program, that copies the content of the FLASH memory to the SD card. It also writes the touch panel configuration to the SD card. It is the latter I need to make the right configuration for  your scope.

This thread holds all this information, so it might be useful to read part of it. Like pages 44 to 46 as to how I got to the new SD card approach.

And you are right in that it does not use the FLASH (it is not an EEPROM) in any way. Removing the program from the SD card makes it return to the original firmware.

Cheers,
Peter

[Gustavo]

Dear Peter, I think the firmware problem goes beyond the TP inversion because there is no trigger at all, the waves are in free run, so I suspect my 1013d has a different FGPA, to put things even more complicated.

One last question.The difference between the old model, mine, and the new one are only cosmetic or there are some functional improvements.

Thanks a lot Peter.

Take a HUG from Colombia.
GUS

[pcprogrammer]

Hi Gus,

for as far as I know is the rest of the hardware the same between the different models. The difference between the old and the new is that it has the recessed connectors, and the front panel is the flat hardened glass.

The hardware differences know to me are
1) The FPGA: Altera Cyclone IV versus Anlogic AL3-10
2) The touch panel. There are differences in the number of sensors used. Most of them have, out the top of my head, 16x10, but I also have one that has 20x14.
3) The display. They have used at least three types, one of which has quite a displacement causing the screen to shift up and to the left.

The firmware is, for as far as I know, the same functionality wise. (Apart from ye or ne writing the touch panel configuration)

Can you post a photo of your pcb? And also some photo's of the device in action.

If you are willing to play with it, you could make a jtag connection on to the FPGA and see if it is possible to reprogram. The older board has it routed to an unpopulated header, so a bit easier.

As you can read in the last 4 or 5 pages, we are in the process of making a new FPGA programming. It is for the Anlogic device, but the verilog can be adapted for the Altera device.

It is a fun little device and would be unfortunate if, after all your efforts it is binned.

Regards,
Peter

[Gustavo]

Hi everybody.
A bit lost because of my Job PCP. This time I need a hardware help,plese. The oscilloscope has TL431 as reference in the power supply section and a TL432 in the analog input section (dont know why), every data sheet I visited says this twuo chips have the same 2.49 V reference, so Gate + Cathode put both ICs as a 2.49 V shunt reference, in both Ocs sections 431 and 432 have the same configuration so it´s why I do not understand about two different references to obtain the same result.The funny part follows.

FRF1 TL432 produces 1.1 volts reference in contradiction with all foud datasheets I found,ok?
I removed the 432 and injected 2.495 volts in there, the trace goes up to the top to a point where you can not take it back to the center, crazzy ah!

So this is the favor I need, can you please measure VFR1 and let me know it´s value in your Osc?

Thanks so much.

[pcprogrammer]

Hi Gustavo,

The voltages I measure are:
TL431 (VREF) 1,194V
TL432 (VRF1) 1,233V

The voltage VREF from the TL431 is sampled by the MCU for the battery status indicator.

The voltage VRF1 from the TL432 is used to raise the virtual ground level on the BNC inputs. It is done this way to avoid a dual supply with a positive and negative voltage for proper signal conditioning. The op-amps are on 2,5V, so to be mid level VRF1 has to be ~1,25V. This why the scope does not work properly when connected to a grounded computer via USB and the inputs are connected to a grounded device under test.

Edit: I based the part identification on the photo of the old model scope. The one in the power supply reads 431 and the one in the analog section 432, and I assumed them to be TL431 and TL432.

[Gustavo]

Thanks for your effort dera friend. Now Im even more confused. No TL431/432 can produce any voltage bellow its 2.49V reference, so neither of the chips dedicated for VREF and VREF1 are TL´s.
In my OS. VREF is 2.49 (a correct value for a TL) and VREF1 is 1.2V, the correct value for 2.5/2, then my SMD marked 432 is something different to a TL. Still surprised about your 1.19V at VREF.

 

This thing is a lot of joy, for sure. Get a hug and thanks again.
GUS

[Kean]

Thanks for your effort dera friend. Now Im even more confused. No TL431/432 can produce any voltage bellow its 2.49V reference, so neither of the chips dedicated for VREF and VREF1 are TL´s.
In my OS. VREF is 2.49 (a correct value for a TL) and VREF1 is 1.2V, the correct value for 2.5/2, then my SMD marked 432 is something different to a TL. Still surprised about your 1.19V at VREF.

The one in the battery circuit is referenced from VBAT not GND, so VREF will be the battery voltage less 2.5V.  Thus VREF will vary with battery charge.
The one in the analog circuit could be a TLV431/TLVH432 (or a similar Chinese clone) which is a 1.24V reference.

A "432" swaps pins 1&2, but that doesn't matter when they are connected anyway.  So they may have used a "432" just because it had different marking from the "431".