Author Topic: FNIRSI-1013D "100MHz" tablet oscilloscope  (Read 402752 times)

stedivid and 5 Guests are viewing this topic.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #725 on: April 17, 2021, 09:50:20 am »
The FPGA Encrypt check is nothing else than sending command 0x41 to the FPGA and read two bytes. The result is checked against 0x8150, being the GT911 register address for "point 1 lsb X coordinate"

Did not look at the other checks yet.

The question is if this function is even used, or how they do the check on the touch panel. Because it it possible to not have the touch panel connected. The scope starts just fine in that case.
« Last Edit: April 17, 2021, 10:03:26 am by pcprogrammer »
 

Online tv84

  • Super Contributor
  • ***
  • Posts: 3214
  • Country: pt
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #726 on: April 17, 2021, 10:12:42 am »
This func is called for sure BUT, depending on its 1st verification : sub_8002330C, it may bypass the HW check.

Or the Touch only fails if you have an invalid touch HW attached.
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #727 on: April 17, 2021, 10:24:52 am »
Which is an interesting function full with all kind of hardware checks, down to the detecting of failure of the AC/DC relays (KAQY214S)

Offline alangave

  • Newbie
  • Posts: 4
  • Country: fr
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #728 on: April 17, 2021, 11:01:32 am »
Hmm very strange. Do you have the problem on both channels?

Check the following signals on the ADC's to see what is there. Should be stable DC levels. REFOUT (pin 6), AINA = AINB (pin 3 and 10).

Also check if there is distortion on the 3.3V supply, since the ADC's are powered with it. And take a look at the ADC1_OFFSET and ADC2_OFFSET signals coming from the FPGA.
Unfortunatelly, nothing weird: Supply ok, no ripp^le (at least nothing visible on my old 20Mhz scope), voltage on above pin looks ok too, I mean, stable
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #729 on: April 17, 2021, 11:31:09 am »
When you are probing the signals with your other scope, can you still see the distortion on the FNIRSI scope? The grounding with the other scope might change the playing field. Is a bit of a problem with this kind of measurements.

It is unlikely that the sine is introduced in the FPGA or the F1C100s code. Since at startup you say it works normal for a while, it might be some capacitor that starts to leak.

Check the power supply schematics, and measure on the switchers to see if you can find a ~25KHz signal. Best bet is the LCD back-light, which is being modulated by the FPGA. Come to think of it, see what happens when you change the brightness to another level. When the signal on the screen changes frequency, then you are closing in on the source.

Offline alangave

  • Newbie
  • Posts: 4
  • Country: fr
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #730 on: April 17, 2021, 04:21:16 pm »
no difference when probing the signal on the other scope, or not ...

I was also suspecting a bad component starrting leaking or something
Even though about external electromagnetic perturbation (led lamp, computer , ...), but no change after having powered off eveything or changing place

Regarding screen, I have noticed that it start flipping when I try to reduce screen brightness when phenomenum occur, after a ~1 minutes.

The strange but noticeable thing is that this parasite appears on both channel even unplugged.

I'll check the LCD back light...
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #731 on: April 18, 2021, 06:12:41 am »
no difference when probing the signal on the other scope, or not ...

I was also suspecting a bad component starrting leaking or something
Even though about external electromagnetic perturbation (led lamp, computer , ...), but no change after having powered off eveything or changing place

Regarding screen, I have noticed that it start flipping when I try to reduce screen brightness when phenomenum occur, after a ~1 minutes.

The strange but noticeable thing is that this parasite appears on both channel even unplugged.

I'll check the LCD back light...

Based on the photo in your first post I did some calculations. The signal on the screen shows it is ~2 divisions whilst the full screen is 8 divisions. This means the signal you are looking at is a 1/4 of the ADC input range. This is according to the specs +/-512mV p-p, so a 1.24V swing. This means the signal on the differential inputs of the ADC is only 0.31Vpp.

Since it is on both channels, even when nothing is plugged in, this means that it resides in the common signals for both the ADC's. 3.3V supply, 2,5V supply and VRF1. Look at these signals again with AC coupling and zoom in on the ripple. See if you can find a ~25KHz, >300mVpp signal.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #732 on: April 18, 2021, 10:36:25 am »
First test with FEL code execution failed. Probably due to missing configuration of the clock registers. Just wrote a simple piece of code setting up the FPGA bus and writing the back-light command to it.
Nothing happened apart from a locked up scope.

Code: [Select]
#include "fpga_control.h"

int main(void)
{
  fpga_init();
 
  fpga_write_cmd(0x38);
  fpga_write_short(0xEA60);
 
  while(1);
}

So some study of the MCU itself is needed to enable the peripherals.

Online tv84

  • Super Contributor
  • ***
  • Posts: 3214
  • Country: pt
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #733 on: April 18, 2021, 12:03:40 pm »
Are you doing the correct delays? Have you analyzed your sequence timings? I think they have embedded delays in the code.
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #734 on: April 18, 2021, 01:23:47 pm »
I looked at the assembly of the code I wrote and it looks similar to what is in the scope. No delays in there. Only difference is that they use function calls for the clock pulse, which might make some timing difference. And the scope might run on a different CPU frequency, but that is most likely higher than default. They switch to 600MHz. Default is 408MHz according to the manual.

Did not find a register for enabling the GPIO yet, so not sure if it is always on. I'm used to the STM devices, and there you have to turn on every peripheral there is including GPIO. I'm always on about the bad quality of the STM documentation, but this is even worse.
« Last Edit: April 18, 2021, 01:55:01 pm by pcprogrammer »
 

Online tv84

  • Super Contributor
  • ***
  • Posts: 3214
  • Country: pt
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #735 on: April 18, 2021, 01:54:20 pm »
I looked at the assembly of the code I wrote and it looks similar to what is in the scope. No delays in there.

For you, what is the use of sub_8000BC34 ?
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #736 on: April 18, 2021, 01:56:40 pm »
That is a delay function, but that is not used when clocking the FPGA. It is used in between some actions they do with the FPGA.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #737 on: April 18, 2021, 04:22:35 pm »
It turns out that the GPIO is indeed enabled when the MCU is running in FEL mode. I hooked up my MSO5074 to the touch panel connection (Port A) and used sunxi-fel to set the port configuration to output and was able to toggle the pins and see it on the scope. Wrote a program to do the same, uploaded it to 0x80000000, called exe on the same address and it did not work.

So now I'm wondering if it is the internal DRAM that needs to be enabled first. I read the three BUS_CLK_GATING_REG registers and the only part turned on is the USB_OTG_GATING.
There is a bit SDRAM_GATING, but most likely other registers need to be configured to make it work. It is back to the Ghidra output and check the SPL part to see what is done in there.

Edit: Had a brain wave |O There is SRAM at address 0x00000000, that can be used. Tested the back-light code there and it just works. This means that for testing bigger stuff FEL is not the way to go, unless a script is made to use the sunxi-fel writel option to configure all the needed registers for enabling the DRAM.

The default PLL_CPU setting is 0x80011000, which translates into 204MHz instead of the 408MHz mentioned in the manual.

Edit2: Used sunxi-fel to set the clock to 600MHz and tested the back-light code again. It still works. Tested it with my port A toggle program and was able to verify that the MCU is indeed running on the higher speed.
« Last Edit: April 18, 2021, 04:59:08 pm by pcprogrammer »
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #738 on: April 19, 2021, 10:01:03 am »
Analyzing the code of function FUN_80024EE0 makes me think the commands in the 0x6X range have the following meaning. In the function FUN_800248f8 the function FUN_80024EE0 is called to do a write and then a read is done. Still have to analyze FUN_800248f8, because there is some sort of fail safe in there. It seems the reading can be done at max 50 times and the whole process (writing and reading) 6 times.

The writing followed by reading, I have also observed when I was measuring on the I2C bus coming from the FPGA.

Code: [Select]
//Commands to interface with the I2C chip connected to the FPGA
//0x64    Prepare bus for reading. Send twice in a row.
//0x65    Prepare bus for writing. Send twice in a row.
//0x66    Start the communication.
//0x67    Read the status flag. Bit 0 needs to become 1. Needs to be preceded by 0x66
//0x68    Not clear about this one. Is read from a memory address and Ghidra sees it as 0x09.
//0x69    Parameter id and byte count. iiiiiicc. 6 bits id and 2 bits count.
//0x6A    Checksum. sum of the other 6 bytes
//0x6B    Value byte 3 MSB. 0x69 when not used.
//0x6C    Value byte 2. 0x96 when not used.
//0x6D    Value byte 1. 0x99 when not used.
//0x6E    Value byte 0 LSB.

Edit: Found a third function that uses the I2C read commands. It is in the initialization section of the code. FUN_80024E18. Based on that I wrote some test code that repeatedly sends the commands to the FPGA. Hooked up my MSO5074 to the I2C bus pins and it is working as I suspected. This first read is used to set the byte in memory that is later used to fill in the byte for command 0x68.
« Last Edit: April 19, 2021, 11:25:56 am by pcprogrammer »
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #739 on: April 19, 2021, 12:51:16 pm »
Am I stupid or can the if parts in below code be done with a single XOR???  |O :-DD

And guess what I'm not. This code is used to invert bits in the received bytes based on the byte received from command 0x68.

Why they made the parameter storage like how they did it, and not with a fer-rite based or other long lasting non volatile storage I don't know. Don't know the prices of these chips and how much a difference it would have made, but I find it stupid design decisions.

Code: [Select]
void FUN_80024b14(void)
{
  byte *pbVar1;
  uint uVar2;
  byte bVar3;
 
  pbVar1 = DAT_80024c78;                                                 //0x8035EC04. Buffer in DRAM
  uVar2 = 1;
  bVar3 = ~*DAT_80024c78;                                                //Byte received from command 68 inverted
  *DAT_80024c78 = ~*DAT_80024c78;                                        //Keep it in the same spot for later

  do
  {
    if ((bVar3 & 0x80) != 0)                                             //When bit 7 of the byte from command 0x68 is set
    {
      pbVar1[uVar2] = ~pbVar1[uVar2] & 0x80 | pbVar1[uVar2] & 0x7f;      //Invert bit 7 and or it back in with the rest of the bits
    }

    if ((bVar3 & 0x40) != 0)                                             //When bit 6 of the byte from command 0x68 is set
    {
      pbVar1[uVar2] = ~pbVar1[uVar2] & 0x40 | pbVar1[uVar2] & 0xbf;      //Invert bit 6 and or it back in with the rest of the bits
    }

    if ((bVar3 & 0x20) != 0)                                             //When bit 5 of the byte from command 0x68 is set
    {
      pbVar1[uVar2] = ~pbVar1[uVar2] & 0x20 | pbVar1[uVar2] & 0xdf;      //Invert bit 5 and or it back in with the rest of the bits
    }

    if ((bVar3 & 0x10) != 0)                                             //When bit 4 of the byte from command 0x68 is set
    {
      pbVar1[uVar2] = ~pbVar1[uVar2] & 0x10 | pbVar1[uVar2] & 0xef;      //Invert bit 4 and or it back in with the rest of the bits
    }

    if ((bVar3 & 8) != 0)                                                //When bit 3 of the byte from command 0x68 is set
    {
      pbVar1[uVar2] = ~pbVar1[uVar2] & 8 | pbVar1[uVar2] & 0xf7;         //Invert bit 3 and or it back in with the rest of the bits
    }

    if ((bVar3 & 4) != 0)                                                //When bit 2 of the byte from command 0x68 is set
    {
      pbVar1[uVar2] = ~pbVar1[uVar2] & 4 | pbVar1[uVar2] & 0xfb;         //Invert bit 2 and or it back in with the rest of the bits
    }

    if ((bVar3 & 2) != 0)                                                //When bit 1 of the byte from command 0x68 is set
    {
      pbVar1[uVar2] = ~pbVar1[uVar2] & 2 | pbVar1[uVar2] & 0xfd;         //Invert bit 1 and or it back in with the rest of the bits
    }

    if ((bVar3 & 1) != 0)                                                //When bit 0 of the byte from command 0x68 is set
    {
      pbVar1[uVar2] = ~pbVar1[uVar2] & 1 | pbVar1[uVar2] & 0xfe;         //Invert bit 0 and or it back in with the rest of the bits
    }

    uVar2 = uVar2 + 1 & 0xff;
  } while (uVar2 < 7);                                                  //Process each of the received bytes except the first
  return;
}

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #740 on: April 20, 2021, 04:59:55 pm »
First attempt of running linux with the back-light turned on failed. Added the tested turn back-light on code to the mach-sunxi/board.c file to be called at the end, after the init of ethernet function, but nothing. Linux started just fine, but no back-light.

I'm now checking the SPL of the scope and a call to a brightness set function is made. Not sure at what point in time though. The FPGA also needs some time to load it's configuration (have to check how much this is) and maybe my linux try does the write to soon when the FPGA is not ready yet.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #741 on: April 22, 2021, 11:28:44 am »
Did some investigation and measurements on the FPGA configuration loading. The measurement with my MSO5074 shows it takes almost a second to load the FPGA. It clocks the flash with ~2.4MHz.
In the picture is the measurement on the flash clock. Also measured the FPGA conf_done pin and it shows the same time frame.

So within the u-boot the back-light can only be turned on after the configuration of the FPGA. This means that when one wants to see the u-boot messages on the display a delay of 1 second is needed.

I also measured on the F1C100S_FPGA_CLK pin and could see the 3 clock pulses for writing the brightness, but these are way to early.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #742 on: April 22, 2021, 01:36:07 pm »
I'm a bit at a loss. Made a delay loop in the code with some extra code to try to avoid optimization from taking it out, and tested it. Did not seem to do the trick. Measurements show that the "void s_init(void)" function I added the code to, is called twice. No idea why, but it gave me the possibility to measure the delay on being extended. Changed the 50000 to 200000 and it made no difference. So it looks like it is optimized out. Extended the code a bit more and that is compiling now.

The pictures show the FPGA flash clock (blue line) with the yellow line being the F1C100S_FPGA_CLK line. It is hard to see, but there are two spikes going low. These are the three clock pulses to set the brightness. In the zoomed in pictures it is possible to see them with the time of center screen in the top of the screen.

Code: [Select]
void fpga_delay(void)
{
  int i,j;

  //The FPGA has a loading time of ~900mS
  //Delay for allowing the FPGA to be up and running
  for(i=0,j=0;i<50000;i++)
  {
    j += 2;
  }

  if(j>1000)
   i=0;
}

Edit: The change in the code did not make a difference.  |O

Code: [Select]
void fpga_delay(void)
{
  int i,j,n;

  //The FPGA has a loading time of ~900mS
  //Delay for allowing the FPGA to be up and running
  for(i=0,j=0,n=0;i<2000000;i++)
  {
    j += 2;
    n = (j * 3) + i;
  }

  if((j>1000) && (n>1000))
   i=0;
}

« Last Edit: April 22, 2021, 01:46:44 pm by pcprogrammer »
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #743 on: April 22, 2021, 04:07:25 pm »
Decided to use some other method of waiting for the FPGA. It has a command 0x06 which returns the version number 0x1432. So I just repeat a write of this command followed by two reads and check if the right number is returned. It is a bit blunt as can be seen on the picture with the MSO5074. The pink line is the FPGA flash clock and the yellow one is the F1C100S_FPGA_CLK signal. After ~350ms the s_init function is called. It then starts probing the FPGA and once it is ready it gets the right number. It is called a second time ~150ms later, which is the write/read of command 0x06 and the write of the brightness command 0x38.

So there is linux output on the display now, without the need of iscle's trick to use reset to have it starts linux after the screen has been turned on. This only works in the old (16Mbit) version because in the new (32Mbit) version the reset vector is set to jump to 0x80000000 and just starts the scope again.

I will upload the u-boot archive and the image to the repository (https://github.com/pecostm32/FNIRSI-1013D-Hack)

Edit: A better location for setting the brightness is after the display has been initialized. The way it is now the display is in an all white mode and when the back-light is turned on it is very bright. It takes a while after that before any linux output is send to the screen. So most likely this u-boot version is not setup for a display at all or not for this display. The whole embedded linux stuff is still new to me and takes a lot of digging to understand what is going on.

As for the scope, there are still many things to figure out before anything working can be made. The whole signal handling is not clear yet. I'm trying to get to a bare-metal implementation of some copy of the original scope, but the lack of documentation for parts of the F1C100s make it difficult to understand. To get the DRAM inside the chip working requires the setting of a lot of registers. u-boot does do this, but with all the different defines for the different models of the allwinner processors it is not that simple to figure it out.
« Last Edit: April 22, 2021, 06:47:56 pm by pcprogrammer »
 
The following users thanked this post: mleyden

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #744 on: April 23, 2021, 08:57:19 am »
Found an interesting archive in a thread on github (https://github.com/RT-Thread/rt-thread/issues/3648). The archive (https://github.com/RT-Thread/rt-thread/files/4730121/F1C100S_USB_Driver_V1_1.2.zip) holds source code for the startup of the F1C100S and there is a file sys-dram.c in it, which matches code I found in the SPL of the scope.
For instance at address 0x00001150 I found the function dram_get_dram_size.

This makes live a bit easier. Still missing is a good description of a lot of the registers existing in the F1C100s. So if anyone out there has a more complete programming manual of the F1C100s please post it here in the forum.

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16618
  • Country: 00
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #745 on: April 23, 2021, 09:41:19 am »
And, we've got image!



Nice, but without the fpga interface it is just a small linux computer

You say that as if a portable Linux computer with screen for 65 Euros is a bad thing.   :-//

The next question should be "Does it run MAME"?

Edit: It's not 65 Euros, it's over 100. My bad.
« Last Edit: April 23, 2021, 10:30:03 am by Fungus »
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #746 on: April 23, 2021, 09:59:07 am »
You say that as if a portable Linux computer with screen for 65 Euros is a bad thing.   :-//

The next question should be "Does it run MAME"?
Ok, I got mine for 25 euros due to refund, but if I was on a salary, by the time it is fixed it would be way more expensive. But where did you find it for 65 euros? Cheapest I have seen them was 100 euro on Aliexpress and that was when it was on special sale. Now it is >110 euros.

For as far as what will run on it I will leave that experiment to others for now.

Still trying to get to the bottom of the signal part of the scope. Getting better with using Ghidra, which is a great tool, so there is progress.

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16618
  • Country: 00
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #747 on: April 23, 2021, 10:29:11 am »
where did you find it for 65 euros? Cheapest I have seen them was 100 euro on Aliexpress and that was when it was on special sale. Now it is >110 euros.

My bad, I searched for it and it showed some of those Aliexpress "fake price" results. 65 Euros is the nasty yellow one.

100 Euros still isn't a terrible price for ARM computer+screen+case+battery.
« Last Edit: April 23, 2021, 10:31:12 am by Fungus »
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #748 on: April 23, 2021, 10:56:02 am »
where did you find it for 65 euros? Cheapest I have seen them was 100 euro on Aliexpress and that was when it was on special sale. Now it is >110 euros.

My bad, I searched for it and it showed some of those Aliexpress "fake price" results. 65 Euros is the nasty yellow one.

100 Euros still isn't a terrible price for ARM computer+screen+case+battery.

For sure, it is not a bad little machine. And definitely a nice hobby project :)

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3684
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #749 on: April 23, 2021, 12:04:16 pm »
It was a bit of work, but I plowed through the SPL (second program loader) and it is doing the system setup for memory, clocks, spi, fpga and display. It turns out that it is not what I thought before. The SPL loads the bitmap image from the flash and puts it on the display. Then it starts to load the header of the 2nd executable (at address 0x00027000 in the flash), to get the length and what more. If that gives an ok result it loads the rest of the program into the DRAM at 0x80000000. Only if it fails the 1st executable is tested and loaded. If that also fails it runs into an endless loop.

So what is in the 1st executable at address 0x00006000 in the flash? Some test program?

Might give it a try and patch the SPL so it loads the 1st executable instead of the 2nd one.


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf