FNIRSI-1013D "100MHz" tablet oscilloscope

[pcprogrammer]

Question for tv84 (or others whom are interested)

What do you make of this function?

It is called through the display_lib_setup sequence of functions. On entry the parameters are: param_1 = 0x8036B7A0, param_2 = 0x00002800.

I have the idea it is pointless and is only a waste of cpu time. (runs for > 2150000 instructions)

Code: [Select]

void FUN_80030564(int *param_1,uint param_2)
{
  byte bVar1;
  ushort uVar2;
  byte extraout_r1;
  ushort extraout_r1_00;
  int extraout_r1_01;
  int extraout_r1_02;
  uint extraout_r1_03;
  uint extraout_r1_04;
  uint uVar3;
  uint uVar4;
  int *piVar5;
  int iVar6;
 
  uVar3 = 0;
  do {
    uVar4 = 0;
    piVar5 = param_1;
    while (uVar4 < param_2 >> 2) {
      divide(uVar4 + uVar3,0xff);
      uVar4 = uVar4 + 1;
      *piVar5 = extraout_r1_01;
      piVar5 = piVar5 + 1;
    }
    uVar4 = 0;
    piVar5 = param_1;
    while (uVar4 < param_2 >> 2) {
      iVar6 = *piVar5;
      divide(uVar4 + uVar3,0xff);
      if (extraout_r1_02 != iVar6) {
        return;
      }
      uVar4 = uVar4 + 1;
      piVar5 = piVar5 + 1;
    }
    uVar3 = uVar3 + 1;
  } while (uVar3 < 2);
  uVar3 = 0;
  do {
    uVar4 = 0;
    piVar5 = param_1;
    while (uVar4 < param_2 >> 1) {
      divide(uVar4 + uVar3,0xff);
      uVar4 = uVar4 + 1;
      *(ushort *)piVar5 = extraout_r1_00;
      piVar5 = (int *)((int)piVar5 + 2);
    }
    uVar4 = 0;
    piVar5 = param_1;
    while (uVar4 < param_2 >> 1) {
      uVar2 = *(ushort *)piVar5;
      divide(uVar4 + uVar3,0xff);
      if (extraout_r1_03 != uVar2) {
        return;
      }
      uVar4 = uVar4 + 1;
      piVar5 = (int *)((int)piVar5 + 2);
    }
    uVar3 = uVar3 + 1;
  } while (uVar3 < 2);
  uVar3 = 0;
  do {
    uVar4 = 0;
    piVar5 = param_1;
    while (uVar4 < param_2) {
      divide(uVar4 + uVar3,0xff);
      uVar4 = uVar4 + 1;
      *(byte *)piVar5 = extraout_r1;
      piVar5 = (int *)((int)piVar5 + 1);
    }
    uVar4 = 0;
    piVar5 = param_1;
    while (uVar4 < param_2) {
      bVar1 = *(byte *)piVar5;
      divide(uVar4 + uVar3,0xff);
      if (extraout_r1_04 != bVar1) {
        return;
      }
      uVar4 = uVar4 + 1;
      piVar5 = (int *)((int)piVar5 + 1);
    }
    uVar3 = uVar3 + 1;
  } while (uVar3 < 2);
  uVar3 = 0;
  while (uVar3 < param_2) {
    uVar3 = uVar3 + 1;
    *(byte *)param_1 = 0;
    param_1 = (int *)((int)param_1 + 1);
  }
  return;
}


[tv84]

Yes, it looks like a delay function.

The number of instructions that are executed is param based.

Maybe it has into account some specific calibration of the device/components or freq. set by the user.

[pcprogrammer]

But it makes no sense in light of initializing a display library, at least not to me.

Can't be for the FPGA startup, because that is already running. Delays for that are in the secondary program loader.

It first writes 0x00 to 0xFE to word based memory (2560 words) then reads them back and checks if they are the same, which when the memory is functional will be the case. Then they repeat this with the data offset by one.

The "divide(uVar4 + uVar3,0xff);" call, which does a modulo since they use the remainder, in the second run has uVar3 set to 1 and 0 in the first run.

Then in the second do while loop they repeat this process on short based memory (5120 shorts) and in the third do while loop they do it again but now on byte based memory (10240 bytes).

Finally they clear the memory in the last while loop.

There is no return value, so no check on any failure of the memory.

Very strange

[tv84]

Is it writing in the display mem area? Like a display clear?

[pcprogrammer]

Does not look like it. It is not the main display buffer it is writing to. Nor is it one of the other screen buffers I found earlier.

Also the numbers do not add up for that. The display buffer is 800 pixels by 480 lines of 2 bytes per pixel. Is 768000 bytes.

[pcprogrammer]

Found an error in my arm core caused by not reading the manual correctly.

The conditional execution checks for "Unsigned lower or same" and "Signed less than or equal" were wrong. Both required an or instead of an and between the two flag checks.

Was

Code: [Select]

        case ARM_COND_LOWER_SAME:
          //For execute on lower or the same C needs to be cleared and Z needs to be set
          if((core->status->flags.C == 0) && (core->status->flags.Z))
            execute = 1;
          break;

        case ARM_COND_LESS_THAN_EQUAL:
          //For execute on less than or equal than N needs to be not equal to V and Z needs to be set
          if((core->status->flags.N != core->status->flags.V) && (core->status->flags.Z))
            execute = 1;
          break;

and needs to be

Code: [Select]

        case ARM_COND_LOWER_SAME:
          //For execute on lower or the same C needs to be cleared and Z needs to be set
          if((core->status->flags.C == 0) || (core->status->flags.Z))
            execute = 1;
          break;

        case ARM_COND_LESS_THAN_EQUAL:
          //For execute on less than or equal than N needs to be not equal to V and Z needs to be set
          if((core->status->flags.N != core->status->flags.V) || (core->status->flags.Z))
            execute = 1;
          break;

Unfortunately it did not solve all the problems, but at least one hurdle has been taken. There are still unimplemented peripherals that can make things go wrong.

The startup screen at least is cleared and after a while this comes up.

[bianchifan]

@pcprogrammer
First, your work is highly appreciated. 
But do the daily water level reports really help anyone?

And now something completely different

Last year's Ali black week I ordered a 1013D Digital Tablet Oscilloscope for roundabout 119$ (~99e).
So far so good, it came in a black cardboard named "TABLE OSCILLOSCOPE". As a short test it could display all the stuff from my MHS5200A up to 25 MHz.
The name "FNIRSI" appears only on the boot screen.
But no FW version etc, no further info.


Due to a momentary lack of my USB scopes I must use it 2 weeks ago to analyze a problem with pulsed Mosfet arrays.
I read somewhere on the internet that its impossible to capture pulses.
I can state, its not easy.., but I did and stumbeled about a lot of glitches in the firmware... and my usecase passed away for its no DSO

- The captured waveform is really poor, its only TWO!! screens.
 
On top there is a green marker, I can move the wave until this marker touches one side.
When visible, the values  of the auto measurements are all ZERO(!).
When this marker isn't visible (maybe at longer time intervals, 20msec and longer, I didn't dig for) you cannot move the wave and cannot change the timebase but the measurement field have some values.. and sometimes(pulses) quite weird

When I capture a wave (stop the scope, NOT save the wave), save a pic, change the timebase to a shorter one and save the new pic the old measuring cursors are saved and on the screen itself the cursors are lost.

And sometimes the wave is lost..

When you like to view at the captured pics on the scope you have to choose them from an index, when I returned to the index afterwards for another pic the index is displayed a little mismatched.

Connected to a PC or similar host the storage appeares as a disc, captured pics show up as BMPs and all files are dated on March, 22, 2020, 23:48



- The scope is useless for low voltage signals.

I know, the lowest vertical voltage is 50vV/div, quite poor although same as on my DDS140.
But the DDS140 can display low voltage signals, noisy, but you can see something and can trace them.
When trying to monitor a low voltage signal with 1013-D I did see... nothing but a zero line. I checked with my MHS5200, On CH1 signals below 30mV aren't displayed any more!
In my case the trigger jumped in at 29mV, a stable signal needed more than 33mV!
Between 29mV and 33mV the screen showed a flashing signal over a zero line.

CH2 is even more crazy.
Flickering junk down to 20mV and up to ~50mV, unstable trigger up to 200mV.
Stable trigger only on signals above 200mV!!

Short vids attached
 22mV-210mV.zip (2359.7 kB - downloaded 51 times.)
Bad firmware or concept due to high noisefloor?

Resume:
The 1013D maybe fine for juggling with logic levels without capturing and many audio purposes but it fails for low voltage (pre)amlifiers.
Its better than no scope but I cannot recommend it - only as an addendum.
Its not a DSO but a DTO, just as stated.

----

7：Storage depth: 240Kbit

Source??

[pcprogrammer]

@pcprogrammer
First, your work is highly appreciated. 
But do the daily water level reports really help anyone?

7：Storage depth: 240Kbit

Source??

a) Thanks
b) They help me For me it helps to write about what I encounter and sometimes brings light to my brain.
c) The storage depth has to do with the FPGA used. It has in total 270Kbits of embedded memory and I guess they use 240Kbits for the acquisition memory.

And you are right it is a simple hobby scope. But who knows what it can become. That is also a reason for me to do the work on it. 

[tv84]

@pcprogrammer
First, your work is highly appreciated. 
But do the daily water level reports really help anyone?

I like them a lot. It helps systematize the progress and evaluate the level of work that is putted into this process.

Most people like to see the end product. I truly appreciate a good description of the path to get there. But that's me...

"It's a shitty scope." - Well it could be a toaster or a vibrator... The level of work and method is awesome! It's reversing at its finest.

[pcprogrammer]

For tv84

An insight in how I found the programming error. You already know I made trace listings and that they are long. 88 full files of 25000 lines each and one with just 1731 lines. The problem was written in file number 88. Files 1 to 87 where mostly the strange function I wrote about yesterday, so I did not have to read through all of the lines .

I used the pseudo C output of Ghidra on one screen and the listing on a second screen. Once in a while I compared things with the assembly in Ghidra. It was looking at the pseudo code and check against the trace data what was really going on when I noticed that a compare was not executed correctly.

It was in the function shown below that I noticed the  "if (uVar5 <= param_1)" not being taken. The trace data is in the second code part.

At first I thought could my carry logic be wrong, but the divide function called many times by the function mentioned yesterday worked as it should. Did test it by inverting the carry logic and run the program again. It did not even get to the displaying of the startup screen. So I was thinking what can it be when a light went on. Every instruction can be conditional and the ones with ls condition did not execute whilst they should have. The rest is history

Code: [Select]

int FUN_8002cf28(uint param_1)
{
  uint *puVar1;
  int iVar2;
  uint uVar3;
  int iVar4;
  uint uVar5;
  uint uVar6;
  int unaff_r5;
 
  FUN_8002fb5c();                        //Already called from FUN_80018464 and therefore does nothing

  puVar1 = DAT_8002d040;                 //0x80857C80
  uVar5 = DAT_8002d040[0x10];            //*0x80857CC0 = 0x00000010

  if (uVar5 <= param_1)                  //16 <= 6032 ??  cmp r1,r4  | r1 = 0x00000010, r4 = 0x00001790 | carry not set ???
  {
    uVar5 = param_1 + 3 & 0xfffffffc;    //Make it on a word boundary.
  }

  uVar5 = uVar5 + 0xc;                   //uvar5 = 0x1C


Code: [Select]

pa:0x8002CF34  0xE59F6104  YES       ldr         r6, [pc, #260]   r0:0x00000001  r1:0x00000080  r2:0x00000178  r3:0xFFFFFFB8  r4:0x00001790  r5:0x80857C8C  r6:0x80857C80  r7:0x80192E6B  cpsr:0x20000053
pa:0x8002CF38  0xE5961040  YES       ldr         r1, [r6, #64]    r0:0x00000001  r1:0x00000010  r2:0x00000178  r3:0xFFFFFFB8  r4:0x00001790  r5:0x80857C8C  r6:0x80857C80  r7:0x80192E6B  cpsr:0x20000053
pa:0x8002CF3C  0xE1510004  YES       cmp         r1, r4           r0:0x00000001  r1:0x00000010  r2:0x00000178  r3:0xFFFFFFB8  r4:0x00001790  r5:0x80857C8C  r6:0x80857C80  r7:0x80192E6B  cpsr:0x80000053
pa:0x8002CF40  0x92840003  NO        addls       r0, r4, #3       r0:0x00000001  r1:0x00000010  r2:0x00000178  r3:0xFFFFFFB8  r4:0x00001790  r5:0x80857C8C  r6:0x80857C80  r7:0x80192E6B  cpsr:0x80000053
pa:0x8002CF44  0x93C01003  NO        bicls       r1, r0, #3       r0:0x00000001  r1:0x00000010  r2:0x00000178  r3:0xFFFFFFB8  r4:0x00001790  r5:0x80857C8C  r6:0x80857C80  r7:0x80192E6B  cpsr:0x80000053
pa:0x8002CF48  0xE5960000  YES       ldr         r0, [r6, #0]     r0:0x00000000  r1:0x00000010  r2:0x00000178  r3:0xFFFFFFB8  r4:0x00001790  r5:0x80857C8C  r6:0x80857C80  r7:0x80192E6B  cpsr:0x80000053
pa:0x8002CF4C  0xE281400C  YES       add         r4, r1, #12      r0:0x00000000  r1:0x00000010  r2:0x00000178  r3:0xFFFFFFB8  r4:0x0000001C  r5:0x80857C8C  r6:0x80857C80  r7:0x80192E6B  cpsr:0x80000053

Unfortunately there are other errors in my code. The same errors were also in the thumb conditional branch instruction, but that did not solve what is going wrong. Found an oversight today where some special data processing functions (ADD(4), CMP(3) and CPY, MOV(3)) were not being handled. But again that did not solve the problem.

Working hard on getting to the root of this next problem

[pcprogrammer]

Here is the last update for today

Solved the problem. It was a stupid copy paste not modify error.

The thumb blx in the next code segment is made up of two thumb instructions (Ghidra shows it as if it is an arm instruction). A bl for the jump address offset << 12 and the blx with the low part of the jump address offset. In my code I made a separate instruction decode struct for it which is used in an union. But whilst renaming the element I forgot to rename the type from ARMV5TL_INSTR_THUMB_B6 to ARMV5TL_INSTR_THUMB_B7 and therefore the first part of the pair was skipped and the wrong jump was taken.

I found it after making the thumb disassembler and looking at the trace listing.

Code: [Select]

                             LAB_80000634                                    XREF[1]:     80000628(j) 
        80000634 02 2c           cmp        r4,#0x2
        80000636 0b d3           bcc        LAB_80000650
        80000638 67 08           lsr        r7,r4,#0x1
        8000063a 32 04           lsl        count,r6,#0x10
        8000063c 7f 00           lsl        r7,r7,#0x1
        8000063e 32 43           orr        count,r6
        80000640 79 00           lsl        data,r7,#0x1
        80000642 28 00           mov        dest,r5
        80000644 00 91           str        data,[sp,#0x0]=>local_20
        80000646 00 f0 3a e9     blx        FUN_800008bc                                     undefined FUN_800008bc()
        8000064a 00 99           ldr        data,[sp,#0x0]=>local_20
        8000064c e4 1b           sub        r4,r4,r7
        8000064e 4d 19           add        r5,data,r5

Next problem was the not yet implemented CLZ instruction. Implemented that and now the code runs down to the sd card part of the code and hangs there in a loop checking on some response of the sd card interface. Since this peripheral is not yet implemented it will stay there until that part of the system has been implemented.

As this is uncharted territory for me, both the sd card interface in the f1c100s and sd card interfacing in general it will take it's time.

[pcprogrammer]

Getting closer

The loop the code hung in yesterday was a check on the uart0 tx being empty. So I implemented the uart to return always empty and the code continued to show the "SD ERROR" message. As a test I decided to just remove the call to the sd card check and see what happens.

It continues to a basic scope screen, but hangs again so not there yet.

Edit: It ran into a not implemented instruction. smulbb

At least closing in on the FPGA stuff which is what it is all about. Still a lot of coding to do. Need to implement mouse to touch screen input to be able to control the scope, FPGA interfacing for the parts we already know about and what more is needed to get a full functioning scope emulator.

[pcprogrammer]

It is nearly there.

Implemented the I2C handling on port A and the mouse part for the scope window, but to get it to work the FPGA part is needed since the panel register address 0x8150 is read from it. Made a trace of what is being send to the FPGA and noticed it tries to read from the special chip connected to the FPGA and that slows the system down since it tries it many times. Which was already known.

So that needs to be implemented. Fortunately this part is already analyzed and known.

The trace also shows the commands initially used and one that is called repeatedly after the scope screen came up. 0x0A, so maybe this is a check to see if there is trace data available.

[pcprogrammer]

The display shows more of the scope screen, but even though I can see that the scope code reads coordinates from the touch panel it does not show any response on the screen.

So again more research is needed

Did not implement the special memory chip stuff yet. Only the reading of FPGA command 0x41 which returns the touch panel register address for the coordinates (0x8150).

Since the scope code reads the right touch panel coordinates, which I verified whilst debugging the scope emulator. By looking at the assembly in Ghidra and checking the contents of the registers in the emulator core and the touch panel data, also in the emulator core, I could see that the numbers are the same.

Why the scope does not respond with the menus or red squares when the buttons are touched needs to be researched.

[pcprogrammer]

One more for the road

I realized one thing, but unfortunately it was not the full solution, the real touch panel will continue to return status "there is touch" as long as there is touch. My first mouse solution did not do that. It only signaled status when there was a change (mouse button down or movement), so had to change that. As it did not work I decided to do another FPGA trace. This shows I have to implement the handling of the special memory chip, because it is called after most touch events. What also happens is that the touch panel is scanned twice followed by another command sequence.

The implementation of the special memory chip will at least speed up the scope, since it will then not loop through trying it so many times.

It is a tough nut to crack, but I keep on cracking

[pcprogrammer]

Had to attend to other business so it took a while to get to the implementing of the parameter storage emulation.

I still wonder what the designer was thinking when he came up with this, to my opinion idiotic, system for the parameter storage. The data seen on the I2C bus between the FPGA and the special chip is "encrypted" with an xor for which the key (a byte) changes after every write and read. After a write the scope code mangles the byte by swapping bits in always the same pairs (7,2),(5,0),(6,4),(3,1). After a read it inverts the byte. There is also a checksum which is checked in the scope code.

Still have to implement the write part, which needs some investigation, because before every read it does a write, so when to know if a value needs to be stored as a new setting.

The reading works, but for now all the parameters return 0, but at least the repeated reading has been eliminated. (It did the write and then tried the read 50 times and repeated this sequence 5 times)

Unfortunately the scope still shows no response to the "touch".

The whole parameter part needs to be investigated to see which settings are read and what the response should be for it to work properly.

[pcprogrammer]

Question.

Is there someone with a 1013D scope and a good I2C sniffer willing to capture the data communication between the fpga and the special chip.

The connections can be made with the 4 pin header next to the fpga flash chip. Tried it myself with a STM32F103 but it is not fast enough. Also the Rigol MSO5074 does not help because triggering on the first data is tricky. The lines flip when the fpga loads and then it takes to long before the actual data comes.

The sniffer needs to be able to handle 820KHz, because that is the rate of the clock signal.

What I need is the raw data. It is a fairly constant process of packets of 8 bytes. First a write session to I2C address 0 and then a read session from I2C address 0. At startup there will be an initial read session without the write. This is to get the "crypt key". I also noticed that when the touch panel is touched the communication stops as long as there is touch.

It would be a great help in the reverse engineering.

[iscle]

I have a cheap eBay "Logic Analyzer" dongle, which *should* support up to 24MHz. (Searching for "24MHz 8 channel login analyzer" brings it up). I can try to sniff it, but I have never used this so I don't even know if it works.

I'll have a try in a few days.

[e_Johny]

Hello.
I have this Logic Analyzer, too.
What kind of dataformat you need? And how many "sequence/frame"?

[e_Johny]

I saved the "turn on procedure" of the scope, with "Saleae Logic 2" (my prog version is 2.3.26)
I hope it can be open without hardware device too.

[bianchifan]

b) They help me For me it helps to write about what I encounter and sometimes brings light to my brain.

That's absolutely ok!
BUt it should be very hard to read for people just searching for some funded infos on the scope.
Instead of a daily diary i would suggest a seperated thread of its own - "Hacking the tablet scope" .
Or a detailed diary on github or something else

And now back to the roots..
After a two weeks break with this stuff I managed the capture of short pulses e.g. slope of a rectangle edge.
Despite the info that the Single Trigger does not work I found out, that it works sometimes..
On MY scope it works after switching on and choosing "Single" trigger at once.

I can save the actual waveform and continue with my observations.
But when I save a pic (in single trigger mode) the scope does not trigger any more.
When I change the timebase before saving, the screen gets black and I'm forced for a switch-circle-party...
When I save a pic elsewhere and change the trigger to single later I 'll get the screen.. but no signal line, the single trigger does not work.
Saving pics the scope still has problems catching the actual measuring cursors...


I strongly recommend DO NOT SAVE PICS during your working session!
Save waveforms and choose the pics you like to save at the end from the stored waveforms.

Question.
Is there someone with a 1013D scope and a good I2C sniffer willing to capture the data communication between the fpga and the special chip.

Maybe later this week.
My problem: I didn't use my DSLogic for a longer time and  with my Ubuntu 20.04 upgrade there went something wrong and must install my system from scratch -> no DSView, no patched Pulseview
Standard pulseview does not recon my hacked DSLogic(plus)

[pcprogrammer]

I saved the "turn on procedure" of the scope, with "Saleae Logic 2" (my prog version is 2.3.26)
I hope it can be open without hardware device too.

Thanks very much. 

I'm able to start the "Saleae Logic 2" program without hardware device and it looks very nice. Did not find an option to actually export the i2c data bytes (did not look very hard though, and maybe there is an option), so I will note them down by hand and decode them to get the "unencrypted" data and see if I can get my code to return the intended results.

Did find what one of the fpga commands needed to return. The 0x0A command seems to always return a 0x01, at least this is what he code check on and skips the touch panel wait if it is true. So the emulator now continues to the scope screen without having to "touch" the screen.

Hope that all the used parameter id's are in the trace you made, but hope that you are willing to capture more if needed.

[pcprogrammer]

The I2C implementation of the chip they used is not up to specs. Found what the capture software rightfully identified as a re start, but actually is data. Could this be the reason why they have this multiple repeat loop in the software.

Edit: I can actually see it going wrong multiple times in the capture. The wider blobs at the beginning and end of the screen are repeated reads.

[e_Johny]

Thanks very much. 
.
.
...hope that you are willing to capture more if needed.

Yes,
I'm happy to help. 

[pcprogrammer]

BUt it should be very hard to read for people just searching for some funded infos on the scope.
Instead of a daily diary i would suggest a seperated thread of its own - "Hacking the tablet scope" .
Or a detailed diary on github or something else

A poll:
How many of the readers of this post want me to move the hacking updates to another thread?