For the knobs and push buttons they use a GD32E230, so most likely no hacking of that part of the system.
Isn't GD32 just a clone of STM32 (same like CKS32), I think firmwares are compatible, meaning you can flash STM32 firmware to GD32, we just need to figure out which STM32 this is clone of exactly.
They are very similar, but not sure if they are exact clones. The datasheet of the GD32E230 is available and the peripherals will most likely have the same functionality as the ones of the STM32 ranges.
It is more a question if they used protection of what is in the flash, to be able to reverse it. Otherwise it means making a schematic of the connections of the rotary's and the buttons to the mcu and write your own program for it. They most likely connected it to the F1C100s via an UART. (The one in PORT A, since there is no touch panel)
The code for the F1C100s of the 1014D is smaller then what is in the 1013D, but it will have a lot of common code.
Have not yet looked at it since I'm still busy with the 1013D reversal.
Too summarize, for anyone reading this "ITS GARBAGE, I WOULD BUY IT WITH YOUR MONEY!!!"
KEEP CLEAR OF IT.
It's much, much better than one I bought from a UK educational supplier for close to three times the price (Owon), or the 50+ Gw Instek ones the College bought. I can't believe how good it is. Not everyone has the need for ultra high precision, nor the funds to spend a fortune on something that might be classed as "better". At a price of just over £125, shipped (including VAT) it's fabulous - unmatched. As long as you accept that it probably will only resolve signals of up to 25-30MHz you won't be disappointed. The measurements being shown on the right hand side of the waveform display is a vast improvement on the Owon, they are lovely and clear in a reasonable 'at a glance' font. The trigger point can be shifted to the left side of the display without it shifting when the time/div is changed (as it does on the Owon) making the display much more friendly for non-repetitive signals. An Owon 30MHz dual channel 'scope is currently £332. It is also a vast improvement on any single PicoScope I have ever used - and I used a lot when I was working in a Further Education College. My favourite 'scope at the College was a Hameg Analogue/Digital one, it had enough analogue circuitry to make it work like a traditional 'scope, but enough digital circuitry to offer waveform measurements and storage. The Fnirsi 1014D is the first 'scope I've used that hasn't made me hate fully digital 'scopes. I absolutely love it and my £125 was money well spent.
The minimum sensitivity is 50mV/div - isn't that a bit limiting?
And where did you find it for £125?
Yeah, 125 pound is about 146 euro and that is, with the new VAT rule in Europe, very cheap. I paid ~163 euro for mine. (Aliexpress)
The minimum sensitivity is 50mV/div - isn't that a bit limiting?
Fatally so.
Connect a 10x probe and it becomes 500mV that makes it unusable for many tasks.
The minimum sensitivity is 50mV/div - isn't that a bit limiting?
Fatally so.
Connect a 10x probe and it becomes 500mV that makes it unusable for many tasks.
Since the lowest setting actually is 100mV/div because to get the 50mV/div the software does a times two and makes it just a digital zoom. So it is even worse
But that being said it is very responsive on the user interface. This is a drawback of the hantek DSO2XXX series, at least the one I have (did not check or upgrade the firmware yet). It responds quite slow to changes of the settings.
For doing measurements on MCU projects it is usable though.
Out of curiosity, is this only done for the 50mV range, or
have they "optimised" the design by using hardware for
every second range (0.1V, 0.5, 2, 10 etc.) and software
for the rest (0.05V, 0.2, 1, 5, etc.)?
The scope has 7 ranges (0-6) that can be selected. 6 of them make actual changes in the hardware. You can hear the relays click. So it is only for the change from the one but lowest to the lowest that they use the digital zoom.
const int8 *volt_div_texts[3][7] =
{
{ "5V/div", "2.5V/div", "1V/div", "500mV/div", "200mV/div", "100mV/div", "50mV/div" },
{ "50V/div", "25V/div", "10V/div", "5V/div", "2V/div", "1V/div", "500mV/div" },
{ "500V/div", "250V/div", "100V/div", "50V/div", "20V/div", "10V/div", "5V/div" }
};
This is the settings lookup table I implemented in my version of the 1013D code, which uses the same hardware as the 1014D, to display the settings for the different probe magnification factors. The original code works with switch statements to get this done.
A hypotetical question: Would it be possible to design a scope where
every second range is hardware (e.g. 5V, 1, 0.2, 0.05, 0.01 and 0.002)
and the rest is software? I.e. trading some resolution for gaining lower
ranges?
And great thanks for your work on the 1013D.
And great thanks for your work on the 1013D.
Your welcome
About the hypothetical question, I guess it should be possible. In the hardware it is either dividing to a lower voltage or amplifying to a higher voltage. Have each step bring the required input range to full scale ADC range. In software the rest is easy.
The scope has 7 ranges (0-6) that can be selected. 6 of them make actual changes in the hardware. You can hear the relays click. So it is only for the change from the one but lowest to the lowest that they use the digital zoom.
const int8 *volt_div_texts[3][7] =
{
{ "5V/div", "2.5V/div", "1V/div", "500mV/div", "200mV/div", "100mV/div", "50mV/div" },
{ "50V/div", "25V/div", "10V/div", "5V/div", "2V/div", "1V/div", "500mV/div" },
{ "500V/div", "250V/div", "100V/div", "50V/div", "20V/div", "10V/div", "5V/div" }
};
This is the settings lookup table I implemented in my version of the 1013D code, which uses the same hardware as the 1014D, to display the settings for the different probe magnification factors. The original code works with switch statements to get this done.
Late reply... My guess would be that this table is for a 1:10 probe. It wouldn't make sense to have a 500V/div setting because that would mean the scope could deal with several kV at the input (which it very likely can't). An upper limit of 50V/div is already high for a DSO.
Also late
Been away on a short vacation to visit family.
I thought the descriptive text would make it clear, but the table is for the three possible probe magnifications. The first row is for the x1 setting giving 5V/div to 50mV/div, the second row is for x10 setting giving 50V/div to 500mV/div and the last row is for x100 setting giving 500V/div to 5V/div.
If it is wise to use it with such a probe and apply 4000V for max screen usage is an other question
With the probe on 1x it is max 40V that can be displayed.
Hi !
I am new on this forum. Today I received link from FNIRSI ( I joined their WhatsUp group) with
new firmware V3.0.
File and description from it are attached.
Judging by the 1013D firmware there are at least 4 versions of it, so might also be the case for this one.
The firmware file can be named:
- FSI-1013.bin
- YPK-1013.bin
- UTX-1013.bin
- DAN-1013.bin
Guess the first one is from FNIRSI and the second one YEAPOOK. The others I don't know
I think that fourth one is for DANIU.
I've seen a few reviews of these "fnisi" things and I find it appalling. (The fnirsi, not the reviews).
They've made a nice box, power supply, display, buttons, etc, but they've cut too many corners in the front end and hardware to call this a decent scope.
Every scope has some "pro's" and "cons", but this one has "it does not work properly" in it's list of cons. Even though it is sometimes capable of making a picture that resembles your signal, that should not matter. It's flaws are so big that you can not rely on the picture of the waveform it shows you. And this is especially troublesome for beginners for they do not recognize when this thing that only looks like a scope from the outside goes in the wrong.
So save up your money and buy something decent.
Decent scopes start at around EUR250.
In light of the developments on the 1013D, I thought lets try to make a backup of the 1014D with my firmware backup program for the 1013D.
Since it lacks the touch panel some modification was needed, and considering previous disaster with my new 1013D scope, I decided to open it up first and make a full backup with FEL.
After that I loaded my 1014D firmware backup program to the SD card and it worked, but there are a couple of issues.
- The display is definitely different from the one in the 1013D. My backup screen flickered quite a bit, so scan frequency or other settings differ.
- There is an issue with my (and the original 1013D) SPI implementation. The first byte of the full flash backup shows zero while it needs to be 6.
This last issue I also noticed on my new 1013D, but not on my old 1013D. Need to dig into the firmware of the 1014D to see if I can find out why. Also needed for the different display settings.
The layout in the flash seems to be the same as for the 1013D.
0x00000000 SPL
0x00006000 Firmware updater
0x00013000 Startup image
0x00027000 Actual scope program
0x001FD000 Settings
0x001FE000 Hardware check disable
I still have to complete the 1013D reverse engineering, but with so many similarities my efforts can form a good base for the 1014D reversal.
Found something interesting. They changed the FPGA programing. In the 1013D there is a FPGA command for setting the display brightness, which expects two bytes for the setting, where the 1014D seems to be using just a single byte. The command number is the same: 0x38.
I found this while going through the boot loader of the 1014D. Most of the code is the same as for the 1013D, even the display configuration seems to be the same for displaying the startup image. So it might be that the startup image is in an apparent different location on the screen between the two models.
This means I have to look into the scope program to see what the display settings they are using are. I expect them to be different.
It raises the question to what else they changed in the FPGA and if it is for the better, signal trigger wise.
Edit: Looked into the main program in Ghidra, and there they use two bytes of data for the brightness, just as in the 1013D
It shows a rather similar code structure as in the 1013D, but there are differences in the main startup functions. The "SD ERROR" is at least a handle into the initialization of FatFs.
I added the parts to my 1013D Ghidra archive, which can be found in the repository:
https://github.com/pecostm32/FNIRSI-1013D-Hack
Worked a bit on naming the functions in the Ghidra archive. There is a lot of common code between the 1013D and 1014D. The major differences are of course the lack of the touch panel and the addition of the generator.
The touch panel is replaced by the GD32 chip that handles the buttons and the rotaries, and I think it uses UART1 to communicate.
For the generator it looks like they added some FPGA commands. Values in the 0x4X range.
The scope part of the FPGA looks to be the same. Found all the commands for setting the diverse settings like volts per div and time base. They also have the code for the parameter translation IC in there, so I guess the whole signal acquisition works the same.
Found bits of the USB code which are also the same, so again a guess that it is also the same as in the 1013D. It definitely hangs in the same way
Just a little bit a day as a thing to take my mind of the 1013D development and diversify a bit
Looking at the FPGA commands being used to do the acquisition on the 1014D and I see some differences to what is done on the 1013D.
There is a new command 0x29 that either takes 0 or 1 as data. No idea what it is for, but it looks like the work done on the 1013D needs adaptation to be able to be used on the 1014D. Luckily there are many similarities.
The Ghidra archive now also holds the latest version of the 1014D code. On a binary level there are many differences, but on code level it is still very similar. It looks like they moved variables to another location, because that entails the majority of the differences.
Between the two version FNIRSI distributes it is only the settings for the display that differ. Two bytes in total. This leads to the check bytes at the end being different too, but that is not code.
See my function for the display initialization. In the comments are the different settings
void sys_init_display(uint16 xsize, uint16 ysize, uint16 *address)
{
int32 time;
//Setup the used port D pins for LCD
*PORTD_CFG0_REG = 0x22222227; //PD00 is not used for the display
*PORTD_CFG1_REG = 0x22222227; //PD12 is not used for the display
*PORTD_CFG2_REG = 0x00222222; //Only 22 pins for port D
//Clear the display memory (Set in bytes so twice the number of pixels)
memset((uint8 *)address, 0, xsize * ysize * 2);
//Clear the DEBE registers
memset((uint8 *)DEBE_MODE_CTRL, 0, DEBE_NUMBER_OF_BYTES);
//Disable the LCD timing control module
*TCON_CTRL = 0;
//Disable the LCD timing interrupts
*TCON_INT0 = 0;
//Disable the LCD clock
*TCON_CLK_CTRL &= 0x0FFFFFFF;
//Disable all the TCON0 display outputs;
*TCON0_IO_CTRL1 = 0xFFFFFFFF;
//Disable all the TCON1 display outputs;
*TCON1_IO_CTRL1 = 0xFFFFFFFF;
//Display engine back end section
//Enable the display engine back end
*CCU_BUS_CLK_GATE1 |= CCU_BCGR1_DEBE_EN;
//De-assert the display engine back end reset
*CCU_BUS_SOFT_RST1 |= CCU_BSRR1_DEBE_RST;
//Enable the display engine back end
*DEBE_MODE_CTRL |= DEBE_MODE_CTRL_EN;
//Set layer0 size to xsize - 1 and ysize - 1
*DEBE_LAY_SIZE = ((xsize - 1) & 0x07FF) | (((ysize - 1) & 0x07FF) << 16);
*DEBE_LAY0_SIZE = *DEBE_LAY_SIZE;
//Set the layer0 line width in bits. (Using 16 bits per pixel)
*DEBE_LAY0_LINEWIDTH = xsize * 16;
//Set layer0 frame buffer address in bits. (8 bits per byte) With a 32 bit address the top 3 bits get lost. The manual is not clear about this.
*DEBE_LAY0_FB_ADDR1L = (uint32)address << 3;
//But in the scope there is a write to an un-described register
*DEBE_LAY0_FB_ADDR1H = (uint32)address >> 29;
//Set the layer 0 attributes to 565 RGB
*DEBE_LAY0_ATT_CTRL1 = DEBE_LAY0_ATT_CTRL1_RGB565;
//Enable layer0
*DEBE_MODE_CTRL |= DEBE_MODE_CTRL_LAYER0_EN;
//Load the module registers
*DEBE_REGBUFF_CTRL |= DEBE_REGBUFF_CTRL_LOAD;
//Start the output channel of the display engine back end
*DEBE_MODE_CTRL |= DEBE_MODE_CTRL_START;
//Video clock section
//Set video PLL to 390 MHz ((24 * 65) / 4)
*CCU_PLL_VIDEO_CTRL = CCU_PLL_ENABLE | CCU_PLL_VIDEO_MODE_SEL_INT | CCU_PLL_VIDEO_FACTOR_N(65) | CCU_PLL_VIDEO_PREDIV_M(4);
//Max checks on PLL becoming stable
time = 4000;
//Wait for the PLL to become stable, but not endlessly
while(time && ((*CCU_PLL_VIDEO_CTRL & CCU_PLL_LOCKED) == 0))
time--;
//Enable the lcd clock
*CCU_BUS_CLK_GATE1 |= CCU_BCGR1_LCD_EN;
//Turn the LCD (TCON) clock on. Assume clock source to be PLL_VIDEO * 1
*CCU_LCD_CLK |= CCU_LCD_CLK_EN;
//De-assert the lcd clock reset
*CCU_BUS_SOFT_RST1 |= CCU_BSRR1_LCD_RST;
//Use the TCON0 registers
*TCON_CTRL &= ~TCON_CTRL_IO_MAP_SEL_TCON1;
//Enable the timing generator. TCON source is DE CH1 (FIFO1 enable). TCON_STA_DLY = 23.
*TCON0_CTRL = 0x80000170;
//Enable all LCD clocks. Dot clock divider is 6.
*TCON_CLK_CTRL = 0xF0000006;
//Set timing based on the sizes. xsize - 1 and ysize - 1
*TCON0_BASIC_TIMING0 = ((ysize - 1) & 0x07FF) | (((xsize - 1) & 0x07FF) << 16);
//18--11-2021
//Found 4 different settings through the software versions
//1014D new version 0x041E0043, 0x041A0019
//1014D old version 0x041E006D, 0x041A0022
//1013D version 1 0x041E0044, 0x041A0017
//1013D version 2 0x041E004A, 0x041A0017
//Horizontal total time and horizontal back porch
*TCON0_BASIC_TIMING1 = 0x041E0044;
//Vertical front porch and vertical back porch
*TCON0_BASIC_TIMING2 = 0x041A0017;
//Horizontal sync pulse width
*TCON0_BASIC_TIMING3 = 0x160000;
//
*TCON0_HV_TIMING = 0;
//
*TCON0_CPU_IF = 0;
//DCLK1 (1/3 phase offset). IO0:2 invert IO3 not invert.
*TCON0_IO_CTRL0 = 0x17000000;
//
*TCON0_IO_CTRL1 = 0;
//Enable the LCD timing control module
*TCON_CTRL |= TCON_CTRL_MODULE_EN;
}
The interfacing with the GD32 for the user interface starts with the F1C100s sending an 0xFF and then reading some data from the GD32. Probably not to complex.
But for this one also a long road ahead. Less then for the 1013D, since a lot of the work has already been done there, and is still being done.
