FNIRSI-1013D "100MHz" tablet oscilloscope

[pcprogrammer]

312MHz: 29.91s, 273.88MB/s
408MHz: 23.15s, 353.86MB/s
The performance increase is linear, so clearly the bottleneck here is the ram itself.
Being memory copy (read+write), the bandwidth would be 2x those numbers: 548 and 707MB/s

You mean CPU I guess. If the RAM is a bottleneck it would top of at some CPU speed.

No expert on Linux but does it actually read and write RAM when these devices are used?

The 16bit bus connecting to the RAM can run on yet another clock speed. AHB and APB bus have their own clocks. The documentation is not clear on where the DRAM is connected, but the DRAMC (controller) is connected to the AHB bus. So if it runs through that it has yet another bottleneck.

Very complex these ARM architectures. Nothing like a simple 6502 system with some ROM and RAM

[DavidAlfa]

Nope, the ram. 312/408MHz was the DDR speed!
The tests were performed with the CPU running at 768MHz.
If at the same CPU speed, increasing the ram speed by 30% also increases throughput by 30%, the cpu isn't bottlenecking.
Otherwise it would't get much better with the extra speed.
AHB runs at 600MHz if I remember correctly.
These things can be seen in the CCU section of the user manual. All the PLLs are listed there with the default values.

[pcprogrammer]

Right, that was not clear to me in your previous post that the 312MHz and 408MHz where RAM speeds. These numbers are much higher then the max you gave earlier for save performance.

In the scope code I'm working on the AHB and ABP buses are tuned down to 300MHz and 150MHz.

There is a lot I have to experiment with when done with the code reversal.

• Clock settings
• DEBE and maybe DEFE peripherals
• TCON peripheral
• GPIO speeds
• etc.

[DavidAlfa]

Because I'm talking about DDR speeds, not the ram speed. The ram was actually 156/204MHz.
To avoid more confusion, I put the real rates

I don't think you should slow down the bus where the DRAM is connected to. You're hurting the performance badly.
Anything else wanting to use at the same time will have to wait. At 600MHz bus and 312MHz ram, it's less likely to happen.
And if it happens, you know the ram will only use 50% at most.
The SRAM is also connected to the AHB. Not a good thing, you want it to be as fast as possible.

[pcprogrammer]

It is getting weirder

When the calculated signal peak peak value is less then 20 or for the lowest volt per div setting 35 it is either overwritten with the average if there is a big enough dc component or the trace offset (center line). For the latter they increment or decrement it, once so many samples, depending on the value of a sample. This explains the small blips when no signal is connected to the scope

Took me a bit of time to figure this out. The code, also with what Ghidra made of it, is rather umpffff

Code: [Select]

void FUN_80006654(void)
{
  uint uVar1;
  uint uVar2;
  ushort *puVar3;
  uint uVar4;
  uint uVar5;
  ushort *unaff_r4;
  ushort *puVar6;
  int unaff_r5;
  int iVar7;
  ushort uVar8;
  uint uVar9;

  puVar6 = DAT_800067a0;                      //0x801AC04A   sample buffer
  uVar8 = *(ushort *)(DAT_80006798 + 0xec);   //0x801FA24C   channel 1 average

  uVar1 = (uint)uVar8;                        //again average

  uVar5 = 0;

  if (*(char *)(DAT_8000679c + 3) == '\x06')   //0x8019D5A0   channel 1 volt per div
  {
    uVar2 = 0x23;                              //Some minimum value???
  }
  else
  {
    uVar2 = 0x14;                              //Less when signal not doubled
  }

  uVar4 = DAT_800067a4;                        //0x000009C4     2500 number of samples

  if (*(byte *)(DAT_8000679c + 10) < 0x19)     //Time base less then 25 (50mS/div - 500nS/div)
  {
    uVar4 = DAT_800067a8;                      //000005DC       1500 number of samples
  }

  //Skip when signal is high enough
  if (uVar2 <= *(ushort *)(DAT_80006798 + 0xe8))      //signal peak peak
  {
    return;
  }

  //Channel screen offset
  // avg + minimum signal needed less then screen offset or screen offset plus minimum signal needed less then avg
  //Check if the center of the signal is outside the minimal signal band around the center line
  if ((uVar1 + uVar2 < (uint)*(ushort *)(DAT_8000679c + 6)) || (*(ushort *)(DAT_8000679c + 6) + uVar2 < uVar1))
  {
    //some dc component detection with small signal on it

    //Double compensation less then peakpeak
    if (uVar2 >> 1 < (uint)*(ushort *)(DAT_80006798 + 0xe8))  //This is nonsense. Only if signal peak peak is less then uVar2 it can get here!!
    {
      return;
    }

    if (uVar4 == 0)  //What the bullshit here. Is set to a fixed value in the above code!!!!
    {
      return;
    }

    //With full compiler optimisation it probably does not make a difference if the loop does only one sample at a time
    //Plus with the number of samples set above (1500 or 2500) it will always be even number

    puVar3 = DAT_800067a0 + -1;  //Point to 1 sample before buffer

    if ((uVar4 & 1) != 0)        //Odd number of samples to do
    {
      *DAT_800067a0 = uVar8;     //fill the buffer with avg value??
      puVar3 = puVar6;           //sample buffer
    }

    uVar4 = uVar4 >> 1;          //Half the count

    if (uVar4 == 0)              //How can it be zero when you set it to 2500 or 1500!!!!!!!!!
    {
      return;
    }

    do                            //Fill the buffer with average value
    {
      puVar3[1] = uVar8;
      uVar4 = uVar4 - 1;
      puVar3 = puVar3 + 2;
      *puVar3 = uVar8;
    } while (uVar4 != 0);

    return;
  }

  iVar7 = DAT_8000679c;           //Settings base 0x8019D5A0

  if (uVar4 == 0)                 //Again how can it be zero!!!!
  {
    puVar6 = unaff_r4;            //Some stack stuff restore for return. Ghidra nonsense
    iVar7 = unaff_r5;
  }

  uVar2 = 0;                     //Init

  if (uVar4 == 0)                //And again how can it be zero!!!!!!
  {
    return;
  }

  do
  {
    uVar9 = (uint)puVar6[uVar2];   //Sample buffer indexed, so get sample

    if (uVar1 <= uVar9 && uVar9 != uVar1)  //if average less or equal and it is not equal, so sample above average line or not
    {
      //above average line
      if (uVar5 < 0x15)   //starts on zero   so first samples are on offset
      {
LAB_80006738:
        uVar8 = *(ushort *)(iVar7 + 6);           //avg var is channel offset
      }
      else
      {
        uVar5 = 0;                                //Reset counter
        uVar8 = *(short *)(iVar7 + 6) + 1;        //avg var is offset + 1
      }
    }
    else
    {
      //below average line

      if (uVar1 <= uVar9)                         //Can only be equal since the other if takes the average less then samples
      {
        uVar8 = *(ushort *)(iVar7 + 6);              //avg var is channel offset
        uVar5 = uVar5 + 1 & 0xfffeffff;
      }
      else
      {
        if ((uVar5 < 0x15) || (uVar5 = 0, *(short *)(iVar7 + 6) == 0))  //The offset can't be zero since it is limitited between 7 and 395 but as safe guard checked on zero before subtract
          goto LAB_80006738;

        uVar8 = *(short *)(iVar7 + 6) - 1;
      }
    }

    puVar6[uVar2] = uVar8;                  //overwrite the sample
    uVar2 = uVar2 + 1 & 0xfffeffff;

    if (uVar4 <= uVar2)  //do all the samples
    {
      return;
    }

  } while( true );
}


I have implemented it in the new code, but might remove it once proved unnecessary.

Edit: Thinking about it, it looks like a squelch setup to suppress noise.

[pcprogrammer]

It would be very interesting to see the actual code written by the developers and compare it to what Ghidra made of it.

For example is this bit compiler cleverness or written this way.

Ghidra output

Code: [Select]

if ((uint)((ulonglong)(uint)*(byte *)(iVar3 + 0xb) * (ulonglong)DAT_8001af94 >> 0x21) * -3 + (uint)*(byte *)(iVar3 + 0xb) == 0)
Translated to some variable name and used constant

Code: [Select]

if (((((ulonglong)backup * (ulonglong)0xAAAAAAAB) >> 0x21) * -3) + backup) == 0)
And my take on it

Code: [Select]

if((backup % 3) == 0)
Getting the short time base trace data capturing and handling reversed is quite the task. There are a lot of variables that still have no real meaning on what they are for and loads of code that do some processing on the data. Still progressing but it takes a lot of energy

Analyzing the output of Ghidra, searching what the value of a constant is, or which variable is pointed to. By now I know quite a bit of them by heart, but something like "*(char *)(iVar3 + 10)" is harder to read then "timeperdiv" or "*(char *)(iVar3 + 0x3a)" which is "runstate"

Guess it will take a couple of day's to get through this bit

[DavidAlfa]

Damn, that's almost ofuscated code! 

[pcprogrammer]

Damn, that's almost ofuscated code! 

And that's throughout the whole code. So you can imagine the effort it takes to get things back to normal C code that works.

[pcprogrammer]

Found another error

When the scope is in stop mode it is possible to zoom in or out on the last sample buffer. They use the up sampling code for this. Only when one sampled in 100nS/div and then zooms in to 25nS/div actually gets 20nS/div

Pictures are not so sharp, but one can see what I'm talking about.

The first image is the original signal. Channel 1 5MHz and channel 2 10MHz. (This is data already gone through factor 5 up sampling)
The second shows it zoomed to 50nS/div. This one is ok.
The third image shows it zoomed to 25nS/div

[pcprogrammer]

Managed to get signal on the display for the short time base settings.

It works somewhat ok from 500nS/div to 10mS/div. On 50mS/div and 20mS/div only the first half of the screen gets the input signal data and the other half is data from a previous sampling on 10mS/div setting. The 250nS/div down to 10nS/div gives the same trace as on 500nS/div.

Experimented a bit with the FPGA commands, but it seems they are all needed. Not calling the special ic to get the command for reading the trace data is needed. Without it the trace is all over the place.

Also, since I'm not processing the data the way the original code does it, and obtain a higher update rate that way, it is quite unstable.

More of the original code is needed to get it to work the way the original does. Knowing what I know now about the system I'm not sure if it is worth continuing on this road. Think it is time to move on to write new FPGA logic to really get some improvements.

This is a whole new ballgame and not something done in a short time.

Will continue with diving into SD card and USB handling first, since that is also needed for a fully working system.

[pcprogrammer]

Here's johnny

Took a couple of day's of to recharge ye ol batteries.

Bought another tablet scope to be able to do side by side comparison and finally re-soldered the flash in the first one. The new one arrived yesterday and fortunately without defects

Screwed the old one back together and started on the flash write code. Had to open it up again, because my boot to fel setup fails to work with the flash for reading it through fel. No idea why, but it just returns zero's. With the original boot to fel no such problem, so had to use that version to check if the flash was written. No such luck, so had to connect the Rigol MSO and check the signals. The CS line was not acting as intended. Miss-optimized things. Needed to wait until all the bytes are send before the code can continue. But that is fixed and working now.

Onto the next. The SD card stuff. Thought, lets use a bigger card with my fel boot on it and then have plenty of room to experiment with the card, but strangely enough it does not work when written to bigger cards, at least not for me. Smallest one after the 128MB I have is 4GB and even with the original fel boot it won't work

So I guess I will have to keep the scope opened up and switch cards to test stuff.

[pcprogrammer]

Here's johnny

Apparently my reference to the Shinning did not trigger anybody

But that aside, the SD card stuff is completely new to me and is going to take a bit of time.

Did manage to crasp a bit of the functionality and more or less matched parts of the code to the sunxi-mmc implementation in the u-boot code for the Allwinner chips. A lot of the debug texts can be found, and there is a function which I called uart_printf that probably is debug(char *str, ...) in the u-boot version. It also uses vararg, but I used the name with UART in it since it writes the string to the UART. (Never leaves the chip though since the UART GPIO is used for the connection with the FPGA)

Looked into SD card interfacing on the net and found the Arduino library, which can act as a guide line. Have to look for the file functions on top of the SD card functions.

The now identified function check_for_firmware_upgrade, which earlier in this thread I dismissed because it can overwrite the first 1000 bytes of the program area in the FLASH with zero's, checks if there is a file with either of these names on the SD card. "UTX-1013.bin", "FSI-1013.bin", "DAN-1013.bin" or "YPK-1013.bin", so there is a starting point for my search.

Noticed that these names have been found before in this thread. (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3144296/#msg3144296) Further searches on the net for these file names did not lead anywhere

Again, the story continues

[pcprogrammer]

Think I found the source code used for the file system used in the scope.

http://elm-chan.org/fsw/ff/00index_e.html

Because what are the odds of several functions showing the same things at the beginning, one of which in my book is a no no.

Code: [Select]

int FUN_800337c4(char **param_1,uchar *param_2,uint param_3)
{
  if (param_1 == (char **)0x0)
  {
    return 9;
  }


Code: [Select]

typedef enum
{
  FR_INVALID_OBJECT,      //(9) The file/directory object is invalid
} FRESULT;

FRESULT f_open (FIL* fp, const TCHAR* path, BYTE mode)
{
  if (!fp)
    return FR_INVALID_OBJECT;


Code: [Select]

uint FUN_80033b18(int param_1,int param_2,uint param_3,int *param_4)
{
  *param_4 = 0;
  uVar1 = FUN_800390e8(param_1,aiStack44);


Code: [Select]

FRESULT f_read (FIL* fp, void* buff, UINT btr, UINT* br)
{
  *br = 0;                                  //Clear read byte counter
  res = validate(&fp->obj, &fs); //Check validity of the file object

The no no is the writing to a pointer without making sure it is valid.
Removed parts of the code not needed for the comparison and cleaned it up a bit. The FatFs code is written in a style I very much dislike. Cluttered and hard to read.

But is makes live easier and all that needs to be done is figure out the low level stuff that is needed on the bottom end of the FatFs code.

Also have a better idea about the firmware upgrade setup. Not sure if it is true and think it could have been done much simpler.

The code reads the header of the firmware image file on the SD card and performs some checks. If found valid the first 1000 bytes of the flash where the program resides is cleared.
Then a reset is forced by the use of the watchdog timer. This triggers the SPL to start loading the code again, but it fails with the loading of the main program because the BROM header is no longer there.
As a result to that, it loads the other program we found in the flash. (When I tried it, some time back, this program set the scope in FEL mode.)
But my guess is that when the SD card holds a valid firmware file it loads that and performs the flash writing to fix the previously cleared part and, at the end of it, restarts the scope again.

When the system file is corrupt it shows this on the scope screen and goes into USB connect mode. This way one can correct the contents of the SD card.

Have not verified this and since there is no firmware file to be found for this device it is also not that simple to check.

It might open up an easy way to update scopes when new firmware has been created. But that still has a long road ahead.

Edit: Realized that for new FPGA content the device needs to be opened up, so in that case it is just as easy to use another method of loading the new code.

[tv84]

Think I found the source code used for the file system used in the scope.

When there is a will, there is a way. You continue to amaze me. 

[pcprogrammer]

Gave the firmware upload a try. Renamed the FSI-1014.bin file to FSI-1013.bin and loaded it onto the SD card of my test scope. Restarted it and it got stuck showing the FNIRSI startup bitmap. Not sure if the SPL is my own version or the original, so not sure why it did not started loading new firmware, even though it is for the other scope.

Read part of the FLASH that holds the main program and the first 1000 bytes are zero, so that actually works.

Re flashed the firmware via FEL and tried with a bitmap file renamed to FSI-1013.bin. This time I got the "system file damaged!!!" message.

This confirms part of my previous post. The found function is for upgrading the firmware, but it fails with the firmware for the 1014D.

[DavidAlfa]

The "no no" is probably optimized because the compiler saw that there was a valid pointer when calling the function.
FatFS is widely used in the embedded world, no surprises here

[pcprogrammer]

The "no no" is probably optimized because the compiler saw that there was a valid pointer when calling the function.
FatFS is widely used in the embedded world, no surprises here

Wrong. The function is called with 0 for that parameter, and it is also in the original source, that they don't check on the pointer being valid.

[DavidAlfa]

You're right! f_open also does the same.
Well, be careful  .

[pcprogrammer]

Not a lot of progress due to other business I have to attend to.

Today I found the functions that do the communication with the SD card. They seem to be based on the sunxi_mmc implementation, but are not an exact match. Improved on using Ghidra some more and inserted the structs used by the sunxi_mmc "send command" function. This makes things easier to read and understand.

Also identified a lot of the FatFs functions. These also are no exact match to the latest version and as there are quite a few revisions of it, it is hard to find the exact match. Also not really needed since it is about the functionality and not the exact same source.

Homing in on the code above the FatFs layer. On the SD card four files are used to maintain information about the picture and waveform files. Two of them are 400000 bytes in size and I think these hold the scope settings of the time the waveform or picture was taken. The other two are 2000 bytes in size. No idea yet as to what these are used for. The files are created when not on the card, so inserting a blank formatted SD card is no problem. The scope makes these files when needed. (Functions "load_selected_list_file" and "load_selected_system_file")

Uploaded a new Ghidra archive with the latest findings. (https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Software%20reverse%20engineering)

It will take a while before I have working code for this all. A lot of functionality to re create

[pcprogrammer]

Still working on the SD card stuff.

Getting an understanding of how things work but run into a question of why something is done.

In the scope code they use DMA when there are more then 64 bytes to transfer. Since they are not using interrupt to handle the transfer, for as far as I can see, it is making things more complex then needed, but that is not what it is about.

When using DMA they use some code to do something with the caches and I wonder why?

Code: [Select]

    uVar7 = (uint)data->data & 0xffffffe0;

    while (uVar7 <= ((uint)(data->data + data->blocks * data->blocksize) & 0xffffffe0))
    {
      coproc_moveto_Invalidate_Data_Cache_by_MVA(uVar7);
      coproc_moveto_Invalidate_Instruction_Cache_by_MVA(uVar7);
      uVar7 = uVar7 + 0x20;
    }

In assembly it is this

Code: [Select]

LAB_800370b8
        800370b8 3e 0f 07 ee     mcr        p15,0x0,r0,cr7,cr14,0x1
        800370bc 35 0f 07 ee     mcr        p15,0x0,r0,cr7,cr5,0x1
        800370c0 20 00 80 e2     add        r0,r0,#0x20
        800370c4 01 00 50 e1     cmp        r0,r1
        800370c8 fa ff ff 9a     bls        LAB_800370b8

They invalidate both the data and the instruction cache for 32 byte blocks. A pointer to where the data resides is send to the co-processor. This pointer is incremented with 32 after every iteration of the loop.

Anyone?

[tv84]

Anyone?

Sorry, can't help. Remember sometimes it's not the app programmers, but the guys that implemented the compiler... 

[pcprogrammer]

Anyone?

Sorry, can't help. Remember sometimes it's not the app programmers, but the guys that implemented the compiler... 

You are right, but if it is something of the compiler then it still has to make some sense

[robca]

They invalidate both the data and the instruction cache for 32 byte blocks. A pointer to where the data resides is send to the co-processor. This pointer is incremented with 32 after every iteration of the loop.

Anyone?

I know nothing about this specific processor, but in one of the processors I worked with (STM32H7), you needed to invalidate the cache to ensure that the DMA transferred actual data and not stale data from the memory not yet updated from the cache to actual RAM. More here https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices

Maybe it's the same in your case?

P.S. big fan of the work you are doing, just lurking here unable to help, but always looking forward to your updates. 

[pcprogrammer]

Robca, thanks for your response.

The stuff about the H7 is very interesting, and I guess it also applies in this case. Still a bit weird that they also invalidate the I-Cache. For the data it makes sense.

For my version of the code I will only use the transfer by cpu method, because without using interrupts and still waiting for the card writing or reading to be finished there is no gain.

This SD card part is a big chunk of the total scope code, so once finished a lot more of the functions in Ghidra will be identified.

Still a long road ahead before there is a complete open source version for this scope

[DavidAlfa]

Of course there's gain waitng for the dma witghout interrupt. The cpu must go through the loop each time, storing/increasing the pointers, fetching the data and moving it somewhere, so there're some instructions there.
DMA handles everything, so setting the DMA and waiting for the transfer to be done will be a lot faster when the transfer size increases.
Of course, there's a minimum transfer size, below which it'll take more time to setup the dma than doing it with cpu power.

Make some test. Ex. transfer a 64-byte block 100.000 times using cpu and dma, then start increasing the  block size, you'll see huge gains.

It heavily depends on the architecture, bus speed, congestion, dma configure cost... for example, just a quick test using a stm32, the dma was lower than cpu in transfer sizes below 256bytes.
For 64 byte transfers, DMA was almost 2x slower, so you must find the size below which dma is no longer efficient.