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

Magua, tokar, Tehnik, boojum, engineer.r152 and 7 Guests are viewing this topic.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #900 on: July 24, 2021, 06:52:21 pm »
Made good progress today :D

The top menu is implemented for all the menus to be shown. Apart from the main menu the others are completely functional. Searching the Ghidra made code for the touch handling, I found more of the FPGA control functions. A lot of the initialization functions in the main function are now clear.

One strange thing I found is: The channels can be enabled or disabled, and this setting is saved at power down and read back in on startup. So far so good. On startup in the main function the functions "set_fpga_channel1_enable" and "set_fpga_channel1_enable" are called and they copy the settings to the FPGA. Command 0x02 for channel 1 and 0x03 for channel 2. So it looks like that at startup the channels are either enabled or disabled in the FPGA. Now comes the strange thing. In the menu function for setting the channel enabled of disabled this FPGA function is not called |O
The only other location where these functions are called from, according to Ghidra, is the "check_hardware" function, and that one is bypassed by a setting in the flash memory.

So could it be that these FPGA commands do nothing?

Next up is the main menu functionality for as far as possible without a lot of research of the Ghidra output. (USB connection :o)
After that the right menu.

Offline e_Johny

  • Contributor
  • Posts: 12
  • Country: hu
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #901 on: July 24, 2021, 07:26:52 pm »

So it looks like that at startup the channels are either enabled or disabled in the FPGA. Now comes the strange thing. In the menu function for setting the channel enabled of disabled this FPGA function is not called |O
The only other location where these functions are called from, according to Ghidra, is the "check_hardware" function, and that one is bypassed by a setting in the flash memory.

So could it be that these FPGA commands do nothing?


Maybe useful info for you:

// On my scopes touch has some blind column, and I ordered a new one, and again a new one (because the first was small).//

When I tried replace with the 1. new touch, I set the 2nd Channel to ON. (here is blind the original touch).
After I connect back the original touch panel, the 2nd channel was OFF again.

My trick was not working. :-(
I sadly put the scope back in its box.
(I hope the 2. touch will arrive on next week)
« Last Edit: July 24, 2021, 07:29:10 pm by e_Johny »
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #902 on: July 24, 2021, 08:00:31 pm »

So it looks like that at startup the channels are either enabled or disabled in the FPGA. Now comes the strange thing. In the menu function for setting the channel enabled of disabled this FPGA function is not called |O
The only other location where these functions are called from, according to Ghidra, is the "check_hardware" function, and that one is bypassed by a setting in the flash memory.

So could it be that these FPGA commands do nothing?


Maybe useful info for you:

// On my scopes touch has some blind column, and I ordered a new one, and again a new one (because the first was small).//

When I tried replace with the 1. new touch, I set the 2nd Channel to ON. (here is blind the original touch).
After I connect back the original touch panel, the 2nd channel was OFF again.

My trick was not working. :-(
I sadly put the scope back in its box.
(I hope the 2. touch will arrive on next week)

Hi e_Johny,

sorry to hear that your scope is still non functional.

The thing I wrote about is something in the software itself. Just one of these Chinese mysteries :-DD

All the settings that one can change with the menus are in the flash and can be changed there to get things running, but I have not mapped out which setting is where in the memory. Not a great solution of course, but when in need it can be done.

Success with repairing your scope when the new touch panel arrives :)

Small update on the scope software. Tried to run it on the actual hardware and it does not work |O Probably some variable initialization issue. On the emulator the whole memory is cleared, which won't be the case on the actual hardware. An earlier test to see if the touch panel code was ok, did work and showed the coordinates when a location was touched, so that is not the problem. Ah well, tomorrow is another day. :=\

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5802
  • Country: es
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #903 on: July 24, 2021, 08:30:04 pm »
How the hell are you emulating it?
Does !emu support the f1c100s hardware?
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #904 on: July 25, 2021, 04:57:19 am »
How the hell are you emulating it?
Does !emu support the f1c100s hardware?

Hi David,

I wrote my own emulator. It is not fully handling the F1C100s but enough to run a patched version of the FNIRSI-1013D. It is all described in this thread :)

It is a bit slow, but allows me to test the code I'm writing.

It most likely won't run linux since the mmu is not implemented.

Everything I do can be found in the repository: https://github.com/pecostm32/FNIRSI-1013D-Hack

The emulator is written for linux and uses xlib, since that is standard available on, I think, any linux flavor.

A question for you: For the hacking of the Hantek you make use of the sunxi fel with uboot to load the executable to ram and then start it.

Code: [Select]
sunxi-fel -p uboot u-boot-sunxi-with-spl.bin write 0x80500000 zImage write 0x81500000 devicetree.dtb write 0x81800000 rootfs.cpio.uboot

Does this also work with non linux code? Is the u-boot-sunxi-with-spl.bin dedicated for the hantek or can it also be used for the FNIRSI-1013D

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #905 on: July 25, 2021, 08:47:01 am »
Solved the issue of not working on the actual hardware. Was indeed a not initialized variable. Need to do some looking into performance because the sliding menu's are slower than the original. Made a video of how it responds.

https://youtu.be/kvgzotcQocY

Also need to find a way to test the code on the hardware without having to flash it. Guess I will spend some time on that first.

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5802
  • Country: es
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #906 on: July 26, 2021, 10:16:37 am »
sunxi-fel is just a tool to interface the FEL mode. It allows writing anything to the memory and executing it.
The file you mention is the compiled u-boot. I don't think it's necessary to use it for launching your code, but theorically it could, uboot has the "go" command that executes any memory address.
But you must take in count that it would already have touched a lot of soc registers... so it could be a mess.
The F1C100s/200s BROM doesn't init the sdram by default, so you have only few KB available (20KB? I don't remember it right now).

A trick is to load u-boot but don't execute it using the spl command. That inits the sdram.
Then you can write your app anywhere and run it. I don't know if there's a proper way of initializing the sdram.
I think this would work:
Code: [Select]
sunxi-fel spl u-boot-sunxi-with-spl.bin write 0x80000000 my_code.bin exe 0x80000000

That would init the sdram, load your code to the sdram start and then execute it.
As long as your code uses relative branching or you make it to be executed at that address, it should work.
« Last Edit: July 26, 2021, 10:19:28 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #907 on: July 26, 2021, 11:31:26 am »
Hi David,

I know. Have used the FEL mode to load some test programs to the SRAM, and that works. But this only works for small bits of code.

Tried the sunxi-fel with uboot command and that did not work indeed. The only thing that happens is that the back light is turned on because that is programmed into the u-boot-sunxi-with-spl.bin I made here to test linux on the scope.

I will give the spl command a try. If that fails I have to write my own USB stuff for the F1C100s to have it behave as a CH340 device and implement commands to load and execute code that way.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #908 on: July 26, 2021, 12:35:16 pm »
Well gave it a try but no deal.

Code: [Select]
sudo ./sunxi-fel -p spl u-boot-sunxi-with-spl.bin write 0x80000000 fnirsi_1013d_scope_nh.bin exe 0x80000000

Tried the file I used to flash the scope with, but that does not work of course |O because it has the spl at the beginning of the file. Was not thinking :palm:

Then tried the output of the linker which is set to be loaded at 0x7FFFFFE0 and executed at 0x80000000, and I can see that something is done because the screen goes from white to some blueish color, but that's it :(

Took of the brom header so that the code starts at the beginning of the binary and it results in the same blueish screen.

So no luck there.

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5802
  • Country: es
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #909 on: July 26, 2021, 04:28:00 pm »
As far as I know the spl thing executes nothing. So it's probably something in the code or linker settings...
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #910 on: July 26, 2021, 04:45:45 pm »
As far as I know the spl thing executes nothing. So it's probably something in the code or linker settings...

Don't think so because the code I'm testing runs when it is written in the flash. And the fact that the brightness is enabled, which requires special code to control the FPGA tells me that the spl code is called to do things.

To get linux to work on this hardware I had to make modifications to u-boot. I do have a SD card with linux on it that runs. The problem is it still needs a uart for communication, which on this hardware is not available :palm:

As linux is not my forte, I did not continue with it. I believe Iscle is working on this, but I have no idea what the status is.

One way or another I will get there. :)

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5802
  • Country: es
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #911 on: July 26, 2021, 08:22:55 pm »
I know. But the flash has a specific header (eGON) for the bootloader to recognize it. I'd try compiling a simple program that blinks a led or something, and work on that.
If it's small enough you could run it from the sram, I don't remember the address right now.
I don't know either, but also I don't feel it's worth the effort on these devices, specially when talking about linux.
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3476
  • Country: us
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #912 on: July 26, 2021, 10:31:22 pm »
I doubt it could possibly run Linux later than 1.0.  But it would work really well with Mecrisp Stellaris.  The thing that forth excels at is bringing up new or unknown hardware.  You can test what things do interactively as you figure out what to do from documentation or FW dumps.

I am not a Linux guy.  I'm a Unix guy.  But Linux is close enough.  If it needs doing, I can do it.

FWIW My Hantek 2D42 uses an STM32F103.  Imagine what it could do with a '303 part.

BTW I'd relly appreciate a link to a summary of components and measurements of 1013D performance.  I've started reading the thread going back to the start, but it's pretty long.

Have Fun!
Reg
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #913 on: July 27, 2021, 05:27:53 am »
I doubt it could possibly run Linux later than 1.0.  But it would work really well with Mecrisp Stellaris.  The thing that forth excels at is bringing up new or unknown hardware.  You can test what things do interactively as you figure out what to do from documentation or FW dumps.

I am not a Linux guy.  I'm a Unix guy.  But Linux is close enough.  If it needs doing, I can do it.

FWIW My Hantek 2D42 uses an STM32F103.  Imagine what it could do with a '303 part.

BTW I'd relly appreciate a link to a summary of components and measurements of 1013D performance.  I've started reading the thread going back to the start, but it's pretty long.

Have Fun!
Reg

It runs a quite recent version of linux for sure. See: https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Linux
Not sure about actual performance because I only booted it to the prompt and typed some commands like "ls".

About FORTH, sure it is nice to play with, but not a language to develop a big project with. I have used it in the past on 8051 a likes and have it in the project box for playing with it on STM devices :)

For the hardware of the FNIRSI-1013D look here: https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Schematics

Everything I do is put in the repository on github.

Have fun with it.

Edit: I looked back in the thread. I joined in on page 19. In the pages before that a lot of discussion goes on about the "performance" of the scope. Up to about page 30 it is all about the touch panel and getting it to work in the right orientation. After that it is mostly me about the actual reverse engineering  of the firmware :-DD
« Last Edit: July 27, 2021, 06:12:53 am by pcprogrammer »
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #914 on: July 27, 2021, 05:41:25 am »
I know. But the flash has a specific header (eGON) for the bootloader to recognize it. I'd try compiling a simple program that blinks a led or something, and work on that.
If it's small enough you could run it from the sram, I don't remember the address right now.
I don't know either, but also I don't feel it's worth the effort on these devices, specially when talking about linux.

For me it is not really about these devices. It is about learning. After 10 years of working in non embedded software development and system management and then 8 years of building my own house (it is always more work than you think) I'm getting back on the horse in embedded programming. The basics are the same as 30 years ago, but the devices have become so much more capable and more complex that it takes its time.

I like to do things bare metal, and that takes its effort to get to know the hardware. This Allwinner device is terrible since the documentation is crap. Way worse than the STM documentation, of which I hate the HAL stuff. For me just as easy to learn the bare hardware then to grasp the HAL layers.

Offline Mr.B

  • Supporter
  • ****
  • Posts: 1237
  • Country: nz
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #915 on: July 27, 2021, 06:40:13 am »
It has been over a year since I purchased one of these.
Never taken it out of the box... Bought it on a whim...
Thanks to everyone involved in this thread.
I will follow more closely and at a minimum actually get it out of the box and play with it this weekend.
Thanks again.
I approach the thinking of all of my posts using AI in the first instance. (Awkward Irregularity)
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #916 on: July 27, 2021, 01:11:49 pm »
Continued with the user interface.

Was quite a bit of going through the Ghidra output to see how things are done for the system settings menu.

Also stumbled on some confusing, still to be confirmed stuff. The buttons for the "always trigger 50%" and "x-y mode display" settings show a grey background when disabled on the actual scope, but the functions I found to draw them use dark green :wtf:

Again these Chinese mysteries :-DD

EDIT: My bad. Misread the C output/asm. The color is light grey (0x00888888)

Code: [Select]
    set_display_fg_color(DAT_80010f04);   //0x00008800 Dark green (my comment)

                             DAT_80010f04                                    XREF[1]:     display_sys_menu_always_trigger_
        80010f04 88 88 88 00     undefined4 00888888h

Implemented it the way I see it on the actual scope. :)

Also when closely observed on the actual scope one can see that the actual settings are drawn after the menu slid onto the screen. In my version the settings are drawn in before the sliding is done.

Consulted a friend of mine about the battery charge reading and he figured that when more current is drawn from the battery the voltage drop will be bigger due to the internal resistance and that a compensation in software is a good way to deal with it. The different sample lengths and then just use the lowest measurement did not make sense to him either. A walking average would be a much better solution.
« Last Edit: July 27, 2021, 01:29:59 pm by pcprogrammer »
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5802
  • Country: es
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #917 on: July 27, 2021, 08:03:11 pm »
The performance is not that bad. I mean, you have  408MHZ core that easily gets 600+MHZ.
What's not so good is the memory interface. 64MB DDR, 16-bit interface, 312MHz effective clock that can usually be overclocked to 384MHz.
But the bandwidth is shared with the LCD driver and the processor instruction fetch. At least in linux, where it load the executables to the ram.
But it's still pretty capable!

If the battery voltage drops significantlywhen using the tablet, then it's crap. I mean, either the battery is rubbish or not correctly sized for the device power.
It's ok that it drops few mV, but not to the extend that the battery reading completely changes.
I recently replaced the battery for a friend, had the same issues. It was new! The current spikes made the battery level to change between fully charged to only a few %.
The voltage was dropping from 4.2V to 3.7V! Replaced it with some old 18650 that I removed from an electric drill. Their internal impedance had become too high for 20amps, but worked perfectly with smaller currents.

Does the circuitry have a shunt resistor or any other method to read the current? That way it would be easy to compensate.
Find out the internal battery impedance by appling a load and writing down the Vdrop and the current. Then just compute the Vdrop reading the current and sum it up to the Vreading.
But anyways, not a good thing if it's happening.


« Last Edit: July 27, 2021, 08:05:40 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #918 on: July 28, 2021, 05:43:08 am »
About the battery, it is not that it is dropping a lot of mV's when operated. It is about the software they use to display the remaining charge level. The compensation for charge left is not that big. Only a small percentage of what is left in the battery.

The hardware uses a TL431 in series with a 10K resistor to reduce the voltage to within the ADC range. The ADC only has 6 bits output. When fully charged the measured level is around 50 and when a charger is connected it goes up to maybe 56 to 58. In the code they take of 7 when on charge. For the brightness they compensate at max with 6. (Full brightness and full battery)

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5802
  • Country: es
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #919 on: July 28, 2021, 10:49:30 pm »
I see. So you might have a lot of noise?
I recommend you the EMA filtering, it's very easy to use and can filter from little to a lot.
As you don't want the level to be changing all the time, I'd use a big factor.
An example:
https://blog.stratifylabs.co/device/2013-10-04-An-Easy-to-Use-Digital-Filter/

I use a different code in the stm32 soldering fw  but it's the same in the end.
To reduce the delay if the system changes quickly (ex. At power on, the average is 0 and with heavy filtering it will rise slowly), I set some limits, so if the difference between average and new readings is huge, I increase a "spike" counter, and if I get x times more consecutive readings like that, I override the filter average with the last reading.
And It works really nice. If you only get few readings a lot different than average, they will be filtered normally and barely affect it.
« Last Edit: July 28, 2021, 10:54:39 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #920 on: July 29, 2021, 05:17:57 am »
Thanks for the example about the digital filter.

But I have the feeling you don't understand what it is about. I'm reverse engineering the FNIRSI software and not complaining about any possible hardware short comings.

The original post about this (https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3611270/#msg3611270) shows the pseudo code Ghidra made of it, and my asking about the why they did it like they did it.

The battery voltage does not fluctuate as far as I checked it with a DMM. It slowly drops when the device is operated, which is normal.

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #921 on: July 29, 2021, 09:50:44 am »
Phase 1 complete 8)

The top control bar is implemented and working. All the menu's open or the setting is toggled on touch (move speed) The channel and trigger menu's work and the settings can be changed. For the main menu all the items respond to touch (highlight), but only the system settings menu has an action coupled. The others (picture view, waveform view and usb connect) still need their functionality implemented. But my first goal is to get the UI framework coded.

The systems settings menu is fully implemented for the settings. The baseline calibration opens the start text and the OK button responds to touch. The "Calibrating..." and "Calibration successful" texts are also shown. The actual calibration still needs to be reversed.

Next up is the right side control bar.

The code so far can be found in the repository. (https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Test%20code/fnirsi_1013d_scope)

Did make a slight change in the trigger settings display on the top bar. Take a look at the pictures and see if you can spot it :-DD
The second image is of the original code and the third is of my code. You have to look close because the difference is very small.  :-//

Offline serverror

  • Newbie
  • Posts: 2
  • Country: us
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #922 on: July 30, 2021, 05:22:54 am »
Take a look at the pictures and see if you can spot it :-DD

Hah, the falling edge symbol....how bizarre.


Excellent progress on your project, impressive as always! Thanks for the updates.
 
The following users thanked this post: pcprogrammer

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #923 on: July 31, 2021, 01:56:11 pm »
So the user interface framework is done.

The right control bar can be touched and in the code the actions taken in the original code are in the comments so making the coupling when the rest of the code is written should be easy.

Next I'm going to make another attempt on getting the testing via FEL working. Have some ideas on this. When it works life becomes a bit easier :phew:

I have said it before but have to say it again. The original code is a mess. It is hard work to find the logic behind a lot of it. My code is not a straight copy but an interpretation of the original.

Just looking at how they did the measures menu |O
First they slide the bitmap onto the screen whilst changing the red color to black and the white color to grey. Then they draw it again, whilst again changing the colors. After that they go through code checking if an item is enabled and if so make the text white again. Not in a loop, but 24 times more or less the same code. And then they copy what was already on screen back to the screen :palm:

Same for the handling of the touch. 24 times the more or less same code with different coordinates.

I made an array with coordinates and go through it in a loop. :-DD

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3572
  • Country: nl
Re: FNIRSI-1013D "100MHz" tablet oscilloscope
« Reply #924 on: July 31, 2021, 04:01:58 pm »
I was lucky :-DD

The first idea I had for loading with FEL sort of works.

I made my own bootloader that enables the DRAM and then returns to the FEL program. It does not work the same as the "Linux" version where the loading of the program to test can directly follow in the FEL command, but with two commands it works.

With this bootloader it is possible to start the scope in FEL mode with the DRAM enabled. The FNIRSI startup image is displayed. (Still need to implement my own image :))

Code: [Select]
sudo ./sunxi-fel -p spl fnirsi_1013d_startup_with_fel.bin
This starts the system and returns to FEL. After this DRAM is enabled and FEL is active.

Code: [Select]
sudo ./sunxi-fel -p write 0x7FFFFFE0 fnirsi_1013d_scope.bin exe 0x80000000
This command then loads and executes the output of the scope project.

Still needs a SD card with FEL boot to be able to switch between the original scope software and the FEL mode. It is possible to put this new bootloader in the FLASH, but then the original code also needs to be loaded through FEL. This way the SD card and USB code can be tested. But for now it allows for a bit more easy testing of the new code 8)

Tested the latest version of my code and everything works but the sliding menu's are still to slow. So this needs investigating.

The bootloader is in the repository. https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Test%20code/fnirsi_1013d_startup_with_fel

Edit: Tried a new idea that came to my mind. I wrote my bootloader to a SD card and stuck it in the scope. It starts with the FNIRSI image and goes into FEL mode. So now I only have to use the second command to test my code.

Wrote it to a SD card with this command. Make sure to change the /dev/sdc to where your SD card shows up.
Code: [Select]
sudo dd if=fnirsi_1013d_startup_with_fel.bin of=/dev/sdc bs=1024 seek=8
« Last Edit: July 31, 2021, 04:23:09 pm by pcprogrammer »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf