Reverse engineering FNIRSI-5012H

[mikerj]

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,

[EEVblog]

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.

[Kilrah]

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.

[EEVblog]

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.

[thinkfat]

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.

[ataradov]

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.

[ataradov]

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.

[ataradov]

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.

[ataradov]

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.

[splin]

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.

[BravoV]

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.

[ataradov]

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.

[dave j]

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.

[ataradov]

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.

[iMo]

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

[ataradov]

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.

[dave j]

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.

[ataradov]

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

[Kilrah]

Was going to suggest that. Instead of swapping the data thousands of times, swap the value it's compared to once.

[ataradov]

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.

[ataradov]

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.

[Kilrah]

I meant on principle, leading to the LUT he was mentioning.

[splin]

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.

[ataradov]

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.

[ataradov]

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.