EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: ataradov 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
-
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.
-
Subbed and thanks for sharing & your effort. :-+ :clap:
-
I've made a breakout board for GD32F407V to make initial project bring up easier - https://github.com/ataradov/breakout-boards/tree/master/gd32f407v (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- (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.
-
Why custom breakout board? Isn’t this GD32 just a clone of STM32F407VET6? There are lots of VET6 boards for sale.
-
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.
-
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.
-
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.
-
.
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! :-//
-
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.
-
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
-
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.
-
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. :-+
-
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 (https://www.eevblog.com/forum/testgear/daniu-ads5012h-100mhz-500-mss-portable-scope-for-$80-usd/msg2741102/#msg2741102)). 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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
I didn't know about this thread.
I just did a review video. The bandwidth is only 10MHz, not 100MHz.
Triggering is pretty horrible.
https://www.youtube.com/watch?v=mqjVriCFliQ (https://www.youtube.com/watch?v=mqjVriCFliQ)
-
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).
-
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,
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
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.
-
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.
-
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
-
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.
-
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.
-
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 :)
-
Was going to suggest that. Instead of swapping the data thousands of times, swap the value it's compared to once.
-
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.
-
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.
-
I meant on principle, leading to the LUT he was mentioning.
-
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.
-
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.
-
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:
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.
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:
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.
-
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.
-
Yes, there is nothing in the hardware to do with 1X/10X. It is a purely software multiplier.
-
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.
-
More testing on the GPIO performance. I just tried to read the input values as fast as I can from the code:
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:
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:
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.
-
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.
-
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 (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
-
I've spotted a performance improvement to that code I posted.
The code of the form:
usub8 temp, samples, triggers
sel temp, temp, zeros
cbnz temp, Found
Can be replaced with:
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
[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.
-
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.
-
https://www.youtube.com/watch?v=SIH48bIUU00 (https://www.youtube.com/watch?v=SIH48bIUU00)
-
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.
-
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.
-
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 really like this $70 scope... seems to me it could be sold even cheaper? The BOM cost was very low!
-
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.
-
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.
-
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
-
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!
-
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.
-
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.
-
The trigger code now works for 100% of samples at 125 MSPS. So i don't think this would be an issue.
-
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.
-
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.
-
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.
-
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 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 :-//
-
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.
-
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.
-
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.
-
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?
-
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 ;)
-
ADC might be the MXT2088: https://item.taobao.com/item.htm?spm=a230r.1.14.19.2eea1df5ep0STN&id=590948654001&ns=1&abbucket=11#detail (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 (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.
-
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.
-
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.
-
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.
-
I hope LCSC sends me genuine gd32f407vet6 :D :D
-
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.
-
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").
-
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.
-
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...
-
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.
-
[attach=1][attach=2]
-
Is there any settings to change language?
Thanks
-
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.
-
Thanks Alex
-
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.
-
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.
-
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.
-
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" (https://www.amazon.com/gp/product/B07XBL4BTL) (you can't make this stuff up)-- had an English UI...
-
The one I had, purchased through Amazon from a vendor named Eple and branded as a "YEEPOOK" (https://www.amazon.com/gp/product/B07XBL4BTL) (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.
-
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.
-
Couldn't find my CRT scope any more
Have a big house? :D
-
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.
-
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.
-
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.
-
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.
-
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.
-
@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. ;)
-
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. :)
-
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?
How bad is the stock FW assuming I don't really need 500 msps?
Dave ranted about it in great detail.
https://www.youtube.com/watch?v=SIH48bIUU00 (https://www.youtube.com/watch?v=SIH48bIUU00)
-
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?
-
Trigger happens purely in the software. The first post here essentially describes the entire digital part of this device.
-
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!
-
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.
-
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?
-
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.
-
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.
-
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 (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 (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.
-
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 (https://www.aliexpress.com/item/4000571425898.html?spm=2114.12010615.8148356.1.74c77dc9ta0ACM)
Again be very careful and wait ....
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
I just read your remark about the backlight better be at 100% brightness for the calibration. :palm:
-
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.
-
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.
-
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.
-
https://gd32mcu.21ic.com/en/index
GigaDevice Vendor documentation
-
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 (https://mysku.ru/blog/china-stores/73960.html#comment3255111)), an attempt was done, in rather clumsy manner, which does not fully remove the problem.
-
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.
-
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.
-
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.
-
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. :=\
-
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.
-
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.
-
Hi can you write a sentence in your github project how to program this new chip? Which tools software is needed?
-
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. :(
-
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 (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/ (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.
-
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.
-
Programming instructions added https://github.com/ataradov/open-5012h/blob/master/doc/Programming.md
-
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 (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 (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:
(http://www.paladinmicro.com/TestEquipment/DSO1C15at53.8Mhz.jpg)
-
Exquisite photoshop work. Too bad they did not remove 200 us/.
-
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.
-
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.
-
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.
-
Here is a mathematically generated square wave, constructed from the first 101 harmonics:
(http://www.paladinmicro.com/TestEquipment/SquareWaveFrom101Harmonics.jpg)
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;
(http://www.paladinmicro.com/TestEquipment/101HarmonicsCalc-1.jpg)
This stuff is 30+ years old, it was part of my Master's work...
-
There is really no point in discussing poor photoshop job. You can spend entire life debunking pictures from Ali.
-
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...
-
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.
-
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... :=\
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
-
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
-
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 (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.
-
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
-
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.
-
I'm almost ready to flash, my GD32F407s from lcsc arrived today! @ataradov, is the compiled binary in github?
-
I'm attaching latest binaries here for now.
But really, it is better to set up and build them for yourself.
-
I'm attaching latest binaries here for now.
Thank you very much!
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:
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
-
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.
-
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.
-
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.
-
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
-
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.
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:
-
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
-
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.
-
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.
-
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.
-
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.
-
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:
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...
(http://apple2.duckdns.org/eevblog/fnirsi.gif)fnirsi-not-ok (http://apple2.duckdns.org/eevblog/fnirsi.gif)
I'm going to grab the solder and redo that flex :-)
Edit: It werks!
(http://apple2.duckdns.org/eevblog/fnirsi-ok.gif)fnirsi-ok (http://apple2.duckdns.org/eevblog/fnirsi-ok.gif)
-
Awesome! You are the second person in the world to run this firmware.
Also, duckdns.org is blocked by uBlock.
-
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! :-+
-
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 :'(
-
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.
-
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.
-
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.
-
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
-
Yes, I meant whatever BOOTx pin is a dedicated pin.
-
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 (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 (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/ (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 (https://github.com/texane/stlink)
Edit: Just in case...
-
: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.
-
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.
-
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)
-
@ 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,
ifeq ($(OS), Windows_NT)
MKDIR = gmkdir
else
MKDIR = mkdir
endif
makes windows users call gmkdir :)
-
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.
-
You do realize that you can source-level debug that thing with the same st-link, gdb and openocd?
-
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.
-
That was more directed to mg3100
-
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
-
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.
-
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.
-
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.
-
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).
-
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.
-
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.
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
-
UQADD8 does not modify Q flag. At least according to the ARM DDI 0403D and a few other places.
-
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 (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:
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 (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 (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/ (http://www.arm.com/support/)
As far as I can see it hasn't been corrected.
-
The armasm (https://developer.arm.com/docs/dui0473/l/arm-and-thumb-instructions/uqsub8) documentation states "The Q flag is not affected even if this operation saturates.". This appears to be common for all the parallel saturating instructions.
-
I will test it later today on the real hardware.
-
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.
-
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:
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.
-
The following test code shows that Q flag nor any other flags are changed by uqadd8.
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).
-
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:
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!
-
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)
-
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:
-
Hmmm - shouldn't there be a grid visible? Somehow my screen looks different to the animated gif george posted earlier!
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 (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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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 ;)
-
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.
-
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.
-
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.
-
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.
-
When lowering the baseline is better, it may mean the more current we draw from the DAC makes it noiser...
-
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.
-
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.
-
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.
-
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...
-
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.
-
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.
-
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.
-
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?
-
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."
-
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.
-
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)
(https://i59.servimg.com/u/f59/19/61/60/05/5mv_at10.jpg)
-
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.
-
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.
-
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.
-
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).
-
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.
-
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?
-
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.
-
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. ]
-
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).
Yes, sure you can get creative, but I'm not sure there are any real benefits to it.
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?
LCD panel is 320x200, the horizontal size of the visible area is 300 px.
My firmware for a set horizontal time scale calculates the highest sampling rate that at least will fill the screen. And yes, it stores more samples than displayed for zooming.
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. ]
I don't use Hantek that much. I find it clunky and hard to use, so I just don't bother.
I use FNIRSI quite a bit, but I found even FNIRSI too much for what I need. In most cases I need a simple scope like this is to check that my UART baudrate is set correctly or a pin toggles at the expected rate. Simple stuff like this. For this I'm not really interested in vertical accuracy. I want to see a general waveform shape though. Basically similar to analog capabilities of the higher end Saleae logic analyzers. For anything more complicated, it is just easier to bring out the real scope.
-
Has anyone got theys hands in this one:
https://www.banggood.com/DSO1C15-Digital-Oscilloscope-500MSs-Sampling-Rate-110MHz-Analog-Bandwidth-Support-Waveform-Storage-With-2_4-Inch-Screen-p-1634767.html?currency=USD&utm_source=rtbhouse&utm_medium=cpc_brand&utm_content=all&utm_campaign=rtb-tools-all-en&cur_warehouse=CN (https://www.banggood.com/DSO1C15-Digital-Oscilloscope-500MSs-Sampling-Rate-110MHz-Analog-Bandwidth-Support-Waveform-Storage-With-2_4-Inch-Screen-p-1634767.html?currency=USD&utm_source=rtbhouse&utm_medium=cpc_brand&utm_content=all&utm_campaign=rtb-tools-all-en&cur_warehouse=CN)
Claims true 500MSPS (but just one channel) and firmware upgradeable. I'd like to see it torn apart to discover what chinesium powers it :D
-
There are pictures of it apart. It used CPLD and separate memory to store samples, so it is less demanding of the MCU. But the analog fron-end still looks pretty bad. And ADC is overclocked again, so who knows the real quality of the samples.
-
Is 5012H still better then FNIRSI-1C15? And does they better then Fnirsi PRO (5MHz) - compare to 2x price?
-
It is hard to "define" better in this case. I have not used 1C15, but I can imagine that joystick thing being pain in the rear. Button controls are good enough.
I don't think anyone has looked closely at the performance of the 1C15. But based on the pictures of the boards, it is probably about the same.
PRO is a toy, essentially, so yes, either one would be better than PRO. But that also depends on your needs.
-
I don't use Hantek that much. I find it clunky and hard to use, so I just don't bother.
Round knobs on a screen GUI are just horrible. (They don't even respond to a scroll wheel.)
-
Hi everyone,
thank you for your amazing work, ataradov and all who helped with it!
I'm looking forward to buy a 5012H and install your firmware on it.
I have a (maybe dumb) question: Can I replace the MCU with a STM32F407VGT6 instead of one from GigaDevice?
From a quick glance in the datasheets they look compatible to me (just checked the pinout and the main specs)
The STM version seems much easier to get and also seems cheaper.
-
No, you can't. We take advantage of memory architecture of the GD devices. You will alt least have to move the code into SRAM. Also, we overclock things, and it is not clear how ST part will deal will that.
We also rely on a very specific timing of the DMA controller, and it it not clear if it is the exact same behaviour as the ST part. On normal applications you may not notice a one or two cycles of difference, but here it is likely to matter.
-
Hello,
at beginning, I want say thank Alex for developing and sharing this project.
I try to replace and flash CPU in my scope.
- Replacement is done without troubles, Soldering looks OK.
- Flashing ends with an error in the first 32 kB. I tried to flash image at once and in 32 ad 16 kB blocks. The error is "Target voltage (12 mV) too low for 32-bit flash, using 8-bit flash writes
size: 16384
2020-07-18T09:30:56 ERROR flash_loader.c: flash loader run error
2020-07-18T09:30:56 ERROR common.c: stlink_flash_loader_run(0x8004000) failed! == -1
stlink_fwrite_flash() == -1"
I can read the image from the scope to a PC and the image is good (no differences). I use a stlink programmer from a nucleo board with burned CPU. I am not sure if the programmer is good.
- The scope doesn't run. Sporadically blinks with display or the mechanical relay create noise. The activity is sometime in 5-10 seconds, sometime a minute without any activity. I showed an image on the scope display only 2 times for very short period.
- I looked a signal on the 20 MHz crystal oscillator and there are only spikes at 610 Hz. Is the CPU resetting after changing clock source? The spikes disappear after pressing the F2 key.
Any idea what to do?
The CPU is corrupted, and must be changed again (I have 2 more).
The flashing is incorrect, but I can read full image from the CPU.
My CPU can't run at 250 MHz.
Many thanks with help!
Cheers,
Tibor
-
Can you show the picture of your board? Make sure is the right version of the board (with one relay).
Hos do you connect the programmer?
Also, I'm not clear on your description. You say there is an error while programming and then say that you can read the firmware back. Is this error intermittent.
-
Hello Alex,
my board contains only one relay.
I connected the programmer with a short usb cable. The cable looks ugly. The cable was 2 m long (before cutting) and was able to transfer files from phones. I think, the cable is good.
When I flash the full image, only the first 32 KiB were programmed. The flash from the address 0x8000 was empty, contained 0xff. I split the image into blocks of 32 (16) kiB (split -b 32768 open-5012h.bin open-5012h.bin.) and flashed each part standalone (st-flash write open-5012h.bin.ab 0x8008000). The flashing of the first part(s) ends with an error, the short final part can flash successfully. I can read full image from the CPU. I tried to flash the image downloaded from this forum also compiled by me.
-
I think your STLink tries to measure the target voltage and does something goofy when it does not find it. See if there VTREF signal on that connector and supply 3.3 V to it (from the target device or from the debugger itself, should not make a difference).
I would definitely work on getting a clean programming first.
If you van build the code, then you may want to try a simple application that just blinks the backlight, for example.
-
I fixed the stlink vdd-target. There was missing R9. Now it uses 32bit flash writes but failed again:
# st-flash write /tmp/open-5012h.bin 0x8000000
st-flash 1.6.1
2020-07-20T10:34:48 INFO common.c: F4xx: 192 KiB SRAM, 512 KiB flash in at least 16 KiB pages.
file /tmp/open-5012h.bin md5 checksum: f996eee3dccbc7f318a3bde681d79faa, stlink checksum: 0x00343fb5
2020-07-20T10:34:48 INFO common.c: Attempting to write 34756 (0x87c4) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000 2020-07-20T10:34:48 INFO common.c: Flash page at addr: 0x08000000 erased
EraseFlash - Sector:0x1 Size:0x4000 2020-07-20T10:34:48 INFO common.c: Flash page at addr: 0x08004000 erased
EraseFlash - Sector:0x2 Size:0x4000 2020-07-20T10:34:48 INFO common.c: Flash page at addr: 0x08008000 erased
2020-07-20T10:34:48 INFO common.c: Finished erasing 3 pages of 16384 (0x4000) bytes
2020-07-20T10:34:48 INFO common.c: Starting Flash write for F2/F4/L4
2020-07-20T10:34:48 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
2020-07-20T10:34:49 ERROR flash_loader.c: flash loader run error
2020-07-20T10:34:49 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1
I think my gd32f407 is corrupted. I disabled switching to high speed clock (in sys_init()). The display remains on. The scope hangs at different points. The relay switches never, once or two times after power on. The best situation I caught is 3/4 of scale on the display.
-
It is possible that not all MCUs are tolerant to overclocking. But I would investigate this further.
Is this picture with the clock configuration disabled? And without disabling it does not work at all?
The project does have hard fault handler installed and it would print the information if this was an actual hard fault. So it just gets stuck in some place in the application logic. But if this is with the slow clock, then I don't know if this is to be expected. I never tried it that way.
One thing I can suggest right away is in the function lcd_data_write() add A LOT more nops for testing. This is where another overclocking happens. The issue may also be with the display itself.
-
The picture was taken with the clock configuration disabled.
At low speed, the MCU probably hangs, display remains white. Only two times I saw the grid on the display.
At high speed, the MCU probably resets, display remains black. The display blinks occasionally.
I will try tomorrow connect with the gdb.
-
I would say hanging at the low clock speed is probably normal. There are a lot of things that are timing sensitive.
Partial picture like this is also normal, since it redraws the screen column by column. So something is hanging in other tasks between redraws.
I would try to lower the overall clock instead of just disabling the configuration altogether. In the following part "(500 << RCU_PLL_PLLN_Pos)" replace 500 with 200 (for 100 MHz total clock). This will drop the clock way below the nominal. But at the same time it will maintain the timing relationship between all the clocks. So it should work, just at a lower overall clock.
-
I tried with the lower clock speed as you suggested. It doesn't help.
I checked again the 20 MHz crystal. There are only single negative pulses (no oscillations) with a width of 26 us with a frequency of 610 Hz (picture in my first post).
I added delay_cycles(100000) before the line RCU->CTL_b.HXTALEN =1. The shape of pulses on the crystal remained the same. The frequency decreased to 127 Hz. The additional delay is 6.2 ms. Adding the same delay after the line RCU->CTL_b.HXTALEN = 1 doesn't change anything. The frequency should decrease to ca 57 Hz but remains on 127 Hz.
The MCU resets on the line RCU->CTL_b.HXTALEN = 1.
Could you point me a documentation for the registers of GD32F407, like RCU->CTL_b, RCU->PLL ? I didn't found. I found only datasheet without this information.
-
I downloaded GD32F4xx_User_Manual_EN_Rev2.3.pdf
I disabled HXTAL and changed PLL to use internal 16 MHz RC. Now it can run also on 250 MHz. Not always it starts. It starts only 1 from 10 times of power on. Tested on 100, 200 and 250 MHz.
Issues:
- HXTAL doesn't work. I want check to use an external clock source instead of the crystal.
- The battery level meter time to time drops to zero level.
- Not always it starts with RC.
-
If MCU resets when you enable the crystal, then something is really wrong. It may be some issue with soldering. Double check that you don't have any shorts.
So even the simplest code like this
RCU->CTL_b.HXTALEN = 1;
while (1);
constantly resets the MCU?
-
After some time my scope become stable with the internal RC clock source.
I have a cold solder joint somewhere. The baseline jumps between two levels in AC mode.
I tried to start the crystal:
while (1); after RCU->CTL_b.HXTALEN = 1; works stable, I can see oscillations on the crystal.
while (1); after RCU->CTL_b.PLLEN = 1; works stable, ...
while (1); after RCU->CFG0 = ... works stable, ...
Full application: can (not always) run. MCU resets when I touch the crystal pins with a probe (1:10).
I go to search the cold solder joint.
Tibor
-
Is there a way to configure the drive strength of the internal amplifier for the oscillator, or a configuration to match a crystal with a different capacitive load requirement? I'd take a good look at the capacitors next to the crystal as well.
-
No, there is only enable or disable.
And it should not be that sensitive to probing with x10 probe. Also, does it stall if you touch either pin (XIN/XOUT)? Or just some specific pin?
-
My device is very unstable. One time it runs stable for few minutes. Other time can't start for few minutes.
I was able to see oscillation on the crystal during running application just now. I probe the crystal pads directly, not the pins of MCU.
I checked noise on capacitors located near the edges of the MCU. Everything looks fine.
I go to check MCU pads soldering by a needle under a microscope.
I already tried to touch any part/pins by a plastic tool without any effect.
Tibor
-
I think you can't avoid more debugging. This is an unusual issue, so there is no readily available answer.
I would start with a simple firmware that just runs on the internal RC (default settings). Initialize only the LCD, but disable all the ADC and scope stuff. Just draw some random lines in the LCD or print some text (incrementing numbers, for example). Make sure that it runs in this configuration reliably even when you poke and touch the MCU.
Then switch to the PLL, still driven by the internal RC (keep the clock low, 100 MHz). Repeat the experiment.
And then switch to the crystal.
-
It is very difficult to debug it. New issues occur, old ones disappear at random time...
I checked all pins of the MCU under microscope. I didn't found any problem. I re-soldered all pins one-by-one manually. After this, the MCU was able to run with crystal at 250 MHz.Unless I closed the back cover. After closing the cover, it was not able to start the crystal more. I changed clock to internal RC, 250 MHz. It runs...
The most recent issues:
- Spikes at 62 and 125 MHz rate, noise only; open or short input, baseline in middle. I think not all bits from the ADC are read in the time. The result is a mixture of bits from 0x7f and 0x80. Rate of the spikes depends on the CPU activity. Pressing the 1/10X button increases the rate little, trigger level button more. After shifting the baseline level, the spikes disappear. The spikes are not present always. Sometime immediately after power on, sometime after some time...
- "Flash error"; reading signature bytes failed. I saw this error today two times, never before.
- It doesn't switch off after sliding the switch to the off position. This issue started yesterday. At beginning it switched off after few seconds, today it stay on for more than 2 minutes. There can be a voltage from the pin PB1 / VBAT_SENSE, if the pin is in an incorrect state.
Tibor
-
I still think there's maybe an issue with the xtal oscillator itself. The crystal needs to meet certain specs so that the oscillator circuit inside the MCU can drive it properly. Maybe the crystal just marginally meets these specs and the changed MCU is a little different from the original? How did you exchange the MCU, did you hot-air the chip off? Maybe the crystal got roasted, maybe the load capacitors near the crystal are damaged or just not the optimal value.
PS: could be a mechanical issue with the PCB, hairline crack in a trace that makes it stop working if you close the case or mechanically stress the PCB when you press the buttons.
-
I used to remove the old MCU a sharp knife to cut off pins from the MCU and a solder iron to remove pins from the board.
I can replace the crystal. I have here an old testing board with an atmega and 20 MHz crystal. It is not SMT but can fit.
I applied a mechanical stress to the scope board without any effect.
Tibor
-
I don't see how the switch can not disable the device. The switch controls the enable pin of the LDOs. VBAT_SENSE takes a divided output of the LDO.
I would double check the primary supply voltage (battery) and the LDO outputs. Check that there are no weird oscillations or something like that.
Given the number of issues that should not be related to each other, I would have a very close look to the power supplies.
-
I already checked the LDO, switch. There are no oscillations. It was measured in the situation when the switch is off and device is on.
The VBAT_SENSE can't be connected to a output of the LDO for sure.
The switch connects battery with a divider. Output of the divider is connected to the VBAT_SENSE pin and through a black component with a label S4 to the enable pin of the LDO. Voltage on both sides of the "S4" component is the same. If the VBAT_SENSE is an output, it can provide a power to the LDO enable.
I checked the MCU at 125 MHz. There were no spikes using both RC and hxtal. The spikes can depend on temperature of the MCU. At 250 MHz, the rate of the spikes increases with time, the temperature also increases. It was able to run on the crystal only a short time.
One time the stlink was able to flash full 32 kiB without printing error. But only one time.
-
I just don't see how VBAT ADC pin can become an output. The device must be super messed up at that point.
So at 125 MHz it basically works fine? Or just the spikes go away and the reset is still broken sometimes?
As for the programming error, I do remember that my tools had issues too when device was running from the PLL. Hence there is while (1) loop if F2 is pressed on power-up. Other than this I never had any issues.
-
I replaced the crystal. Nothing changed. It can't run using the crystal most of the time. No matter of the PLL speed.
It runs fine using the internal RC at any speed. The spikes are there only at the highest speed, 240 MHz is spike-less.
The problem with the power off disappeared yesterday. This problem was there also at lower speed.
Many problems come-in, come-out at random time.
A wrong level of the ground level of a part of the MCU can explain at least part of the problems, like unstable battery level measurements, a voltage on an input pin (over-voltage protection: pin o---|<|----| ground).
I will check the all ground pins of the MCU. One of the edge capacitors is connected to the pins VDD and NC (pins 72, 71).
The F2 helps with the programming, thanks.
Tibor
-
The unconnected pin is actually connected on the original ST part. So this may explain why the capacitor is there.
It is possible that some parts are less stable, of course. All my parts (3 in the scopes, one on the breakout/prototyping board) came from the same batch and they seem to be doing fine.
Without F2 my devices refused to program almost always. No idea why, SWD connection just was not stable. Access to the reset pin would solve that, but we don't have it.
-
Correction: the pins VDD and NC are 49, 50. I looked to a wrong package.
-
I checked all the power pins of the MCU, everything looks good. On page 24 of gd32f407 datasheet, the pin 49 is a NC with the function: "Default: VCORE".
After touching the power pins, it was able to run with hxtal. The spikes were there at 250 MHz. I made many tests at 240 MHz, all OK. I tried to find the highest stable frequency and the power-on ends now with "Flash error". Sometime the bottom half of the screen contains a garbage at the highest speed. It is a "periodical" pattern with a different color, probably single bit mismatch. I don't have a photo of it. This MCU is not able to run at 250 MHz.
The "Flash error" is now permanent using both hxtal / internal RC PLL clock. I checked signals on the flash chip. CLK and DO signals looks strange (on both MCU and flash chips). I checked the DAC output located near the pins used for flash wiring. There is only very slow rise of voltage (T1/2 ca 10 s).
Tibor
-
This looks like a short on the board, so signals have to fight with each other. But i have no idea why all the signals would be affected at the same time.
I think you need to make a simple program that toggles each pin on and off and have a look at them individually. May be start with the flash pins, since they are obviously affected.
-
I checked a resistance between the flash CLK and DO pins. There was only 120/160 Ω (depending on polarity). I cleaned the space between these pads by a needle. It works now!
It seems it can work fine at 120 MHz. It is not a big drawback. I'll not replace the MCU for this issue.
Thanks!
Tibor
-
It looks like your flux may be conductive or something, which would explain a lot of the issues. May be try to clean it better from the rest of the MCU.
The issue with running from the lower clock is that you will have to recalculate all the timings.
-
It looks like your flux may be conductive or something, which would explain a lot of the issues. May be try to clean it better from the rest of the MCU.
Yep, that's what I suspect is happening. I've also had that problem once. Find something to dissolve the flux, and use a loupe and a toothbrush or something. Sometimes I wish there was a mini karcher for things like that.
-
Ultrasonic cleaner helps. Even the cheapo ones for jewelry work ok, you may need to run them a bit longer.
But in this case it is not ideal, since display is soldered to the board.
-
I changed period and error variables to float. It can handle now a non integer value of the BASE_SAMPLE_PERIOD.
PLL setting and BASE_SAMPLE_RATE is derived from F_CPU. If you want change the frequency, it can be done only in one place (Makefile). The picture shows a correct timing of the device running at 240 MHz.
The file with the patch was corrupted. I send it again.
Tibor
-
Bug report.
Hello,
I found one small bug in the code. If the vertical scale is changed, the trigger position is wrong. There is missing config.trigger_level_mv = config.trigger_level * vs_px_value[config.vertical_scale] in the function static void change_vertical_scale(int delta). I think it is better to call here change_trigger_level(0); instead of duplicate the code.
Cheers,
Tibor
-
Yep, fixed on GitHub.
-
Hello,
I wrote a support of simple cursor lines. I introduced modes:
- Move: the normal one. Use arrows to change position, shift + arrows for scale.
- Zoom: the inverted mode. Use arrows to change scale, shift + arrows for position.
- Cursor: the cursor mode. The status line contains the time and voltage intervals between the cursor lines. Use arrows to move the cursor1 lines, shift + arrows for the cursor2 ones. During moving the cursor lines, the status line contains position of the corresponding cursor lines..
The cursor lines are shown only in the cursor mode.
Tibor
-
All samples only in the single trigger mode?
Hello Alex,
it seems, that only the each fourth sample is displayed in the normal and auto mode, see photos of a 10 MHz clock signal captured in the single and the normal mode, and spikes of my device running @ 250 MHz. When the trigger edge is the fall one, not in the all cases is the edge at the trigger position.
Could you be so kindly and make a look to these issues? Or suggest what to check.
I used for the test the non-modified code from the git.
Many thanks,
Tibor
-
For the display in normal and auto modes the signal is decimated 4 times. There is not enough memory to keep the entire trace and continue signal acquisition. So when trigger happens (on a high sampling rate signal, 182K samples), every 4th sample is copied into a buffer that is 32K samples. The display works on that small buffer. The main buffer in the mean time is filled with the new data.
In a single mode mode there is no repeated triggering, so the whole big buffer is displayed. You can see that logic in the function capture_get_data() where it selects between g_capture_buffer_info and g_storage_buffer_info depending on the mode.
The trigger point between the samples is also normal. On the captures green part of the trace is a linear interpolation of the missing data. You can see the actual sampling points in yellow. It is possible that the actual triggering sample got removed in that 4x decimation process. Basically there is not much point in looking at things in extreme close up.
-
Thank you for the explanation.
Tibor
-
Preview of an auto cursor mode.
Hello,
I introduced an automatic setting of the cursors (msg. #305).
Button AUTO enable/disable this mode (in the cursor mode only).
SHIFT + AUTO cycles between auto modes:
- Follow Trace (FT). The y position follows the trace at the x cursors positions.
- Pulse Width (PW). The x cursors are set to an one signal period (at the trigger level).
- Positive Pulse width (PP). Similar to PW, but the positive pulse only.
- Negative Pulse width (NP). Similar to PW, but the negative pulse only.
Please let me know, if you have a suggestion to implement other modes, better 2-letters abbreviations or icons, ...
My suggestions: rising/falling edge, set y to maximum/minimum on the PW modes.
Cheers,
Tibor
-
Feel free to fork the code, of course, but I myself not interested in extending the functionality. In fact, I'm looking for ways to reduce it.
If I feel like I need cursors, I will bring out the real scope rather than this toy. Fiddling with the buttons is just painful.
But as far as feedback on the changes goes, if I were to implement the cursors, I would implement them tied to the signal in the storage buffer, not the display buffer. That way you could zoom in on one edge, set the cursor, zoom in on the other edge, set the other cursor, and have a good delta value.
Screen cursors only automate counting of the grid squares. And that's not that hard.
-
Hello Alex,
thank you for the feedback. I have read all the posts on this topic. I am sure you are not interested for these changes. I did it for relax during vacation. I wrote the post mainly for other readers.
I am now interested if it could be possible to reconstruct a periodical signal in a time precision better than the sampling rate.
Cheers,
Tibor
-
If you mean true ETS, then it is impossible, since ETS needs analog triggering and precisely controlled trigger delay.
You may do some questionable tricks, like collecting multiple samples triggered from the same trigger and assume that the first point after the trigger condition is sampled at a random point in the actual analog signal. You can then depending on the amplitude of the first sample sample calculate possible analog delay and place that sample accordingly in the buffer. But that would only work for slowly changing signals. And memory management would be an issue.
It may be possible to do some sinc-style interpolation, but it will be very slow. For this you basically need to replace my linear interpolation code with sinc. But I have not thought about how much calculation it would actually take. I feel like it is a lot.
-
True ESR is not possible.
I mean, I have stored samples of many periods of the signal. I can calculate the period of the signal in very high precision. I can determine the phase shift (with respect of the signal periods) of the samples between adjacent periods of the signal. It should be possible to obtain many points of one period of the signal. Ratio of the signal frequency and sampling rate can not be a fraction of small integers.
In short. I can't set the timing of sampling with respect of the trigger point but I can calculate the timing of the stored samples.
Tibor
-
This is what I described in the second paragraph. There are two possible options:
1. Work with multiple periods from the same capture. The issue here is to capture multiple periods at high enough sample rate. I'm not sure if that makes any sense.
2. Work with the first period from multiple captures. This has some potential, but a lot of assumptions and guessing will be involved, so it will work for some signals, but not others.
-
If the frontend is fast enough and no anti-alias filter is present, then the ADC of a DSO can certainly act as digital down-converter. Meaningful results can only be expeted for certain frequencies, though, which which happen to alias to the 0...fs/2 range in a suitable way. For instance, frequencies which are integral multiples of the sampling rate won't work at all, while a periodic signal with (say) 1.2511 MHz, undersampled at 125kSa/s, can give a nice result, down-converted to 1.1 kHz (just an arbitrary example).
-
Just reflashed mine and what I difference! You just turned this toy into something useful. Special thanks to Ataradov for all your work!
As a hw guy I'm typically interested in transition details, so how would I do to change the code so all samples are viewed in auto and normal mode? Instead of having 128k capture and 32k data, could I just set these to 80k each? I understand the penalty for this, but would there be other parts that would need change as well?
Is there a reason to keep buffer size to 2^n and keep them at 64k both or would 80k work?
My c skills are somewhat limited but I have good help from programming friends.
//Zeb
-
It would not be easy to do given the way memories are organized on this device. The memory accessible by the DMA (necessary for the capture) is a chunk of 128 KB. The reset of the memory (64 KB) is only accessible by the MCU. That's where I allocate 32 KB for the secondary buffer and the rest of the variables.
Splitting away part of the 128K buffer would mean that the other buffer would be discontinuous. So the code would have to handle this. It is not that hard, as the actual buffer for the display is populated in one function.
There is a lot of code that relies on the power of 2 size, but again it is only because I assumed that buffers will be power of 2 sized. There is nothing hard that requires that. But it still would be quite a bit of work to change that.
The easiest thing you can do is to not select every 1/4 sample when filling out the smaller buffer. You will end up with a trace that only fills 1/4 of the screen, but contains all samples.
-
Thanks for the answer. Sounds tricky.
If I understand you right, if both buffers were to be 64k they would both fit in the dma section and not be discontinous? Or is there any problem for the mcu to access this area? Or setting up the dma for only using 64k?
//Zeb
-
Yes, if you split the 128 K buffer in two then it will work fine and both buffer will be continuous. There may be minor performance issues when MCU and DMA try to access the same memory. But it should not be significant.
The trickiest part with adjusting for 64K buffer would be to recalculate time/div values, since they all are calculated based on the 128 K buffer. I'm not sure how hard that would be.
-
Great! The code looks really well written so it seems to be mostly defines, and I need to check through the calculation for setting horizontal config.
The memory map looks fishy, is there 3 banks? Sram0 is 112kB sram1 is 16kB and sram3 is 64kB but they all seem to be consecutive in memory. A good start may be to just change the size and location of the buffers and see if I can get it to run without performance or other issues...
//Zeb
-
GD32F407xx only has SRAM0, SRAM1, and TCMSRAM. SRAM0 and SRAM1 are basically the same memory. TCMSRAM is a very different memory at a different address.
While there are defines in the code, it does not mean you can just change them and things will work 100%.
-
Ill have too look more closely into the memory map.
I just meant that it only took me acouple of minutes to find 2 places where this is calculated and needs a closer look. The way the code is hierarchicallly structured I wouldn't expect there to be changes on too many places. But of course "assumptions are the mother of all f.....". I don't expect anything.
//Zeb
-
Hi all!
I'm new to the forum and also kinda new to electronics, but I am a highly skilled and experienced software developer, and I do understand the very basics of electronics, like what a ransistor/capacitor/diode/resistor does, how to build from a schematic, how to solder, how to interface with a simple IC, etc.
I have purchased everything necessary for this project, but haven't yet received the chip and some other parts. I've read all of the github repo instructions, and I've read a whole lot of the thread but I am still going through it (currently on page six).
Would you folks who have done the project be willing to kindly help me through the process?
The first questions I have are simple. Did I buy the right parts?
I got this debugger:
https://www.amazon.com/gp/product/B00PVJ8Q4C/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 (https://www.amazon.com/gp/product/B00PVJ8Q4C/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1)
And this USB connector:
https://www.amazon.com/gp/product/B07Q4J5NKZ/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 (https://www.amazon.com/gp/product/B07Q4J5NKZ/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1)
And this cabling:
https://www.amazon.com/gp/product/B01DP13EDA/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1 (https://www.amazon.com/gp/product/B01DP13EDA/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1)
Question 2: I have no idea how I will get 3.3v power to the debugger. How do you suggest I shall do that? I was thinking perhaps I would just hook up a few AA batteries and a voltage divider? I'm a newbie but I think I have figured it out. Is my diagram and my math correct? Will this be OK to power the debugger?
edit, tried img tag but the image didn't show up? Here is the circuit (edit, nvm, I realized the resistance is way too high to power the board, and alex says I don't need an extra power source. But here's the very bad circuit I designed anyway):
(https://i.imgur.com/PkxXqTj.png)
-
Why would you need to supply the voltage? I don't see any voltage shifters on this debugger. The only reason to supply the target voltage is if programming software cares about it. And chances are it does not.
And if it does, there is 3.3 V output right no that connector. Just short it to the target voltage sense pin, of there is one.
-
Ah, OK thanks. I don't have the programming board yet. So I take it the board is suitable?
I was just trying to understand your comment in github. Sorry, I'm very new to this and trying to learn a lot of things at once.
"It is important to keep in mind that programmers supporting multiple target voltages often use level shifters powered by the reference voltage provided by the target board. In this case there is no reference voltage, so you would need to provide that voltage (+3.3V) externally."
How will the board get power? Will it come directly from the scope?
-
Hardware-wise the debugger is fine. I've never used ST-Link or its clones, so I have no idea what software works with it.
The comment applies to the debuggers that have voltage level shifters to accommodate multiple target voltage levels. In this case the debugger is fixed at 3.3 V.
The debugger will be powered from the USB, the target will be powered from the battery. Both sides are fixed at 3.3 V, so there are no issues with voltage levels.
-
OK, I've got everything now. Silly me, I only ordered 1 replacement chip :/ I can buy more but they take a long time to ship of course.
I'm kind of new to soldering. I bought an SMD rework station, but the air gun doesn't really work all that well. I happen to have some SMD breakout boards and a bunch of SMD cmos chips I ordered by accident (meant to get through-hole chips). So I figure I'll practice with that. To get the original chip off, I'm thinking I'll just use solder-wick instead of trying to use the air gun to heat it off the board. Then I'll do my best to mount the new one.
I'm really nervous about this, any tips to help me succeed, other than practice a bunch?
I'm really looking forward to flashing the new firmware on! Also, as I mentioned earlier, I'm a professional software engineer. I'll be happy to contribute any improvements I make to the firmware, assuming I succeed with the hardware mod! Alex, is there anything in particular you think needs work and you aren't actively working on now, or have put on the back-burner?
-
I'm not sure how well solder wick will work on a TQFP part. I imagine it will not work too well. The better option may be to carefully cut the old device pins with exacto knife close to the package and remove the leftovers with the wick.
But the hot air is definitely the best method.
As far as improvements go, I'm not really interested in doing more work on this. It really needs analog front end improvement to be a real tool. And really it is still too cumbersome to operate except for a few simple cases.
-
OK, I've got everything now. Silly me, I only ordered 1 replacement chip :/ I can buy more but they take a long time to ship of course.
I'm kind of new to soldering. I bought an SMD rework station, but the air gun doesn't really work all that well. I happen to have some SMD breakout boards and a bunch of SMD cmos chips I ordered by accident (meant to get through-hole chips). So I figure I'll practice with that. To get the original chip off, I'm thinking I'll just use solder-wick instead of trying to use the air gun to heat it off the board. Then I'll do my best to mount the new one.
I'm really nervous about this, any tips to help me succeed, other than practice a bunch?
Use plenty of flux. Everything works better with more flux.
-
RE: no more updates - Sad but understandable. If I manage to get the firmware updated I'll poke around and see if there's anything I feel I can contribute. As an extreme novice in EE, I don't see much hope that I could build a better front-end for it or improve the existing one, but maybe someday that will be a project I decide to take on. But when it comes to software, I'm incredibly comfortable and confident with just about anything, including assembly language on a chip I've never used before, so maybe I'll have some bright ideas.
Anybody else have features or tweaks they'd like to see if I do manage to get it flashed? Also, what would a better front end look like/consist of?
RE: lots of flux - yeah, I knew that in an abstract way already from many sources over the years, but I'm definitely learning that flux really is the king of solder in my practice sessions. :)
I've decided to get either a real scope, or a USB scope/logic analyzer, so I'm a little less concerned about hurting the FNIRSI. Think I'll just go for it this weekend when I have time. I'll see if I can get the air gun to function. I probably shouldn't have cheaped out on my rework station. It only goes to 480 degrees, and maybe it is simply my (lack of) skill but the whole rig seems very inconsistent, sometimes the iron works great and other times it just heats the pins and doesn't melt the solder. The heat gun seems kinda hopelessly bad. But maybe I'm bad. Here's the one I got: https://www.amazon.com/gp/product/B07XC9VV2C/ref=ppx_yo_dt_b_asin_title_o08_s01?ie=UTF8&psc=1 (https://www.amazon.com/gp/product/B07XC9VV2C/ref=ppx_yo_dt_b_asin_title_o08_s01?ie=UTF8&psc=1)
-
One of the bigger problems of this device is overclocking of everything. MCU is overclocked, ADC is overclocked (presumably, since we don't really know the ADC model).
There are a few decent frontend designs out there. The Rigol one can be used as a decent starting point.
But the bigger issue is that it is cumbersome to use. Knobs and a bigger screen are just better.
This device is still useful and I do use it from time to time if I need to quickly check if the signal is there or check UART baudrate. But if I need stuff like decode or accurate measurements, a real scope has no alternatives.
Generally those cheap air guns work fine. What is wrong about it? Does it not get hot?
-
Yeah the air gun doesn't seem to get all that hot, I've managed to use it to get some solder off boards I didn't care about messing up, combined with a desolder vacuum pump. I read through the entire thread yesterday and saw your recommendation to use a thin wire to pull underneath the pins, but it seems like the solder will just re-solidify before I get all 4 sides up. I'm just afraid I'll burn the board or something.
Oh well, I ordered a real scope that's coming this weekend, so I'm feeling more adventurous now with this one. You guys will probably laugh at it but it really looks good for the price. Hantek DSO5102P. I couldn't bring myself to spend another $150 for the $400 Rigol when I haven't even run into a need for a scope yet.
-
Yeah the air gun doesn't seem to get all that hot, I've managed to use it to get some solder off boards I didn't care about messing up, combined with a desolder vacuum pump.
Why would you need a pump. Hot air should be able to melt the solder and then you just remove the component.
It is hard to tell if the gun is indeed under-performing or you are doing something wrong. Usually those heat guns either work or not at all. I assume you have tried to adjust air flow and temperature?
I read through the entire thread yesterday and saw your recommendation to use a thin wire to pull underneath the pins, but it seems like the solder will just re-solidify before I get all 4 sides up. I'm just afraid I'll burn the board or something.
The hot air gun must be able to produce enough heat to heat up the whole chip at once. The wires are pulled when the solder has melted on all 4 sides.
-
Yeah the air gun doesn't seem to get all that hot, I've managed to use it to get some solder off boards I didn't care about messing up, combined with a desolder vacuum pump. I read through the entire thread yesterday and saw your recommendation to use a thin wire to pull underneath the pins, but it seems like the solder will just re-solidify before I get all 4 sides up. I'm just afraid I'll burn the board or something.
Oh well, I ordered a real scope that's coming this weekend, so I'm feeling more adventurous now with this one. You guys will probably laugh at it but it really looks good for the price. Hantek DSO5102P. I couldn't bring myself to spend another $150 for the $400 Rigol when I haven't even run into a need for a scope yet.
Well, "buy cheap, buy twice" is what they say. You bought cheap the second time already :palm:
-
Well, "buy cheap, buy twice" is what they say. You bought cheap the second time already :palm:
LOL it's a fair point... but this time I was a lot more careful to look at reviews and the specs of the device. Let's face it, there's no maximum price for a scope. There's always a more expensive one with more features and better bandwidth. I'm completely new to this game, I probably won't even need the scope any time soon, and I can't justify spending $400 - $20,000 on a tool I don't even need yet. I'm planning to do mostly arduino and simple hobby projects, I think the Hantek will last me quite some time.
Really I could probably get by with the unmodified FNIRSI, it did fine testing my signal generator. But I figure it will be nice to be able to look at non-periodic signals someday.
The first real workout the Hantek will get will probably be when I build my bench power supply. Someday when I learn what the heck I'm doing, I figure I will build my own oscilloscope. That day is a long way off.
-
The hot air gun must be able to produce enough heat to heat up the whole chip at once. The wires are pulled when the solder has melted on all 4 sides.
Ahh. But the chip is surrounded by tiny little smd parts... capacitors I guess? How to avoid dragging those along for the ride?
-
if you heat the IC itself (from the top, but concentrating towards the sides), then surrounding components will not heat enough. Or even if they do, they will be held by the solder tension.
You need to adjust air flow so it does not just blow everything away. Generally the lowest flow possible works fine for that.
-
You need to adjust air flow so it does not just blow everything away. Generally the lowest flow possible works fine for that.
That's probably my issue. I just turned the knob all the way to the right. Less flow equals more heat. That makes sense. Thanks for being so patient with my beginner @55. :)
-
You need to adjust air flow so it does not just blow everything away. Generally the lowest flow possible works fine for that.
That's probably my issue. I just turned the knob all the way to the right. Less flow equals more heat. That makes sense. Thanks for being so patient with my beginner @55. :)
That depends on how cheap the hot-air gun is. If it's properly regulated (even if it's just half-arsed), more airflow means more energy transfer.
-
That depends on how cheap the hot-air gun is. If it's properly regulated (even if it's just half-arsed), more airflow means more energy transfer.
It's about as cheap as they go, so my guess is there's nothing proper about it. Unfortunately I don't have a thermocouple that can measure temperatures this high so I dunno how hot it actually is. I'm just gonna play with it for a bit and then go for it on Saturday. Wish me luck!
-
The hot air gun must be able to produce enough heat to heat up the whole chip at once. The wires are pulled when the solder has melted on all 4 sides.
Ahh. But the chip is surrounded by tiny little smd parts... capacitors I guess? How to avoid dragging those along for the ride?
Kapton tape may help.
-
Aborted the mission this weekend, I got a 3d printer and spent most of my weekend trying to get the damn thing set up. :rant: May try it tonight.
I did get the Hantek though, and it's a very nice little machine for $250!
-
Finally got the chip off and the new one on, but a few of the pins are connected according to my multimeter :(. I assume none of the pins are supposed to be connected?
I can't see a bridge in my microscope, either. Bummer :(
-
What specific pins you are talking about? Have you seen the pictures of the board with the chip removed (first page of this tread)? You can clearly see what pins are supposed to be connected.
There are not a lot of of pins connected, but there are multiple pins that are power supply and grounds, and they all are connected together.
-
What specific pins you are talking about? Have you seen the pictures of the board with the chip removed (first page of this tread)? You can clearly see what pins are supposed to be connected.
There are not a lot of of pins connected, but there are multiple pins that are power supply and grounds, and they all are connected together.
Just checked, it's those pins! So maybe I was successful after all.
-
Well I did a connectivity test on each pair of pins and checked for continuity and bridges, I got 100% with my multimeter. So now I need to solder a micro connector. I took pictures of my SWD board can you help me figure out which pins I need to connect? Edit: never mind, I've got it I think. Missed the diagram in the middle on the back side of the board, I see the pins from the docs.
So now solder a connector, plug the programmer into my PC along with the multimeter, install OpenOCD or whatever it's called, power on with F2 and flash the code, right? I'll try that out tomorrow, it's super late here.
-
You don't need F2 on a blank device, but generally yes, this is the process. I don't know anything about those programmers, so it would be on you to figure that out.
-
You don't need F2 on a blank device, but generally yes, this is the process. I don't know anything about those programmers, so it would be on you to figure that out.
Yeah, fair enough. If it recognizes the board but can't flash it for some reason I'll probably just buy yours, I should have done that anyway to thank you for your work on the project. I'll hit your tip jar if I get mine to work. :)
-
I've got openOCD installed and I'm trying to use it, not having a lot of luck because I have no idea what I'm doing. I need to compile the code to some format and run a flash utility on it, right? GCC I guess? I'll figure it out eventually I guess!
-
You can use binaries attached to this thread. You don't actually need to use GCC or compile anything.
But you need to get OpenOCD to recognize your debugger and your chip. And I really have no idea about that.
-
I've got openOCD installed and I'm trying to use it, not having a lot of luck because I have no idea what I'm doing. I need to compile the code to some format and run a flash utility on it, right? GCC I guess? I'll figure it out eventually I guess!
IRC still exists, if you go over to the #openocd channel on the freenode network, you'll surely find someone to help you. Or, write to the openocd-users mailing list which is hosted on sourceforge (yes, that also still exists).
-
I've got openOCD installed and I'm trying to use it, not having a lot of luck because I have no idea what I'm doing. I need to compile the code to some format and run a flash utility on it, right? GCC I guess? I'll figure it out eventually I guess!
IRC still exists, if you go over to the #openocd channel on the freenode network, you'll surely find someone to help you. Or, write to the openocd-users mailing list which is hosted on sourceforge (yes, that also still exists).
Thanks I'll check it out if I get stuck. I just ran out of time last night, doing lots of stuff, I figure I can probably get it working on my own, forgot that there are binaries already made, that helps. I'll want to change them eventually but if I can get the device flashed in the meantime that would be good.
-
Not sure what you are using... but if you have an ST-Link clone, why not use the ST-Link utility?
https://www.st.com/en/development-tools/stsw-link004.html (https://www.st.com/en/development-tools/stsw-link004.html)
Worked for me without problems IIRC.
-
Not sure what you are using... but if you have an ST-Link clone, why not use the ST-Link utility?
https://www.st.com/en/development-tools/stsw-link004.html (https://www.st.com/en/development-tools/stsw-link004.html)
Worked for me without problems IIRC.
Thanks for the tip! Yeah that's what I was thinking too. I did load it up last night, but didn't get anywhere with it, but good to know that my intuition was correct. So is that all you needed, software-wise?
-
Not sure what you are using... but if you have an ST-Link clone, why not use the ST-Link utility?
https://www.st.com/en/development-tools/stsw-link004.html (https://www.st.com/en/development-tools/stsw-link004.html)
Worked for me without problems IIRC.
I'm connected to it and able to flash it and it passes the checksum but I just get a blank screen with the backlight on.
I'm not sure how to flash it, there are two files, I've tried both the bin and hex files. Am I supposed to put them in different memory locations?
Edit: I figured out the bin and hex files hold the same data, and ST-LINK just recognizes both of them, so they both show up in the choose file dlg.
So I'm getting a blank screen, but it seems I can erase it and flash it just fine, and also the backlight is working.
Maybe I damaged the screen during the operation, I tried to be careful but it kinda flopped around some when I had the board off the unit. My electronic debugging skills aren't really great yet, so maybe I can figure it out eventually but it won't be trivial for me to debug the circuitry. I knew I was risking a brick by doing it so I'm not too upset, plus I have a good scope that's pretty portable anyway.
-
Display damage is not likely if there are no signs of visible damage.
It is much more likely that there is an issue with soldering. You have checked that there are no shorts between the pins, but you have not really verified that there are no opens/disconnects.
And since you have a working scope, put it to works. The things to check are:
1. Try to hold F2 while power cycling. Does the backlight go away?
2. Check the crystal oscillator pins (Xin/Xout have the clock).
3. Check if ADC lines have activity on them.
4. Check if display lines have activity on them.
-
Display damage is not likely if there are no signs of visible damage.
It is much more likely that there is an issue with soldering. You have checked that there are no shorts between the pins, but you have not really verified that there are no opens/disconnects.
And since you have a working scope, put it to works. The things to check are:
1. Try to hold F2 while power cycling. Does the backlight go away?
Yes and also ST-LINK recognizes it's in low-power debug mode, and recognizes the chip. I'll check the other items tomorrow, thanks again for this and all your help so far! I figure recognizing debug mode and turning off the display is a pretty good sign the flash is at least partly working?
I did make an attempt to test conductivity by using my multimeter and touching each pin with one lead and the corresponding track with the other lead, but as you said that's not perfect by any means.
-
Now, there is a new 70$ model from China: ZDYZ DS100.
250MSa/s， 50M analog bandwith.
3.5“IPS 400x320 resolution.
Dual channel analog input and simple signal generator.
-
设计思路应该大同小异，都是ADC和MCU超频以达到250M的采样率。
The design ideas should be similar, both ADC and MCU are overclocked to reach a sampling rate of 250M.
-
Ataradev congratulations for your work, and all the people supporting this project.
I bought and changed GD32 in my device and a friend's. Working All perfectly, now I can see UART pulses without triggering in a bad way.
From time to time with normal use I get "TIMER OVERFLOW" error messages (usually changing options with the keyboard), which forces me to restart the device, is it a known behavior?, Or i must check something?
tzenis, great job too with cursor lines and AUTO mode! have you continued with the development? i'll compile and flash the device with your patches.
-
Timer overflow does happen from time to time. It is a bug, I have no idea why it happens and I don't have enough interest in the unit to debug this.
-
One of the bigger problems of this device is overclocking of everything. MCU is overclocked, ADC is overclocked (presumably, since we don't really know the ADC model).
Just finished skimming this thread and kept reading about the MCU being unstable for some at 250mhz.
Have you guys tried to raise the voltage and apply extra cooling?
I get a lot more out of a Raspberry Pi this way. I know they are not the same but it's the same principle.
You may even be able to get those extra cycles you need to allow the DMA to "keep up".
-
Interesting topic. Any news?
-
Not really. I came to a conclusion that the hardware is crap and not really worth spending more time on it. I just bought Owon SDS1102 and it does all I need a simple scope to do, most importantly not having a fan and being totally silent.
Portability aspect is nice, but was not a real factor for me.
-
I see in the pic there is a small 8 pin eeprom/flash, probably used to store captured images from the scope.
Is it a SPI or i2c device?
I am thinking about an hack to use it to extract snapshot.
-
I agree with you, just ... the Owon SDS1102 is listed at 250 euro, so it's also 5x more expensive than FNIRSI-5012H ;D
-
The first page lists all the part numbers. It is SPI flash W25Q64JV.
But Owon is actually a useful tool. This one is not. The price does not matter here, if functionality is not there.
-
The price does not matter here, if functionality is not there.
If the price does not matter, why not a Fluke (2500 Euro).
If the price does matter, I already have my MSO! I am looking for a low cost digital oscilloscope for things in the bandwidth of 2Mhz, so things for which I don't need to carry my professional (and much more expensive, ~1800 Euro) MSO with me!
Anyway, why do you say, after a long topic, the hardware is crappy? What's wrong now?
-
Everything is overclocked, so does not work reliably in some cases. Analog front-end is a joke, and has strange offsets and gain issues that. I make an attempt to calibrate them out in the firmware, but the result is not perfect.
The stock firmware is just crap. Typical for this kind of product - UI that is unintuitive and frustrating to use. My firmware makes an attempt at a better UI, and generally it is functional, but would need more work.
If you need a unit that just works, then I personally would pass on this one. But if you are ok with it being a project, then it is more of less fine.
-
Ok, just the last thing, umm, I see there are three models
- 5Mhz
- 30Mhz
- 100Mhz
They look the same hardware, with different firmware, and in this case the last two are an overclocked "equivalent time" version of the first.
I am not sure, but I was considering the first one, the 5Mhz version.
Have you tried to not overclock your firmware? Is it still so bad?
p.s.
I also considered a couple of "USB-DSO" supported by Sigrok
- Rocktech BM102
- Hantek 6022BL (this also has 8chs LA)
But they seem problematic with "PulseView"
-
They are not the same:
https://translate.google.com/translate?hl=en&sl=ru&u=https://mysku.ru/blog/aliexpress/72062.html&prev=search
https://translate.google.com/translate?hl=en&sl=ru&u=https://mysku.ru/blog/aliexpress/77475.html&prev=search&pto=aue
-
All those models are fundamentally different. The only thing covered by this topic is FNIRSI-5012H, or equivalent rebranded devices, typically with "5012" somewhere in the name.
20 MSPS is pretty crap for 5 MHz bandwidth.
No, I have not tried to overclock. It would require dramatic redesign, since all the timings and hand-coded routines are all designed around fixed timings.
Overclocking works fine if it works on your device. All my units function fine, but I've seen reports from people having stability issues.
And its sampling rate is already pretty poor, slowing it down further turns it into a complete toy.
-
20 MSPS is pretty crap for 5 MHz bandwidth.
Talking about periodic signals, to create a waveform accurately, the DSO must gather a sufficient number of samples after the initial trigger. In theory a digital scope needs at least 2 samples per period, one full cycle of a regular waveform, to faithfully reproduce a sine wave; otherwise the acquired waveform will be a distorted representation of the input signal. In practice, using Sin(x)/x interpolation in a DSO needs at least 2.5 samples per period.
Assuming the firmware is not silly and really uses Sin(x)/x interpolation
Real time bandwidth = sample rate / 2.5
Therefore, 20M / 2.5 = 8Mhz, which is not too bad!
-
I am more afraid about the abuse of Equivalent-Time-Sampling in other DSOs.
I know, if I want "true" Real-Time I have to pay for it, that's why I bought a professional MSO.
-
Are you going to look at sine waves only? Then yes, sure. But if you are going to look at more complex signals, then you still will be be seeing sine waves only. Also those things don't have computational resources to do sinc(). They just show sampled points as is, with linear interpolation. The stock firmware on 5012H does some weird averaging when you zoom in too closely.
-
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.
-
Hi,
When it will arrive, please write here your impressions and a report about the DSO, please.
-
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-
-
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.
-
Oh wow- thanks for the quick reply and help Alex! Much much appreciated!
Nick-
-
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
-
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.
-
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-
-
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-
-
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.
-
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?
-
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.
-
OK I will go ahead and replace the MCU. That part is the easy part fort me :D
-
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
(http://)
-
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);
}
-
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.
-
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-
-
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-
-
- 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.
-
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 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-
-
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.
-
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?
-
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.
-
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 (https://www.ebay.com/itm/152587007700) 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.
https://www.youtube.com/watch?v=5vVAewYdqn4 (https://www.youtube.com/watch?v=5vVAewYdqn4)
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
-
I really don't have time and interest to mess with this. Especially adding measurements, which are always annoying on the button-based interface.
But also, do you really need scope and a full ADC for TDR? Is not it something that can be done with a couple comparators and a reasonably fast MCU? If this is something you need to do over and over, having a dedicated tool seems like a better option.
And I'm sure tools like this exist already anyway. I had an Ethernet cable break detection feature in a BIOS 15 years ago. There have to be dedicated tools for this.