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

0 Members and 1 Guest are viewing this topic.

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3796
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #375 on: April 21, 2021, 12:25:06 pm »
Are you going to look at sine waves only?

A digital clock waveform can be "decently" recognized even with just the first five harmonics, assuming you cannot do Sync interpolation, with 5Mhz of bandwidth you can decently recognize a clock waveform of 1Mhz

it should be enough if you just need to quickly check if a GPIO is start moving, the baud rate of a uart (up to 115200bps < 150Khz), and simple tasks like these.

One week ago I ordered the 10Mhz FNIRSI DSO. For me, it's more than decent for these tasks.
« Last Edit: April 21, 2021, 02:04:25 pm by DiTBho »
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline paulc

  • Contributor
  • Posts: 32
  • Country: il
Re: Reverse engineering FNIRSI-5012H
« Reply #376 on: April 22, 2021, 05:34:24 am »
Hi,
When it will arrive, please write here your impressions and a report about the DSO, please.
 

Offline petrenn

  • Contributor
  • Posts: 12
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #377 on: November 04, 2021, 02:32:27 pm »
Hello Alex, hope you're well!

I've recently purchased one of those 5012H scope from Amazon (under Yapook brand but sees the same and the other ones out there) strictly for portability and simple up-to-10MHz measurements but the fact I can't use the single and normal triggering is just disappointing...

I found your post and it gave me hopes!

I know this post hasn't been updated in a long time and actually went thru all replies trying to figure out how to use your firmware - for which, like the other users I am thankful you worked on.
I'm not a software guy- I'm actually a hardware eng with some limited coding experience and I was hoping you could post the binary files for the GD32F407VET6 device I just ordered from LCSC.com (maybe on the github using the latest revision with all the patches?. I know there were some attached but since posted, I've seen you made a few updates/fixes to the code)

I have a j-link programmer and it appears it supports the device family and was hoping to simply program just the binary.

Also a couple of more questions (as I might have missed the answers in the long post replies):

- The one function I was hoping your firmware fixed and I really need is the single and normal triggering issue. Is that the case?
- It is a little unclear on the programming documentation of whether I need to supply power to the board from the programmer or the power is coming from the scope battery. The pics suggests the board is powered by the battery and the programmer only connects the SWC and SWD lines and GND. Is that correct?

Many thanks,

Nick-

 

Offline ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #378 on: November 04, 2021, 03:15:23 pm »
Here are the binaries built from the most recent code.

- The one function I was hoping your firmware fixed and I really need is the single and normal triggering issue. Is that the case?
Yes, triggering is way better than in the stock firmware, and realistically it is as good as it can be on this hardware. This was the area that took the most time to develop.

- It is a little unclear on the programming documentation of whether I need to supply power to the board from the programmer or the power is coming from the scope battery. The pics suggests the board is powered by the battery and the programmer only connects the SWC and SWD lines and GND. Is that correct?
I used the battery for power, only connecting SWD pins and ground. I see no reason it would not work with externally supplied power.  For me it was more of a hassle, since you need to supply 5V though USB. It is just easier to keep the battery attached.
Alex
 
The following users thanked this post: MarcosL

Offline petrenn

  • Contributor
  • Posts: 12
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #379 on: November 04, 2021, 03:46:20 pm »
Oh wow- thanks for the quick reply and help Alex! Much much appreciated!

Nick-
 

Offline petrenn

  • Contributor
  • Posts: 12
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #380 on: November 26, 2021, 12:33:39 am »
Alex,

You talk about calibrating, post chip-change in both single channel and dual channel mode. Dual Channel?? there is only one channel on this scope. Am I missing something?

Many thanks,

Nick
« Last Edit: November 26, 2021, 12:40:04 am by petrenn »
 

Offline ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #381 on: November 26, 2021, 01:12:01 am »
The ADC is actually dual channel with both channels connected to the same input. At the fastest sampling rate the channels are interleaved so that each channel runs at half the sample rate. And even though they both sample the same signal, there are differences in the samples.
Alex
 

Offline petrenn

  • Contributor
  • Posts: 12
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #382 on: November 26, 2021, 01:52:50 pm »
The ADC is actually dual channel with both channels connected to the same input. At the fastest sampling rate the channels are interleaved so that each channel runs at half the sample rate. And even though they both sample the same signal, there are differences in the samples.

Ah - ADC channels - makes sense. Thank you for clarifying it, Alex!
Nick-
 

Offline petrenn

  • Contributor
  • Posts: 12
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #383 on: November 26, 2021, 04:35:52 pm »
Quote
I used the battery for power, only connecting SWD pins and ground. I see no reason it would not work with externally supplied power.  For me it was more of a hassle, since you need to supply 5V though USB. It is just easier to keep the battery attached.

Alex, sorry, need to come back to this. So according to your github description I also need to also supply external 3.3V power to the programmer, correct?

I think you mentioned the existing chip cannot be programmed but can it be read? Before I replaced the chip I wanted to be sure my programming interface connections work so I tried connecting my Jlink as follows:

- SW to their respective pins on the scope board via USB connector
- GND to GND of the programmer
- Scope Battery connected to the scope board
- power up with F2 pressed to stop the ADC acq (LCD is off as you said)
- tried to connect to target - it wasn't successful.

Should I assume that connection is not possible if the chip is locked. If not what else am I missing. I know above connections are correct. But if the connections are correct perhaps I am missing the 3.3V external source to the programmer? Although it suggests Reset is high:
(Also, this particular JLINK programmer is actually supplying 3.3V on the voltage pin instead of expecting it - like with the original JLink - which is handy when programming as it does not require the target to be powered when connected)

Connecting ...
 - Connecting via USB to J-Link device 0
 - J-Link firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
 - Device "GD32F407VE" selected.
 - Target interface speed: 4000 kHz (Fixed)
 - VTarget = 3.261V
 - RESET (pin 15) high, but should be low. Please check target hardware.
 - RESET (pin 15) high, but should be low. Please check target hardware.
 - RESET (pin 15) high, but should be low. Please check target hardware.
 - RESET (pin 15) high, but should be low. Please check target hardware.
 - RESET (pin 15) high, but should be low. Please check target hardware.
 - RESET (pin 15) high, but should be low. Please check target hardware.
 - RESET (pin 15) high, but should be low. Please check target hardware.
 - RESET (pin 15) high, but should be low. Please check target hardware.
 - ERROR: Failed to connect.
Could not establish a connection to target.

Many thanks,

Nick-


« Last Edit: November 26, 2021, 04:44:47 pm by petrenn »
 

Offline ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #384 on: November 26, 2021, 04:51:19 pm »
Alex, sorry, need to come back to this. So according to your github description I also need to also supply external 3.3V power to the programmer, correct?
Only if your programmer uses level shifters on the pins to support various interface voltages.

In my case, I used 3.3V-only  programmer, so I did not need to connect anything. J-Link does have those level shifters, so you need to supply it with the interface voltage. It can be taken from the target (ideally), or just from an external source. 

Did you modify your J-Link to provide the voltage? It is handy if the target is not powered by its own power, and it is dangerous when connecting to the target that is powered.

I have a couple of Atmel-ICE programmers modified to supply power, but I add a switch that lets me switch back to the original configuration.

I think you mentioned the existing chip cannot be programmed but can it be read?
No, the existing chip is locked entirely. They used the highest locking levle that disconnects SWD interface. There is no recovery from that mode.

- RESET (pin 15) high, but should be low. Please check target hardware.
Your attempt is failing for a different reason. J-Link controls the state of the reset pin it drives. In this case we are not using reset, so you'll need to figure out how to tell J-Link to not care about it.
Alex
 
The following users thanked this post: MarcosL

Offline petrenn

  • Contributor
  • Posts: 12
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #385 on: November 26, 2021, 09:26:10 pm »
Quote
Your attempt is failing for a different reason. J-Link controls the state of the reset pin it drives. In this case we are not using reset, so you'll need to figure out how to tell J-Link to not care about it.

Thank you Alex; That is what I thought. The MCU appears to have NRST on pin 14. If I connect the NRST from the programmer to that pin in theory it should work. Isn't that true?

 

Offline ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #386 on: November 26, 2021, 10:11:24 pm »
It will work with a new MCU. But there must be an option  to ignore reset in J-Link software. Reset is not mandatory for programming.

It will still do nothing for the stock MCU.

Alex
 

Offline petrenn

  • Contributor
  • Posts: 12
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #387 on: November 26, 2021, 10:15:21 pm »
OK I will go ahead and replace the MCU. That part is the easy part fort me :D
 

Offline petrenn

  • Contributor
  • Posts: 12
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #388 on: November 27, 2021, 05:46:06 pm »
Alex, I replaced the, MCU and managed to program but I now get a Flash Error on the screen, Any idea what might be wrong?
It verifies properly after programming and also tried lowest speed at 600kHz
« Last Edit: November 27, 2021, 06:04:53 pm by petrenn »
 

Offline petrenn

  • Contributor
  • Posts: 12
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #389 on: November 27, 2021, 06:55:46 pm »
Fixed. Looks like they changed the SPI flash and the code was looking for the old one. Here is the code patch for the flash.c file:


diff --git a/flash.c b/flash.c
index bc86b52..2ccc4fb 100644
--- a/flash.c
+++ b/flash.c
@@ -68,7 +68,7 @@ static bool flash_test(void)
   id2 = spi_write(0);
   HAL_GPIO_CS_set();
 
-  return (id0 == 0xef && id1 == 0x40 && id2 == 0x17);
+  return (((id0 == 0xc8) || (id0 == 0xef)) && id1 == 0x40 && id2 == 0x17);
 }
 
« Last Edit: November 27, 2021, 07:26:55 pm by petrenn »
 

Offline ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #390 on: November 27, 2021, 06:59:54 pm »
The flash is not used for anything anyway, so the whole flash test can be removed. I just left it there as a hardware test.
Alex
 

Offline petrenn

  • Contributor
  • Posts: 12
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #391 on: November 27, 2021, 07:28:27 pm »
True, though as it is right now, it does stop it from running so just in case. Gone thru calibration right now and it works really well.

Many thanks Alex! Your efforts made this tool usable.

In summary:
- My initial programming issues were related to the USB connector. The unit programmed fine using Jlink connecting only the SWD, SWCK and GND no other settings required.
- The Flash error was due to the fact that the manufacturer changing flash. Once fixed in the code it came up fine

Nick-
« Last Edit: November 27, 2021, 09:21:52 pm by petrenn »
 

Offline petrenn

  • Contributor
  • Posts: 12
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #392 on: November 28, 2021, 03:19:35 pm »
Sorry to bother again, Alex So I've been playing a bit with the scope. I have noted three issues:

- Occasionally I get a timer overflow error on the screen and the only cure is a power cycle. I am unsure what combination of keys causes it but I do know it is a combination of keys used
- Also often the scope freezes especially when I use the vertical scale/ up and down buttons. Again the only cure is a power cycle. This one is also caused by a combination of keys.
- While the left section of the bottom bar shows the vertical and respectively horizontal scale, I am assuming  the right section should be the values measured (amplitude and respectively frequency of the waveform in seconds but they don't seem to work. I changed the amplitude and frequency and they are not changing. (It would be nice if I could select between seconds and hertz so I can see the frequency instead)

Am I missing something? Also is it possible to add the frequency measurement as this a function I always use when I work on automotive projects  where I'm always trying to get the PWM frequency of certain modules.

Thank you very much,
Nick-

 

Offline ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #393 on: November 28, 2021, 05:46:33 pm »
- While the left section of the bottom bar shows the vertical and respectively horizontal scale, I am assuming  the right section should be the values measured (amplitude and respectively frequency of the waveform in seconds but they don't seem to work. I changed the amplitude and frequency and they are not changing. (It would be nice if I could select between seconds and hertz so I can see the frequency instead)

Copy from GitHub:

Yeah, I've seen that time error, and I have no idea why it happens. I suspect it has something to do with gross overclocking of the device (168 MHz in datasheet, 250 MHz in firmware).

This check was added as a programmer sanity check. If iteration of a loop takes a very long time, then timer would overflow and it would indicate that something that was added takes too much time and should be split into smaller chunks. But normally the loop is way faster than the overflow limit, so something just locks.

The check is done here https://github.com/ataradov/open-5012h/blob/a41308d68ac38f0a9de6d6bd00ef01d0524174c9/timer.c#L135 , and you can try to just remove it and see if that affects device operation.

This timer is only used for timing user events, so it would not affect capture, but you may still see minor glitches, since something still hangs for a long time. But the fact that it comes to that check indicates that it does not hang forever.

I suspect button hang is also related to overclocking, but I don't know for sure.I see no obvious reasons for that to happen based on the code review. I suspect that the root cause is that something freezes when buttons are pressed (or rather code related to button handling is called). It then can freeze forever, or for some time. Freeze for some time shows itself as a timer error.

There are no measurements. Those numbers are trigger level and offset settings.

It would not be too hard to add measurements, but I don't have time to spend on this firmware. I have no real interest in a project. The hardware is too poor and overclocking of everything does not help.
Alex
 

Offline ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #394 on: November 29, 2021, 04:15:27 am »
I've implemented the measurements in the latest commit. I did minimal testing, but it seems to work quite well. MODE button toggles display of measurements and trigger parameters. Frequency measurements are performed at the trigger level, so the scope must be triggered (as any other scope).
Alex
 
The following users thanked this post: MarcosL

Offline petrenn

  • Contributor
  • Posts: 12
  • Country: ca
Re: Reverse engineering FNIRSI-5012H
« Reply #395 on: November 30, 2021, 12:22:22 am »
Alex, the changes seem to work well. Frequency measurement is bang-on and so is the voltage/ amplitude while measuring a square wavesignal (if calibrated properly). Many thanks for taking the time to add these. Also included in the attached hex files (for those who are not software-inclined like myself) are the SPI ID update, the disabling the check that triggers the freezing and timer overflow issue courtesy of my buddy.

The only thing that still does not work - and I get the point of scope needed to being triggered - is the voltage measurement in DC mode. Right now I am using the trigger cursor to measure it in trigger mode by pressing MODE button. The same amplitude measuring is perfect in frequency measuring mode because the scope is triggered continuously. I'm assuming that is not an easy fix for the voltage measuring, right?

Otherwise I calibrated this thing carefully and now it is perfectly in sync with my bench Tek scope.

Nick-
« Last Edit: November 30, 2021, 01:16:14 am by petrenn »
 
The following users thanked this post: MarcosL

Offline MarkR42

  • Regular Contributor
  • *
  • Posts: 139
  • Country: gb
Re: Reverse engineering FNIRSI-5012H
« Reply #396 on: December 26, 2021, 08:41:50 pm »
Hi I have just read this entire thread after watching Dave's video about the scope.

This alternative firmware sounds so cool, even though the scope's hardware is a bit dodgy. It would be really cool if Dave reviewed the firmware.
 

Offline cliffyk

  • Frequent Contributor
  • **
  • Posts: 358
  • Country: us
    • PaladinMicro
Re: Reverse engineering FNIRSI-5012H
« Reply #397 on: December 31, 2021, 05:17:15 pm »
The work that has been done in this effort is quite amazing--but seriously hasn't the point of diminished return been in the rear view mirror for some time now?
-cliff knight-

paladinmicro.com
 

Offline ataradovTopic starter

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Reverse engineering FNIRSI-5012H
« Reply #398 on: December 31, 2021, 07:27:41 pm »
The work that has been done in this effort is quite amazing--but seriously hasn't the point of diminished return been in the rear view mirror for some time now?
It took just a couple hours to add the measurements, and there was no other work on this since the original stuff.

In general, it works for what it is, I don't foresee too many changes.

Reviewing this firmware is hard, since it requires IC change, and those ICs are impossible to find today.
Alex
 

Offline MarcosL

  • Newbie
  • Posts: 4
  • Country: us
Re: Reverse engineering FNIRSI-5012H
« Reply #399 on: August 16, 2022, 07:12:11 pm »
Hello Alex,

I am very interested in what you have done with this oscilloscope. I was looking for a way to use a cheap oscilloscope as a Time Domain Reflectometer. I would use an inexpensive external clock like this one to generate the pulse. I was hoping to have a simple interface where you had the coefficient of the cable you are working with and manually align the to points to get time. It could just spit out an estimated distance. Here is a good video explaining the process. This concept has been around so long I am not sure why the feature can't be included in these cheap oscilloscopes.



I know that you no longer want to work on this firmware anymore but If the project interests you, it would be a super cool addition to the firmware. The flash could be used to store the different coefficients of different cables.

For what it is worth you can now get the ICs even though they are twice what they used to be. I would be happy to help in any way I can but I am also a hardware guy.

Thanks,

Marcos
« Last Edit: August 16, 2022, 07:16:15 pm by MarcosL »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf