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

0 Members and 9 Guests are viewing this topic.

Offline YurkshireLad

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: ca
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #775 on: May 02, 2021, 05:42:53 pm »
You could almost turn this epic adventure into a YouTube series.   :-+
 
The following users thanked this post: pcprogrammer

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #776 on: May 02, 2021, 07:27:26 pm »
An epic adventure it is indeed. The bootloader was easy for play. Useful though. A lot of the initialization is the same, but for some reason they set a different horizontal back porch for the lcd in the main code. In the bootloader the TCON0_BASIC_TIMING1 register is written with 0x41E0044, whilst in the main code it is written with 0x041E004A. It is only 6 clock pulses and does not seem to make a difference. They both work.

At the moment I'm working on getting the whole display code out in the open. It is a lot of code that needs to be examined, but I already found some memory addresses that are definitely used for video. The screen memory used by the DEBE is from address 0x803849A0 up. Then there is a video buffer at 0x804FB9B4, which can be copied over to the memory used by the DEBE.

The screen memory address is also set in 0x8019CF60 which seems to be some place holder. Not sure if it is also used for other parts of the code, or just for the video. This address has 353 hits in Ghidra search, so one can see the amount of work to be done.

To get to the FPGA commands in depth is also a hell of a job, and my thoughts are that once I have the video up and running making test code is much easier.

The whole thing will take its time.

But when I get there I will put in a new startup screen.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #777 on: May 03, 2021, 03:54:29 pm »
The adventure of looking into the display part of the code revealed that the pointer I found at address 0x8019CF60 is indeed dedicated to the display system. I think it only holds one of two values.
a) the base address of the screen itself. 0x803849A0
b) the base address of a frame buffer. 0x804FB9B4

Found two more frame buffers but it seems these are not used via the global pointer. (0x804401B4 used in 7 functions and 0x805B7228 only used in two functions) Maybe one of these buffers is used to capture the screen for writing to a file on the SD card. (save picture)

So far I extracted 67 functions of which I suspect some 39 to be part of a drawing library. They sit in memory almost consecutively.

At the beginning of the code I found functions like memcpy and memset and two divide functions.

From the 67 functions, I identified and named 4.

Previous investigations revealed functions that do not use the buffers or pointers I found, but do belong to the display system. Need to extract and investigate them to.

Uploaded what I have so far to the "software reverse engineering" section of the repository.

Again, the story continues :)

Offline eljot

  • Contributor
  • Posts: 31
  • Country: pl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #778 on: May 04, 2021, 12:52:36 pm »
Hi Dears, I havent been here for a long time. I had a lot of work so I had to put away my toys  :). Many interesting information since last time I've been here  :). My regards.
 

Offline vzgherea

  • Newbie
  • Posts: 3
  • Country: us
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #779 on: May 04, 2021, 04:32:44 pm »
Besides the X/Y inversion my screen had another problem, it was configured to work at a lower resolution - 800x480. In order to click a button I had to touch the screen to the right of the button and a little lower. The fix was to set the right resolution of 1024x600 in the 0x8048-0x804B registers. Modifying these values requires checksum update. The attached arduino sketch sets resolution to the 1024x600 and also includes checksum computation logic. IMPORTANT: Use 3.3V Arduino for programing.
« Last Edit: May 04, 2021, 09:23:24 pm by vzgherea »
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #780 on: May 04, 2021, 05:07:47 pm »
Since the scope does the checksum calculation and the location of the configuration data in the flash is now know it is also possible to follow a route where one modifies the configuration there and let the scope do the setup of the touch panel.

The configuration data is coming from the packets 716 to 734. In the cpu memory it is set at address 0x8019CF82. The byte there is send to the touch panel config register 0x8047. The bytes are send consecutive. The data in the code below is the patched version. It is possible to extend the packed data, but make sure to remove the same amount of bytes just after the initial data section. There is a range of zero's there that can be removed. (beyond flash address 0x001BA8D8 or so)

Code: [Select]
flash: 0x001BA610  |  packet 716: 0x12, 0xFF                                                                                  0x8019CF82: 0xFF, 0x00,
flash: 0x001BA612  |  packet 717: 0x16, 0x04, 0x58, 0x02, 0x0A, 0xFD                                                          0x8019CF84: 0x04, 0x58, 0x02, 0x0A, 0xFD, 0x00,
flash: 0x001BA618  |  packet 718: 0x70, 0x09, 0x01, 0x08, 0x28, 0x08, 0x5A, 0x3C, 0x03, 0x05                                  0x8019CF8A: 0x01, 0x08, 0x28, 0x08, 0x5A, 0x3C, 0x03, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
flash: 0x001BA622  |  packet 719: 0x30, 0x0C, 0x18, 0x1A, 0x1E, 0x14, 0x87, 0x29, 0x0A, 0x75, 0x77, 0xB2, 0x04                0x8019CF99: 0x18, 0x1A, 0x1E, 0x14, 0x87, 0x29, 0x0A, 0x75, 0x77, 0xB2, 0x04, 0x00, 0x00, 0x00,
flash: 0x001BA62F  |  packet 720: 0x14, 0x9A, 0x01, 0x11                                                                      0x8019CFA7: 0x9A, 0x01, 0x11, 0x00,
flash: 0x001BA633  |  packet 721: 0x92, 0x01                                                                                  0x8019CFAB: 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
flash: 0x001BA635  |  packet 722: 0x27, 0x50, 0xA0, 0x94, 0xD5, 0x02, 0x08                                                    0x8019CFB5: 0x50, 0xA0, 0x94, 0xD5, 0x02, 0x08, 0x00, 0x00,
flash: 0x001BA63C  |  packet 723: 0x14, 0x04, 0xA1, 0x55                                                                      0x8019CFBD: 0x04, 0xA1, 0x55, 0x00,
flash: 0x001BA640  |  packet 724: 0x13, 0x8F, 0x62                                                                            0x8019CFC1: 0x8F, 0x62, 0x00,
flash: 0x001BA643  |  packet 725: 0x13, 0x7F, 0x71                                                                            0x8019CFC4: 0x7F, 0x71, 0x00,
flash: 0x001BA646  |  packet 726: 0x13, 0x73, 0x82                                                                            0x8019CFC7: 0x73, 0x82, 0x00,
flash: 0x001BA649  |  packet 727: 0x13, 0x69, 0x95                                                                            0x8019CFCA: 0x69, 0x95, 0x00,
flash: 0x001BA64C  |  packet 728: 0x02, 0x24, 0x69                                                                            0x8019CFCD: 0x69, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
flash: 0x001BA64F  |  packet 729: 0x18, 0x0C, 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x0E, 0x10, 0x12, 0x14, 0xFF, 0x01          0x8019CFF2: 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x0E, 0x10, 0x12, 0x14, 0xFF, 0xFF, 0xFF, 0xFF,
flash: 0x001BA65D  |  packet 730: 0x01, 0x11                                                                                  0x8019D000: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
flash: 0x001BA65F  |  packet 731: 0x28, 0x10, 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x1D, 0x1E, 0x1F, 0x20, 0x21, 0x22, 0x24, 0x26, 0x28, 0x24    0x8019D011: 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0C, 0x1D, 0x1E, 0x1F, 0x20, 0x21, 0x22, 0x24, 0x26, 0x28, 0xFF, 0xFF, 0xFF, 0xFF,
flash: 0x001BA671  |  packet 732: 0x49, 0x01                                                                                  0x8019D024: 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
flash: 0x001BA673  |  packet 733: 0x01, 0x11                                                                                  0x8019D02A: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
flash: 0x001BA675  |  packet 734: 0x89, 0x90                                                                                  0x8019D03B: 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #781 on: May 04, 2021, 07:08:38 pm »
Cracking the display code is not easily done. Found the function that initializes the data for it to make it function. There are 35 functions for this task. It starts with setup_display_lib just after the display hardware has been initialized and just before the touch panel is setup. This function calls 7 functions of which one is very simple. It does nothing. The other 6 functions setup function pointers and what more. At some point it looses sense. The content of a pointer is multiplied by 0x78 (120). It is set with 0x80189750 and the multiplication is done in two 32 bit steps. The first one multiplies by 15 and the second one by 8. This leads to 0x0B86ED80 which makes no sense since there is no memory there. Not clear what they do with it next.

Code: [Select]
     rsb        r0,r0,r0, lsl #0x4
     mov        r5,r0, lsl #0x3

The display system seems to work with function pointers and function pointer pointers, so this makes tracing it by hand very hard to do. The display_text function uses 39 functions and there is no direct connection with the screen buffers.

Code: [Select]
void main(void)
{
  int iVar1;
  undefined auStack568 [568];
 
  sys_clock_init();
  some_memory_stuff();
  sys_init_uart0(BAUD_115200);
  setup_timer_int();
  sys_spi0_init();
  fpga_init();
  turn_off_brightness();
  sys_init_display();
  setup_display_lib();
  tp_i2c_setup();

So, that story stops for now. Need to think of another way to figure out the working of the scope. Either write a kind of emulator to track the code or write test code that works with uart1 and do tests directly on the scope hardware to figure out the FPGA commands. Most of the commands in use are known and can be traced in the original code to see how many bytes need to be send or retrieved. At least the relays should be easy to find this way, since they click :)

It is not the end of the adventure. :box:
« Last Edit: May 04, 2021, 07:23:58 pm by pcprogrammer »
 
The following users thanked this post: e_Johny

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #782 on: May 05, 2021, 03:41:13 pm »
Decided to go the emulator route. Wrote an xlib based first setup of the scope. This is the simple part. Next is an emulator window where the MCU can be monitored. This will take a bit more time :)

It can also aid in later development.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #783 on: May 05, 2021, 07:06:46 pm »
For the emulator window I made a first draft. Needs some push buttons to control things and maybe some more displays with control information. It is based on earlier work I did when I made an emulator for the Elka Synthex and the Siel Opera 6 (Back in the day's I wrote programs under windows with devstudio) Started making a HTML/PHP based copy but never finished it. For the Opera 6 I made my first xlib based version as a controller for an STM32 based digital version of the synth. (To many projects and to little time |O)  The code is still handy though for quick startups of new projects.

First picture is a screen cap of the arm emulator window. The second of the HTML canvas based 6502 emulator window, which is part of the Synthex project of which the third image is the screen cap. The fourth window is of the Siel Opera 6 controller I wrote using xlib. It connects via USB to a STM32 bluepill and sends control information based on the mouse input. The fifth picture is of the digital Siel Opera 6 project I was working on. There is one master controller and 6 voice controllers. It is just hobby fun :)
« Last Edit: May 05, 2021, 07:16:20 pm by pcprogrammer »
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #784 on: May 07, 2021, 09:04:49 am »
Now the real programming begins. The user interface of the emulator will most likely be extended but for now it will do. The processor status and register displays are set to give an idea of what it is going to look like.

Edit: Since the Synthex picture in the previous post is looked at quite a bit, I uploaded the project to github: https://github.com/pecostm32/Elka_Synthex_Emulator.

Edit2: The Siel Opera 6 project is far from finished and is what I was working on before I took up the scope project, so it has to wait  :=\
« Last Edit: May 07, 2021, 11:03:37 am by pcprogrammer »
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #785 on: May 14, 2021, 04:24:33 pm »
Just a short update.

Still working on the emulator. It is a lot of work but a great learning experience. Getting a lot of insight in the ARM processor. The emulator is already capable of running the first instructions of the scope boot loader, but got stuck on the switch to thumb instructions, since these were not yet programmed in. Working on that part now. These are much easier to decode, but it is still a lot of programming. Got the first three sections done. (Thumb instructions more or less have the top three bits as a main separation of types)

The code is in the repository but still under development :)

I know there is code out there that might do the trick, but would also be a lot of work. Getting qemu to work would take a lot of research, in how to hook in all the peripherals the F1C100s has. I rather write my own code and learn about ARM and the F1C100s than dive into projects like qemu.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #786 on: May 16, 2021, 09:11:52 am »
Most of the arm and thumb instructions are implemented. Some are tested and the original boot loader code of the scope runs smoothly to the part where it initializes the DRAM. There is a check on the PLL getting stable and locked, which never happens since it it not implemented in the emulator yet.

So it is time to add the F1C100s peripherals to the emulator code.

It is going to be a useful tool, not just for the scope, but my other projects will benefit from the work too. Having an emulator makes embedded development easier. At least, during development, for initial checking of code. :)

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #787 on: May 17, 2021, 09:51:07 am »
Again a short update.

The core is running smoothly and with very basic implementation of the F1C100s CCU and DRAMC controllers it continues to arrive at address 0x051C where it calls the initialization routine for the spi0 controller to be able to read from flash. So next on the list is the implementation of this peripheral.

Updated the repository with the code so far.

Still a lot of work to be done.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #788 on: May 20, 2021, 07:36:30 pm »
Due to other chores it took a while to get the emulation of the flash reading via SPI0 implemented. I did it a bit unstructured and needs improvement for a final version of the emulator, but for now it does the trick. To get it working I had to tackle a programming error in the arm core code for determining an overflow. It was correct for addition but not for subtraction causing the compare instruction to give wrong results. The check "is 0 less then 4" (bytes to transmit) was not seen as such and therefore the scope code did not reach the transmition of  the bytes part.

It is working now and the code flows through to the loading of the actual scope program at address 0x05FC, so it is time to hook up the emulator display and see if the startup bitmap can be displayed.


Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #789 on: May 22, 2021, 12:16:37 pm »
The startup image gets displayed :) but I need to improve on performance. The screen update is called to often and that kills the core performance. So there is progress, but at the same time a set back |O

Edit: Stupid me :palm: Forgot to save the previous counter value for making a delay on the cpu instruction counter, so the display update was called every instruction. :o

The story keeps on going.
« Last Edit: May 22, 2021, 12:22:26 pm by pcprogrammer »
 
The following users thanked this post: tv84, ledtester, Martin72, zildan

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2272
  • Country: gb
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #790 on: May 22, 2021, 01:38:23 pm »
Your emulator work is interesting and impressive :-+
I would never have tried to write one, it would have seemed too complicated a task (which it is, for me).
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #791 on: May 22, 2021, 01:58:27 pm »
Your emulator work is interesting and impressive :-+
I would never have tried to write one, it would have seemed too complicated a task (which it is, for me).

Thanks.

It is not the first one for me. And I have many (~40) years of experience in programming and also like the challenge :)

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #792 on: May 22, 2021, 05:14:51 pm »
I found the next challenge. The scope code runs into a delay loop that is controlled with timer0 under interrupt. In the interrupt handler the value written to 0x8019cf68 is incremented with one. So this is the next item on the list. Implement the arm interrupt handling and the f1c100s timer peripheral.

For now it still is investigating the scope code with the gnu debugger in netbeans. Doable, but having output in the emulator window and the ability to single step would be very nice.

In the emulator window the processor status and the registers are updated semi live. Still need to do stack and memory and the disassembly. Also the buttons need to be connected to the code to do things.

It will take its time, but it is getting to be more and more fun.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #793 on: May 24, 2021, 12:27:31 pm »
Hit a, most likely, programming error in my arm core. |O

implemented the timer and interrupt system and the code continues to run but at address 0x800197AC it encounters the instruction "bx r3". Unfortunately r3 is 0 instead of some correct code address and now I need to find out why this is.

Is it indeed an error in the core or is it missing peripheral implementation? The FPGA support is not there yet and I know the scope reads from the I2C device connected to the FPGA.

The core is working for most of the instructions since it is capable of loading the display image and do quite a bit before it hits this snag. It even calls thumb code and returns to arm state.

Did a full program counter trace with a change to the code where the trace file is split in separate files when it holds 250K lines. For arm execution it shows "pc: 0x800197AC  exec: 1" and for thumb "pc: 0x80000116  T". This leads to a difference in file size by which I could tell thumb code is called at some stages.

The part where it goes wrong is part of the display lib setup. In main the function setup_display_lib is called and from that function a call is made to FUN_80019764. And there it fails :-//

This means I have to implement a better tracing system. Already have some ideas about this. It will need an other program to read the trace data. The idea is to gather data for each instruction and write it in binary to a file. Already made a structure for it and support in the core code to allow for a circular buffer to be filled with trace data. Next up is add code to the instructions that load or store to or from memory.

Code: [Select]
typedef struct tagARMV5TL_REGS              ARMV5TL_REGS;
typedef struct tagARMV5TL_TRACE_ENTRY       ARMV5TL_TRACE_ENTRY;

struct tagARMV5TL_REGS
{
  u_int32_t r0;
  u_int32_t r1;
  u_int32_t r2;
  u_int32_t r3;
  u_int32_t r4;
  u_int32_t r5;
  u_int32_t r6;
  u_int32_t r7;
  u_int32_t r8[2];
  u_int32_t r9[2];
  u_int32_t r10[2];
  u_int32_t r11[2];
  u_int32_t r12[2];
  u_int32_t r13[6];
  u_int32_t r14[6];
  u_int32_t r15;
  u_int32_t cpsr;
  u_int32_t spsr[5];
};

struct tagARMV5TL_TRACE_ENTRY
{
  u_int32_t    instruction_address;    //Address of the traced instruction
  u_int32_t    instruction_word;       //Instruction word for arm, half word for thumb
  u_int32_t    execution_status;       //Information about if the arm instruction has been executed or not
  ARMV5TL_REGS registers;              //The 37 registers
  u_int32_t    memory_address;         //Depending on the type of instruction this is set with the targeted memory address
  u_int32_t    memory_direction;       //For load or store multiple instructions this signals if the given address is incremented or decremented
  u_int32_t    data_width;             //For instructions that load or store half words or bytes this will reflect this, otherwise word width
  u_int32_t    data_count;             //The number of words read or written by the instruction
  u_int32_t    data[16];               //The data read or written. Single instruction can do a max of 16 words
};

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3211
  • Country: pt
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #794 on: May 24, 2021, 01:01:36 pm »
This means I have to implement a better tracing system. Already have some ideas about this. It will need an other program to read the trace data. The idea is to gather data for each instruction and write it in binary to a file. Already made a structure for it and support in the core code to allow for a circular buffer to be filled with trace data. Next up is add code to the instructions that load or store to or from memory.

 :palm: Respect for your work! Would love to see your working methods.  :clap:
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #795 on: May 24, 2021, 01:54:37 pm »
:palm: Respect for your work! Would love to see your working methods.  :clap:

Thanks.

About my working methods, some would say very unstructured. I don't have a plan laid out. Just started with the idea of "I need an emulator" and started writing code. It evolves as I go along. This means code changes and needs adaptation once in a while to suit a new idea. Most of what I made in my live has been done this way :)

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #796 on: May 25, 2021, 07:18:51 pm »
To keep the fans happy 8)

The new tracing is implemented and produces huge amounts of data. Limited it to 25000 instructions per file and for just the display lib setup to the point where it fails it results in 88 files. Well over 2 million instructions :o

Started the trace file reader and already have some output. It lacks the disassembly which is vital for a proper trace, so began the implementation of that part. Will take a couple of days to get something working.

The trace lines are the last lines of the last trace file, but the registers and the memory are not real yet. The idea is to have an asterisks on the current line (CUR field) for which the second display shows the register and optional memory data. The memory data will only be displayed for load and store instructions.

With the scroll buttons one can move through the list. Will probably add extra buttons to jump to the start or the end of the list, and maybe a search field to allow quick jumping to a desired address.

As with all my work it grows into what it needs to be :)

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #797 on: May 27, 2021, 11:45:44 am »
The trace system helps to find out what is happening, but it did not help to solve the problem yet. Found an earlier address where it goes sour due to some data not being set. Why this data is not set is the next question. The arm core code seems to be correct looking at the contents of the registers and the memory. Made an excerpt of the trace data. Removed the not used registers.

Had to fix some copy paste errors and other oversights in the disassembler (still have to add the mul instructions and the thumb instructions) and it is working nicely. Will be a good tool for other projects once it is finished.

Code: [Select]
0x8002FAA8  0xE92D4070  YES  stmdb  sp!, { r4 r5 r6 lr }  r0:0x80857D4C  r1:0x8019D464  r2:0x8019D45C  r3:0x00000320  r4:0x00000000  r5:0x00000000  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8001933C  r15:0x8002FAA8  cpsr:0x80000053   memory:0x81FF35A4  type:word   count: 4  dir:down  0x8001933C  0x00000000  0x00000000  0x00000000 
0x8002FAAC  0xE59F509C  YES  ldr    r5, [pc, #156]        r0:0x80857D4C  r1:0x8019D464  r2:0x8019D45C  r3:0x00000320  r4:0x00000000  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8001933C  r15:0x8002FAAC  cpsr:0x80000053   memory:0x8002FB50  type:word   count: 1  dir:up    0x8019D464 
0x8002FAB0  0xE1A04000  YES  mov    r4, r0                r0:0x80857D4C  r1:0x8019D464  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8001933C  r15:0x8002FAB0  cpsr:0x80000053
0x8002FAB4  0xE595000C  YES  ldr    r0, [r5, #12]         r0:0x80857D4C  r1:0x8019D464  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8001933C  r15:0x8002FAB4  cpsr:0x80000053   memory:0x8019D470  type:word   count: 1  dir:up    0x80857D4C 
0x8002FAB8  0xE28FE030  YES  add    lr, pc, #48           r0:0x80857D4C  r1:0x8019D464  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FAB8  cpsr:0x80000053
0x8002FABC  0xE2801004  YES  add    r1, r0, #4            r0:0x80857D4C  r1:0x80857D50  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FABC  cpsr:0x80000053
0x8002FAC0  0xE5800038  YES  str    r0, [r0, #56]         r0:0x80857D4C  r1:0x80857D50  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FAC0  cpsr:0x80000053   memory:0x80857D84  type:word   count: 1  dir:up    0x80857D4C 
0x8002FAC4  0xE580103C  YES  str    r1, [r0, #60]         r0:0x80857D4C  r1:0x80857D50  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FAC4  cpsr:0x80000053   memory:0x80857D88  type:word   count: 1  dir:up    0x80857D50 
0x8002FAC8  0xE2801008  YES  add    r1, r0, #8            r0:0x80857D4C  r1:0x80857D54  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FAC8  cpsr:0x80000053
0x8002FACC  0xE5800040  YES  str    r0, [r0, #64]         r0:0x80857D4C  r1:0x80857D54  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FACC  cpsr:0x80000053   memory:0x80857D8C  type:word   count: 1  dir:up    0x80857D4C 
0x8002FAD0  0xE5841014  YES  str    r1, [r4, #20]         r0:0x80857D4C  r1:0x80857D54  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FAD0  cpsr:0x80000053   memory:0x80857D60  type:word   count: 1  dir:up    0x80857D54 
0x8002FAD4  0xE5D01011  YES  ldrb   r1, [r0, #17]         r0:0x80857D4C  r1:0x00000000  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FAD4  cpsr:0x80000053   memory:0x80857D5D  type:byte   count: 1  dir:up    0x00000000 
0x8002FAD8  0xE2850024  YES  add    r0, r5, #36           r0:0x8019D488  r1:0x00000000  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FAD8  cpsr:0x80000053
0x8002FADC  0xE7900101  YES  ldr    r0, [r0, r1, lsl #2]  r0:0x00000000  r1:0x00000000  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FADC  cpsr:0x80000053   memory:0x8019D488  type:word   count: 1  dir:up    0x00000000 
0x8002FAE0  0xE590100C  YES  ldr    r1, [r0, #12]         r0:0x00000000  r1:0x00000000  r2:0x8019D45C  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FAE0  cpsr:0x80000053   memory:0x0000000C  type:word   count: 1  dir:up    0x00000000 
0x8002FAE4  0xE5912030  YES  ldr    r2, [r1, #48]         r0:0x00000000  r1:0x00000000  r2:0x00000000  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FAE4  cpsr:0x80000053   memory:0x00000030  type:word   count: 1  dir:up    0x00000000 
0x8002FAE8  0xE2841008  YES  add    r1, r4, #8            r0:0x00000000  r1:0x80857D54  r2:0x00000000  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x8002FAE8  cpsr:0x80000053
0x8002FAEC  0xE12FFF12  YES  bx     r2                    r0:0x00000000  r1:0x80857D54  r2:0x00000000  r3:0x00000320  r4:0x80857D4C  r5:0x8019D464  r6:0x00000000  r7:0x80192E6B  r8_usr:0x80000E48  r9_usr:0x81000000  r10_usr:0x80192E9C  r11_usr:0x80192E9C  r12_usr:0xFFFFFFFF  r13_svc:0x81FF3598  r14_svc:0x8002FAF0  r15:0x00000000  cpsr:0x80000053


So the search again continues. Like a dog with a bone, relentless :-DD

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #798 on: May 27, 2021, 06:28:59 pm »
Hope my updates are still appreciated, because here is another one.

I'm not sure, but I think I found the cause of the system failing. I did not implement memory management in the arm core, because I thought it is not used in a special way. It is used at startup, but that is for testing where the vectors need to be written. 0x00000000 or 0xFFFF0000. I assumed 0x00000000, but maybe I'm wrong and should it be 0xFFFF0000 to get them out of the way of the memory at address 0x00000000.

The things I see happening is that at some point the code writes to addresses in the 0x00000000 to 0x000001E0 range, which is where the exception vectors are located in my setup. They use register r0 for this and check against it being 0, so it seems intentional. No idea on what the mmu can do in this case :-//, but there is this function I named some_memory_stuff that is called right after the clock initialization well before the setup_display_lib.

It does all sorts of reads and writes to the p15 co-processor. (forgot all about that |O)

Code: [Select]
                             main                                            XREF[1]:     prepare_for_main:800001a8(c) 
        80035320 8e df 4d e2     sub        sp,sp,#0x238
        80035324 00 00 a0 e3     mov        r0,#0x0
        80035328 3e cb ff eb     bl         sys_clock_init                                   void sys_clock_init(void)
        8003532c 54 08 00 eb     bl         some_memory_stuff                                void some_memory_stuff(void)
        80035330 20 01 9f e5     ldr        r0,[BAUD_115200]                                 = 0001C200h
        80035334 58 cb ff eb     bl         sys_init_uart0                                   void sys_init_uart0(uint baudrate)
        80035338 2a cb ff eb     bl         setup_timer_int                                  void setup_timer_int(void)
        8003533c 72 bf ff eb     bl         sys_spi0_init                                    void sys_spi0_init(void)
        80035340 56 85 ff eb     bl         fpga_init                                        void fpga_init(void)
        80035344 14 9d ff eb     bl         turn_off_brightness                              void turn_off_brightness(void)
        80035348 a1 a0 ff eb     bl         sys_init_display                                 void sys_init_display(void)
        8003534c f2 8f ff eb     bl         setup_display_lib                                int setup_display_lib(void)
        80035350 7d 89 ff eb     bl         tp_i2c_setup                                     void tp_i2c_setup(void)

So new study material. Figure out how the mmu works and how to implement it in my arm core.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #799 on: May 28, 2021, 12:48:07 pm »
I looked into the memory management and when I understand it correctly it is not the solution to what is going wrong :palm:

The function setup_mmu_trans_table is called to setup the first level translation table. 

The first call to it sets the first part of the table with translation address 0x000 - 0x7FF in the upper part of the word and 0xC12 in the lower part. The 0xC12 in binary shows 11 0 0000 1 00 10. The first two bits (left to right) are the AP bits for specifying the access. The third bit is always zero. The next 4 bits give the domain number. Only domain 0 is being used and set to client mode. The next bit is always one. The two zero bits specify that this section is not cache-able. The last two bits specify it it a section descriptor, and therefore translate (M)VA to a PA directly, and since the table is written linear they are basically the same.

The second call sets the second part with translation address 0x800 - 0xFFF in the upper part of the word and also 0xC12 in the lower part.

The third call replaces some of the entries written by the second call. the range 0x800 - 0x81F (DRAM) is replaced with 0xC1E in the lower part. This signals that these addresses can be cached and buffered.

If I'm right they could have sufficed with just enabling the caches and not the mmu.

Code: [Select]
void setup_mmu(void)
{
  uint baseaddress;
 
  baseaddress = 0x80730000;
  setup_mmu_trans_table(baseaddress,0x80000000,0,0,0,0,0x80000000,0,0);
  setup_mmu_trans_table(baseaddress,0,0x80000000,0,0x80000000,0,0x80000000,0,0);
  setup_mmu_trans_table(baseaddress,0x80000000,0x80000000,0,0x80000000,0,0x2000000,0,3);
  mmu_set_base_address(baseaddress);
  mmu_clear_wb_tlb();
  mmu_set_domain_access(1);
  mmu_enable();
  mmu_instr_cache_enable();
  mmu_data_cache_enable();
  return;
}

void setup_mmu_trans_table(uint baseaddress,uint param_2,uint param_3,uint param_4,uint memaddress,uint param_6,uint param_7,uint param_8,uint cacheable)
{
  uint uVar1;
  uint uVar2;
  uint uVar3;
  uint uVar4;
  bool bVar5;
 
  uVar2 = param_3 >> 0x14 | param_4 << 0xc;
  uVar3 = memaddress >> 0x14;
  uVar4 = param_7 >> 0x14 | param_8 << 0xc;
  uVar1 = param_8 >> 0x14;

  while ((uVar1 | uVar4) != 0)
  {
    *(uint *)(baseaddress + uVar2 * 4) = uVar3 << 0x14 | 0xc10 | (cacheable & 3) << 2 | 2;
    bVar5 = uVar4 == 0;
    uVar4 = uVar4 - 1;
    uVar1 = uVar1 - bVar5;
    uVar2 = uVar2 + 1;
    uVar3 = uVar3 + 1;
  }
  return;
}

So unless some other part of the code rewrites the translation table the fault lies somewhere else

Guess it is back to analyzing the display lib setup code to see where it goes sour |O


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf