FNIRSI-1013D "100MHz" tablet oscilloscope

[OneDiy]

V0.019g found a problem with display. Tried setting TP and couldn't fix it.

[_AVP_]

try to change config sector 710. Firmware loader doing it

[Atlan]

interestingly, it didn't move his image before. I would try another SD card. I'm curious what the PC programmer will say. Try this
https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/configuration_file.txt

[Atlan]

How is it possible to delete the data saved by the firmware on the sd card.  They are in an area where they cannot be deleted even by formatting.  By deleting the partition?

[tokar]

Fill in "00" from 16 to 2047 physical sector.  Use the loader to record the attached file.  The entire FW area on the SD card will be cleared.

[pcprogrammer]

While it has been some time ago that I did work on it, my thought was the program size had gone up to much, but the latest bin file is still below 300KB, so no problem there by the looks of it.

Another thought is if it could have been overwritten by an increased number of settings written to the card. They are also in the reserved 1MB part of the SD card, but have to look at the code to see where they are located.

I would have expected you (Atlan) to also suffer from the same issue then, since your scope is an even newer release and might have a shifted display too.

@OneDiy, you can always remove the card from the scope and use a card reader/writer connected to the PC to write the needed configuration file or reload the version that did work to see if it still works as before.

[pcprogrammer]

Fill in "00" from 16 to 2047 physical sector.

That is the way to get rid of the new firmware 

[pcprogrammer]

Just looked and the settings are written starting from sector 700 on the SD card. Means 5KB of room before the display configuration data. That is a lot of settings, so not likely to be a problem, I would think.

From the file variables.h

Code: [Select]

//----------------------------------------------------------------------------------------------------------------------------------
//Defines
//----------------------------------------------------------------------------------------------------------------------------------

#define SETTINGS_SECTOR                 700    //Location of the settings on the SD card for now



[Atlan]

And why doesn't the command with "zero" in the Linux terminal delete the configuration?  I don't remember exactly which numbers in the console are used for deletion.

[tokar]

Fill in "00" from 16 to 2047 physical sector.

That is the way to get rid of the new firmware 

Nothing prevents you from uploading it, or another firmware again.  But there will be confidence that no remnants from the previous code will interfere.  Or did I misunderstand the question about deleting data?

[Atlan]

My goal was to get the device into flood condition.  Neither the command zero nor the return to the default state via the loader will erase the configuration data from the sd card.

[pcprogrammer]

The command "sudo dd if=/dev/zero of=/dev/sdc bs=1024 seek=8 count=1" only clears the first 1024 bytes of the area where the program resides on the SD card.

As a bit of background information, overwriting only the first 32 bytes of sector 8 is sufficient to forsake the loading of the program. It is the eGON header that needs to be there to signal the MCU that there is program code that needs to be loaded. The F1C100s has a build in boot loader that checks the attached storage devices at specific locations and in a specific order to see if there is such a header.

With the SD card being checked before the FLASH, allows us to take over the scope like we do. It took a bit of searching to find information about this. The Allwinner documentation is quite sparse.

I worked on this for a good part of a year to figure it all out. Reverse engineering the original firmware, searching the web for information about the F1C100s, writing code to emulate the whole thing, figuring out the commands for the FPGA and how it all worked, dismissing the special IC as not needed by performing several tests, etc.

But that is just a bit of background.

The problem with the shifting display is a bit of a mystery, and the question is if others also experienced it. It is up to OneDiy to do some tests, like reloading the other version that did work properly, to see what is causing the problem.

[Sleo]

My goal was to get the device into flood condition.  Neither the command zero nor the return to the default state via the loader will erase the configuration data from the sd card.

You can erase (fill with zeros) any single sector using my loader. Just go to 'LCD/TP Config' tab, double click on word 'Sector' and input required sector number (decimal). Then select 'Clear configuration (all bytes are null)' in the list and write it.
If you need to fill more than one sector, create a null binary of the required length and load it using 'Firmware' tab to the required start sector (start sector field can be edited in the same way).
You will receive an error if you try to modify an MBR or an existing partition.

If necessary, I can modify the loader so that it fills with zeros any required space, for example all 'hidden' sectors between partition table and beginning of the first partition.

[Atlan]

It would be nice to have a button in the LOADER that deletes the data on the sd card from sector 700 where the settings are located.  There are some 16-bit constants and at the end 14pcs 32-bit constants newly added.  (I am not sure if they are included in the control sum).  By erasing and turning on the oscilloscope, the basic settings will be loaded.  (the button must delete only the calibration data on the SD card, the firmware on the SD card must remain)

1013 I have 2 pieces.  New versions: one from 2022 and the other from 11/2023, the touch display and the screen work normally on both, they don't even require special settings.

Currently, the firmware contains more code and various auxiliary information for debugging that I use.  It works normally.  And the helper code is not found in the published versions.  The file may have been damaged during transfer, or there may be a problem with the sd card.

PS That button will be a necessity even if I could do it in the program to check the calibration values.  It will be better if someone messes up the calibration to be able to delete it

[OneDiy]

I encountered a scrolling display problem. with all versions of modified firmware Fixed by writing TP CONFIG value with 1013d_version_3.bin The display screen is normal. But it doesn't work with v0.019g.

[Atlan]

try 0.019e

version e and version g, enables progress scrolling. I got a lot of trouble with this and x times the oscilloscope ended up frozen with a rainbow image.
I canceled some things to make the shift possible. There is some mention about overflow

else if(xrange > 725.0)
  {
    //Limit on max screen pixels to avoid disp_xend becoming 0x80000000 due to overflow
    //xrange = 725.0;//comment
  }

I always knew that the measure was a bit inaccurate. But even now, when I check it, I see how it is out of tolerance.
Does anyone want to check the original firmware, how exactly does it show the voltage?
I would be interested if the manufacturer carries out any calibration.

[Atlan]

New firmware v0.020d Calibration of the input divider. You must have the notification confirmation option turned on. Otherwise, only the search for 0 of the ADC converter is performed.

What will happen if it has more than 300kB?

[pcprogrammer]

What will happen if it has more than 300kB?

If the binary grows beyond the 300KB nothing will happen. When it grows beyond 346KB it will start to overwrite the settings sector (700).

You still have plenty of room for now.

In the case you do grow it to big, the settings sector has to move up, and when that comes in range of the configuration sector (710) that will have to move too. The code needs to be adapted for these changes, so it will read and write the correct new locations in that case.

When it becomes really big the reserved space on the card needs to be enlarged (now 1MB) but for that to happen, you will have to write a lot of code first 

[facekim]

With the new version 0.020d the measurements appear higher on the screen and do not start from the bottom

In case it helps.
Thanks for all the development, it is spectacular.

[Atlan]

This is preparation for displaying the position of the displayed signal in buffers.  Now it is possible to scroll the displayed signal in a larger range than 2 screens.  To make it possible, you need to reduce the sampling frequency through the menu ACQ.

I would be interested in how to solve the display problem.  (oneday)

[Atlan]

  v0.020d Follow the instructions for calibration.  You must have the notification confirmation option turned on. Calibrate without usb and probes.  In the next step, when prompted, connect the required voltage to both channels at once.  After finishing the calibration, close the menu and turn off the oscilloscope to save the data. 

I would appreciate it if you could let me know if the accuracy has improved.

[Atlan]

I have a feeling that loader does not write data.  I tried to write the configuration to sector 700. The result should be data corruption and loading of preset values.  It didn't do anything.  Even uploading a different configuration does nothing to the display.  It will either not be written or the program data will be shifted and it will be written to the wrong location.

[Sleo]

I have a feeling that loader does not write data.  I tried to write the configuration to sector 700. The result should be data corruption and loading of preset values.  It didn't do anything.  Even uploading a different configuration does nothing to the display.  It will either not be written or the program data will be shifted and it will be written to the wrong location.

I had to remember; the loader was written almost a year ago... It really rewrites one sector, i.e. 512 bytes, because of this is a requirement of WinAPI and driver. BUT it changes only the first 30 bytes (the rest 482 bytes is a copy of old sector), exactly as described by pcprogrammer. Sorry for misrepresentation. To write the whole sector you have to prepare 512-bytes binary file and load it using 'Firmware' tab (start sector may be edited by double click on words 'Start sector'). The location of written data should be correct, if you enter sector 700, loader writes to offset 0x57800. I just read sector 700 of my device (v0.019b) and corrected byte 16 (0x5780F) from 0x00 to 0x0F. As you can see in HxD it was written to correct location.

[Atlan]

Yes, I checked it, the bytes change, but it does not affect the result, the oscilloscope still starts in the basic configuration and ignores what is recorded in sector 710.

Therefore, ONEday does not move the image on the display

//----------------------------------------------------------------------------------------------------------------------------------
#include "display_control.h"
#define DISPLAY_CONFIG_ADDRESS    (uint32 *)0x81BFFC00

this shows somewhere in the RAM memory, but I don't know how the value from the sd card gets to the data instead of the ram.
In addition, other data can already be written in the given place, since some data (RAM) has been added to the program

I found something here: fnirsi_1013d_sd_card_bootloader.c
It's just that I don't even have it included in the MAKE translation, so I don't know if it will change anything

    //Load the remainder of the program from the SD card
    if(sd_card_read(PROGRAM_START_SECTOR + 1, blocks, (void *)0x81C001E0) != SD_OK)
    {
      //On error just frees
      while(1);
    }
  }
 
  //Load the display configuration sector to DRAM before the startup screen program
  if(sd_card_read(DISPLAY_CONFIG_SECTOR, 1, (void *)0x81BFFC00) != SD_OK)
  {
    //On error just frees
    while(1);
  }
 
  //Run the startup screen program
  unsigned int address = 0x81C00000;

It would be good if the flood programmer looked at it. well thank you

[pcprogrammer]

Code: [Select]

//----------------------------------------------------------------------------------------------------------------------------------
#include "display_control.h"
#define DISPLAY_CONFIG_ADDRESS    (uint32 *)0x81BFFC00


This is a bit of a bodge, I confess. As it was something added late in the development and spread over multiple projects the define is not well documented. 
Should have been in a shared include file.

In the "fnirsi_1013d_sd_card_bootloader" project the display configuration data is read from the SD card into this memory location, and then used by the other two programs for setting up the display. First the splash screen program "fnirsi_1013d_startup_screen" uses it, and then the final program "fnirsi_1013d_scope" uses it again.

So check if your changes to the main program "fnirsi_1013d_scope" overwrite the memory starting from 0x81BFFC00 in any way.