FNIRSI-1013D "100MHz" tablet oscilloscope

[dmitrkov]

Turning on the oscilloscope on a modified firmware several times in a row, I caught a working (reversible) touchscreen on one of the inclusions. But the next time it was turned on, it did not work again. This happened 2 times at random.

[ser8989]

Turning on the oscilloscope on a modified firmware several times in a row, I caught a working (reversible) touchscreen on one of the inclusions. But the next time it was turned on, it did not work again. This happened 2 times at random.

Попробуйте мой патч, он немного другой.

Try my patch, it's a little different.

[pcprogrammer]

That is why I think I removed to much of the code. It most likely is not initializing the touch panel to slave address 0x14.

I'm looking at the code in depth to see what is going on.

Would be interesting to see what ser8989's modification does.

[dmitrkov]

I wrote earlier that I tried both versions of the modified firmware.  In both cases, the touchscreen does not work.  Tomorrow I'll get a connector for connecting a touchscreen, I'll try it after flashing the touchscreen

[pcprogrammer]

I made a new version. I was right about that the  slave address initialization was also removed. Nopped the call to the send the configuration function to stop only that part. Uploaded it to the hacked files section of the repository. Tested it with my I2C monitor connected and some of the other calls to the touch panel that where removed are now back in.

So the new patched file should work on every power up. Tested it a couple of times. The touch panel needs to have the right configuration of coarse.

Here is the startup communication with the touch panel

Code: [Select]

S
0x28 A 0x80 A 0x40 A 0x02 A P
//Config used to be send here
S
0x28 A 0x80 A 0x40 A 0x00 A P
S
0x28 A 0x81 A 0x4E A S
0x29 A 0x80 N P
S
0x28 A 0x81 A 0x4E A 0x00 A P
S
0x28 A 0x81 A 0x4E A S
0x29 A 0x00 N P
S
0x28 A 0x81 A 0x4E A S
0x29 A 0x00 N P
S
0x28 A 0x81 A 0x4E A S
0x29 A 0x00 N P

Analyzed the function to what it is doing and added comments

Code: [Select]

undefined4 FUN_8001794c(void)                   //This is the function that sets up the configuration for the touch panel
{
  char *pcVar1;
  undefined4 uVar2;
  byte bVar3;
  uint uVar4;
  undefined4 in_r3;
  int iVar5;
  undefined4 local_10;
 
  uVar2 = DAT_80017ab4;                         //0x01C20800. Base register address for Port A
  local_10 = in_r3;
  FUN_8001764c(DAT_80017ab4,3,1,0);             //Setup SCL (PA3) as output
  FUN_8001764c(uVar2,2,1,0);                    //Setup SDA (PA2) as output
  FUN_8001774c(uVar2,3);                        //Set SCL high
  FUN_8001774c(uVar2,2);                        //Set SDA high
  FUN_8001764c(uVar2,0,1);                      //Setup RESET (PA0) as output. Start of slave address init of touch panel
  FUN_8001764c(uVar2,1,1,0);                    //Setup INT (PA1) as output
  FUN_80017738(uVar2,0);                        //Set RESET low
  FUN_80017738(uVar2,1);                        //Set INT low
  FUN_8000bc34(100);                            //Delay function.    100
  FUN_8001774c(uVar2,1);                        //Set INT high. Sequence for selecting 0x14 as slave address (0x28/0x29, write/read bytes)
  FUN_8000bc34(DAT_80017ab8);                   //Delay again.     20000 (Should be 100uS)
  FUN_8001774c(uVar2,0);                        //Set RESET high
  FUN_8000bc34(DAT_80017abc);                   //Delay again.     10000
  FUN_8001764c(uVar2,1,0);                      //Set INT as input
  FUN_8000bc34(DAT_80017ac0);                   //Wait again.     100000
  uVar2 = DAT_80017ac4;                         //0x00008040
  local_10._0_1_ = 2;
  FUN_80017d2c(DAT_80017ac4,&local_10,1);       //Write 0x02 to register address 0x8040. Touch Panel command (read diff data or raw data)
  bVar3 = 0;
  uVar4 = 0;

  do
  {
    pcVar1 = (char *)(DAT_80017ac8 + uVar4);    //There is a buffer at 0x8019CF82 in RAM where it calculates the checksum for the config of the touch panel
    iVar5 = DAT_80017ac8 + uVar4;
    uVar4 = uVar4 + 2 & 0xfffeffff;
    bVar3 = *(char *)(iVar5 + 1) + bVar3 + *pcVar1;
  } while (uVar4 < 0xb8);

  *(byte *)(DAT_80017ac8 + 0xb8) = ~bVar3 + 1;

  //This is the function I nopped out with mov r0,r0
  FUN_80017d2c(DAT_80017acc,DAT_80017ac8,0xba); //Write the configuration data the the touch panel starting from register address 0x8047

  FUN_8000bc34(DAT_80017ad0);                   //Wait again.  200000
  local_10 = (uint)local_10._1_3_ << 8;
  FUN_80017d2c(uVar2,&local_10,1);              //Write 0x00 to register address 0x8040. Touch Panel command (read coordinate status)
  return 0;
}


[dmitrkov]

I made a new version.

In this version, the touchscreen works!  (while still reversible)

[pcprogrammer]

Hopefully you get your connectors tomorrow and can set the touchscreen right

Make sure to only connect 3.3V to the touch panel. Reversal of SDA and SCL won't damage it, but my program will say E1 and DONE. E1 means it failed. Don't forget about the pullups to 3.3V (2K2) on the SDA and SCL lines

Success

[pcprogrammer]

While further analyzing the I2C code, I stumbled on code that is used for communication with the FPGA. Why this is done while reading the I2C bus is a puzzle, but it means I'm closing in on the FPGA.
It looks like they created an 8 bit bus with 2 selects and a clock signal.
Figuring out what the different selects mean is probably not going to be so easy

Code: [Select]

//Read something from the FPGA
uint FUN_80016850(void)
{
  int iVar1;
 
  FUN_800167a0();                                   //Setup port E pins 0:7 for input
  iVar1 = DAT_8001689c;                          //0x01C20890. Port E config register base
  FUN_80017738(DAT_8001689c,9);          //Set pin PE09 low
  FUN_80017738(iVar1,10);                       //Set pin PE10 low
  FUN_80017738(iVar1,8);                         //Set pin PE08 low
  FUN_8001774c(iVar1,8);                         //Set pin PE08 high
  return *(uint *)(iVar1 + 0x10) & 0xff;      //Read a byte from the FPGA (port E data register holds twelve bits)
}

//Set port E pins 0:7 as input
void FUN_800167a0(void)
{
  uint *puVar1;
 
  puVar1 = DAT_8001684c;                   //0x01C20890. Port E configuration register (FPGA)
  FUN_8001764c(DAT_8001684c,0,0);    //Set pin PE0 as input
  FUN_8001764c(puVar1,1,0);               //Set pin PE1 as input
  FUN_8001764c(puVar1,2,0);               //Set pin PE2 as input
  FUN_8001764c(puVar1,3,0);               //Set pin PE3 as input
  FUN_8001764c(puVar1,4,0);               //Set pin PE4 as input
  FUN_8001764c(puVar1,5,0);               //Set pin PE5 as input
  FUN_8001764c(puVar1,6,0);               //Set pin PE6 as input
  FUN_8001764c(puVar1,7,0);               //Set pin PE7 as input
  return;
}


[iscle]

Interesting... What memory map do you have configured in Ghidra?

[pcprogrammer]

Take a look at the readme.txt file in the repository: https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Binaries/Separated%20parts

Also added a new directory in the Software reverse engineering directory with all the related C functions in separate files with added comments and a text file describing what the functions do within the system.

My next step is looking into why the base address of UART0 is used in the code. Found several locations where it is used, so interesting to see what it is being used for and how they combined it with the parallel fpga bus. (If that is actually the case.)

[dmitrkov]

I want to download STM32F1_I2C_TP_conf_reader in bluepill with ST-Link v2. I have windows 10. I connected bluepill to ST-Link v2. Opened the application STM32 ST-LINK Utility. File - Open, The program requires *.bin, *.hex, *.srec, *.s19. I have not found such files in the repository. 

Download the elf file with STM32 CubeProgrammer! 


Now I can't understand where the data will be output? How do I get them?...

[pcprogrammer]

In the repository is a .elf file that holds the code including debug information. I will take a look at making a .hex or .bin for you.

Attached is a .hex file. Try if that works for you.

After the bluepill has been programmed it can be connected via the usb port to your computer and you should be able to open it as a serial port like a ch340. The baudrate settings don't matter and do nothing since it is just data over usb.

[dmitrkov]

In the repository is a .elf file that holds the code including debug information. I will take a look at making a .hex or .bin for you.

Attached is a .hex file. Try if that works for you.

After the bluepill has been programmed it can be connected via the usb port to your computer and you should be able to open it as a serial port like a ch340. The baudrate settings don't matter and do nothing since it is just data over usb.

Thank You! Can You make reader.hex file to?

[pcprogrammer]

You can find it in the repositories. Just uploaded them there

[dmitrkov]

will output anything to the com port without a connected touchscreen?

[pcprogrammer]

Yes you will see Press key, E1 and Done message for writer and Press key for reader

[dmitrkov]

The firmware has loaded successfully. But there is nothing in the com port monitor. 

[pcprogrammer]

Strange. I will take a look at it here. May be the conversion to hex with "objcopy -S -O ihex f103_i2c_tp_conf_writer.elf f103_i2c_tp_conf_writer.hex" did not do the trick. Need to startup my old laptop to get to the linux version of the STM programmer software. Have not yet installed on my new desktop system Don' t use it that much.

[pcprogrammer]

Just reprogrammed my bluepill with the STM32 CubeProgrammer and the writer.hex file and it works just fine. Looks like the .hex file is ok.
Even without the two pull-up resistors connected it outputs "Press key", so you should see at least that.

For the I2C part of the code to work the pull-ups need to be connected, otherwise the mcu can't generate the start condition.

Also tested the reader.hex file and it works also.

Started an even older laptop with windows 7 on it. Had to install the ch340 driver and putty since hyperterm is no longer there. Had the reader.hex in the bluepill and had to hit a key after opening putty, and it worked. The writer code does not have a loop back to the beginning and most likely receives some garbage on connection and jumps through the hit a key message and is done before you can open up your terminal program. Linux seems to buffer the data, and opening with cutecom brings it up.

Also noticed that windows needs the carriage return and the line feed, so the text shifts to the right on every key hit.

[dmitrkov]

I'm out of ideas. I tried it on two different boards with cs and no cs. On two different PCs with Windows 10 and Windows 7. I tried different programs for monitoring the com port. In which port nothing is displayed. In this case, bring the simplest sketch on arduino to the com port normally ...     It remains only to install Linux.....

[pcprogrammer]

By the looks of it the UART0 is not actually used on the port E pins. Within the code, so far, I only found the pins being setup for input or output and not for uart. The code that makes use of the uart looks like for sending some sort of debug info. Messages like "D_info->sectorSize=[%d]\r\n" The code makes use of 0x01C25000 (RX and TX data register) and 0x01C2507C (status register).

For now I added it to the repository without comments under the C analysis directory.

For the FPGA I think they use one line as a read/write indicator and the other as a data/command indicator. Needs a lot of analyzing to go through all the files and comment on what it is doing. So far I separated the top functions that make use of the 0x01C20890 address and the three gpio functions I found. (Also added to the repository)

There are a couple of big functions in there, so maybe these are the ones that get the signal data from the FPGA.

One thing is for sure, it is starting to reveal a lot of its secrets. And there is room for improvement, by for instance not using 8 calls to the set io pin to input or output function when you can do it in one write to the register.

Also in the I2C routines it is possible to avoid the spikes in the signal I noticed, by not using this io pin setup function and do direct writes to the register. The status of the other pins is always known, so no need for and-ing and or-ing.

When I'm done with the FPGA analysis I will put the result in the repository.

[pcprogrammer]

I'm out of ideas. I tried it on two different boards with cs and no cs. On two different PCs with Windows 10 and Windows 7. I tried different programs for monitoring the com port. In which port nothing is displayed. In this case, bring the simplest sketch on arduino to the com port normally ...     It remains only to install Linux.....

Did you try the reader.hex, to see if that gives output like I saw on windows 7? Because that one keeps looping on receiving usb input.

If that works, you can connect your touch panel to it and see if it reads the config. And when that is the case you can, most likely, safely use the writer to write the config. Just connect it to the usb and the change is big it will write to the touch panel. After that confirm with the reader or the scope if it did the trick.

I did not spend to much time on making these programs and they are crude and could do with improvements, but only if really needed Because there is so much to do on the project and a day has only so many productive hours

And sure linux is an option. It works for me

[iscle]

I've been investigating the original firmware in ghidra and I've found how data gets written to and from the FPGA.
While doing so, I noticed an interesting function which could very well be the function that sets the LCD brightness. I've translated the required functions to normal C from the ghidra pseudocode in case anybody wants to try to implement them.

Code: [Select]

#define Pn_BASE(n) (0x01C20800 + (n * 0x24))
#define Pn_CFG0(n) ((volatile uint32_t *) (Pn_BASE(n) + 0x00))
#define Pn_DATA(n) ((volatile uint32_t *) (Pn_BASE(n) + 0x10))

#define SET_PIN(n, x) (*Pn_DATA(n) |= (1 << y))
#define CLR_PIN(n, x) (*Pn_DATA(n) &= ~(1 << y))
#define FPGA_SET_DATA(x) (*Pn_DATA(4) = (*Pn_DATA(4) & ~0xFF) | (x & 0xFF))

void fpga_set_input(void) {
*((volatile uint32_t *) Pn_CFG0()) = 0x00000000;
}

void fpga_set_output(void) {
*((volatile uint32_t *) Pn_CFG0()) = 0x11111111;
}

void fpga_write_cmd(uint8_t data) {
SET_PIN(PE_DATA, 9);
SET_PIN(PE_DATA, 10);
FPGA_SET_DATA(data);
CLR_PIN(PE_DATA, 8);
SET_PIN(PE_DATA, 8);
}

void fpga_write_data(uint8_t data) {
SET_PIN(PE_DATA, 9);
CLR_PIN(PE_DATA, 10);
FPGA_SET_DATA(data);
CLR_PIN(PE_DATA, 8);
SET_PIN(PE_DATA, 8);
}

void set_backlight(uint8_t level) {
fpga_set_output();
fpga_write_data_2(0x38);
fpga_write_data(0xEA);
fpga_write_data(level);
}

fpga_write_data_2 and fpga_write_data are temporary names. I think they might be "fpga_write_cmd" and "fpga_write_data".

Edit: As @pcprogrammer says, pin PE9 looks like a "W/!R" pin, while pin PE10 looks like a "CMD/!DATA" pin.

[pcprogrammer]

That might be it.
For the I2C coordinates register read the command seems to be 0x41.

So that means we might already have two commands
0x38  Set display brightness
0x41  Read touch panel coordinates register address

I will do my analysis first and then look into writing code to test things.

For the data register write an and with 0xFF should be used, to avoid changing the other pins.

Also setting the direction of the databus pins needs to be incorporated in the functions, because you won't know what they are set to. So register 0x01C20890 needs to be set to 0x111111111 to make them outputs, or 0x00000000 for inputs.

[dmitrkov]

Did you try the reader.hex, to see if that gives output like I saw on windows 7?

I tried it. It also does not output anything to the com port. What connection speed of the com port should be set?