Author Topic: Reverse engineering FNIRSI-5012H  (Read 51158 times)

ace1903, Martinn and 6 Guests are viewing this topic.

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Reverse engineering FNIRSI-5012H
« on: October 06, 2019, 05:32:04 am »
Source code is now available here https://github.com/ataradov/open-5012h

I've recently got FNIRSI-5012H, and it is a very neat device. Once again, I would not use it as a primary scope, but it is a nice addition to the multimeter.
It has a fast boot time and, finally, sane and intuitive controls from the keyboard.

But there are some minor annoyances, which would be nice to fix. For example it does not remember settings for volts/div, time/div, 1x/10x, AC/DC.
Some of the controls could be improved.

So I decided to reverse engineer the board to see if there is any possibility of making open firmware for that thing. It only took a day to completely describe the board. My findings are below.

Note that there are two models of the PCB. The first revision has 4 mechanical relays. The second revision has only one mechanical relay.
The text below only applies to the second revision.

Main components on the board:
GD32F407VET6 - MCU (Cortex-M4, 512 KB Flash, 192 KB SRAM)
AD9288 (probably a clone, no markings) - ADC
TP4056 - Li-lon Battery Charger
TLV70033DDCR - 3.3 V LDO
PC817 - Photocoupler
CPC1002N - Optically coupled solid state relay
SN74HC148 - 8-line to 3-line priority encoder
SS8550 - PNP transistor
HFD4 - Mechanical relay
OPA356 - 200 MHz, CMOS OpAmp
W25Q64JV - 64 Mbit SPI Flash
TFT Display - Based on ST7789S

The MCU is locked (can't even erase), but it does not really matter, since there is zero value to having the original binary.
New MCUs are available for $5 from LCSC. Unfortunately a chip replacement is the only way to go, unless we can find a way to exploit GigaDevice MCUs, which is unlikely.

The ADC is pin-compatible with AD9288, but there are a couple of pins in the original that are marked NC, but bypassed to ground with capacitors in this design.
It also has a hemispherical dimple for first pin marker. The original has a flat bottom dimple. So it is possibly a knock-off, but fully pin-compatible.
But they have a few NC pins on the MCU bypassed to ground as well, so may be they just know more about those devices.

There are two LDOs in the system. One is the main LDO powering all the components. The other one is dedicated to the LCD backlight. The brightness is controlled by PWMing the enable signal.
Note that the LDO inputs are always supplied by the battery. The power switch only controls enable pin of the main LDO.

The display controller type is unknown, but the 20-pin connector pinout matches commonly available LCDs, so it should not be too hard to figure out the type once we get to the ID registers.

The USB connector actually has SWDIO/SWCLK on the data pins, so this connector is used for initial programming during the manufacturing process.
There is no way to get USB working without hardware modification. Although modification would be relatively easy to do. USB FS data pins are located right next to the programming pins.
But I'm not really sure of value of the USB on this device.

CPC1002N is used for shorting the AC/DC capacitor.
SS8550 are used to control PC817s and a mechanical relay.
OPA356 is a buffer right before the ADC.
W25Q64JV is used for waveform storage (and possibly settings, but not the firmware).
SN74HC148 are used to read the keyboard. Each IC handles 8 buttons and two buttons are connected directly to the MCU pins (for a total of 18 buttons).

Allocation of keys to priority encoders (PE):
PE0.0 - STOP
PE0.1 - F1
PE0.2 - EDGE
PE0.3 - AC/DC
PE0.4 - UP
PE0.5 - RIGHT
PE0.6 - MODE
PE0.7 - AUTO

PE1.0 - 50%
PE1.1 - TRIG DOWN
PE1.2 - TRIG UP
PE1.3 - TRIG
PE1.4 - MENU
PE1.5 - SAVE
PE1.6 - LEFT
PE1.7 - DOWN

F2 and 1X10X are connected directly to the MCU pins.

It is an interesting way to reduce the number of pins required for the keyboard, but obviously only one key from the group can be detected at a time, even if multiple keys are pressed.

As to the claim of 500 MHz real time sampling, I could not confirm it in any way.
The fastest sampling rate is with 6 ns/div - 200 ns/div. In this mode both channels of the ADC are used and the clock supplied to the ADCs is 125 MHz. So at best it is a 250 MSPS scope.
With slower settings only one channel is used and the sampling rate drops to 25 MHz, 12 MHz or 5 MHz, and in some cases to 27.8 MHz. In some cases there are also periodic single clock pulses following at a rate of about 30 kHz. Not sure what that is about.
The clock is only supplied when the samples are read, so the ADCs are not clocked significant potion of the time. This can't be good for their performance. I assume they discard the first few samples.

Attenuation is set though the 7 transistors (controlling optocouplers and a relay). I number the transistors Q0-Q6 starting from the one closest to the BNC connector.
Each volts/div setting enables one transistor:
10 V/div - Q4
5 V/div - Q5
2 V/div - Q6
1 V/div - Q1
500 mV/div - Q0
200 mV/div - Q2
100 mV/div and 50 mV/div - Q3

50 and 100 mV/div are not different on the hardware level, so the amplitude is just changed in the software.
This is also the only range that is controlled using a mechanical relay.

And finally, the full pinout of the MCU:
PD0  - ADC B D0
PD1  - ADC B D1
PD2  - ADC B D2
PD3  - ADC B D3
PD4  - ADC B D4
PD5  - ADC B D5
PD6  - ADC B D6
PD7  - ADC B D7
PD8  - ADC A D7
PD9  - ADC A D6
PD10 - ADC A D5
PD11 - ADC A D4
PD12 - ADC A D3
PD13 - ADC A D2
PD14 - ADC A D1
PD15 - ADC A D0
PA8  - ADC A CLK
PA9  - ADC B CLK

PC6  - LCD_RESET
PB0  - LCD_BL_EN
PB3  - LCD_RD
PB4  - LCD_WR
PB5  - LCD_RS
PB6  - LCD_CS
PE0  - LCD_D0
PE1  - LCD_D1
PE2  - LCD_D2
PE3  - LCD_D3
PE4  - LCD_D4
PE5  - LCD_D5
PE6  - LCD_D6
PE7  - LCD_D7

PB9  - Q0
PB8  - Q1
PB7  - Q2
PC12 - Q3
PC11 - Q4
PC10 - Q5
PA15 - Q6
PC15 - AC/DC
PA4  - Offset (DAC output)

PE13 - PE0.A0
PB14 - PE0.A1
PB13 - PE0.A2
PE14 - PE0.GS
PE15 - PE1.A0
PB12 - PE1.A1
PB11 - PE1.A2
PB10 - PE1.GS
PE12 - BTN_1X10X
PE11 - BTN_F2

PA3  - FLASH_CS
PA5  - FLASH_CLK
PA6  - FLASH_MISO
PA7  - FLASH_MOSI

PB15 - CHARGE
PB1  - VBAT_SENSE (Vbat / 2)
PH0 / PH1 - 20 MHz crystal
PA13 - SWDIO
PA14 - SWCLK
« Last Edit: January 27, 2020, 02:43:24 am by ataradov »
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #1 on: October 06, 2019, 05:33:35 am »
I have a few GD32F407VET6 on a way and another scope just in case.

I have not tried to think though the actual data capture, but I assume it is DMA triggered by the same timer that generates the clock signal. Hopefully it will not be a problem.

« Last Edit: October 06, 2019, 06:14:10 am by ataradov »
Alex
 
The following users thanked this post: argg

Online BravoV

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: 00
  • +++ ATH1
Re: Reverse engineering FNIRSI-5012H
« Reply #2 on: October 06, 2019, 06:09:30 am »
Subbed and thanks for sharing & your effort.  :-+ :clap:

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #3 on: October 07, 2019, 07:21:37 am »
I've made a breakout board for GD32F407V to make initial project bring up easier - https://github.com/ataradov/breakout-boards/tree/master/gd32f407v PcbWay is currently making them.
The same board may be used to poke around the security locks. ST chips have some issues there, so may be there is a way to unlock the device.

Given the annoying triggering bug (https://www.eevblog.com/forum/testgear/daniu-ads5012h-100mhz-500-mss-portable-scope-for-$80-usd/msg2727270/#msg2727270) and no ability to update the regular firmware, making a new firmware is actually the only way to make this thing usable.
« Last Edit: October 07, 2019, 07:23:24 am by ataradov »
Alex
 
The following users thanked this post: amspire, mikerj, Kilrah, girishv

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 470
  • Country: ru
Re: Reverse engineering FNIRSI-5012H
« Reply #4 on: October 09, 2019, 08:20:34 am »
Why custom breakout board? Isn’t this GD32 just a clone of STM32F407VET6? There are lots of VET6 boards for sale.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #5 on: October 09, 2019, 05:17:32 pm »
Why custom breakout board? Isn’t this GD32 just a clone of STM32F407VET6? There are lots of VET6 boards for sale.
There are a few reasons:
1. I always do a breakout board for the new to me MCU. This ensures that I have correct CAD symbols/footprints for when the device goes into a real project. Plus I have a chance to work out any gotchas on a custom design. This does not really matter here, but a process is a process.
2. I hate standard dev kits with a bunch of peripherals on them. I never use any of that stuff and it is always in a way.
3. I do not like ST-Link. I much prefer a standard CMSIS-DAP programmer/debugger. I have lots of custom tools for working with that.
4. It only took half a day and I had PcbWay order going out anyway, so time and money investment are minimal.
5. Custom board will also let me poke around the original locked chip, may be try to do some power glitching to see how it compares to ST devices in that respect.

It is also not a perfect clone, just a register set compatible implementation. There are differences between them, and I'd rater use the same exact device.
Alex
 
The following users thanked this post: 001, msliva, dave528

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #6 on: November 02, 2019, 11:15:01 pm »
Parts finally arrived after a long time sitting at LAX customs. No Idea why, some packages I ordered later actually came first.

I swapped the chip and now I can program the device in my scope and I can blink the backlight and read a button state. The next order of business is to figure out the display type.

I must say, I rather like having SWD interface on the external connector. This lets me debug the hardware while having it all assembled.

I also saved the original chip and soldered it onto one of the breakout boards. I quickly poked at it, and it does appear to be locked. But if I hold the chip in reset, the debug interface actually responds, and I can read and write debug registers. Any attempt to read any other registers result in zeros being read, but no faults or errors. Writes seem to be ignored, but who knows. I will have a more detailed look at that later.

As a bonus, here is a picture of the board under the GD32. I don't think this exists anywhere else on the internet.

PS: While debugging some of this hardware, I tried to use this scope as is, and it is basically unusable in its current form. Without a decent firmware it is a total junk.
« Last Edit: November 02, 2019, 11:38:01 pm by ataradov »
Alex
 
The following users thanked this post: BravoV, uer166, jhpadjustable

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #7 on: November 03, 2019, 01:51:44 am »
The display is based on the ST7789S controller. I have not tried to output an actual image yet, but the device ID register matches the datasheet for that controller.

EDIT: I can now display an image. Tomorrow will be a fun day.
« Last Edit: November 03, 2019, 04:29:58 am by ataradov »
Alex
 
The following users thanked this post: jhpadjustable

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #8 on: November 03, 2019, 07:44:55 pm »
.
Main components on the board:
GD32F407VET6 - MCU (Cortex-M4, 512 KB Flash, 192 KB SRAM)
AD9288 (probably a clone, no markings) - ADC
...
As to the claim of 500 MHz real time sampling, I could not confirm it in any way.
The fastest sampling rate is with 6 ns/div - 200 ns/div. In this mode both channels of the ADC are used and the clock supplied to the ADCs is 125 MHz. So at best it is a 250 MSPS scope.

Interesting info - thanks for sharing.

I guess the only way the MCU could keep up with the ADC data would be through the FSMC -  DMA GPIO to memory is 1/4 CPU clock or 42MHz max on the ST version of the processor whereas the FSMC can manage approx twice that. That would suggest that the GD32F407 is being overclocked from 168MHz to 250MHz to be able to read 125MSPs which seems quite a stretch. Maybe the clone version is different but I doubt it.

The 500MSPs claim seems totally bogus.  I'm curious as to the motivation behind the claim.  I can't believe they thought it wouldn't be uncovered soon enough so perhaps they assume that most potential buyers don't care or perhaps even expect the specs to be wildly exaggerated - so would assume it to be a 62.5MSPs  scope if they stated 125MSPs!  :-//
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #9 on: November 03, 2019, 07:52:59 pm »
This is actually the only puzzling thing about this while design. ADCs are hooked up to regular pins, so they must be sampling them as regular GPIOs, but I don't see how this would work either. I will have to experiment.

ADC clocks are connected to the timer outputs. In this case to generate 125 MHz, the timer would have to be running at 250 MHz. This is indeed somewhat overclocked :). Unless I've missed something about those timers.

And I guess the data is read as normal GPIO by the DMA triggered by the TC.

There is nothing inherently wrong with overclocking, I did it many times for my projects.  Usually overclocking starts to cause troubles at extreme voltages and temperatures. But in this case we can assume stable 3.3 V supply and around operation at a room temperature.
« Last Edit: November 03, 2019, 07:55:20 pm by ataradov »
Alex
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #10 on: November 03, 2019, 10:17:27 pm »
Must be a difference in implementation between the STM32 and the GD32 versions, the latter having more efficient bus matrix arbitration/synchronisation or whatever.  As to the almost 50% overclock it could be down to conservative ratings for the GD32 - they may prefer to emphasize the similarity to, and hence its compatability with the ST parts rather than highlight the differences even though being faster (if it actually is) would normally be a significant marketing advantage.

Are the two ADCs clocked with different timers to allow interlacing interleaving? That would make the GPIO read timings interesting - both ADCs will be read simultaneously with an 8ns clock cycle the ADC's output data will be offset by 4ns from each other leading to some hairy setup time and hold time margins!

[EDIT] typo
« Last Edit: November 04, 2019, 10:29:37 am by splin »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #11 on: November 03, 2019, 10:32:36 pm »
The ADC clocks are out of phase (when both channels are used), but the ADC itself has a data align setting, which makes data from both channels available on the rising edge of the channel A clock. So from the MCU point of view it looks like 16-bit samples coming in at 125 MHz rate.
Alex
 

Online BravoV

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: 00
  • +++ ATH1
Re: Reverse engineering FNIRSI-5012H
« Reply #12 on: November 04, 2019, 08:40:45 am »
I also saved the original chip and soldered it onto one of the breakout boards. I quickly poked at it, and it does appear to be locked. But if I hold the chip in reset, the debug interface actually responds, and I can read and write debug registers. Any attempt to read any other registers result in zeros being read, but no faults or errors. Writes seem to be ignored, but who knows. I will have a more detailed look at that later.

 :popcorn: ... again thanks for your effort, time & energy spent.  :-+

Offline dave j

  • Regular Contributor
  • *
  • Posts: 59
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #13 on: November 04, 2019, 10:53:33 am »
Quote
An analog watchdog block can be used to detect the channels which are required to remain within a specific threshold window
(page 44).

Surely that's what they use for the trigger?

It's using an external ADC (AD9288 or clone) not the ones in the MCU. Alex's investigation shows it's not even routing the analog signal to the MCU.

Part of the reason for the triggering problems with this scope is because it doesn't appear to be checking for a trigger as the samples come in. It appears to be doing:

1. Read a buffer full of samples.
2. Check for a trigger occurring somewhere in that buffer using software.
3. Repeat if haven't found a trigger.

The problem with this is it isn't reading samples whilst doing step 2 which means triggers can occur that aren't detected.

It's possible to check for triggers using software surprisingly quickly (see here). I think Alex's plan is to do something like that so it can check samples continuously rather than have gaps where triggers can be missed.
I'm not David L Jones. Apparently I actually do have to point this out.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #14 on: November 04, 2019, 05:51:57 pm »
Yes, then only  thing internal ADCs are used for is the battery voltage measurement.

The only way I can think of to avoid dead time would require additional hardware, e.g. a small-ish fpga piggybacked on top of the ADC sniffing d0..7 :-)
Adding FPGA would complicate the design, and potentially increase the price. And at the highest sampling rate it would be D[15:0], since both channels are used.

My goal would be to optimize things so that I can guarantee that at some sampling rate, I look at every single sample. And at a higher rate there will be dead windows.

In a single and normal modes there is no need to update the display, so most of the CPU time can be spent looking at samples and scanning the keyboard. And in auto mode missed triggers are not that big of a deal anyway.

I spent entire day yesterday figuring out ways to put the stuff on the screen efficiently. I will try to make the simple naive version first and then optimize based on the profiled bottlenecks.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #15 on: November 04, 2019, 06:19:30 pm »
I will after I have more pieces in place. At this stage there is not a whole lot to look at. And the code is not in the publishable shape.

The thing still runs from the internal RC oscillator, I have not tried to switch to the PLL yet.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #16 on: November 05, 2019, 06:49:22 pm »
I've got the device to run at 250 MHz and the simple application seems to run without any immediate issue. With that I configured timers to output 125 MHz on the clock pins.

I'm now trying to figure out how to configure DMA to receive the data. And I'm not sure I understand how their DMA works. Typically you configure source address, destination address and the trigger event (for P2M transfers). But in this case I see no way to configure the trigger. So far the way I rad the datasheet the trigger is inferred from the peripheral address that you configure in the DMA registers.

The issue is that I need to transfer the data from the GPIO based on the timer/counter event.

I will obviously need to do more reading of the sample code and documentation, but if someone knows this, I would appreciate the hints.

Also, the GD32 already bumps the maximum frequencies of the buses to 200 MHz, so 250 MHz is much less of an overclock than it would be with ST devices.
Alex
 

Offline dave j

  • Regular Contributor
  • *
  • Posts: 59
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #17 on: November 05, 2019, 07:29:41 pm »
It looks like it's done by setting the PERIEN field in the DMA_CHxCTL registers. See section 10.4.1 Peripheral handshake starting on page 198 which contains two tables that map peripherals to the channels'  PERIEN fields.
I'm not David L Jones. Apparently I actually do have to point this out.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #18 on: November 05, 2019, 07:36:21 pm »
Thanks! That's it.

I was looking for a bigger field. But it looks like in this device different peripherals are spread over fixed channels with up to 7 peripherals assigned to a channel.

Boy, this is primitive, but I guess functional enough.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #19 on: November 06, 2019, 03:49:51 am »
Ok, I've got the whole capture setup working in a very non-optimized way. But there is one more wrinkle to the performance. My original pinout was slightly wrong - PD8  is actually ADC A D7 and PD15 is ADC A D0, which means that samples from one of the channels will have to be bit-reversed before processing.

ARMv7-M has "rbit" instruction, but moving the data around will take additional processing time.

And the original firmware uses ADC A in cases when only one channel is necessary.  So I guess they just like to reverse things, since simply using channel B would have no other side effects.
« Last Edit: November 06, 2019, 03:51:47 am by ataradov »
Alex
 
The following users thanked this post: mikerj

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2550
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #20 on: November 07, 2019, 11:38:09 am »
Ok, I've got the whole capture setup working in a very non-optimized way. But there is one more wrinkle to the performance. My original pinout was slightly wrong - PD8  is actually ADC A D7 and PD15 is ADC A D0, which means that samples from one of the channels will have to be bit-reversed before processing.

I suppose this was done to ease layout?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #21 on: November 07, 2019, 03:24:32 pm »
I suppose this was done to ease layout?
Correct. This way it is a bunch of short parallel traces going from the ADC to the MCU.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #22 on: November 08, 2019, 06:04:45 am »
I was playing with the original device to see how locked it really is, and I noticed that it generated a lot of traffic on the SPI flash pins. The traffic turned out to be just repeated attempts to read the device ID (and failing, since the chip is on an empty breakout board).

But that gave me an idea to actually read the flash. I don't think I used any store functions on this device, so the flash should be in its factory state.

The majority of the device is empty (0xff). The first data starts at address 0x007da000. Then there is a small chunk at 0x007df000, then one byte at 0x007e4000, and then a long (8.5K) block at 0x007ee000.

I'm attaching the binary dump starting from 0x007da000.

I have not tried to interpret any of this data yet. I assume from of it is calibration information.
Alex
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 32016
  • Country: au
    • EEVblog
Re: Reverse engineering FNIRSI-5012H
« Reply #23 on: November 08, 2019, 12:48:21 pm »
I didn't know about this thread.
I just did a review video. The bandwidth is only 10MHz, not 100MHz.
Triggering is pretty horrible.

 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #24 on: November 08, 2019, 01:05:04 pm »
I also saved the original chip and soldered it onto one of the breakout boards. I quickly poked at it, and it does appear to be locked. But if I hold the chip in reset, the debug interface actually responds, and I can read and write debug registers. Any attempt to read any other registers result in zeros being read, but no faults or errors. Writes seem to be ignored, but who knows. I will have a more detailed look at that later.

You cannot do a lot with the debug unit while the chip is in reset, but you can program the flash and you can also read it, if you want to extract the original firmware. This is the usual trick to recover a chip if you messed something up and used the SWD lines for some other purpose (accidentally or deliberately).
Everybody likes gadgets. Until they try to make them.
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2550
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #25 on: November 08, 2019, 01:51:03 pm »
I didn't know about this thread.
I just did a review video. The bandwidth is only 10MHz, not 100MHz.
Triggering is pretty horrible.

The seller claims bandwidth 1X = 5MHz, 10X = 100MHz.  This is pretty poor as the highest sensitivity range in 1x is a rather disappointing 50mV/div.  I guess that's what you get with such a simple front end,
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 32016
  • Country: au
    • EEVblog
Re: Reverse engineering FNIRSI-5012H
« Reply #26 on: November 08, 2019, 01:55:21 pm »
I didn't know about this thread.
I just did a review video. The bandwidth is only 10MHz, not 100MHz.
Triggering is pretty horrible.

The seller claims bandwidth 1X = 5MHz, 10X = 100MHz.  This is pretty poor as the highest sensitivity range in 1x is a rather disappointing 50mV/div.  I guess that's what you get with such a simple front end,

Feeding directly in with BNC cable. 1X and 10X setting makes no difference, that's for probe matching.
Someone else mentioned this is actually an input attenuator!, not just a software setting for x1/x10 probe like on normal scopes.
If that's the case it's incredibly confusing, as there is no extra software option for x10 probe, if you had a x10 probe you'd have to use x1 setting, and x10 setting would actually be x100?
Will look at this before I release the video.
« Last Edit: November 08, 2019, 02:00:40 pm by EEVblog »
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1855
  • Country: ch
Re: Reverse engineering FNIRSI-5012H
« Reply #27 on: November 08, 2019, 02:07:34 pm »
10x means 10x less voltage swing at same input, so it can result in higher effective bandwidth if the limit is caused by too slow dV/dt components.
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 32016
  • Country: au
    • EEVblog
Re: Reverse engineering FNIRSI-5012H
« Reply #28 on: November 08, 2019, 02:30:18 pm »
10x means 10x less voltage swing at same input, so it can result in higher effective bandwidth if the limit is caused by too slow dV/dt components.

Yes, but still crazy confusing. Hitting the X1/X10 button does nothing to the waveform on screen, it just changes the V/div setting, so it appears just like it's a regular scope software multiplier.

BTW, the sample memory is not 128k. I could not zoom into any detail at all when in STOP mode, screen resolution only.
And no software cursors.
 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #29 on: November 08, 2019, 02:35:16 pm »
You cannot do a lot with the debug unit while the chip is in reset, but you can program the flash and you can also read it, if you want to extract the original firmware. This is the usual trick to recover a chip if you messed something up and used the SWD lines for some other purpose (accidentally or deliberately).
But the program is in the internal flash not in the spi.

Yes, no difference. The debug port on those Cortex-M MCUs is normally on the systems AHB bus which maps the complete address range of the system. If you have access to the AHB, you can see everything the cpu core can see. If you know the address of the flash bank, you can easily extract the content. You just read it like the cpu would do.
Everybody likes gadgets. Until they try to make them.
 
The following users thanked this post: GeorgeOfTheJungle

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #30 on: November 08, 2019, 04:18:42 pm »
You cannot do a lot with the debug unit while the chip is in reset, but you can program the flash and you can also read it, if you want to extract the original firmware. This is the usual trick to recover a chip if you messed something up and used the SWD lines for some other purpose (accidentally or deliberately).
Not, if the chip is in the high security mode. In this case the whole thing should be locked out, but they let the SWD be functional. Unfortunately it still does not give any access to the internal buses.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #31 on: November 08, 2019, 04:21:59 pm »
Yes, no difference. The debug port on those Cortex-M MCUs is normally on the systems AHB bus which maps the complete address range of the system. If you have access to the AHB, you can see everything the cpu core can see. If you know the address of the flash bank, you can easily extract the content. You just read it like the cpu would do.
I know how debug ports work on Cortex-M devices. All this is true if security lock is not set.

My comment was to highlight the difference between ST and GD devices. ST explicitly says that they disable the debug pins in the locked mode. GD documentation does not say this explicitly, and they do not disable the debug pins, just the debug system access to the internal buses.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #32 on: November 08, 2019, 05:02:50 pm »
Triggering is pretty horrible.
On non-periodic signals it is broken entirely.

Despite of all the false claims by the manufacturer, this is a very good unit for what it is, provided there is a better firmware. And hopefully there will be a better firmware soon.

This is like a transitional device between a multimeter and a real scope. Often all I need to know that my pin toggles at 100 ms, or my UART baudrate is indeed 115200. And with fast boot time and small physical footprint this is a perfect device.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #33 on: November 08, 2019, 05:25:05 pm »
The sampling rate is not close to 500 MHz either. Again, those are Chinese units. That's just how it works. I'm really not surprised by this at all. In fact I'm surprised that it does not perform any worse.

And every seller on AliExpress still claims that they use IPS screen and 5000 mAh  battery. This was not the case for a long-long time. The official store is at least honest about that part.
Alex
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #34 on: November 08, 2019, 05:32:54 pm »
I didn't know about this thread.
I just did a review video. The bandwidth is only 10MHz, not 100MHz.

Please add a caption to the video pointing out that whilst the 100MHz BW claim may be wishful thinking, the 500MSPs claim is an outright lie - there's no way that the 250MHz GD32F450 can read two interleaved samples every clock cycle via its GPIO port, nor could it generate a 250MHz clock. It is almost certainly 250MSPs. At 11:29 the 100MHz sine wave has ony 2 1/2 real samples per cycle so presumably they are interpolating the signal to show lots of intermediate samples - approx 32 per cycle of the 100MHz I/P signal.

You might also want to note the 200MHz OPA356 amp at 18:10 - the SOT23-5 marked OVVI.
 

Online BravoV

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: 00
  • +++ ATH1
Re: Reverse engineering FNIRSI-5012H
« Reply #35 on: November 08, 2019, 05:35:40 pm »
I know its still at early stage, noob question, is it realistic to expect, full bandwidth at 60 MHz ? Or even lower ?

Of course with "decent" triggering that just work.

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #36 on: November 08, 2019, 05:42:12 pm »
I know its still at early stage, noob question, is it realistic to expect, full bandwidth at 60 MHz ? Or even lower ?
Well, I'm not doing anything to analog parts, so you get what you get.

Given the need to reverse the bits on one of the channels, there is no way to get 100% reliable triggering at 250 MSPS. There is just no enough processing power.

I really have no idea what is the realistic sampling rate at which we can look at every single sample for triggering purposes. I'm thinking some thing like 25 MSPS may be realistic.
Alex
 
The following users thanked this post: BravoV

Offline dave j

  • Regular Contributor
  • *
  • Posts: 59
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #37 on: November 08, 2019, 08:18:13 pm »
Given the need to reverse the bits on one of the channels, there is no way to get 100% reliable triggering at 250 MSPS. There is just no enough processing power.

I really have no idea what is the realistic sampling rate at which we can look at every single sample for triggering purposes. I'm thinking some thing like 25 MSPS may be realistic.

I think think you're being too pessimistic.

I've been playing about on an STM32F3 (the only Cortex-M4 MCU I have). With code put in CCMRAM, so it most closely matches what you'll be able to do with the GD32F450 (e.g. zero wait states), I can check 16K of samples in 31275 CPU clock ticks.  With a 250MHz clock, this should be able to handle 125MSPS whilst leaving about 1500 CPU clock ticks for button checking, etc., before the next set of samples arrive.

You call it as
Code: [Select]
uint8_t* res = FindRisingTrigger(bufferAddress, sampleCount, triggerValues);
bufferAddress should be where the samples are stored.
sampleCount is the number of samples to check. This must be a multiple of 32.
triggerValues should be four trigger values in an unsigned 32 bit word. e.g. 0x80808080.

It will return the address of the first sample that exceeds the trigger or zero if none of them did.


I've attached the code below.
« Last Edit: November 08, 2019, 08:29:23 pm by dave j »
I'm not David L Jones. Apparently I actually do have to point this out.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #38 on: November 08, 2019, 09:15:25 pm »
Thanks! I was going to do some performance measurements this weekend. I will see how this performs on the real hardware while there is ongoing DMA transfer in the background.

I will stick with 125 MSPS single channel for now. 250 MSPS would require a lot more processing. There is also about 5 LSB of difference between the channels. So they would have to be calibrated separately. I'm not sure if this will matter in the end after all the scaling factors are applied.
Alex
 

Offline imo

  • Super Contributor
  • ***
  • Posts: 2653
  • Country: 00
Re: Reverse engineering FNIRSI-5012H
« Reply #39 on: November 08, 2019, 09:54:22 pm »
I've been playing about on an STM32F3 (the only Cortex-M4 MCU I have). With code put in CCMRAM, so it most closely matches what you'll be able to do with the GD32F450 (e.g. zero wait states)..
GD32Fxxx is a flash-less chip. No flash for the program on the chip. There is an external flash chip (a standard 8pin SPI flash) inside the tqfp package bonded onto the CM4 arm die. The GD32 has got only ram. GD boots the program off the external flash into its ram, and runs it there. Therefore GD32Fxxx is so fast.

Interesting shot: https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices
« Last Edit: November 08, 2019, 10:05:11 pm by imo »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #40 on: November 08, 2019, 10:00:33 pm »
Therefore GD32Fxxx is so fast.
We'll see how fast it really is. Even running from SRAM, there is still a possibility to screw up buses.

It has 64K of TCM that may end up being the fastest option.
Alex
 

Offline dave j

  • Regular Contributor
  • *
  • Posts: 59
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #41 on: November 08, 2019, 10:10:20 pm »
Thanks! I was going to do some performance measurements this weekend. I will see how this performs on the real hardware while there is ongoing DMA transfer in the background.

I will stick with 125 MSPS single channel for now. 250 MSPS would require a lot more processing. There is also about 5 LSB of difference between the channels. So they would have to be calibrated separately. I'm not sure if this will matter in the end after all the scaling factors are applied.

It's worth noting that the code assumes sampling from two channels, one of which is reversed. If you are sampling from just the normal channel you can remove the code that unreverses every other sample. If you are sampling from just the reversed channel you can replace the rbit, ror, sel sequences with rbit, rev. Either of those should speed things up a bit.
I'm not David L Jones. Apparently I actually do have to point this out.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #42 on: November 08, 2019, 10:32:02 pm »
It's worth noting that the code assumes sampling from two channels, one of which is reversed. If you are sampling from just the normal channel you can remove the code that unreverses every other sample. If you are sampling from just the reversed channel you can replace the rbit, ror, sel sequences with rbit, rev. Either of those should speed things up a bit.
Yes, I will obviously review the code. I'm not a huge fan of just running random code copy-pasted from the internet :)
Alex
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1855
  • Country: ch
Re: Reverse engineering FNIRSI-5012H
« Reply #43 on: November 09, 2019, 12:18:57 am »
Was going to suggest that. Instead of swapping the data thousands of times, swap the value it's compared to once.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #44 on: November 09, 2019, 12:21:32 am »
How long does a table lookup from RAM take?  If it's reasonable, you could do the bit swap and trigger level check with just a 256 entry table lookup.
This is a great idea. I'm not sure about the timings on that specific device. But I bet it is faster than 3 instructions. I will test that too.

 The same table could be used to correct linear offsets between the channels.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #45 on: November 09, 2019, 12:22:17 am »
Was going to suggest that. Instead of swapping the data thousands of times, swap the value it's compared to once.
It will not work. We are not comparing for equality.
Alex
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1855
  • Country: ch
Re: Reverse engineering FNIRSI-5012H
« Reply #46 on: November 09, 2019, 12:28:49 am »
I meant on principle, leading to the LUT he was mentioning.
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #47 on: November 09, 2019, 03:47:36 am »
How long does a table lookup from RAM take?  If it's reasonable, you could do the bit swap and trigger level check with just a 256 entry table lookup.
This is a great idea. I'm not sure about the timings on that specific device. But I bet it is faster than 3 instructions. I will test that too.

 The same table could be used to correct linear offsets between the channels.

Not going to work I'm afraid. At 250MSPs you have only one clock cycle per sample. But each lookup will take at least  four cycles - one to rotate the sample (one of the 4 within a 32 bit word) into the least significant byte of a register, one to clear the upper 24 bits and two more to do the lookup. Then you need another cycle to evaluate the result - ie. to set a flag (Z,C etc.) and another cycle to test that flag, so 250/6 cycles per sample or 41.7MSPs maximum.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #48 on: November 09, 2019, 03:52:27 am »
Yes, I'm not expecting to do it in real time. But any acceleration is welcome. At 250 MSPS there will be gaps, no matter what.

Also, SIMD instructions discussed earlier will help some.

Tomorrow we'll know for sure. I'm prepping an external counter to act as a data source to the breakout board. It is much easier to work with than a real scope.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #49 on: November 09, 2019, 06:53:02 am »
Well, I'm running into the first problem. I'm using CD74HCT393 to generate increasing 8-bit pattern. Given that the counter is slow, I also slowed down the system clock to 8 MHz using the lowest possible PLL output and the highest possible PLL divider. But I kept all other bus prescalers the same, so overall timing relationships did not change.

As expected, I get 4 MHz clock on the timer output. With this clock DMA struggles to receive the data, some values are just missing. Here is an example capture:
Code: [Select]
01 03 04 07 09 0a 0d 0f 10 13 15 16 19 1b 1c 1f 21 22 25 27 28 2b 2d 2e 31 33 34 37 39

This is not the counter problem. I verified that by switching the clock back and manually toggling the clock pin and capturing the data. In this mode the capture works reliably up to 6.4 MHz. And at that point propagation delays within the counter start to be too big, and the MSB gets corrupted. So 6.4 MHz is realistic highest clock for CD74HCT393 in 8-bit mode.

4 MHz is well below that. And the failure does not really show the bit sampling issues, but more capture or bandwidth issues.

So this is the first problem to be solved.

EDIT 1: BTW, pin write on this device is truly one cycle. The following code outputs 4 MHz with CPU running at 8 MHz.
Code: [Select]
  while (1)
  {
    HAL_GPIO_CLK_A_set();
    HAL_GPIO_CLK_A_clr();
    ......... same stuff many times
    HAL_GPIO_CLK_A_set();
    HAL_GPIO_CLK_A_clr();
  }

EDIT 2: And if you divide the timer output by 3 to get 8/3=2.667 MHz, every other sample is missing:
Code: [Select]
18 1a 1c 1e 20 22 24 26 28 2a 2c 2e 30 32 34 36 38 3a 3c 3e 40 42 44 46 48 4a 4c 4e 50

Only dividing by 4 produces the correct result.

So it looks like something else needs to be overclocked as well.
« Last Edit: November 09, 2019, 07:03:39 am by ataradov »
Alex
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 32016
  • Country: au
    • EEVblog
Re: Reverse engineering FNIRSI-5012H
« Reply #50 on: November 09, 2019, 08:30:40 am »
It appears the X1 x10 setting is just a software option and not a hardware attenuator that effects the bandwidth.
I got about 104MHz 3dB bandwidth, but the probe compensation changes with voltage range, and on the lowest range you can't even compensate the probe, it's out of range.
Sample rate measured at 120MHz or so differential, but it drops to a single ended clock at lower timebase settings.
There is a big non-linearity in the response at 42MHz, and the signal is wonky over about 20MHz, so I put the proepr usable bandwidth around 20MHz.
And the displayed sinusoidal signal goes nuts at precisely 100MHz, fine at 99MHz and 101MHz, so there is some really funky interleaved sampling software artifacts happening.
The deeper I look the more issues I find.
« Last Edit: November 09, 2019, 08:36:08 am by EEVblog »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #51 on: November 09, 2019, 08:32:03 am »
Yes, there is nothing in the hardware to do with 1X/10X. It is a purely software multiplier.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #52 on: November 09, 2019, 08:36:37 am »
Sample rate measured at 120MHz or so differential, but it drops to a single ended clock at lower timebase settings.
It is 125 MHz and it is not differential. It is using either one or two ADC channels.

And its default firmware is crap, there is no question about it.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #53 on: November 09, 2019, 09:22:09 am »
More testing on the GPIO performance. I just tried to read the input values as fast as I can from the code:
Code: [Select]
  uint32_t a0 = GPIOD->ISTAT;
  uint32_t a1 = GPIOD->ISTAT;
  uint32_t a2 = GPIOD->ISTAT;
  uint32_t a3 = GPIOD->ISTAT;
  uint32_t a4 = GPIOD->ISTAT;
  uint32_t a5 = GPIOD->ISTAT;
  uint32_t a6 = GPIOD->ISTAT;
  uint32_t a7 = GPIOD->ISTAT;

All those things went into registers:
Code: [Select]
800025a: f8d3 9010 ldr.w r9, [r3, #16]
 800025e: f8d3 8010 ldr.w r8, [r3, #16]
 8000262: f8d3 e010 ldr.w lr, [r3, #16]
 8000266: f8d3 c010 ldr.w ip, [r3, #16]
 800026a: 691f      ldr r7, [r3, #16]
 800026c: 691d      ldr r5, [r3, #16]
 800026e: 691c      ldr r4, [r3, #16]
 8000270: 6918      ldr r0, [r3, #16]

When clock is 4 MHz (system clock divided by 2), I get the following pattern: "03 04 04 05 06 06 07 07".

So GPIO itself can definitely sample every value.

EDIT: Another test - run the DMA in an untriggered M2M mode. So it just reads GPIO register as fast as it can. It already misses bytes:
Code: [Select]
17 19 1a 1b 1d 1e 1f 20 22 23 25 26 27 28 29 2b 2c 2d 2e 2f 31 32 34 35 36 37 38 3a 3b 3c
So the bottleneck is DMA itself.
« Last Edit: November 09, 2019, 09:41:43 am by ataradov »
Alex
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2550
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #54 on: November 09, 2019, 12:08:15 pm »
Therefore GD32Fxxx is so fast.
We'll see how fast it really is. Even running from SRAM, there is still a possibility to screw up buses.

It has 64K of TCM that may end up being the fastest option.

I don't think the DMA can access the TCM, this is the case on the STM32 at least.
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #55 on: November 09, 2019, 01:44:07 pm »
So the bottleneck is DMA itself.

Have you enabled the DMA FIFO to allow it to pack the 16 bit source into 32 bit writes?  See section 1.1.9 in:

https://www.st.com/resource/en/application_note/dm00046011.pdf

[EDIT] Otherwise, if the DMA performs 16 bit writes to (32 bit) memory it will cost an additional cycle as it will need to perform a read-modify-write operation
« Last Edit: November 09, 2019, 02:00:13 pm by splin »
 

Offline dave j

  • Regular Contributor
  • *
  • Posts: 59
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #56 on: November 09, 2019, 01:58:38 pm »
I've spotted a performance improvement to that code I posted.

The code of the form:
Code: [Select]
usub8 temp, samples, triggers
sel temp, temp, zeros
cbnz temp, Found

Can be replaced with:
Code: [Select]
uqsub8 temp, samples, triggers
cbnz temp, Found

This saves 8 instruction each time round the loop or 4096 while processing a 16K buffer.


Separately, how often are we likely to have a pulse that is only one sample long? I'm wondering if, in interleaved 250MSPS mode, it's practical to just check the unreversed samples (i.e. every other one) during the loop and when we find a potential match in a word to look at the reversed samples when we check to see which sample in the word is the real trigger. Obviously, there's a possibility of a very short pulse being missed but, given the sample rate and effective bandwidth of the scope, it it going to be a real concern?
I'm not David L Jones. Apparently I actually do have to point this out.
 
The following users thanked this post: GeorgeOfTheJungle

Offline dave j

  • Regular Contributor
  • *
  • Posts: 59
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #57 on: November 09, 2019, 02:32:54 pm »
OK. I've tried it out now.

I can process a 16K buffer in 14,891 CPU clock ticks - leaving about 1400 to check for key presses, etc. This means if people are willing to accept a "may not detect pulses shorter than 8ns" restriction, there is the potential for supporting 250MSPS.


Edit: After some optimisation this now executes in 13,613 CPU clock cycles with nearly 17% of CPU cycles left for other tasks.
« Last Edit: November 09, 2019, 07:02:17 pm by dave j »
I'm not David L Jones. Apparently I actually do have to point this out.
 
The following users thanked this post: GeorgeOfTheJungle, mikerj

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #58 on: November 09, 2019, 07:11:15 pm »
I don't think the DMA can access the TCM, this is the case on the STM32 at least.
The idea was to execute from TCM and unload the main AHB bus. But in this device TCM is data-only. And as test show AHB bus is really multi-layer and capable of supporting instruction fetch and data transfer at the dame time, so that's not a problem anymore.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #59 on: November 09, 2019, 07:15:55 pm »
Have you enabled the DMA FIFO to allow it to pack the 16 bit source into 32 bit writes?  See section 1.1.9 in:
I tried FIFO. It makes things worse. There are a few values that get read with the same pattern, but then there are 4-5 values that are missing entirely. I assume that's where it turns around and drains the FIFO in a big burst transfer. One thing I don't understand is why it is stopping the receive part. In theory DMA has two masters and they are on different buses. I don't understand why they can't work at the same time.

[EDIT] Otherwise, if the DMA performs 16 bit writes to (32 bit) memory it will cost an additional cycle as it will need to perform a read-modify-write operation
Why? The buses support 8-, 16- and 32-bit transfers. Why would it do RMW? It is also not the case in practice. Changing both transfers to 32-bit does not improve the situation.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #60 on: November 09, 2019, 07:26:17 pm »
Separately, how often are we likely to have a pulse that is only one sample long? I'm wondering if, in interleaved 250MSPS mode, it's practical to just check the unreversed samples (i.e. every other one) during the loop and when we find a potential match in a word to look at the reversed samples when we check to see which sample in the word is the real trigger. Obviously, there's a possibility of a very short pulse being missed but, given the sample rate and effective bandwidth of the scope, it it going to be a real concern?
Yes, I was also thinking about doing a more sparse checks. I would not consider missing a one sample pulse to be a real issue.

I want to spend some time trying to get F_CPU/2 sample rate on a single channel working reliably before moving on to timing tests. At the moment I'm thinking that hardware is not actually capable of capturing 250 MSPS stream and they either just ignore that, or do something in the software. There is no reliable triggering at this sample rate in their software, so it may show whatever it wants and nobody would notice. I will experiment with the working device to see if I can make out something.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #61 on: November 10, 2019, 02:37:27 am »
Ok, I'm giving up for now on trying to make it work with 125 MSPS/channel. The best my device can do reliably at this time is SYS_CLK/4 or 62.5 MSPS.

I also did try code by dave j. I tried the modified version. I only ran it on arrays of zeros to get the longest run time. I have not tested that the code actually works, just measured its run time. And all my experiments were done on the system running at 8 MHz. But again, all things measured in clock cycles should scale proportionally and it is much easier to debug with the slow code.

There is a noticeable performance impact from the DMA. The code running in a simple loop on the array of 32K samples is executed in 6.79 ms. The same code running in the DMA IRQ handler while DMA is receiving another buffer is taking 7.69 ms to run.

There is no contention if the buffers are split between the two SRAMs. But in this case each buffer can only be 16 K, since the second SRAM is only 16 K.

But even without splitting the buffers, there is still some room for the main code to execute. This was not the case with the  original code that had 'sel' instructions. That one was too slow.

This means that we can capture two channels at 62.5 MSPS and process each sample for triggering for a total of 125 MSPS scope.

If someone finds a way to actually make the DMA run with 125 MHz clock, it would be nice.
Alex
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #62 on: November 10, 2019, 05:31:47 am »
Have you enabled the DMA FIFO to allow it to pack the 16 bit source into 32 bit writes?  See section 1.1.9 in:
I tried FIFO. It makes things worse. There are a few values that get read with the same pattern, but then there are 4-5 values that are missing entirely. I assume that's where it turns around and drains the FIFO in a big burst transfer. One thing I don't understand is why it is stopping the receive part. In theory DMA has two masters and they are on different buses. I don't understand why they can't work at the same time.

That's not encouraging. You may well be right that they don't actually achieve even 250MSPs sampling reliably but it is possible they have better access to the silicon developers which allowed them to configure the device appropriately, perhaps even using undocumented features. I guess that only a lot of testing of the scope will be needed to reveal the truth. Have you tried stopping the CPU using WFI to guarantee there is no contention for the memory/buses/AHB matrix?

Quote
[EDIT] Otherwise, if the DMA performs 16 bit writes to (32 bit) memory it will cost an additional cycle as it will need to perform a read-modify-write operation
Why? The buses support 8-, 16- and 32-bit transfers. Why would it do RMW? It is also not the case in practice. Changing both transfers to 32-bit does not improve the situation.

Sorry, brainfart. I realised not long after posting that it was rubbish but had to go out before I could correct it. I put it down to some badly remembered notes on store instruction timings which can incur extra cycles, but on checking it was referring to unaligned half word accesses etc.
 
The following users thanked this post: GeorgeOfTheJungle

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #63 on: November 10, 2019, 05:49:25 am »
You may well be right that they don't actually achieve even 250MSPs sampling reliably
I'm starting to think this is the case.

but it is possible they have better access to the silicon developers which allowed them to configure the device appropriately, perhaps even using undocumented features.
It is possible, but not likely.

Have you tried stopping the CPU using WFI to guarantee there is no contention for the memory/buses/AHB matrix?
I tried, but the CPU does not introduce any overhead. In my tests it is waiting for the interrupt flag in a loop without accessing SRAM. And the code is in a totally separate section.

I did more tests on the FIFO stuff, and I don' think it actually loses any more data than without FIFO, but it also does not make it any better.

It looks like things get lost on a way from the GPIO register to the DMA controller, before they get a chance to be put into FIFO or sent over the other master.
Alex
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 32016
  • Country: au
    • EEVblog
Re: Reverse engineering FNIRSI-5012H
« Reply #64 on: November 11, 2019, 03:14:01 am »
 
The following users thanked this post: GeorgeOfTheJungle, dave528

Offline dave j

  • Regular Contributor
  • *
  • Posts: 59
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #65 on: November 11, 2019, 11:49:18 am »
I did more tests on the FIFO stuff, and I don' think it actually loses any more data than without FIFO, but it also does not make it any better.

It looks like things get lost on a way from the GPIO register to the DMA controller, before they get a chance to be put into FIFO or sent over the other master.

When testing the with the FIFO did you just test doing transfers when the FIFO was full? I'm wondering if doing the transfers when the FIFO is half full might allow it to continue receiving samples whilst the FIFO to memory transfer is going on. It would also be worth looking at whether 4 x 16 bit transfers in burst mode are faster than 2 x 32 single transactions - there'd be more memory writes but less DMA transaction latency.

I've also discovered a bug in my trigger detect code. I got which bytes are reversed wrong. I've attached a fixed version.
I'm not David L Jones. Apparently I actually do have to point this out.
 
The following users thanked this post: GeorgeOfTheJungle

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #66 on: November 11, 2019, 05:26:12 pm »
When testing the with the FIFO did you just test doing transfers when the FIFO was full? I'm wondering if doing the transfers when the FIFO is half full might allow it to continue receiving samples whilst the FIFO to memory transfer is going on. It would also be worth looking at whether 4 x 16 bit transfers in burst mode are faster than 2 x 32 single transactions - there'd be more memory writes but less DMA transaction latency.
I tried multiple configurations based on the same thinking. But they all yield the same result. I really don't think it has anything to do with the bandwidth limits. It looks like DMA just can't capture the data with triggers going this fast.

I also restructured the program to move all the regular variables to the TCM. So now I have full 128 KB for the sample memory. The plan is to divide that into 16 KB chunks and implement a circular buffer. I tested parts of this and it seems to work just fine. This even allows for capture long after the trigger event, all you need to do is just count the number of 16 KB buffers. And for the last buffer I can stop on the exact sample in the middle of the buffer (+/- a few samples). For the last buffer I just block in the DMA ISR and manually poll the counter.

The next thing to figure out is how to periodically let the MCU access the buffer for the auto mode. In this mode minor loss of trigger is not a big deal, of course, so it should not be a big deal to stop the whole thing and update the display. Switching to rolling mode at high time/div settings would be interesting too.

I will do more experiments later on. For now I switched gears and started working on the UI and navigating the waveform with artificially generated data. It is interesting how you don't think about a lot of stuff when using scopes and the UI is intuitive. But when you have to make an actual implementation, so many questions come up. And you start to see the differences between different vendors.
Alex
 
The following users thanked this post: sotos, mikerj, paulc, jealcuna

Offline dave j

  • Regular Contributor
  • *
  • Posts: 59
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #67 on: November 11, 2019, 08:13:18 pm »
I tried multiple configurations based on the same thinking. But they all yield the same result. I really don't think it has anything to do with the bandwidth limits. It looks like DMA just can't capture the data with triggers going this fast.

I was thinking of capturing to separate buffers to avoid the memory contention. The only check the unreversed samples version of the trigger detection code would be able to process samples quickly enough but not if it's fighting for memory bandwidth with the DMA. It would limit total sample size to 32K though.

Since 125MSPS with 128K samples is likely useful to more people than 250MSPS with 32K samples I think focusing on that is the way to go. Writing the whole scope firmware from scratch is a big enough task in itself.
I'm not David L Jones. Apparently I actually do have to point this out.
 

Offline tmf

  • Contributor
  • Posts: 45
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #68 on: November 11, 2019, 08:47:15 pm »
I really like this $70 scope... seems to me it could be sold even cheaper? The BOM cost was very low!

Man of many hats :-)

 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #69 on: November 11, 2019, 09:55:46 pm »
There is no memory contention that affects the ability to capture at 250 MSPS. My code at the moment uses TCM for variables, so the only thing that writes into SRAM is DMA. I tried disabling the trigger searching code. DMA still fails to capture all the samples. And for 125 MSPS trigger search is still plenty fast even with DMA going in the background.

Since 125MSPS with 128K samples is likely useful to more people than 250MSPS with 32K samples I think focusing on that is the way to go. Writing the whole scope firmware from scratch is a big enough task in itself.
I was thinking of skipping the reversal and checking every other sample for 250 MSPS. The code still would have to look at all the samples, but reversing code takes a significant amount of time, so just removing this would be a huge boost. There would still be a need to mask out every other sample for SIMD instructions. I have not thought about it a lot.

But yeah, I'm 100% focused on making 125 MSPS version first. Especially given potentially poor analog front-end anyway.
Alex
 
The following users thanked this post: paulc

Offline dave j

  • Regular Contributor
  • *
  • Posts: 59
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #70 on: November 12, 2019, 10:34:44 am »
I was thinking of skipping the reversal and checking every other sample for 250 MSPS. The code still would have to look at all the samples, but reversing code takes a significant amount of time, so just removing this would be a huge boost. There would still be a need to mask out every other sample for SIMD instructions. I have not thought about it a lot.

It's trivial. You take a copy of the triggers to use inside the loop and set the values for the samples you don't want to 0xff (or zero for a falling trigger). One thing to be aware of is that the earliest sample in a word is one of those tested and the sample before it is the last sample in the previous word. Additionally, if you detect a trigger on the first sample in a buffer, you have to check the last sample in the previous buffer. Easy enough to code and, because it's not in the loop, it doesn't have any performance implications.
I'm not David L Jones. Apparently I actually do have to point this out.
 
The following users thanked this post: GeorgeOfTheJungle, paulc

Offline mg3100

  • Contributor
  • Posts: 9
  • Country: nl
Re: Reverse engineering FNIRSI-5012H
« Reply #71 on: November 12, 2019, 09:32:37 pm »
Hi,

I bought the 5012H for more or less the same reasons that Alex did, and unfortunately I also still am unable to unlock the device.
I tried using the boot0/boot1 pins to get into the bootloader but that does't work. Boot0 had to be lifted from the board because
it was hardwired to gnd. Boot1 was NC so that was no problem and so was USART0_RX. USART0_TX is assigned to TIMER0_CH1 but
since that is an input on ad9288 I assume it doesn't matter.

So Alex (and others) please keep up the good work
 

Offline cliffyk

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: us
    • PaladinMicro
Re: Reverse engineering FNIRSI-5012H
« Reply #72 on: November 13, 2019, 12:49:40 am »
There is no memory contention that affects the ability to capture at 250 MSPS. My code at the moment uses TCM for variables, so the only thing that writes into SRAM is DMA. I tried disabling the trigger searching code. DMA still fails to capture all the samples. And for 125 MSPS trigger search is still plenty fast even with DMA going in the background.

Since 125MSPS with 128K samples is likely useful to more people than 250MSPS with 32K samples I think focusing on that is the way to go. Writing the whole scope firmware from scratch is a big enough task in itself.
I was thinking of skipping the reversal and checking every other sample for 250 MSPS. The code still would have to look at all the samples, but reversing code takes a significant amount of time, so just removing this would be a huge boost. There would still be a need to mask out every other sample for SIMD instructions. I have not thought about it a lot.

But yeah, I'm 100% focused on making 125 MSPS version first. Especially given potentially poor analog front-end anyway.

Sir,

I admire both your knowledge of these things, and also your tenacity--you remind me of...me 30 years ago--BRAVO!
-cliff knight-

paladinmicro.com
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #73 on: November 18, 2019, 01:01:32 am »
Here is approximate view of the UI I have at this time. The waveform is simulated. Basically what I'm doing is simulating a single capture and debugging the navigation of the captured waveform. After that works I will hook it up to the actual ADC.

The battery meter took quite some time to implement.

AD/DC and trigger leading/falling edge symbols will be replaced by proper images later.
Alex
 
The following users thanked this post: all_repair, perdrix, edavid, Kean, neil555, gnavigator1007, jhpadjustable

Offline mg3100

  • Contributor
  • Posts: 9
  • Country: nl
Re: Reverse engineering FNIRSI-5012H
« Reply #74 on: November 19, 2019, 04:27:11 pm »
Nice job Alex!

I gave up on unlocking the device. I also ordered a few of them from lcsc.
Now I just have to wait for them to arrive with dhl.

For the time being I'm still using my modified DSO138, so once we have a working 5012H  it is a nice upgrade for me.
Even if we only reach like 25msps , that's more then enough for me.
I am sure we can use one of the unused pins to create some external trigger option, maybe even add a second channel if we modify the ad9288 circuit.
The best improvement compared to the DSO138 is the amount of buttons the 5012H has. Can't wait to custimize the button functions the way I want them.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #75 on: November 19, 2019, 05:17:00 pm »
The trigger code now works for 100% of samples at 125 MSPS. So i don't think this would be an issue.
Alex
 
The following users thanked this post: Kean, mg3100

Offline cliffyk

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: us
    • PaladinMicro
Re: Reverse engineering FNIRSI-5012H
« Reply #76 on: November 20, 2019, 12:47:57 am »
The trigger code now works for 100% of samples at 125 MSPS. So i don't think this would be an issue.

Alex, let me first commend you on your knowledge and diligence!

I have wondered though, has anyone done a simple Nyquist "flat-line" test of the 5012H sample rate?  I would--however I do no longer have a 500 MHz signal source. As I am certain you are aware, a simple test of feeding a DSO a signal of a frequency equal to the DSO's sampling rate will result in a flat line trace. 499 MHz would alias to 1 MHz as would 501 MHz.

If a 500 MHz input doesn't cause a flat line display it is not sampling at 500 MSps.
-cliff knight-

paladinmicro.com
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #77 on: November 20, 2019, 12:53:49 am »
Its clock is derived from a cheap crystal oscillator. Measuring any sort of timing performance is a futile effort. We know "nominal" sample rate because we feed it to the ADC and we can measure it. There is no need for roundabout methods. Also, its front-end will not let 500 MHz through. There is 200 MHz buffer op-amp.

The 125 MSPS is achieved by interleaving 2 channels, so matching and timing between the odd and event samples in this mode is also very questionable. 

Remember, this will never be a real measurement equipment.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #78 on: November 20, 2019, 07:33:58 am »
Here is a schematic of the so called front-end of this scope. None of the capacitor values are known, obviously.

Transistors are part of the optocouplers.

The paired transistors are the same optocouplers, but they are driven at the same time (LEDs on the other side are in series). If anybody knows what is going on with those paired transistors, please chime in.
Alex
 

Offline lordium

  • Contributor
  • Posts: 27
  • Country: cn
Re: Reverse engineering FNIRSI-5012H
« Reply #79 on: November 20, 2019, 08:25:54 am »
Seems like they just short the 1.3M to get easier ranges to work with (sure it's bjts, and not mosfets?).   x 0.9, 0.3, 0.1 ,0.05, 0.025, 0.01 (close enough)
 
The following users thanked this post: WattsThat

Online BravoV

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: 00
  • +++ ATH1
Re: Reverse engineering FNIRSI-5012H
« Reply #80 on: November 20, 2019, 08:32:14 am »
The paired transistors are the same optocouplers, but they are driven at the same time (LEDs on the other side are in series). If anybody knows what is going on with those paired transistors, please chime in.

Assuming those are CPC1002, I think its optomos relay / mosfet switch.

CMIIW  :-//
« Last Edit: November 20, 2019, 08:33:53 am by BravoV »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #81 on: November 20, 2019, 08:38:13 am »
CPC1002 shorts the AC/DC capacitor. The range switches are PC817 optocouplers.

And those pairs are controlled separately for different ranges.

Each transistor or pair of transistors represent a separate volts/div setting.
« Last Edit: November 20, 2019, 08:40:53 am by ataradov »
Alex
 

Offline exile

  • Contributor
  • Posts: 5
  • Country: se
Re: Reverse engineering FNIRSI-5012H
« Reply #82 on: November 20, 2019, 03:04:11 pm »
I think it has to do with Emitter-collector voltage quite low. (zenerdoid effect)
And I think it starts to affect before 6volt as the data sheet says. By coupling 2 in each direction it can withstand higher voltage.

That's what I think, but I can be wrong.
 

Online magic

  • Super Contributor
  • ***
  • Posts: 2619
  • Country: pl
Re: Reverse engineering FNIRSI-5012H
« Reply #83 on: November 20, 2019, 07:54:13 pm »
Yeah, given that they are in antiseries I would guess it's something to do with reverse breakdown.

And FYI, the opamp is configured for unity gain with low series resistance, so per the DS it's supposed to have massive gain peaking at 300MHz and -3dB point at 450MHz. Not sure why they did that.
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #84 on: November 21, 2019, 12:30:28 am »
And FYI, the opamp is configured for unity gain with low series resistance, so per the DS it's supposed to have massive gain peaking at 300MHz and -3dB point at 450MHz. Not sure why they did that.

That graph is for .1Vpp output. For a full scale, 1Vpp ADC input, slew rate distortion will start at about 35MHz according to the graph on page 8. However, unusually, the graph also implies that the slew rate is a function of the output signal level - approx 65V/us @ 5Vpp rising to 110V/us at 1Vpp and nearer 300V/us at 100MHz which is closer to the datasheet 300 to 360V/us values. (The latter are quoted for a gain of 2 but the gain wouldn't normally affect slew rate significantly).

So perhaps slew rate won't actually be a limit until 150MHz or above for signals < .9Vpp. Does the graph suggest an unusual compensation scheme in the amp or is the graph suspect?
 

Online magic

  • Super Contributor
  • ***
  • Posts: 2619
  • Country: pl
Re: Reverse engineering FNIRSI-5012H
« Reply #85 on: November 21, 2019, 08:08:11 am »
Probably the plot is right, and all plots are for 5V supply and gain of 2 so you don't even know what will happen at unity gain at 3.3V. But it's unlikely to be anything good indeed, this chip is simply too slow and quirky for the claimed BW. (Assuming the ADC really is 1Vpp full scale, I didn't follow the thread).

I only remarked about the possibility of getting any sort of 500MHz signal in there at all ;)
 

Offline OwO

  • Super Contributor
  • ***
  • Posts: 1224
  • Country: cn
  • RF Engineer @ OwOComm. Discord: スメグマ#2236
Re: Reverse engineering FNIRSI-5012H
« Reply #86 on: November 21, 2019, 10:18:52 am »
ADC might be the MXT2088: https://item.taobao.com/item.htm?spm=a230r.1.14.19.2eea1df5ep0STN&id=590948654001&ns=1&abbucket=11#detail

I just searched for "AD9288" + the Kanji for "substitute" on taobao and that turned up. More digging found this page which lists more ADCs: http://www.mxtronics.com/n107/n808/n809/n815/index.html

Unfortunately I couldn't find most of those on taobao, especially the 1GSPS+ ones. Maybe they are all sold under the ADI/TI part numbers instead.
« Last Edit: November 21, 2019, 10:26:57 am by OwO »
Discord: スメグマ#2236
Email: OwOwOwOwO123@outlook.com
GitHub: gabriel-tenma-white
 
The following users thanked this post: edavid

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #87 on: November 21, 2019, 04:38:18 pm »
Thanks for this information. Interestingly, if you search AliExpress for "MXT2088", it will come up with a bunch of listings for "AD9288" that otherwise do not mention MXT2088 at all. So it looks like there some hidden connection/keywords in their system.

It is also good. Because while it is obvious  that all those AD9288 are fakes, they are quite a bit cheaper than the original. And for applications like this scope it really makes no difference.
Alex
 

Offline mg3100

  • Contributor
  • Posts: 9
  • Country: nl
Re: Reverse engineering FNIRSI-5012H
« Reply #88 on: November 22, 2019, 07:47:19 pm »
Quote
that all those AD9288 are fakes

At least they seem to function  :D.

Last month I ordered  a couple of P-Channel power mosfets and even though they looked genuine and had all the markings in the right place
I couldn't get them to function. In the end they turned out to be N-Channel mosfets  :'( ... and of course no reply from the seller.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #89 on: November 22, 2019, 07:49:18 pm »
If there is one item you should never buy from China, it would be power mosfets. It seems like they are the most faked item ever.
Alex
 
The following users thanked this post: boB, dave528

Offline mg3100

  • Contributor
  • Posts: 9
  • Country: nl
Re: Reverse engineering FNIRSI-5012H
« Reply #90 on: November 22, 2019, 08:07:49 pm »
I hope LCSC sends me genuine gd32f407vet6  :D :D
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #91 on: November 25, 2019, 01:19:51 am »
I've implemented the basic version of the triggering setup. Basically a single trigger. I start the ADC DMA and run the trigger detection code. After the trigger is detected, I wait for ~64K more samples and stop the capture.

The issue is that on continuous AC signals the trigger is detected immediately, so there is no pre-trigger history. So it looks like I just need to collect 64K samples without running the trigger detection code, and then start  it. I guess it is fine, since this is really only an issues for periodic signals, and they will hopefully continue running.

A bigger issue is that current trigger detection code actually just detects that sample is above the threshold, not the moment of crossing. So if trigger detection code starts when the signal is already higher than the trigger, it marks the first sample as the trigger point. It is not a big deal, but will cause some loss of performance.
Alex
 

Offline dmendesf

  • Regular Contributor
  • *
  • Posts: 151
  • Country: br
Re: Reverse engineering FNIRSI-5012H
« Reply #92 on: November 25, 2019, 02:05:43 am »
Trigger needs to have a state. Initial state is "non-triggered". For each sample in the buffer you do the trigger logic (for a rising edge trigger, logic is "if last sample is below trigger value and actual sample is equal or bigger than sample value, then state is triggered").
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #93 on: November 25, 2019, 02:09:13 am »
Well, yes, I know how triggers are working in general. In this case we are extracting the last bit of performance with SIMD instructions, so it is not that trivial. Looking at the last sample every cycle is not an option.

So it looks like I would have to look for the opposite condition and then for the real trigger condition. It should not add a lot of instructions. I'm a bit distracted at the moment to think hard about it. I'll figure it out tomorrow.
« Last Edit: November 25, 2019, 02:11:49 am by ataradov »
Alex
 

Offline EL-TRONIC

  • Newbie
  • Posts: 4
  • Country: cs
Re: Reverse engineering FNIRSI-5012H
« Reply #94 on: November 26, 2019, 06:14:03 am »
I bought FNIRSI-5012H and I got this today...
Please see images, is there any way to change language?
Maybe new firmware? Where to download?
Thanks in advance...
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #95 on: November 26, 2019, 06:15:58 am »
Please see images, is there any way to change language?
Maybe new firmware? Where to download?
There are no images attached.  Also, there is no way to download or upgrade the firmware.
Alex
 

Offline EL-TRONIC

  • Newbie
  • Posts: 4
  • Country: cs
Re: Reverse engineering FNIRSI-5012H
« Reply #96 on: November 26, 2019, 06:23:37 am »
[attach=1][attach=2]
 

Offline EL-TRONIC

  • Newbie
  • Posts: 4
  • Country: cs
Re: Reverse engineering FNIRSI-5012H
« Reply #97 on: November 26, 2019, 06:24:50 am »
Is there any settings to change language?
Thanks
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #98 on: November 26, 2019, 06:28:31 am »
I don't see any settings to change the language. So it looks like you are stuck with Chinese. Thankfully there are not that many menus you actually need to use past the initial setup.
Alex
 

Offline EL-TRONIC

  • Newbie
  • Posts: 4
  • Country: cs
Re: Reverse engineering FNIRSI-5012H
« Reply #99 on: November 26, 2019, 06:35:45 am »
Thanks Alex
 

Offline Alarus

  • Newbie
  • Posts: 1
  • Country: ru
Re: Reverse engineering FNIRSI-5012H
« Reply #100 on: December 10, 2019, 02:39:22 am »
Is there any settings to change language?
Thanks

Maybe to change the language you need to press a combination of buttons and turn on the power. For example: press down arrow when turning on the power hides the splash screen, and the up arrow turns it on. It is also possible to enter the firmware update mode.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #101 on: December 10, 2019, 02:50:21 am »
There is no firmware update mode since there is no way to get anything into the device. It has no external interfaces. Apart from the analog input, which would be a cool way to update the firmware - like in the old days, play a file from a tape :).

I also tried holding down buttons in various configurations. Some will make the device hang, but no other activity that I could see. The hangs may be interesting to investigate later, but I don't think they will do anything useful, probably just some flaw of scanning the keyboard.

Also, I did not abandon the project, in fact I'm working on it every time I have a few hours to spare. It is coming along quite nicely.
Alex
 
The following users thanked this post: Kean

Offline JustACat

  • Newbie
  • Posts: 1
  • Country: ru
Re: Reverse engineering FNIRSI-5012H
« Reply #102 on: December 16, 2019, 12:17:17 pm »
Also, I did not abandon the project, in fact I'm working on it every time I have a few hours to spare. It is coming along quite nicely.

Thank you for your effort! Hope it will lead to something wonderful eventually.
 

Offline cliffyk

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: us
    • PaladinMicro
Re: Reverse engineering FNIRSI-5012H
« Reply #103 on: December 16, 2019, 03:28:10 pm »
I don't see any settings to change the language. So it looks like you are stuck with Chinese. Thankfully there are not that many menus you actually need to use past the initial setup.

Alex,

The one I had, purchased through Amazon from a vendor named Eple and branded as a "YEEPOOK" (you can't make this stuff up)-- had an English UI...
-cliff knight-

paladinmicro.com
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #104 on: December 16, 2019, 10:20:05 pm »
The one I had, purchased through Amazon from a vendor named Eple and branded as a "YEEPOOK" (you can't make this stuff up)-- had an English UI...
Majority of them seem to have English UI. EL-TRONIC got a very unique unit.

I've made a lot of progress this weekend. It starts to look like a real scope. Still a lot of work ahead, but the more structure takes place, the easier it gets.
Alex
 
The following users thanked this post: all_repair, edavid, dave528

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #105 on: December 19, 2019, 02:22:45 am »
Hi there,

Couldn't find my CRT scope any more, just ordered a 5012H this evening.  And I hit this interesting thread. 

I noticed that there are more that one make of 5012H available online .  The FINRISI uses 2 relays but the Denis has 4.   Hence the input section may be different. 

Is there a hardware version making on board?  I ordered a noname 5012H for its bigger 5000mAH battery. I'll check mine when it arrives.

Regards.
 

Offline Bud

  • Super Contributor
  • ***
  • Posts: 4385
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #106 on: December 19, 2019, 02:27:39 am »
Couldn't find my CRT scope any more

Have a big house?  :D
Facebook-free life and Rigol-free shack.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #107 on: December 19, 2019, 02:30:51 am »
No, there is an older version with a lot of relays and newer version with just two relays.  From what I gather all the old versions are sold out by now, so you get the new one from any vendor. Unless they are so obscure that they could not manage to move old stock.

Also, don't buy that 5000 mAh battery claim. All new devices come with TFT LCD and 3000 mAh battery. Some less honest vendors "forget" to update the description.
Alex
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #108 on: December 19, 2019, 06:22:19 pm »
Too late.  I have placed the order.  I'll see what I get when it arrives.  Probably it is the same no matter where I order from. 

The CRT and vacuum tubes based scope was bought in the 70's.  If my wife had not thrown it out, it should still be hinding somewher in my basement. 

BTW, is 5012H really capable of 500M samples/sec?   It sounds tight comparing to the MCU clock unless the ADC buffers enough making repeated snapshots possible.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #109 on: December 19, 2019, 06:25:34 pm »
BTW, is 5012H really capable of 500M samples/sec?
The answer is in the first post of this thread. No, it is 250 MSPS at best. And I actually have good reasons to doubt that its sampling at 250 MSPS is reliable. It uses 250 MSPS clock, but I think it misses samples and they simply don't care.

With the stock firmware it is a really bad scope.
Alex
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #110 on: December 19, 2019, 08:01:58 pm »
Sorry I did not read through the entire thread.  I even missed the details in your first post.  :palm:

If you measured 125MHz at the clock, it would unlikely do 1 samples per edge to make 500MSPS, unless the unmarked chip has 4 channels instead of 2.  AD9288 is only spec'ed upto 100MSPS per channel at best.

If you improve the FW it is great.  We worry about how to load it up after. 
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #111 on: December 19, 2019, 09:06:05 pm »
If you measured 125MHz at the clock, it would unlikely do 1 samples per edge to make 500MSPS
No, it is just Chinese 500 MSPS. The same way as your battery is "5000 mAh".

There is just no hardware on the inside the MCU that can capture a stream that fast.

AD9288 is only spec'ed upto 100MSPS per channel at best.
They can be pretty reliably overclocked. They will lose some of the performance, but they still have plenty for this application.

But there is also evidence that this is a pin-compatible clone, which can really have any performance characteristics.

And there is no uploading new firmware. At this time the only option is a chip swap. The chip that is there is locked.
« Last Edit: December 19, 2019, 09:09:36 pm by ataradov »
Alex
 

Offline all_repair

  • Frequent Contributor
  • **
  • Posts: 654
Re: Reverse engineering FNIRSI-5012H
« Reply #112 on: December 20, 2019, 02:15:13 am »
@ataradov
I wanted one of this, given up after learning about the triggering issue.  Now there is one shipping on the way waiting for your code. ;)
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #113 on: December 23, 2019, 05:14:52 am »
Don't really have capability to work on smd.  Can't do chip swap unless it comes with some sort of socket .  Are you sure we can't erase and rewrite? Mine is still waiting for shipment.  Not sure if it would ever be shipped.  Item turned no longer available a couple of day after placing order.
How bad is the stock FW assuming I don't really need 500 msps?  The battery did look bigger on one review youtube than another. Perhaps we have a Chinese 5000 vs 3000 mAH. :)

 
 

Offline jhpadjustable

  • Frequent Contributor
  • **
  • Posts: 295
  • Country: us
  • Salt 'n' pepper beard
Re: Reverse engineering FNIRSI-5012H
« Reply #114 on: December 23, 2019, 09:57:09 am »
Don't really have capability to work on smd.  Can't do chip swap unless it comes with some sort of socket .  Are you sure we can't erase and rewrite?
As Alex said eariler, it appears to be level 2 locked. You are welcome to argue with the chip all day long, but I don't think it will be moved. :) Perhaps your local phone repair hut can do the swap for you?

Quote
How bad is the stock FW assuming I don't really need 500 msps?
Dave ranted about it in great detail.
 
"There are more things in heaven and earth, Arduino, than are dreamt of in your philosophy."
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #115 on: December 23, 2019, 08:44:59 pm »
I did watch that video before ordering.  The complaints were mostly on the trigger and vertical dropoff at higher frequency.  The vertical may be something addressable hardware-wise. 

Is there a trigger input on board?  Do we have a circuit diagram?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #116 on: December 23, 2019, 09:09:10 pm »
Trigger happens purely in the software. The first post here essentially describes the entire digital part of this device.
Alex
 

Offline alx359

  • Newbie
  • Posts: 2
  • Country: 00
Re: Reverse engineering FNIRSI-5012H
« Reply #117 on: January 09, 2020, 06:04:44 pm »
Quote from: ataradov
Also, I did not abandon the project, in fact I'm working on it every time I have a few hours to spare. It is coming along quite nicely.

So cool project! Found this thread while researching for a 5012H. After the initial creative burst though it feels a bit quiet lately. @Alex: may I ask if you're still willing to spend some more of your valuable time until delivering an open FW out of this? Cheers!
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #118 on: January 09, 2020, 06:17:52 pm »
Yes, I'm still actively working on it. It is getting close to a releasable state. But it is a lot of work to create good software.

The horizontal part is working pretty well now, I have triggering in both single- and dual-channel mode working reliably. Horizontal offset controls are also working well. In general the UI is pretty complete.

I'm currently working on proper trace display. I have a basic implementation, but I don't like it. When showing a large buffer on a small screen, it is not sufficient to just take every N-th sample. The results look like crap, so this weekend I will be working on finding the min/max values in the range of samples that corresponds to a pixel and showing a vertical bar instead of a single sample.

The steps for the initial public release:
1. Finish trace display
2. At least rudimentary vertical calibration. The signal is pretty close as is, but on some ranges it is quite off
3. Vertical offset control that is actually in Volts, not in DAC counts.
4. General code clean up. There are a lot of TODOs there.
Alex
 
The following users thanked this post: all_repair, mikerj, neil555, Kilrah, alx359

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #119 on: January 10, 2020, 06:22:59 pm »
Great. I am still waiting for my 5012H.  Last tracking was Dec 27 2019 in China.  Haven't reached Canadian airspace yet.    |O

Is there any chance for releasing your FW in some form, like a daughter board with configurable MCU?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #120 on: January 10, 2020, 07:01:50 pm »
Is there any chance for releasing your FW in some form, like a daughter board with configurable MCU?
Daughter board for what? The only way to get this firmware to run on 5012H is to desolder the old MCU and place a new one. There is no other way for now.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #121 on: January 13, 2020, 06:32:10 am »
I've made a lot of progress this weekend. All horizontal controls (position/scale) are working. Acquisition and triggering modes are working too.

Vertical controls UI part is working, but it is not actually hooked to the hardware (DAC). Vertical scale is working (relay switching part, not the actual conversion of the ADC values to volts for display).

Here is a picture of the current sate of the UI. Here you can see 3 kHz square wave being fed into the input directly from the signal generator without any probes. As you can see analog performance is not the best without probe compensation.

I will have a closer look at the analog part when I'm done with the digital. I'm sure it is fixable.
Alex
 
The following users thanked this post: mikerj, dcarr, alx359

Offline webnavigator

  • Newbie
  • Posts: 2
  • Country: gr
Re: Reverse engineering FNIRSI-5012H
« Reply #122 on: January 14, 2020, 09:32:06 pm »
Excellent job.

It seems that there is a new device with firmware upgrade capabilities:
https://www.aliexpress.com/item/4000571425898.html?spm=a2g0o.productlist.0.0.12fa7d388Lzfjc&algo_pvid=6c34e913-1d3d-4385-ac47-d42bf2ff2b22&algo_expid=6c34e913-1d3d-4385-ac47-d42bf2ff2b22-0&btsid=5ef1452f-80b4-4876-9a21-5162ea7dc9a2&ws_ab_test=searchweb0_0,searchweb201602_5,searchweb201603_53 

Be warned that the seller is new without any feedback, and he has only this item for sale ... 

There is a Russian page with more information about it and a firmware in Mediafire:
https://mysku.ru/blog/discounts/78121.html 

It's too risky to buy anything from the specific store, but if it is not a scam, there will be plenty of clones in the near future, with upgrade function.
 

Offline webnavigator

  • Newbie
  • Posts: 2
  • Country: gr
Re: Reverse engineering FNIRSI-5012H
« Reply #123 on: January 14, 2020, 09:43:20 pm »
The above aliexpress link is too lengthy, there is a shorter one :
https://www.aliexpress.com/item/4000571425898.html?spm=2114.12010615.8148356.1.74c77dc9ta0ACM

Again be very careful and wait ....
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #124 on: January 14, 2020, 09:44:38 pm »
It looks like something I was planning to do in the future. Put FPGA/CPLD for trigger detection and some signal pre-processing. Plus a better analog front-end. Plus a better display.

I really like the performance of GD32F407, so downgrade is rather unfortunate. I also see no need for external SRAM. But they probably got a better price on slower MCU+SRAM.

Specs are still BS, of course, but overall design seems to be more reasonable. At least there is a trim cap for internal compensation.

I'm personally sticking with GD32F407. This device is a beast.

And just from the button layout I can guarantee that controls will suck. The old one was right on point.
Alex
 

Offline alx359

  • Newbie
  • Posts: 2
  • Country: 00
Re: Reverse engineering FNIRSI-5012H
« Reply #125 on: January 22, 2020, 05:51:13 am »
Got mine 5012H the other day. @Alex: are you still motivated to finish and release your FW now that the hardware-changed & FW-updatable 1C15 seems upcoming so soon?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #126 on: January 22, 2020, 05:55:49 am »
Yes, I'm still working on it. It is getting close to release. I expect initial release to happen this weekend or the next weekend.

I finished calibration mode and majority of vertical control stuff last weekend.

I don't care much about their new hardware. I'm just not interested at all. Plus I know that their software will be unusable crap. And better hardware will not save it.
Alex
 
The following users thanked this post: all_repair, bgnass, alx359

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #127 on: January 27, 2020, 02:42:35 am »
The source code is now public! You can have a look at it here https://github.com/ataradov/open-5012h

It should be considered to be a beta or even an alpha version. The main functionality is there, but it was not tested apart from testing I did during the normal development process.

The main thing that is missing is menus of any sort. So all the settings that depend on the menus (like 1X/10X or backlight brightness).

1X/10X mode is also not implemented yet, all values are shown in 1X mode.

All of those things and more features are coming. I just wanted to release some code, and what I have now is releasable.

Overall I'm very happy with the results. This is a solid platform and a lot of functionality can be added on top of that. After the basic menus and stuff like this, I'm considering implementing serial decode, and even serial console mode, where entire screen just turns into a console. No trace is displayed, but just the received characters. Spectrum analyzer is also a possibility, but it may take a while.

I want to implement the necessary parts and then use it for a while and implement things that are useful in real life.
« Last Edit: January 27, 2020, 02:47:53 am by ataradov »
Alex
 
The following users thanked this post: oPossum, BravoV, all_repair, vivaT, mikerj, james_s, alx359

Online BravoV

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: 00
  • +++ ATH1
Re: Reverse engineering FNIRSI-5012H
« Reply #128 on: January 27, 2020, 02:46:33 am »
Alex, just a suggestion, update the 1st post with the latest update you've posted and the upcoming onces, as I believe once matured, this thread will be drowned into gazillion pages and makes new comer hard to track as they need to read every posts.
« Last Edit: January 27, 2020, 02:48:17 am by BravoV »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #129 on: January 27, 2020, 02:49:07 am »
Alex, just a suggestion, update the 1st post with the latest update you've posted and the upcoming onces, as I believe once matured, this thread will be drowned into gazillion pages and makes new comer hard to track as they need to read every posts.

I've put the link in the first message already. This is the first thing people finding this thread will see.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #130 on: January 27, 2020, 03:55:03 am »
A few comments on the architecture. This will eventually go into the documentation, but I'm too tired to format that appropriately.

First of all sample buffer size. There are two buffers. The primary buffer is 128K samples and this is the buffer filled by the DMA. At the end of the capture (when necessary number of post-trigger samples were captured), the data from this buffer is decimated 4 times and transferred into 32K buffer. After this transfer, in Auto and Normal modes, the DMA goes back to looking for the trigger.

So the contents of the 128K buffer are gone. This makes for the shortest blank time. The disadvantage - in Auto and Normal modes the effective sample rate is 1/4 of the configured. The only way to use full sample rate is to use Single mode.

This is not a real issue in practice. It all feels good.

Another difference compared to what you would see in other scopes is trigger positioning. The trigger here can only be positioned in the sample buffer. So the sample rate is selected automatically to fit the currently displayed window and the trigger point inside the sample buffer.

You can also limit highest sample rate value if for whatever reason you want to capture more data than necessary according to your current window.

And another thing is that because trigger search happens in the software, the trigger level is limited to the displayed vertical span. Trigger level can never go outside of the visible window.

For the same reason it does not move with the vertical offset. So if you had vertical offset at 0V and trigger at 1V, and then you move your vertical offset to -3V, you will end up with a trigger at 4V. This part is mildly annoying, but in real life you don't need to adjust vertical offset too often, so it is probably fine.

Also, if you are adventurous and actually want to try this firmware, let me know, I will provide all the help I can.

I'm using  some questionable programming adapter. I'll think about making a dedicated PCB for that.
« Last Edit: January 27, 2020, 03:57:03 am by ataradov »
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #131 on: January 27, 2020, 08:01:00 am »
What's "dual channel mode" ?
125 MSPS sampling rate. In this case two ADC channels running at 62.5 MSPS are combined.

The wording on the documentation could be better. I threw it together in an hour because I wanted to release this stuff before the end of the day.

Can't upload the FW via USB to the blank new GD32F407VET6 soldered in the scope? If not, won't you sell us at least a few pre-programmed chips, please? ;D
No, you need a programmer. There are plenty of cheap ARM programmers out there.

I can't really pre-program a chip without some sort of a socket. Also, there is no point. The firmware is so beta at this point that you will want to change it, so having a way to program the device at will is really necessary for this.

USB connector does not have actual USB signals in it, so USB boot is not an option.

You can try to identify good points to tap into those other interfaces, of course. But there are no obvious test points, so it might be hard. Much harder than actually finding a programmer.
« Last Edit: January 27, 2020, 08:03:16 am by ataradov »
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #132 on: January 27, 2020, 05:45:53 pm »
Yes, USB connector is what I was using all this time. It alone is enough to program the device.

I still don't want to be in a business of shipping devices. That's sounds like a recipe for disaster.

I'm using my own tools, so I don't know the extent of support for those GigaDevice devices in other tools. You need to research that. The hardware will probably fine. The question is what tools to use.

Bigger flash size should not be a problem. But is it really worth for a $1 difference? You only need a few devices.
Alex
 

Online Martinn

  • Contributor
  • Posts: 18
  • Country: ch
Re: Reverse engineering FNIRSI-5012H
« Reply #133 on: January 28, 2020, 05:33:23 pm »
Hi Alex, I've been watching this thread for some time... thanks a lot for making this available! I think when the Chinese are back from holiday, I'll order a scope and a couple of the GD32F407.
Nice to see some code without the usual STM32 HAL bloat.
I guess I can manage (with enough effort) to put your code into an Truestudio (CubeIDE) or IAR project (I am using those regularly), but it would help a lot if you could publish a compiled binary along with the source code (particularly as I believe your sampling code will be time/compiler optimization critical).
I wonder if STM32CubeIDE or the STLink tool can handle GD32 devices directly.

- Martin
 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #134 on: January 28, 2020, 05:45:03 pm »
I just read your remark about the backlight better be at 100% brightness for the calibration. :palm:
Everybody likes gadgets. Until they try to make them.
 
The following users thanked this post: WattsThat

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #135 on: January 28, 2020, 05:55:56 pm »
I just read your remark about the backlight better be at 100% brightness for the calibration. :palm:
What is wrong with it? I don't think there are actual issues, but backlight is dimmed though the PWM on the LDO enable input. Why not eliminate all sources of the noise, even if they don't actually contribute much or anything at all?

Again, I have zero evidence that BL PWM actually adds noise. Having charger plugged does add noise.

I will publish binaries at some point.
« Last Edit: January 28, 2020, 05:57:47 pm by ataradov »
Alex
 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #136 on: January 28, 2020, 06:46:46 pm »
I just read your remark about the backlight better be at 100% brightness for the calibration. :palm:
What is wrong with it? I don't think there are actual issues, but backlight is dimmed though the PWM on the LDO enable input. Why not eliminate all sources of the noise, even if they don't actually contribute much or anything at all?

Again, I have zero evidence that BL PWM actually adds noise. Having charger plugged does add noise.

I will publish binaries at some point.

No, no, it's all good. The :palm: was towards the hardware design. I interpreted your remark such that the backlight circuit produced enough noise to upset the calibration when not at full brightness.
Everybody likes gadgets. Until they try to make them.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #137 on: January 28, 2020, 06:51:53 pm »
Ah, ok. No, it is actually surprisingly non-intrusive. I expected that PWMing LDO enable pin at 120 Hz would not be great, but it seems to work fine. That being said, I ran at 100% backlight most of the time. The dimming was added just last week. So it may show itself.

On the other hand, I'm not sure it makes sense to run it at less than 100% anyway.
Alex
 

Offline states

  • Newbie
  • Posts: 1
  • Country: vi
Re: Reverse engineering FNIRSI-5012H
« Reply #138 on: January 30, 2020, 09:27:15 am »
https://gd32mcu.21ic.com/en/index

GigaDevice Vendor documentation
« Last Edit: January 30, 2020, 09:34:15 am by states »
 

Offline Evi

  • Contributor
  • Posts: 35
  • Country: ru
Re: Reverse engineering FNIRSI-5012H
« Reply #139 on: January 30, 2020, 09:41:13 am »
I guess, the first thing that must be done before any reverse engineering is to correct input resistive divider to remove undercompensation on 2V range. Here(https://mysku.ru/blog/china-stores/73960.html#comment3255111), an attempt was done, in rather clumsy manner, which does not fully remove the problem.
« Last Edit: January 30, 2020, 09:53:12 am by Evi »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #140 on: January 30, 2020, 05:12:45 pm »
Yeah, I'm divided on what to do with analog part.

Also, it appears this is one more variation of the board. With one relay, but only 6 optocouplers.
Alex
 

Offline OwO

  • Super Contributor
  • ***
  • Posts: 1224
  • Country: cn
  • RF Engineer @ OwOComm. Discord: スメグマ#2236
Re: Reverse engineering FNIRSI-5012H
« Reply #141 on: January 30, 2020, 05:21:43 pm »
The hardware is very simple and all the parts are easy to get, so have you considered redesigning the whole thing from scratch "properly"? It seems it wouldn't be too hard and you can get the cost close to the sell price of that thing, even in prototype quantities. FPGAs are also cheap (< $5 for a spartan 6) so you could consider that path as well.
Discord: スメグマ#2236
Email: OwOwOwOwO123@outlook.com
GitHub: gabriel-tenma-white
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #142 on: January 30, 2020, 05:28:02 pm »
The hardware is very simple and all the parts are easy to get, so have you considered redesigning the whole thing from scratch "properly"?

Yes, I did consider that. I need to give attention to some other projects, but redesigning this thing from scratch is definitely on the list.

On that note, if anyone has good and proven designs for ~40 MHz front-end, I'd like to see them to get a general idea of what to do.
Alex
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #143 on: January 30, 2020, 11:52:59 pm »
The source code is now public!   

Thanks.  I'll see if I can replace the MCU or add an font end, when my 5012H arrives. The source code should give me an idea how the software triggering works.   

My oreder cleared Customs on te wrong side of Canada on Jan 13, supposed to be delivered on Jan 17 but I am still waiting for it 2 weeks after.   :=\
« Last Edit: January 30, 2020, 11:54:42 pm by wasp09 »
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #144 on: February 08, 2020, 02:17:57 am »
Finally mine arrive today, 51 days after order.  CanadaPost blew its delivery standard by 3 weeks. 

It turns out a FNIRSI with single relay and smaller battery inside.    I found it restarted on its own quite often while I was playing with it.  It also hanged in autoset, I guess, when it didn't know how.    It also picked up some noise, sine wave at around 78MHz, when it was charging.  The noise only appears at 10/100V input setting and most obvious at 6nsec timebase.  Hard to figure out why it does not show any at lower input settings.  I don't have another scope which can handle that frequency to troubleshoot the input stage and amp.    It would be an interesting exercise. 

Those may be battery or condensation related after a long cold journey.   I'll charge it up and keep it warm tonight. 

 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #145 on: February 08, 2020, 02:23:22 am »
The noise from charging is always there. I would strongly advice against using this device while it is plugged in. This is one of those cases where you should not trust the design to not kill you.
Alex
 

Offline Johannsen

  • Contributor
  • Posts: 23
  • Country: 00
Re: Reverse engineering FNIRSI-5012H
« Reply #146 on: February 08, 2020, 11:29:55 am »
Hi can you write a sentence in your github project how to program this new chip? Which tools software is needed?
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #147 on: February 08, 2020, 05:00:12 pm »
The test probe wasn't attached when I saw those noise while charging.   I can't tell the status of  the battery unless I power it up.  It has to support power up charging I suppose. 

Mine still hangs showing "autoset" everytime when I press the "auto" button and there is a valid input signal.    If there was no input, it survived and set the timebase to 500us.  The scope wasn't plugged in.

Is it FW, something like stack over or watchdog kicking in when it is too busy?  Or do I get a lemon with bad hardware?  Do you know of any debug logs accessible on the unit?

Mine is far from what a realtime scope does.  No single shot at slower timebase.    Haven't figured out how to scroll horizontally.   Basically the scope picks the window it wants to show.  The time it covers is too short and I have little chance of hitting the piece I want to see.

It looks great but it is more a toy than a tool for now.  :(

 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #148 on: February 08, 2020, 05:52:44 pm »
Hi can you write a sentence in your github project how to program this new chip? Which tools software is needed?
Yes, I will. I totally forgot about that. So far I've been using solution that is really hacked together. I will make a proper adapter and add instructions.

One of those connectors https://www.ebay.com/itm/10Pcs-Mini-Micro-USB-5-Pins-Male-Connector-Port-Solder-Plug-Plastic-Cover-Useful/293118487488 or a simple cut off from a micro USB cable would be required. Note that because connector is deep, in case of a micro USB cable you may need to cut a bit of the plastic close to the connector, so it fully seats in the scope.

Then you will need any SWD programmer. I've used my own, because I have them (https://www.tindie.com/products/ataradov/cmsis-dap-compliant-swd-debugger/). But you can use any. There are dozens, including implemented on Arduino.

In case of a programmer it is important to remember that there is no reference voltage (+3.3V) on the outside connector. So if your programmer has level shifters and uses target voltage as a reference, then you will have to supply this voltage externally somehow.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #149 on: February 08, 2020, 05:55:38 pm »
The test probe wasn't attached when I saw those noise while charging.   I can't tell the status of  the battery unless I power it up.  It has to support power up charging I suppose. 
Yes, the noise is induced though the ground. It is fine to have it on, as long as you are not measuring anything , and generally staying away from the BNC connector. Again, it is 99.99% paranoia, but I personally don't want to take even 0.01% chance.

It looks great but it is more a toy than a tool for now.  :(
I really have no idea about its default firmware. I've only used it for 10 minutes to figure out it was a joke.
Alex
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #150 on: February 08, 2020, 10:52:56 pm »
Alex
 
The following users thanked this post: Martinn

Offline cliffyk

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: us
    • PaladinMicro
Re: Reverse engineering FNIRSI-5012H
« Reply #151 on: February 10, 2020, 01:40:19 am »
Excellent job.

It seems that there is a new device with firmware upgrade capabilities:
https://www.aliexpress.com/item/4000571425898.html?spm=a2g0o.productlist.0.0.12fa7d388Lzfjc&algo_pvid=6c34e913-1d3d-4385-ac47-d42bf2ff2b22&algo_expid=6c34e913-1d3d-4385-ac47-d42bf2ff2b22-0&btsid=5ef1452f-80b4-4876-9a21-5162ea7dc9a2&ws_ab_test=searchweb0_0,searchweb201602_5,searchweb201603_53 

Be warned that the seller is new without any feedback, and he has only this item for sale ... 

There is a Russian page with more information about it and a firmware in Mediafire:
https://mysku.ru/blog/discounts/78121.html 

It's too risky to buy anything from the specific store, but if it is not a scam, there will be plenty of clones in the near future, with upgrade function.

Now that is an amazing instrument--look at these precisely defined 53.8 MHz square waves:

-cliff knight-

paladinmicro.com
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #152 on: February 10, 2020, 01:42:49 am »
Exquisite photoshop work. Too bad they did not remove 200 us/.
Alex
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #153 on: February 10, 2020, 03:22:04 pm »
Perfect square wave at 53.8MHz?  We need a bandwidth to support 9th harmonics to show a not so sharp square.  For a perfect square, the front end needs to be able to handle something around 500MHz or more.  Too good to be true for a scope at a price range as 5012H.

My 5012H did pick up 9x MHz distorted sinewave from my analog sig gen manufactured in the 70s,  but it stopped working slightly beyond 100MHz.  It is kind of up to spec via some kind of sampling.   

BTW, is the philips screw on the probe for 10X tuning?  I can't turn it and don't want to break it yet. 
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #154 on: February 10, 2020, 05:40:28 pm »
BTW, is the philips screw on the probe for 10X tuning?  I can't turn it and don't want to break it yet. 
Yes, it is a standard probe compensation thing. It should turn pretty easy. But don't use actual philips screwdriver, they are too pointy for that. Use a flat screwdriver that fits into the widest part of the trimmer cap.
Alex
 

Offline Bud

  • Super Contributor
  • ***
  • Posts: 4385
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #155 on: February 10, 2020, 05:51:00 pm »
Exquisite photoshop work. Too bad they did not remove 200 us/.
Right..., if the 200 is uS/ then it is just a 1kHz waveform displayed. Funny.
Facebook-free life and Rigol-free shack.
 

Offline cliffyk

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: us
    • PaladinMicro
Re: Reverse engineering FNIRSI-5012H
« Reply #156 on: February 11, 2020, 01:43:42 am »
Here is a mathematically generated square wave, constructed from the first 101 harmonics:



Still not as good as the image in the scope's ad copy--or a 53.8 MHz looking as good as shown above would require a 5,433,800,000 (5.5 GHz) front-end bandwidth.

Here are the numbers that drove the waveform's construction;



This stuff is 30+ years old, it was part of my Master's work...
-cliff knight-

paladinmicro.com
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #157 on: February 11, 2020, 01:47:16 am »
There is really no point in discussing poor photoshop job. You can spend entire life debunking pictures from Ali. 
Alex
 

Offline cliffyk

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: us
    • PaladinMicro
Re: Reverse engineering FNIRSI-5012H
« Reply #158 on: February 11, 2020, 02:32:02 am »
There is really no point in discussing poor photoshop job. You can spend entire life debunking pictures from Ali.

A disappointing number of people don't understand that...
-cliff knight-

paladinmicro.com
 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #159 on: February 11, 2020, 05:46:54 am »
There is really no point in discussing poor photoshop job. You can spend entire life debunking pictures from Ali.

A disappointing number of people don't understand that...

Heh, but then they exactly get what they deserve ;) The instant Karma of Aliexpress punishes stupidity without fail.
Everybody likes gadgets. Until they try to make them.
 

Online Martinn

  • Contributor
  • Posts: 18
  • Country: ch
Re: Reverse engineering FNIRSI-5012H
« Reply #160 on: February 11, 2020, 06:44:25 pm »
I will publish binaries at some point.

A bit out of curiosity I threw the source into an empty CubeIDE project. After a few tweaks (like compiler -O3, setting a few defines in the options dialogs) at least there was no error during compilation and a binary file came out.
I ordered both the scope now from Ali and some GD32F407 from LCSC, now long wait... :=\

 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #161 on: February 13, 2020, 08:00:03 pm »
Did you order any tools for swapping out surface mounted chips?   I wonder if anyone had succeeded in desoldering/soldering GD32F407 using a regular solder iron.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #162 on: February 13, 2020, 08:05:08 pm »
Did you order any tools for swapping out surface mounted chips?   I wonder if anyone had succeeded in desoldering/soldering GD32F407 using a regular solder iron.
You definitively want a hot air rework station.

Absent that I would carefully cut the pins close to the chip first and then remove leftover stubs with a soldering iron. This is a bit annoying and takes a long time, but I've done that before for very large packages that are hard to remove even with hot air. It does work, but requires care.

If you have a hot air station, the trick I started using recently is to pass a thin wire (single strands from a multi-strand wire) under the chip. This creates a very convenient pull handle. It also lets you know the exact moment chip is ready to come off. No unnecessary overheating.  This also avoids the need for a vacuum pickup, which are typically not the greatest.
« Last Edit: February 13, 2020, 08:09:21 pm by ataradov »
Alex
 

Offline Bud

  • Super Contributor
  • ***
  • Posts: 4385
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #163 on: February 13, 2020, 09:27:20 pm »
Place the board on the coffee mug warmer if you do not have a pre-heater, wait 15 minutes then apply hot air, the chip will come off much easier. I measured my coffee warmer runs at 94 C, i use it all the time for jobs like that.
Facebook-free life and Rigol-free shack.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #164 on: February 13, 2020, 09:32:39 pm »
Sure, having proper equipment makes things easier, but where is the fun in that?

I never had a coffee mug heater. Are they even remotely hot enough to helping with desoldering?  Another issue that I can see is that actually heating up the boars would require very close positioning, which may not work due to other parts on the board.

In case of this oscilloscope the challenge with using a lot of non-directed heat is there is a display attached to the board. It flips away from the board, so it is fine, but it is still too close and flops around when handling.

In any case removing 100-pin package is not that hard. I was talking more about 208-QFP.
Alex
 

Online Martinn

  • Contributor
  • Posts: 18
  • Country: ch
Re: Reverse engineering FNIRSI-5012H
« Reply #165 on: February 15, 2020, 05:39:42 pm »
I thought I might add a short tutorial on how to swap a TQFP part. Probably there are several on YT already, one more probably can't hurt...
If people think they need a hot air rework station before they can swap the processor, it will be a very lonely thread here I fear. I guess many not so experienced believe that swapping a QFP is way beyond their skill level (hint: it's not).
What do you think?

- Martin
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #166 on: February 15, 2020, 06:56:53 pm »
Do you have a way to remove TQFP parts without hot air? Can you at least describe it?

The issue is that no matter what method you are using, chances of screwing up are pretty high if you are doing it the first time.
Alex
 

Online Martinn

  • Contributor
  • Posts: 18
  • Country: ch
Re: Reverse engineering FNIRSI-5012H
« Reply #167 on: February 15, 2020, 07:16:31 pm »
I guess the most foolproof beginner suitable method would be the Chip-Quik alloy. Dave has a video on it.

But I'd also recommend hot air. More universal and cheaper than a hot air rework station would be a hot air gun with (at least some basic) air flow and temperature control. That's what I'd recommend and also what I'll do for my unit (although I have access to all kinds of higher end equipment). In brief:
From the backside, preheat PCB to 130-150 °C (check with IR thermometer) with the hot air gun (I'll use a heat plate, but not everyone has one and it works with the hot air gun well enough). Turn over. Mask GD32 area: Cut a square hole into office paper and tape it to the PCB with polyimide ("Kapton") tape so everything around the GD32 is covered (actually do this before preheating). With lowest air flow and moderate temperature (maybe 300 °C) on the hot air gun, heat up the GD32 and remove it when the solder melts. Nice idea with the thin wire BTW!
This requires just a decent hot air gun (which is a useful tool anyway) and the PI tape (cheap on ebay/Ali). As you say I'd also strongly recommend practising this on scrap PCBs before messing up the scope. Maybe it's also worth mentioning the wave solder tips (like Weller GW style) - these are incredible for QFP soldering and to my knowledge not widely known.

- Martin
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #168 on: February 15, 2020, 07:29:03 pm »
There is really no need for any of this. Any cheap hot air station like this https://www.ebay.com/itm/110V-858D-700W-Electric-Hot-Air-Heat-G-un-Soldering-Station-Desoldering-Tool-LED/193176118091 would do the trick. No need to mask anything.

I do cover the LCD screen out of abundance of caution, but it is probably not necessary.
Alex
 

Offline perdrix

  • Frequent Contributor
  • **
  • Posts: 287
Re: Reverse engineering FNIRSI-5012H
« Reply #169 on: February 18, 2020, 10:36:30 am »
So with your re-written firmware, what does this wee beastie actually achieve in terms of real bandwidth, etc. etc.

IOW is it worth me buying one installing your firmware?

David
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #170 on: February 18, 2020, 04:59:43 pm »
So with your re-written firmware, what does this wee beastie actually achieve in terms of real bandwidth, etc. etc.
125 MSPS sampling rate. The real bandwidth is unknown, but it is high enough for the sampling rate.


IOW is it worth me buying one installing your firmware?
Only if you want a "hackable" device you can modify for your needs and generally mess around. If you just plan to use the firmware as is, it is probably too early. There are some features missing that I would like to implement, but I need to take a break for some other projects. I'll get back to it eventually.

Overall, the analog performance is mediocre, especially when it comes to compensation. My personal preference would be to redesign the whole PCB, and I have no issues with the digital part, but the analog part would require some experimentation, and I don't have time for that right now.
Alex
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2704
  • Country: tr
Re: Reverse engineering FNIRSI-5012H
« Reply #171 on: February 18, 2020, 05:15:58 pm »
I'm almost ready to flash, my GD32F407s from lcsc arrived today! @ataradov, is the compiled binary in github?
The further a society drifts from truth, the more it will hate those who speak it.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #172 on: February 18, 2020, 05:21:30 pm »
I'm attaching latest binaries here for now.

But really, it is better to set up and build them for yourself.
Alex
 
The following users thanked this post: GeorgeOfTheJungle

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2704
  • Country: tr
Re: Reverse engineering FNIRSI-5012H
« Reply #173 on: February 18, 2020, 06:05:07 pm »
I'm attaching latest binaries here for now.

Thank you very much!

Quote
But really, it is better to set up and build them for yourself.

Sure, but I don't know how to do that yet. I've tried with platfomio and I get a .bin that's not like yours:

Code: [Select]
          mine       yours
.elf    148264      148052
.hex     62701       97838
.bin     22264       34756

Edit:
Alex, any idea how to compile it with this?
https://docs.platformio.org/en/latest/boards/ststm32/black_f407vg.html
« Last Edit: February 18, 2020, 06:15:03 pm by GeorgeOfTheJungle »
The further a society drifts from truth, the more it will hate those who speak it.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #174 on: February 18, 2020, 06:09:41 pm »
Well, compiler versions are likely different. ELF files include debug information, so they are going to be different no matter what unless you put your files at exactly the same place as I do. Plus my stuff was build on Linux.

They may use different settings for hex files too. The only thing you can really compare is output of the arm-none-eabi-size command or the size of the raw binary files.
Alex
 

Offline maginnovision

  • Super Contributor
  • ***
  • Posts: 1914
  • Country: us
Re: Reverse engineering FNIRSI-5012H
« Reply #175 on: February 18, 2020, 06:13:30 pm »
To remove the chip you really can just use an xacto knife with new blade. Hold the chip to the board(if it slides you may pull up pads, especially as fewer pins hold it) while applying downward pressure with a small amount parallel to the plastic package as close to the plastic as possible. You are basically snapping the leads at the package so if a pad lifts it likely wasn't used(95%). Then carefully using some wick(don't slide it until leads are removed) to get the leads off. Go again to clear remaining solder. Then solder new chip. People pull pads up at about the same rate as using hot air the first times. At least from my experience training people.
« Last Edit: February 18, 2020, 06:17:55 pm by maginnovision »
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2704
  • Country: tr
Re: Reverse engineering FNIRSI-5012H
« Reply #176 on: February 18, 2020, 06:16:01 pm »
Well, compiler versions are likely different. ELF files include debug information, so they are going to be different no matter what unless you put your files at exactly the same place as I do. Plus my stuff was build on Linux.

They may use different settings for hex files too. The only thing you can really compare is output of the arm-none-eabi-size command or the size of the raw binary files.

I've updated the msg above, and yep, the .bin file sizes are different too.
The further a society drifts from truth, the more it will hate those who speak it.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #177 on: February 18, 2020, 06:31:47 pm »
I've updated the msg above, and yep, the .bin file sizes are different too.
Again, differences in compilers will explain this. Also differences in compiler flags.

I have no idea what platform.io is. And I don't want to know. I have a very low tolerance for arduino-style things.

I use a compiler provided by ARM - https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm
Alex
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2704
  • Country: tr
Re: Reverse engineering FNIRSI-5012H
« Reply #178 on: February 18, 2020, 10:57:35 pm »
I have no idea what platform.io is. And I don't want to know. I have a very low tolerance for arduino-style things.

You're an elitist  ;D . But Platformio has nothing to do with Arduino.

Quote
I use a compiler provided by ARM - https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm

I'll try to decipher your makefile and make it work with what I have.

I've soldered the new chip already. The most complicated part is to keep it aligned properly for the first solder tack. Once tacked in place, a minimum of solder skills and lots of flux and Bob's your uncle! Some photos:
« Last Edit: February 18, 2020, 10:59:44 pm by GeorgeOfTheJungle »
The further a society drifts from truth, the more it will hate those who speak it.
 
The following users thanked this post: thinkfat, mskeete

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2704
  • Country: tr
Re: Reverse engineering FNIRSI-5012H
« Reply #179 on: February 20, 2020, 08:24:33 pm »
Code: [Select]
st-info --probe
Found 1 stlink programmers
 serial: 363f71064d56383533070643
openocd: "\x36\x3f\x71\x06\x4d\x56\x38\x35\x33\x07\x06\x43"
  flash: 1048576 (pagesize: 16384)
   sram: 196608
 chipid: 0x0413
  descr: F4 device

st-flash erase
st-flash 1.5.1
2020-02-20T21:14:42 INFO common.c: Loading device parameters....
2020-02-20T21:14:42 INFO common.c: Device connected is: F4 device, id 0x16080413
2020-02-20T21:14:42 INFO common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
Mass erasing.

st-flash write open-5012h.bin  0x8000000
st-flash 1.5.1
2020-02-20T20:55:24 INFO usb.c: -- exit_dfu_mode
2020-02-20T20:55:24 INFO common.c: Loading device parameters....
2020-02-20T20:55:24 INFO common.c: Device connected is: F4 device, id 0x16080413
2020-02-20T20:55:24 INFO common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2020-02-20T20:55:24 INFO common.c: Attempting to write 34756 (0x87c4) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08008000 erasedEraseFlash - Sector:0x2 Size:0x4000
2020-02-20T20:55:24 INFO common.c: Finished erasing 3 pages of 16384 (0x4000) bytes
2020-02-20T20:55:24 INFO common.c: Starting Flash write for F2/F4/L4
2020-02-20T20:55:24 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 1988
2020-02-20T20:55:25 INFO common.c: Starting verification of write complete
2020-02-20T20:55:26 INFO common.c: Flash written and verified! jolly good!

 :( The backlight turns on but all I get is a blank screen... :o
« Last Edit: February 20, 2020, 08:26:50 pm by GeorgeOfTheJungle »
The further a society drifts from truth, the more it will hate those who speak it.
 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #180 on: February 20, 2020, 08:38:16 pm »
If that's openocd being used in the background, it doesn't look like its successfully programmed.
Ah no, it says "verified", it's all good.
Everybody likes gadgets. Until they try to make them.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #181 on: February 20, 2020, 09:23:56 pm »
Try to build your own binary and see that you get at least to the LCD backlight. LCD initialization happens after main clock initialization, so some amount of code has run successfully.

If your binary works, then basic debugging is very simple. Just move lcd_set_backlight_level(100); to different points and see where it stops being enabled.

Most likely the reason is the LCD communication. I have not really checked that all the timings are followed correctly. It might be overclocked quite a bit.

As a first step I would look at lcd_data_write() and add a lot more nops there to see if that helps.
Alex
 
The following users thanked this post: GeorgeOfTheJungle

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2704
  • Country: tr
Re: Reverse engineering FNIRSI-5012H
« Reply #182 on: February 20, 2020, 09:48:25 pm »
Thanks Alex, but I'm a total STM32 noob, and haven't found yet a way to compile that here.

Now I regret two things. 1st I shouldn't have removed the LCD. I think I haven't damaged anything (looks fine with the loupe) but who knows. And 2nd buying the 1024k flash GD32 instead of the same that came with the scope. I hope that's not the problem but again, who knows?

Today I spent all the day making my STLINK V2 clone with a blue pill, and learning to use it. It's been the first time ever I've done an st-info --probe or an st-flash write, or used SWD.

Oh well, tomorrow will be another day.
« Last Edit: February 20, 2020, 10:02:18 pm by GeorgeOfTheJungle »
The further a society drifts from truth, the more it will hate those who speak it.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #183 on: February 20, 2020, 10:07:55 pm »
Just download the compiler from ARM site I linked. Then run 'make' in the 'make' directory and it should build the image.

Yes, removing of the LCD was not necessary. Double check that you have soldered it back correctly.

The bigger part should not be the problem. I don't see any dependencies in the code on the bigger flash or SRAM size.
Alex
 
The following users thanked this post: GeorgeOfTheJungle, Vovk_Z

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2704
  • Country: tr
Re: Reverse engineering FNIRSI-5012H
« Reply #184 on: February 21, 2020, 03:08:37 pm »
I can compile now. Setting up the toolchain was easy, and it just werks :-+ To be sure it makes it to the loop, I've put this:

Code: [Select]
  uint32_t ctr= 0;
  int flip_flop= 1;
  while (1)
  {
    timer_task();
    scope_task();
    battery_task();
    buttons_task();
    config_task();
    if (!(++ctr%65536)) {
      lcd_set_backlight_level(flip_flop*100);
      flip_flop= !flip_flop;
    }
  }

And...

fnirsi-not-ok

I'm going to grab the solder and redo that flex :-)

Edit: It werks!

fnirsi-ok
« Last Edit: May 18, 2020, 10:09:22 am by GeorgeOfTheJungle »
The further a society drifts from truth, the more it will hate those who speak it.
 
The following users thanked this post: Kean

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #185 on: February 21, 2020, 05:21:33 pm »
Awesome! You are the second person in the world to run this firmware.

Also, duckdns.org is blocked by uBlock.
Alex
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2704
  • Country: tr
Re: Reverse engineering FNIRSI-5012H
« Reply #186 on: February 21, 2020, 06:03:49 pm »
Awesome! You are the second person in the world to run this firmware.

:-+ 8)

Blocks duckdns? Why? Fuck uBlock... ( use Brave! :-) )

I've been playing with it:

up/down: offset the trace up/down
up+down: reset the trace offset to 0
left/right: move the trigger left/right
left+right: reset trigger to center of screen

TRIG (mode): normal, single, auto
EDGE: up, down, both
trigger up/down: moves trigger level
STOP: run/stop

In stop mode, you can move the trace left/right/up/down, scroll horizontally along the sample memory, AND ZOOM in x and in y !!! It's the dogs bollocks!

AC/DC: ac/dc

NOTE: SHIFT IS 1X10X

shift+up/down: vertical scale 50mV, 100mV, 200mV, 500mV, 1V, 2V, 5V, 10V
shift+left/right: time base 50ns..500ms

MENU: not yet
SAVE: not yet
MODE: not yet
AUTO: not yet
50%: not yet
F1: not yet
F2: while (1) ; :-) (beware!)

Love it!  :-+
« Last Edit: February 21, 2020, 06:33:06 pm by GeorgeOfTheJungle »
The further a society drifts from truth, the more it will hate those who speak it.
 
The following users thanked this post: sotos, Vovk_Z

Offline mg3100

  • Contributor
  • Posts: 9
  • Country: nl
Re: Reverse engineering FNIRSI-5012H
« Reply #187 on: February 22, 2020, 07:24:21 pm »
When I first saw the picture that Alex took from the pcb, I noticed that PC3 was connected to Vcc.
I forgot about it until I removed the chip a few days ago. I cut the trace (just in case) before I soldered the new chip back in place.
I removed the chip without removing the board from the case. Just to make sure I did not damage the LCD/cable.

Anybody any idea why it was connected to Vcc because PC3 is nothing special according the GD32 manual?
Maybe they used it to measure Vcc because one of it's alternate functions is ADC123_IN13.

I made a list of all the unused pins and the most useful alternate functions :

7 - PC13   GPIO
8 - PC14   GPIO
15 - PC0   GPIO
16 - PC1   SPI1_MOSI
17 - PC2   SPI1_MISO
(18 - PC3)   SPI2_MOSI
23 - PA0   UART3_TX
24 - PA1   UART3_RX
25 - PA2   USART1_TX
33 - PC4   GPIO
34 - PC5   USART2_RX
37 - PB2   SPI2_MOSI/BOOT1
39 - PE8   GPIO
40 - PE9   GPIO
41 - PE10   GPIO
64 - PC7   SPI1_SCK/Usart5_Rx
65 - PC8   GPIO   
66 - PC9   GPIO
69 - PA10   USB_ID
70 - PA11   USB_DM
71 - PA12   USB_DP

So we have access to UART3, SPI1, an USB port and a couple of GPIO's. That gives us a lot of extra options for this device.
Adding a serial port is easy and I was also thinking about adding a normal usb connector next to the existing one. We have an ID pin so even OTG should be possible. I only wish I had a lot more knowledge about programming USB devices  :'(

« Last Edit: February 22, 2020, 07:26:34 pm by mg3100 »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #188 on: February 22, 2020, 07:45:20 pm »
I don't see hoe it can be used to measure VCC. There are no dividers and none of the voltage references are higher than VCC. This may just be some sort of ID pin that their original firmware understands.

There is no real point of having working USB on this device. I see no value it can add.
Alex
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2704
  • Country: tr
Re: Reverse engineering FNIRSI-5012H
« Reply #189 on: February 22, 2020, 07:58:27 pm »
I didn't notice until it was too late that BOOT1 is connected to GND under the chip, I would have liked to cut that to upload the fw with the serial bootloader (*) because everybody has a working serial port but not everybody has a working SWD hardware and driver.

USB would be a good thing, it can be setup as a CDC serial port or as a mass storage device to download screen captures or remote control or fw updates in dfu mode or whatever, I think.

(*) One of the pins of USART1 is used by a clock of the ADC, but it doesn't matter.
« Last Edit: February 22, 2020, 08:00:41 pm by GeorgeOfTheJungle »
The further a society drifts from truth, the more it will hate those who speak it.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #190 on: February 22, 2020, 08:11:50 pm »
Yes, cutting BOOT1 pin is a good idea if someone wants to use serial port. But you would need to add external pull-down resistor in that case.
Alex
 

Offline mg3100

  • Contributor
  • Posts: 9
  • Country: nl
Re: Reverse engineering FNIRSI-5012H
« Reply #191 on: February 22, 2020, 08:28:04 pm »
BOOT1 doesn't have to be cut because it is not used (as you can see in my list).
I think you mean BOOT0 which is indeed connected to GND. I lifted it from the board in my first attempt
to get into the bootloader.

So if we don't need PC3 we can have an extra ADC pin. Now I can add fancy features like autodim display :-DD
« Last Edit: February 22, 2020, 08:32:02 pm by mg3100 »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #192 on: February 22, 2020, 08:29:40 pm »
Yes, I meant whatever BOOTx pin is a dedicated pin.
Alex
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2704
  • Country: tr
Re: Reverse engineering FNIRSI-5012H
« Reply #193 on: February 23, 2020, 10:22:59 am »
BOOT1 doesn't have to be cut because it is not used (as you can see in my list).
I think you mean BOOT0 which is indeed connected to GND. I lifted it from the board in my first attempt
to get into the bootloader.

Oh, sorry. Yeah, BOOT0 :-)

With a bluepill and three resistors you can make an STLINK V2:

Use this circuit but don't use that .bin (it doesn't work!):
https://hackaday.io/project/158262-using-blue-pill-stm32f103c8t6-as-st-link

Use this .bin:
http://e.pavlin.si/wp-content/uploads/2016/02/STLinkV2.J16.S4.bin_.zip
Taken from here:
http://e.pavlin.si/2016/02/28/how-to-program-blank-stm32f1-with-stlink-v2-firmware/

Then probe, erase and flash with st-link:
https://github.com/texane/stlink

Edit: Just in case...
« Last Edit: February 24, 2020, 09:08:30 am by GeorgeOfTheJungle »
The further a society drifts from truth, the more it will hate those who speak it.
 

Offline mg3100

  • Contributor
  • Posts: 9
  • Country: nl
Re: Reverse engineering FNIRSI-5012H
« Reply #194 on: February 23, 2020, 11:13:52 am »
 :scared:

Alex, do you want us to report "white screen of death" events? I did look at the code to find out what the cause might be but there was no comment in the code for the "timer overflow" error.
« Last Edit: February 23, 2020, 04:17:51 pm by mg3100 »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #195 on: February 23, 2020, 04:43:25 pm »
Alex, do you want us to report "white screen of death" events? I did look at the code to find out what the cause might be but there was no comment in the code for the "timer overflow" error.
Yes! Especially if you can make a note of what you were doing at a time, or even better can reproduce it reliably.

This error means that something took a long time (> ~0.5 s), but ultimately recovered. I originally assumed that this will never happen in the real life, so there was just a dummy while (1) loop.

It froze on me a couple of times when I had intentional long delays, so I added an error message, so I would not have to guess.

After that I've seen that error only 2 times. And I could not figure out what I was doing at the time  and I could not reproduce it.

If it is really gets in a way, you can safely comment that error out in timer.c, it is mostly harmless, unless it happens a lot.

Alex
 

Offline robca

  • Regular Contributor
  • *
  • Posts: 131
Re: Reverse engineering FNIRSI-5012H
« Reply #196 on: February 23, 2020, 05:15:58 pm »

With a blue pill and three resistors you can make an STLINK V2:


At this time, you can buy an STLink clone on eBay for ~$2, same price as a Blue Pill... so, given that anyone who wants to modify this DSO needs to wait for the processors to arrive from China anyway, might as well order an STLink at the same time. There was a time when SWD programmers were expensive, but not anymore...

Granted, if you already have a Blue Pill laying around, might as well do it, but I'd bet that most people who have Blue Pills around very likely also have an STLink also (given that debugging a Blue Pill without STLink is an exercise in frustration)
 

Offline mg3100

  • Contributor
  • Posts: 9
  • Country: nl
Re: Reverse engineering FNIRSI-5012H
« Reply #197 on: February 23, 2020, 06:30:49 pm »
@ Alex

It happened twice and both times while I was scrolling through a sample in stop mode but I can't reproduce it (yet).

BTW I had to edit the makefile,

Quote
ifeq ($(OS), Windows_NT)
  MKDIR = gmkdir
else
  MKDIR = mkdir
endif

makes windows users call gmkdir   :)
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #198 on: February 23, 2020, 06:33:18 pm »
This is because normal windows mkdir is stupid and does not understand "-p" switch. This is not ideal, but this is the least offensive solution I found.
Alex
 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #199 on: February 23, 2020, 08:08:42 pm »
You do realize that you can source-level debug that thing with the same st-link, gdb and openocd?
Everybody likes gadgets. Until they try to make them.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #200 on: February 23, 2020, 08:10:11 pm »
Yes, and?

Also, in my case SWD link is super unreliable when ADC is running. No idea why specifically, I have not investigated it. So debugging may be a bit complicated.

But there is really not much to debug there.
« Last Edit: February 23, 2020, 08:11:53 pm by ataradov »
Alex
 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #201 on: February 23, 2020, 08:27:47 pm »
That was more directed to mg3100
Everybody likes gadgets. Until they try to make them.
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #202 on: February 24, 2020, 02:09:30 am »
Ordered a hot air station on ebay.  It said shipped but seller did not response when I asked for a tracking number.   Perhaps the price was too good to be true.

Then I checked LCSC.  It says GD32F407VET6 is out of stock.  Would you know of a shop that ships GD32F407 to Canada?  I can only find STM32F407 on ebay or GD32F301 on aliexpress. 

BTW also cloned open-5012H tonight.   Both 4.8.4 and 7.3.1 arm-none-eabi  complained about NULL.   I am running debian stable. I had to add include <stddef.h> to common.h to get through the make.

Regards
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #203 on: February 24, 2020, 02:17:16 am »
Then I checked LCSC.  It says GD32F407VET6 is out of stock.

GD32F407VGT6 is in stock. It is essentially the same part with more flash. But it is not important, it just won't be used. And it is actually cheaper at the moment.

Both 4.8.4 and 7.3.1 arm-none-eabi  complained about NULL.   I am running debian stable. I had to add include <stddef.h> to common.h to get through the make.

I'm using "gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q2-update)" and I see no issues or warnings of any sort.
Alex
 

Offline mg3100

  • Contributor
  • Posts: 9
  • Country: nl
Re: Reverse engineering FNIRSI-5012H
« Reply #204 on: February 24, 2020, 04:20:05 pm »
I'm using gcc-arm-none-eabi-9-2019-q4-major with buildtools gnu-mcu-eclipse-windows-build-tools-2.12-20190422-1053 under windows 10, also no problems.
It produces a different binary file of course but it still functions. Maybe this is the reason why I can't reproduce the white screen of death anymore?

Building the binary using eclipse needed some tweaking in the configuration before it compiled without errors.

I'm using a segger j-link to flash the device, the only thing I had to do was "route power to target" for the level convertors.
No need to use F2, it connects without problems.
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #205 on: February 24, 2020, 05:29:35 pm »

GD32F407VGT6 is in stock. It is essentially the same part with more flash. But it is not important, it just won't be used. And it is actually cheaper at the moment.


Ordered 3 x GD32F407VGT with 512K extra data flash.  Thanks.
 

Offline bson

  • Supporter
  • ****
  • Posts: 1740
  • Country: us
Re: Reverse engineering FNIRSI-5012H
« Reply #206 on: February 24, 2020, 06:23:12 pm »
Given the need to reverse the bits on one of the channels, there is no way to get 100% reliable triggering at 250 MSPS. There is just no enough processing power.
Maybe a viable UX solution is to only allow triggering at full speed on the unreversed channel.  The other channel can be limited in triggering to what can be viably sustained.

But, it is impossible to trigger on 250MSa/s with a CPU that runs at 250MHz.  Even if it executes one instruction per cycle by placing the trigger code in SRAM, one cycle is not enough; it needs to least load a sample, advance a pointer [mod N] for a DMA ring buffer, compare the value, and conditionally continue with the next sample - and this is as simple as it possible can get; with perfect pipeline occupancy this is 5 or 6 cycles.  So it *can't* trigger properly, and can realistically only process every N samples.  Dave's suggestion of 10MHz sounds realistic, giving it 25 cycles per pass through the trigger detector.  This is undoubtedly why the triggering is so awfully poor and requires the signal to repeat until the trigger code eventually sees it.  It's possible this could be improved on if the CPU has an internal comparator that can be used to drive the detector, but even that is really sketchy stuff (not really instrument grade).
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #207 on: February 24, 2020, 06:27:29 pm »
Maybe a viable UX solution is to only allow triggering at full speed on the unreversed channel.  The other channel can be limited in triggering to what can be viably sustained.
That's how it works right now for 125 MSPS (2x62.5 MSPS).

Even if it executes one instruction per cycle by placing the trigger code in SRAM, one cycle is not enough; it needs to least load a sample, advance a pointer [mod N] for a DMA ring buffer
SIMD instructions process 4 samples at a time in one clock cycle. Otherwise even triggering at 62.5 MSPS would be impossible.

Here is the triggering code in all its assembly beauty https://github.com/ataradov/open-5012h/blob/master/trigger.c

With 250 MSPS the issue is that there is no way to get all the data into the device. The DMA just does not have the performance and misses samples.
Alex
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #208 on: February 25, 2020, 04:16:45 pm »
Here is the triggering code in all its assembly beauty https://github.com/ataradov/open-5012h/blob/master/trigger.c

You can do better by taking advantage of the Cortex saturation flag (Q flag). The following code takes a fraction more than 2 cycles to check 4 buffer values which should allow it to handle real time triggering at 250MSPS (2 x 8bit samples @ 125MSPS). It's a shame the DMA can't maintain that rate.

Presumably the samples from the two ADCs are interleaved in the buffer with alternate samples being bit reversed. Thus the trigger search will only check the two non-reversed buffer entries.

Code: [Select]

int trigger_find_rise_single(uint32_t buf, uint32_t count, uint32_t g_trigger_levels)
{
...
...
...

//Clear the saturation (Q) flag
    MRS r5, APSR
    BIC r5, r5, #(1<<27)
    MSR APSR_nzcvq, r5

   //Set triggers to (256 - trigger_level) (for rising edge) for the two non bit-reversed samples per 4 buffer samples,
   // zero for the two which are reversed.


TrigLoop:
    LDM        %[buf]!, { b0, b1, b2, b3, b4, b5, b6, b7 }
    UQADD8    t, %[triggers], b0 ;Sets saturation (Q) flag if saturation occurs,
    UQADD8    t, %[triggers], b1 ; otherwise leaves Q flag unchanged
    UQADD8    t, %[triggers], b2
    UQADD8    t, %[triggers], b3
    UQADD8    t, %[triggers], b4
    UQADD8    t, %[triggers], b5
    UQADD8    t, %[triggers], b6
    UQADD8    t, %[triggers], b7

    //Repeat as many times as desired to reduce the loop overhead:
    LDM        %[buf]!, { b0, b1, b2, b3, b4, b5, b6, b7 }
    UQADD8    t, %[triggers], b0
    UQADD8    t, %[triggers], b1
    UQADD8    t, %[triggers], b2
    UQADD8    t, %[triggers], b3
    UQADD8    t, %[triggers], b4
    UQADD8    t, %[triggers], b5
    UQADD8    t, %[triggers], b6
    UQADD8    t, %[triggers], b7

    //Check if saturation occured. Note that Q flag can't be tested directly.
    MRS r0, APSR
    TST r0, #(1<<27); Z is clear if Q flag was set
    BEQ TrigLoop    ;Saturation didn't happen so carry on looking for trigger

Triggered:
    //Saturation occurred - search through buffer looking for first entry that reached trigger level
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #209 on: February 25, 2020, 04:45:12 pm »
UQADD8 does not modify Q flag. At least according to the ARM DDI 0403D and a few other places.
Alex
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #210 on: February 25, 2020, 05:38:06 pm »
UQADD8 does not modify Q flag. At least according to the ARM DDI 0403D and a few other places.

It would be pretty silly if it didn't. See section 3.7 of the Cortex-M4 DevicesGeneric User Guide:

https://static.docs.arm.com/dui0553/a/DUI0553A_cortex_m4_dgug.pdf?_ga=2.5155316.61267785.1582642986-542401930.1582303288

[attachimg=1]


Joseph Yiu's book 'The Definitive Guide to ARM Cortex-M3 andCortex-M4 Processors' also states that UQADD8 sets the Q flag.

Personally I find ARM's documentation confusing and poor. For example, there is no definition that I can see of when saturation occurs - is it when the value exceeds the maximum value that can be held by the target or is it when the value matches or exceeds the saturation value? It's actually the former as you'd probably expect but it isn't spelt out.

I raised an error report with ARM about misleading or missing flag information several years ago but got an arrogant 'brush off' response:

Quote
Hi xxxx,

Thanks for pointing out these.

> Errata from external InfoCenter for:
> Cortex-M series processors
> Cortex-M4 Devices Generic User Guide
>
> Home > The Cortex-M4 Instruction Set > General data processing instructions > SSUB16 and SSUB8
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/BABJJACB.html
>
> The description for the SSUB8 and SSUB16 instruction specifically states: "These instructions do not change the flags."
>
> But My understanding is that it sets the GE flags.
>
> This error applies to all the instructions which set the GE flags including SADD16, SSAX. USUB8, UASX etc.
>
> However all these instructions, except SUBB8/SUBB16, do show that GE is affected in the instruction set summary table.

The specific state is for "Condition flags", so no problem here.

> A separate issue is in the load/store instruction timing page:
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/CHDDIGAC.html
>
> Wrt LDM and STM it states: "So, a three element LDM takes 2+1+1 or 5 cycles when not stalled."
>
> So is it 4 or 5 cycles when not stalled? If it could be either then this should be reworded to clarify.

It should be 2+1+1 = 4 cycles. Our documentation team will fix this into our next release. Thanks.

Best regards,

Xuechun Gu
ARM Partner Enablement Group

For documentation, downloads and other useful resources see:
http://www.arm.com/support/

As far as I can see it hasn't been corrected.
« Last Edit: February 25, 2020, 05:43:13 pm by splin »
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2550
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #211 on: February 25, 2020, 06:28:23 pm »
The armasm documentation states "The Q flag is not affected even if this operation saturates.".  This appears to be common for all the parallel saturating instructions.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #212 on: February 25, 2020, 06:30:28 pm »
I will test it later today on the real hardware.
Alex
 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #213 on: February 25, 2020, 06:34:12 pm »
The same document states in table 3-1 that none of the saturating SIMD instructions modify the Q flag. See page 3-6, for example.
Everybody likes gadgets. Until they try to make them.
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #214 on: February 25, 2020, 07:42:11 pm »
The same document states in table 3-1 that none of the saturating SIMD instructions modify the Q flag. See page 3-6, for example.

That's because the ARM documentation is s**t.  The description on the QADD8 instruction on page 3-98 says:

Quote
Condition flags

These instructions do not affect the condition code flags.

If saturation occurs, these instructions set the Q flag to 1.

Given their business model it's pretty piss poor that they can't even document the instruction set properly. Take a look at the GE flags for example.  The instruction set table 3-1 shows some,  but not all the instructions that set the GE flags - USUB8, UADD8, SADD8 but not ssub8.

Much worse is the fact that not one of the actual instruction descriptions show the GE flags being set - the only mention is in the SEL instruction which uses the GE flags.

Personally I don't trust the ARM documentation much and prefer to use Joseph Yiu's book I mentioned earlied. I probably should have pursued my errata request with ARM (in 2017), but the email response gave me the impression that I would have been wasting my time.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #215 on: February 25, 2020, 09:41:21 pm »
The following test code shows that Q flag nor any other flags are changed by uqadd8.
Code: [Select]
  uint32_t a = 0x00050000;
  uint32_t b = 0x00f00000;
  uint32_t apsr = 0xffffffff;
  uint32_t res = 0;

  asm volatile (R"asm(
    mrs    r5, APSR
    bic    r5, r5, #0xf8000000
    msr    APSR_nzcvq, r5

    uqadd8 %[res], %[a], %[b]

    mrs    %[apsr], APSR
    )asm"
    : [apsr] "+r" (apsr), [res] "+r" (res)
    : [a] "r" (a), [b] "r" (b)
    : "r5"
  );

APRS remain 0 for both a,b = 0x00050000,0x00f00000 and a,b = 0x00550000,0x00f00000. The result saturates as expected, but there is no detectable change in flags.

So ARM documentation appears to be correct in this case.

The test was performed on Cortex-M4F (SAM E54).
Alex
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #216 on: February 25, 2020, 10:35:53 pm »
The result saturates as expected, but there is no detectable change in flags.

So ARM documentation appears to be correct in this case.

The test was performed on Cortex-M4F (SAM E54).


That's unfortunate and the documentation does actually say it in the 'Cortex-M4 Devices Generic User Guide'  DUI0553.pdf

On page 3-98 describing the QADD instructions:

Quote
Operation

These instructions add or subtract two, four or eight values from the first and second operands
and then writes a signed saturated value in the destination register.

The QADD and QSUB instructions apply the specified add or subtract, and then saturate the result to
the signed range −2n–1 ≤ x ≤ 2n–1−1, where x is given by the number of bits applied in the
instruction, 32, 16 or 8.

If the returned result is different from the value to be saturated, it is called saturation. If
saturation occurs, the QADD and QSUB instructions set the Q flag to 1 in the APSR. Otherwise, it
leaves the Q flag unchanged. The 8-bit and 16-bit QADD and QSUB instructions always leave the Q
flag unchanged.


To clear the Q flag to 0, you must use the MSR instruction, see MSR on page 3-164.
To read the state of the Q flag, use the MRS instruction, see MRS on page 3-163.

Restrictions

Do not use SP and do not use PC.

Condition flags

These instructions do not affect the condition code flags.

If saturation occurs, these instructions set the Q flag to 1.

I saw the last line which is quite unequivocale but wrong (or at least highly misleading), and missed the note earlier that SIMD versions of the instructions, QADD8 and QADD16, don't change the Q flag. The 32 bit QADD which does support the Q flag is not a SIMD instruction.

The UQADD8 and UQADD16 SIMD instructions have the same behaviour presumably because the SIMD ALU doesn't have the necessary hardware.

It also seems that Joseph Yiu's book is simply wrong in this case:

[attachimg=1]

The ARM instruction set documentation is still piss poor - just not quite as bad as I thought!
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #217 on: February 25, 2020, 10:40:47 pm »
One thing about ARM documentation is that those pseudo-code snippets they provide for each instruction and other functions are actually real code. That code is part of the formal verification process.

Obviously the code may still be edited more than necessary for the document, but in general it is correct despite of what the text says.

I think there is even the whole unmodified text of that pseudo-code published, but I can't remember where I saw it. There was some blog by an ARM engineer who was doing all sorts of fun analysis on that formal model.

This is the blog https://alastairreid.github.io/ A worthwhile read for anyone interested in low level details of ARM stuff.

And here is the link to the actual machine-readable architecture specifications https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools (appears to be only available for A-profile)
« Last Edit: February 25, 2020, 10:47:15 pm by ataradov »
Alex
 

Online Martinn

  • Contributor
  • Posts: 18
  • Country: ch
Re: Reverse engineering FNIRSI-5012H
« Reply #218 on: February 28, 2020, 07:26:44 pm »
Not so long wait... FNIRSI arrived, I changed the processor (as I described earlier, masking+hot air gun), soldered the new one (wave tip LTGW), cut off micro-USB cable and soldered to $2 ST-LINK clone. Programmed with ST-LINK utility and... it works!
Thanks Alex! :-+ :-+ :-DMM :clap:
 
The following users thanked this post: edavid

Online Martinn

  • Contributor
  • Posts: 18
  • Country: ch
Re: Reverse engineering FNIRSI-5012H
« Reply #219 on: February 29, 2020, 05:59:37 pm »
Hmmm - shouldn't there be a grid visible? Somehow my screen looks different to the animated gif george posted earlier!
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #220 on: February 29, 2020, 06:01:36 pm »
The grid should be visible. But it has a very shitty LCD, so it is only visible under certain angles. The grid is actually drawn at the same time as trace, so it should be there on your unit too.
Alex
 

Online Martinn

  • Contributor
  • Posts: 18
  • Country: ch
Re: Reverse engineering FNIRSI-5012H
« Reply #221 on: February 29, 2020, 06:15:16 pm »
You are right, it is there - under a certain angle I can faintly see something... but essentially invisible in regular use. Do you know if the LCD driver has a setting for adjusting it? Maybe gamma set?
Looking a the code
#define GRID_FG_COLOR          LCD_COLOR(200, 200, 200)
looks pretty bright to me, so there has to be something strange with the display.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #222 on: February 29, 2020, 06:21:32 pm »
I don't know. On all my displays it looks pretty bright, you would definitely see it.

The are some display settings in lcd.c, which I just copied from some sample code, since I have no idea what any of them mean. But all displays should be the same, so I have no idea.

Changing the color may be your only real option.
Alex
 

Online Martinn

  • Contributor
  • Posts: 18
  • Country: ch
Re: Reverse engineering FNIRSI-5012H
« Reply #223 on: February 29, 2020, 07:31:06 pm »
Just had a bit of a fight getting the compile to work. Had to install gcc-arm (link you provided), then gnu make, then modify makefile (gmkdir -> mkdir, remove -p option), setup all paths and as final bonus discover that the ST-link tool does not reload a binary if it has changed on disc.
Well, finally it works, I changed the grid to 255,255,255 and now it's perfectly visible. I'll maybe have to change some other colors too.
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #224 on: March 19, 2020, 05:20:15 pm »
Still waiting for GD32F407VGT6s and hot air gun from China.   The hot gun listed here won't ship to Canada.  Another seller took my order but did not really ship, no tracking number and no responses to my messages.  Wasted more than a month in that order.   A second order for a hot air gun was made on Aliexpress, tracking number is not valid yet.   GD32F407 last seen on March 1 in China.  It has not hit Canadian airspace yet.  Would LCSC has a dispute process if the shipment never shows up?

i do have a STM32F407VGT6 development board ordered on Aliexpress at the same time.  That passed Canadian Customs last week.  Expected delivery was March 17, but it has not arrived yet.  I could test the code on the STM32F407.  I would alter to code make use of the on board ADCs for a lower frequency scope with display onto my linux box or replaying onto my 5012H or 016 scope.

Do we know how many time/machine cycles we need to start up a scan on  GD32F407?  If we have some form of delay line we may start the scanning after an interrupt fires off.  How much delay we would need on such delay line?  In that case we can perform more detail time consuming processing after stocking up sufiicient number, say a few thousands, of scans since the VGs have an extra 512KB for data assuming it is fast enough for DMA...

BTW, the probe/front end sucks, at MHz range the 5012H shows more or less the same reading switching the probe from 1X to 10X.  That would be the next project after getting the scans displayed correctly.

Have fun.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #225 on: March 19, 2020, 08:23:24 pm »
Would LCSC has a dispute process if the shipment never shows up?
No idea. I never had issues with them.

I could test the code on the STM32F407.  I would alter to code make use of the on board ADCs for a lower frequency scope with display onto my linux box or replaying onto my 5012H or 016 scope.
That's going to be A LOT of work. It would be easier to start from scratch rather than alter that code to use internal ADC.

Do we know how many time/machine cycles we need to start up a scan on  GD32F407?  If we have some form of delay line we may start the scanning after an interrupt fires off.  How much delay we would need on such delay line?  In that case we can perform more detail time consuming processing after stocking up sufiicient number, say a few thousands, of scans since the VGs have an extra 512KB for data assuming it is fast enough for DMA...
I'm not sure what you mean here. VGs have more flash, not SRAM.
Alex
 

Online Martinn

  • Contributor
  • Posts: 18
  • Country: ch
Re: Reverse engineering FNIRSI-5012H
« Reply #226 on: March 20, 2020, 07:06:23 am »
My GD32 arrived very quickly from LCSC, that was before corona. But most passenger flights are now shut down and air freight that was transported along with these flights is grounded. Air shipping costs have risen up to 10x I have read.
If you are looking for a backup for the hot air station, you could use the chip quik alloy.
 

Offline robca

  • Regular Contributor
  • *
  • Posts: 131
Re: Reverse engineering FNIRSI-5012H
« Reply #227 on: March 20, 2020, 06:19:44 pm »

I could test the code on the STM32F407.  I would alter to code make use of the on board ADCs for a lower frequency scope with display onto my linux box or replaying onto my 5012H or 016 scope.
That's going to be A LOT of work. It would be easier to start from scratch rather than alter that code to use internal ADC.

Agree. There already are quite a few STM32F407 internal ADC oscilloscope projects that can be found with a quick Google search (e.g. http://dso.naftilos76.com/dl/tutorial.pdf). The ocde for those is available, and changing the screen driver and buttons to map the device you have seems a better option. Out of curiosity (I'm following this project but don' t have the hardware), how hard would it be to re-route the analog input signal to the main CPU? That also seems gnarly and require cutting traces and adding bodge wire, as far as I can tell
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #228 on: March 20, 2020, 06:27:49 pm »
how hard would it be to re-route the analog input signal to the main CPU? That also seems gnarly and require cutting traces and adding bodge wire, as far as I can tell
It would definitively require cutting traces. There are not too many free pins left. I don't know if one of them has ADC function. I think one of the ADC data pins would have to be cut and routed to the buffer opamp.

But I really see no point in doing that.
Alex
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #229 on: March 23, 2020, 04:47:08 pm »
LCSC said they would check.  Tracking showed FD32's were leaving for Toronto on March 1 but have not showed up in Canadian Customs yet.   That is my first LSCS order.

STM development board had passed through Customs.  Last epacket took almost a month from west to east after clearing customs in B.C before that it used to take only a few days.   

Second hot air gun just showed up on tracking 20 days after order.  It is supposed to be shipped via epacket but really via 4PX instead.   

Probably would be a while before I can do anything on my 5012H.  :=\ 

If my 5012H resets or freezes after everything is ready.  That gives me a good reason to tear it down. 

You are saying we cannot use data flash to store captured data,  or we can only DMA into ram.  That is probably true.  I haven't looked at the instruction set yet.  I'll look into how much ram we need when my STM32F407 arrives. 

Thanks.

 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #230 on: March 23, 2020, 10:01:02 pm »
You are saying we cannot use data flash to store captured data,  or we can only DMA into ram.
Flash is VERY slow and has limited number of write cycles.
Alex
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2550
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #231 on: March 24, 2020, 08:29:24 am »
You are saying we cannot use data flash to store captured data,  or we can only DMA into ram.  That is probably true.  I haven't looked at the instruction set yet.  I'll look into how much ram we need when my STM32F407 arrives. 

Thanks.

You could use flash to store a waveform after it's been captured, but you couldn't possibly store directly to flash during a capture.  This is something you could do for a datalogger with a few samples per second, not for 100+ MS/s.
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #232 on: April 02, 2020, 04:44:50 am »
Still no tracking update on my order of FD32F407's since March 1.  It is stuck in China somewhere.  Got a refund from LCSC today.  Even the STM32F407 development board hasn't showed up.  That one passed Canadian Customs March 11 and had an experted delivery of March 17.   My hot air station has not reached Canadian air space either.   Hence I won't be able to experiment on the 5012H any time soon. 

I did receive my ebay order of Si5351A breakout board and be able to test the 5012H with sinewave from 8K to over 100MHz. That works better than my old sign gen from the 70s. 

The front end of my 5012H sucks but is still able to show a sinewave up to around 100MHz if we aren't serious about the ampitude reading.  The 3dB point is way way below 100MHz.   

My 5012H restarts/hangs even with no probe connected on changing input gain or timebase.   To workaround that I have to put trigger in normal mode while changing gain or timebase and then put it back to auto trigger.  If the waveform is too complicated, it may also restarts/hangs on pressing the auto button.   

That may have something to do with the auto process.      You did not notice this issue as you probably swapped out the MCU right away.    However nobody else hit that is a bit strang  Perhaps I got a lemon after all, something like my 5012H is abnormally noisy.     Nothing works out so far. 
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #233 on: April 02, 2020, 05:01:54 am »
Yes, it is probably not the best time for reliable shipping.

It would show something for a 100 MHz signal, of course. But there is no real point. All it really tells you that there is "something" on the input.

I personally have not run it nearly enough to tell if stock firmware has issues. I probably used it for less than 30 minutes before it became clear that it is a joke. But in that time I have not seen any locking up issues.

How noisy it actually is? Do you have pictures for a shorted input?
Alex
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #234 on: April 02, 2020, 08:21:37 pm »
I think it is the signal/noise it picks up during gain or timebase switch.  With no probe connected, sometimes it shows a big step on the screen when pressing the arrow buttons.  Grounding the input did not help.

On reset, it just blanks and then shows the start up screen.  When it hangs, usually nothing special on screen before freezes.   I can't realy tell what happens by reading the screen.

With probe connected, touching the tip with my finger to pick up some noise, it often hangs/reset when I press the auto button.    If the input is simple repetative, auto survives. 

It seems like the MCU hits some errors when working hard or takes too long that a watchdog kicks in.  Change gain/timebase manually or automatically may make the MCU work too hard.

 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #235 on: April 04, 2020, 10:11:20 pm »
Vidioes would be too big for the forum.   Happened to be frozen with the ripple displayed.  I took the picture.

Input was grounded with probe set to x1.  Usually the input gain setting does not matter, the noise picked up would not increase with higher gain setting.  Actually it is less likely to freeze or reset with input set at the maximum gain. 

The worst zone is around 100ns to 200ns time base. On a bad day like today, it hangs/restarts almost everytime stepping 100/200ns timebase.  You would see it ripples at 100ns or 200ns with no input.  Sometimes it picks up a pulse of several ns with timebase set at 6ns, but usually it is clean.    I tried putting the whole thing inside an antistatic bag, it does not help.  The noise is somewhat internal.    You mentioned that the unit is overclocked perhaps mine isn't capable in overclocking.  The crystal on mine is running at 20MHz.   

On a good day, it does not freezes/restarts that ofen.  Let me try putting it in a fidge to see if lowering its temperture helps.  Currently my 5012H can only operate reliably as a low Mhz scope.  :(

BTW, nothing arrives.  Aliexpress refunded the STM32F407 development board as well. 
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #236 on: April 05, 2020, 01:26:55 am »
Yes, this looks like overclocking is not working our so well. I don't remember it being that noisy. But the fact that it does not change with gain, means that it is added before the ADC after all the input dividers.

I'm not sure if locking and noise are related.
Alex
 

Offline serniko97

  • Newbie
  • Posts: 1
  • Country: it
Re: Reverse engineering FNIRSI-5012H
« Reply #237 on: April 05, 2020, 11:39:10 am »
Hi, I'm new to the forum.
I read all the thread and the GitHub repository as well.

I think that what you are doing is amazing but, at least to me, it's not clear what are the benefit of your firmware over the original at this point of the work and what would be in the future.

Often on GitHub for beta projects there is a checklist of features that have been added and what comes next. Something like this would be extremely helpful.

I love your work, keep it up ;)
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #238 on: April 05, 2020, 05:49:47 pm »
It is better because it at least does not have a single shot trigger bug, which makes the original unusable for a lot of cases.

I have no significant work planned for this. I've allocated as much time as I can at this time. I need to work on other things too.

I'm also not very happy with the quality of the hardware, so without redesigning the hardware, there is very little point in working on the software. For this kind of device the hardware must be much simpler.

For now one significant benefit over the original firmware is that you can actually add your own code, if you are so inclined.
Alex
 
The following users thanked this post: voltsandjolts

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #239 on: April 09, 2020, 04:03:04 am »
Lowering the temperature of 5012H did not help.  It still locked up or reset after putting it in a ridge for several hours.   

My hot air gun finally arrived today, 36 days after the 2nd order.  Heating the 5012H up seemed making it more stable for a while.  I amost thought the issue was fixed, but it's not.

Now it was consistent in locking up or reset when we put the input at the lowest gain 2 settings i.e. 5V and 10V (x1) at timebase at 50ns or shorter.  If it did not lockup or reset, the 10V range sometimes picked up a few cycles of sinewave of around 62MHz at 6ns timebase. 

With no probe connected or with probe connected and grounded at x1 or x10 did not make any difference.  The amptitude of the sinewave was way too high to be coming from the probe. 

If we used a higher gain setting, 2V or above, including 100mV and 50mV, 5012H survived all timebase setting including 6ns and did not pick up the 62MHz noise.  This is the reverse of what we expected if the noise is coming from the input.

It suggests there may be a noisy grounding in the front end since in 5V/10V settings the input to the amplier sitting in front of the ADCs would be closer to ground Or there may be something wrong with switches themselves.   The input switches seem OK at DC with lower speed timebase.    Then with this "wetting" of -8V on the probe, I found that the 5V and 10V gain setting could survive the 6ns timebase.   The 5012H uses optical couplers, would a photo transister work correctly as a simple high frequency switch before saturation, i.e. without any "wetting"?   In the good old rotary selectors, we don't have to worry about that.   We have more relays in the older version, now we cut it down to one....

Anyway the 5012H front end sucks.  Even at DC I can tell that the probe isn't giving me 1/10 reading on 10x. 

I remember seeing a circuit drawing of the input attenuators/selectors. Do you know which page is it on?  I'll troubleshoot the 5V and 10V switches.  Don't have another scope capable at 6ns range, but I can do some bypassing.   
 
Lockup/reset on my 5012H may be a firmware bug or hardware related.  It seems to happen on handling more complex and higher frequency waveform.   The 62MHz noise picked up is not a continuous sinewave, its harmonics may be out of range.  I guess that noise is driving the firmware/hardware nuts more often than showing up on the display.

 


 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #240 on: April 09, 2020, 04:24:09 am »
Front-end schematic is here https://github.com/ataradov/open-5012h/blob/master/doc/frontend.jpg

I've been using this scope some more due to working from home and being lazy to pull out the real scope for small tasks. I kind of like the form factor, but I'm thinking of completely redoing the front end to a more fixed design within the same board layout. Something that would only expect 10X probe and will only accept -1 V to +1 V range or even smaller, but in a single vertical setting. It will hopefully  make tuning it much easier. And it is only suitable for microcontroller debugging type use anyway, so there is no particular need for super wide range.
Alex
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #241 on: April 09, 2020, 02:12:48 pm »
Ah there it is.   Thanks.

The scope input is really "grounded" via the refenence.   That may be why you warned about using the scrope while charging.

After my last post, I aso noticed shifting the baseline down in auto mode stabilized the 5V and 10V mode such that they survived 6ns. 

Since reference is controlled via ADC.  That strange behaviour actually makes sense.  The effect of shifting the base line is similair to applying "wetting" externally.   Actually I found the noise shifting from one voltage range to another by changing the vertical position of the baseline. 

It suggests that my 5012H probably has a noisy reference.   

Not sure if I can do a lot about it, because when we hit the auto button in auto mode, it centers the baseline as well as changes the input range during the auto process.  If we stabilize reference too much, the auto button may not work.   

Changing the input range and reference during the auto process is a dangerous move.  If it hits something non-linear, the process may not converage.   If it blows up on time or value the unit may lockup or reset.    The optical switches could be non-linear during switchng before they saturate. 

Anyway that is a theory,  but I have at least a workaround now.   Just shift the baseline down first if it locks up or resets.

I won't do anything too drastric as none of my FD/STM32F407 orders show up.    I still hope they would.

Take care and stay happy.













 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #242 on: April 09, 2020, 02:55:11 pm »
When lowering the baseline is better, it may mean the more current we draw from the DAC makes it noiser... 
 

Offline wasp09

  • Contributor
  • Posts: 22
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #243 on: May 17, 2020, 07:09:36 pm »
Just like to mention that the USB cable came with 5012H isn't a regular usb cable.  I could not use that cable to connect my STM32F407 development board to my computer. 

BTW I ordered the cheapest DIYmore STM32F407 development boad that just extends the SMD pins out with minimum add-ons for power supply and clock generation.    There is a microSD connector but no USBserial chip.   When it arrived 3 months after ordering, it turned out worse than expected.  It has a STM32F407VET6 instead of the STM32F407VGT6 shown on the description and reviews... 

I need usb support trying to do hello world as there isn't a display.  It's harder to find projects for this bare board than arduino.  Finally I found a port of miropython.  While I was trying to uploading the build via ST-link, it turned out that the STM32F407 bootloader actually supports uploading via usb by emulating a DFU device.   Took me a while to figure out how boot1 and boot2 pins work.  Both are pulled high on that board, I need a jumper, not supplied with the board for uploading and normal operation. 

I totally agree with you, triggering on the 5012H stock firmware is miserable.   Even auto triggering has problems handling petty slow repeatitive waveform generated by DueArbitraryWaveformGenerator on the due. 

If you are sure that we cannot erase the stock firmware, I'll swap out the GD32F407... eventually when I have confidence with my heat gun.  :)

I wonder if PA11 and PA12 are available on the 5012H for an usb connector.    That would be useful for data transfer (and FW uploading if we untie bootx or force it to bootloader via software.)

Cheers.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #244 on: May 17, 2020, 07:21:35 pm »
The cable that comes with it is a power-only cable. This is pretty typical for this kind of devices.

There is no obvious way to erase the firmware. I don't think there will be one found.

PA11 and PA12 are available, but realistically there is no need for data transfer. Firmware update is a more useful case.
Alex
 

Offline rigol52

  • Contributor
  • Posts: 37
  • Country: si
Re: Reverse engineering FNIRSI-5012H
« Reply #245 on: June 17, 2020, 03:16:56 pm »
Source code is now available here https://github.com/ataradov/open-5012h

I've recently got FNIRSI-5012H, and it is a very neat device. Once again, I would not use it as a primary scope, but it is a nice addition to the multimeter.
It has a fast boot time and, finally, sane and intuitive controls from the keyboard.


Great effort Ataradov. Thank you.

I hope producer will follow you on  sensitivity battle field.

Tablet Scope FNIRSI 1013D vertical sensitivity of 50mV/div is really unacceptable poor.

Par example competitor Micsig last tablet model Micsig STO1152C Plus has 100 times better vertical sensitivity of 0.5mV/div.

Even micro toy DSO112A has better vertical sensitivity of 2mV/div.

One more thing that need to be improved.
 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #246 on: June 17, 2020, 08:10:49 pm »
I'd not call the Micsig a competitor ;) They're in a different class, price and everything... It's 100x better but also 100x 5x more expensive...
Everybody likes gadgets. Until they try to make them.
 

Offline Vovk_Z

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: ua
Re: Reverse engineering FNIRSI-5012H
« Reply #247 on: June 17, 2020, 08:34:44 pm »
Quote
Par example competitor Micsig last tablet model Micsig STO1152C Plus has 100 times better vertical sensitivity of 0.5mV/div.
I'm not sure STO1152 is a competitor because it costs about $400  or more.
 

Offline rigol52

  • Contributor
  • Posts: 37
  • Country: si
Re: Reverse engineering FNIRSI-5012H
« Reply #248 on: June 18, 2020, 03:29:07 am »

 They're in a different class .........It's 100x better but also 100x 5x more expensive...


Good, following this 5x logic, its vertical sensitivity should be 2.5mV/div and not degrading 50mV/div.

As I wrote, even 3x cheaper micro toy DSO112A (different class) has better vertical sensitivity of 2mV/div.

Trying to observe small signal it is a big difference.
« Last Edit: June 18, 2020, 03:37:05 am by rigol52 »
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2550
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #249 on: June 18, 2020, 11:30:24 am »

 They're in a different class .........It's 100x better but also 100x 5x more expensive...


Good, following this 5x logic, its vertical sensitivity should be 2.5mV/div and not degrading 50mV/div.

As I wrote, even 3x cheaper micro toy DSO112A (different class) has better vertical sensitivity of 2mV/div.

Trying to observe small signal it is a big difference.

I agree the vertical sensitivity is poor, but you are missing the point, the STO1152 is not a competitor.
 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #250 on: June 18, 2020, 12:14:40 pm »

 They're in a different class .........It's 100x better but also 100x 5x more expensive...


Good, following this 5x logic, its vertical sensitivity should be 2.5mV/div and not degrading 50mV/div.

As I wrote, even 3x cheaper micro toy DSO112A (different class) has better vertical sensitivity of 2mV/div.

Trying to observe small signal it is a big difference.

5mV/div according to the spec, and those are real 5mV/div? Or just digitally scaled up?
Everybody likes gadgets. Until they try to make them.
 

Offline rigol52

  • Contributor
  • Posts: 37
  • Country: si
Re: Reverse engineering FNIRSI-5012H
« Reply #251 on: June 19, 2020, 07:36:17 am »

5mV/div according to the spec, and those are real 5mV/div? Or just digitally scaled up?


You mean DSO112A?

5mV/div was previous model, which was year or two ago improved to 2mV/div.


"DSO112A Upgrade Version 2MHz Touch Screen TFT Digital Mini Handheld Oscilloscope With Battery

DSO112A is an upgraded model of DSO112 with re-designed schematic and PCB. Due to the new design
 this oscilloscope becomes more accurate and reliable.
As high as 2mV/div sensitivity and ultra low background noise made the device particularly useful for
measuring weak signals. Up to 24 presets with customizable titles allow setups be retrieved in seconds."


 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #252 on: June 19, 2020, 07:39:06 am »
Yes, and the next year model would be 1 mV/div. This is not realistic in any way, so what's the point of discussing it? I can multiply numbers til the cows come home, but there is no chance any of those things have front-end good enough for this sensitivity. 
Alex
 

Offline rigol52

  • Contributor
  • Posts: 37
  • Country: si
Re: Reverse engineering FNIRSI-5012H
« Reply #253 on: June 19, 2020, 12:07:39 pm »

Yes, and the next year model would be 1 mV/div.
This is not realistic in any way, so what's the point of discussing it?


Maybe 1mV next year, I don't know. Not really interested. Nevertheless.

If you live in world of logic analyzer, then probably vertical sensitivity is not theme of discussing.

But if you live in world of oscilloscope and small signals, then vertical sensitivity is very important parameter.

50mV/div is simply not acceptable (despite other technical data of FNIRSI-5012H are adorable)

If your cows are all home, then look at this 40 euro mini scope toy, it is really funny:

(Rigol DG1011 is not able to go lower than 4mV pp, and firmware of my old DSO112A still start at 5mV)


« Last Edit: June 19, 2020, 12:10:52 pm by rigol52 »
 
The following users thanked this post: GeorgeOfTheJungle

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #254 on: June 19, 2020, 03:47:45 pm »
Yes, and the next year model would be 1 mV/div. This is not realistic in any way, so what's the point of discussing it? I can multiply numbers til the cows come home, but there is no chance any of those things have front-end good enough for this sensitivity.

The bandwidth of these pocket scopes is not very high. It's much easier to achieve high sensitivity in a 2MHz front end than in a 200MHz front end.
Everybody likes gadgets. Until they try to make them.
 

Offline gf

  • Regular Contributor
  • *
  • Posts: 230
  • Country: de
Re: Reverse engineering FNIRSI-5012H
« Reply #255 on: June 19, 2020, 03:50:58 pm »
Yes, nice toy ;) I have one, too. IIRC, they simply use a TL04x or similar for the frontend amp. Obviously sufficient for the offered 2mV/div, but don't forget, the bandwith is pretty limited, too. At high bandwidths, the same is no longer that easy to achieve, and not at all at the same low cost.
 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #256 on: June 19, 2020, 03:57:14 pm »

 They're in a different class .........It's 100x better but also 100x 5x more expensive...


Good, following this 5x logic, its vertical sensitivity should be 2.5mV/div and not degrading 50mV/div.

As I wrote, even 3x cheaper micro toy DSO112A (different class) has better vertical sensitivity of 2mV/div.

Trying to observe small signal it is a big difference.

That is nonsense. The DSO112A has 2mV/div but only due to its tiny bandwidth. Increase the bandwidth to 150MHz and see if you can achieve 2mV/div easily.
Everybody likes gadgets. Until they try to make them.
 

Offline gf

  • Regular Contributor
  • *
  • Posts: 230
  • Country: de
Re: Reverse engineering FNIRSI-5012H
« Reply #257 on: June 19, 2020, 04:50:27 pm »
That is nonsense. The DSO112A has 2mV/div but only due to its tiny bandwidth. Increase the bandwidth to 150MHz and see if you can achieve 2mV/div easily.

Well, 2mV/div may be achievable - if you don't mind that the signal drowns in the noise floor :-DD

The point ist just, everybody wants a scope with the highest bandwidth and sampling rate one can get for the money - and then they complain about limited sensitivity and too much noise. However, for some use cases one does not need the bandwidth at all, but rather a better sensitivity. In the low-cost sector usually one cannot get both. Even the 20MHz BW limit is usually not sufficient to drop the noise to a level which were suitable for a higher sensitivity than say 5mV/div, but the scope would rather need a dedicated low-bandwith pre-amp for the high-sensitivity ranges (which is not an option for a low(est)-cost device due to extra cost).
« Last Edit: June 19, 2020, 06:43:10 pm by gf »
 

Online thinkfat

  • Supporter
  • ****
  • Posts: 1266
  • Country: de
    • Matthias' Hackerstübchen
Re: Reverse engineering FNIRSI-5012H
« Reply #258 on: June 19, 2020, 08:41:37 pm »
Well, that's the real reason why a 500MHz scope has a 20MHz bandwidth limiter: If you want to measure e.g. power supply ripple in the 10mV range, 500MHz bandwidth is not really an advantage, rather the opposite. SMPSUs usually don't switch in the high MHz, more with a couple hundred kHz. That limits the dirt they output above 20MHz.
Everybody likes gadgets. Until they try to make them.
 

Offline gf

  • Regular Contributor
  • *
  • Posts: 230
  • Country: de
Re: Reverse engineering FNIRSI-5012H
« Reply #259 on: June 19, 2020, 09:30:21 pm »
Well, 2mV/div may be achievable - if you don't mind that the signal drowns in the noise floor :-DD

I have certainly exaggerated a bit ;) If the signal is eligible for averaging, then 2mV/div is well feasible, too, on a say 100MHz scope at full bandwidht, even if it is as noisy as my Hantek 6xx4 (-> about 300uV RMS, or ~1.5mVpp, @2mV/div). When averaging e.g. 64 frames, the noise drops to ~0.2 divpp, and then 2mV/div starts becoming usable, too.

Btw, does the FNIRSI-5012H actually have enough resources (particularly memory) to allow averaging?
« Last Edit: June 19, 2020, 09:44:26 pm by gf »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #260 on: June 19, 2020, 09:48:11 pm »
Btw, does the FNIRSI-5012H actually have enough resources (particularly memory) to allow averaging?
It basically has 256 Ksamples of DMA-accesible memory and may be 32Ksamples for a storage buffer that is only CPU-accessible.

Doing any averaging you would be sacrificing number of samples a lot. You will also run into performance issues.

The default firmware actually tries to do some averaging at high ADC clocks, but they do it to hide that their actual sampling rate is bad.

Those things are not high performance devices. I'm not sure why people want them to be.
Alex
 

Offline gf

  • Regular Contributor
  • *
  • Posts: 230
  • Country: de
Re: Reverse engineering FNIRSI-5012H
« Reply #261 on: June 19, 2020, 10:36:21 pm »
Btw, does the FNIRSI-5012H actually have enough resources (particularly memory) to allow averaging?
It basically has 256 Ksamples of DMA-accesible memory and may be 32Ksamples for a storage buffer that is only CPU-accessible.
Doing any averaging you would be sacrificing number of samples a lot. You will also run into performance issues.
The default firmware actually tries to do some averaging at high ADC clocks, but they do it to hide that their actual sampling rate is bad.
Those things are not high performance devices. I'm not sure why people want them to be.

If there is not enough memory to keep N buffers for N-fold averaging, then a less memory-hungry alternative might be a single accumulator buffer and exponential moving average (e.g. Anew = Aold - Aold/16 + newSample/16).

Assumedly the display width is not more than 500..1000 pixels, so I guess any samples beyond that are just recorded for zooming/panning anyway?

Btw, if I remember correctly, you also own a Hantek 2000. Do you see any areas where the FNIRSI-5012H outperforms the Hantek 2000, or do you think that the Hantek 2000 is generally still one level above the FNIRSI? [ Like the FNIRSI, I guess that the Hantek could likely also benefit from an improved firmware. ]
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 6799
  • Country: us