Hantek DSO2xxx schematics

[pcprogrammer]

I decided to look into the Hantek DSO2xxx series because I like the hardware as a basis to play with.

To get an understanding of it all reverse engineering of the schematics seems the logical first step, so that is what I started with. First up is the "User Interface Board" as it is the simplest to tackle. In the other threads about the Hantek a touch panel connector was mentioned and there is indeed room for it on the board. I soldered a connector onto it and placed a touch panel in front of the display. The rubber push cushions can be turned to lower them. They have two slots in them to slide over the metal holder.

Will post some pictures of that later.

An observation of the schematics shows how they handle the buttons and the encoders. They scan them in a matrix. This might explain why the response sucks when turning an encoder.

For the user interface part I made three sheets. The first shows the connectors and the LCD power setup, the second shows the buttons and the encoders and the third shows the LED's.

[gnuarm]

I don't understand what they are doing with the pots.  They are pots, right?  So what is the point of the diodes?  Are they measuring the voltage on the wiper arm?  It makes no sense to me.  Can you explain?

[pcprogrammer]

They are not pots but rotary encoders, so just two switches that are closed and opened one after the other. That is why the diodes are there. It works as a key scanning matrix. A problem with this design is that the buttons don't have the diodes so pressing two at the same time could result in not detecting one of them. (When they are on the same scan data line)

The HC4051 ic's work for both analog and digital signals. U3 is used to pull the scan lines low in following order and U2 is used to connect the scan data lines to the scanner. The HC393 is setup as a six bit counter and controls the scanning.

[pcprogrammer]

Here are some pictures of the touch panel fitted into the housing.







The rubber stoppers need to be swapped. On the picture below you can see the top one in its original orientation and the bottom one in the swapped orientation.

[DavidAlfa]

Interesting, but really, don't waste too much time with it, Hantek uses customized kernel, there're no sources, so adding new features will be almost impossible unless the functionality and its dependencies can be build as module.
We've been trying to implement networking through USB (RNDIS/ECM), the usb gadget could be compiled and loaded, but the kernel was built without networking support, and this feature cannot be added as module.

AFAIK, the scope already includes and loads the module tp-adc.ko, which probably includes the touch functionality, but knowing hantek, it very likely doesn't...
The Goodix GT911 driver is disabled in the devicetree (Check it here)

Code: [Select]

touchscreen@14 {
compatible = "goodix,gt911";
reg = < 0x14 >;
interrupt-parent = < 0x0c >;
interrupts = < 0x04 0x0a 0x02 >;
pinctrl-names = "default";
irq-gpios = < 0x0c 0x04 0x0a 0x00 >;
reset-gpios = < 0x0c 0x04 0x09 0x00 >;
status = "disabled";
};


[pcprogrammer]

I'm more interested in the hardware as a development and play platform. So write software from scratch without linux. Not as a replacement for the Hantek firmware, just for me as a hobby. I'm also interested in playing with the GOWIN FPGA.

The FNIRSI-1013D code is also bare metal no linux and I like it that way, even though it means implementing a lot of things yourself.

I did notice someone on the forum informing about the schematics a while back, and that is why I thought, lets post what I'm making here. The main board will take a bit of time since I also have to draw the symbols for some of the parts. The F1C100s I already did for the FNIRSI

[DavidAlfa]

Definitely baremetal could boost things up, but also make it very complicated, as every function needs to be done at low level and probably from scrap!
I think you already know, made a basic connection list in the hacking thread... but the ADC/FPGA are massive and have a *ton* of pins...
Adding all the current DSO functions would take years of work. For sure, Hantek uses its existing library, common-for-all, porting it for each hardware and enabling/disabling different parts.
I'll gladly help in what doesn't risk my hw! I don't think I'm opening my scope anymore, had to re-solder many pins as the solder is very soft, will warp and short very easily when probing with the DMM tips...

Be prepared, you'll enter the dangerous infinite loop of "Plz do this for me" and "Your FW is crap, why doesn't do what a $2000 DSO can?" 

[pcprogrammer]

Oh, and you'll enter the dangerous infinite loop of "Plz do this for me" and "Your FW is crap, why doesn't do what a $2000 DSO can?" 

You are right, that is something I'm not going into If I manage to make something useful it will be "it is this and nothing more" in a github repository.

[pcprogrammer]

Was a bit of a search to get the FPGA pin out above board

Not sure if there is a proper pin out document from Gowin, but all I found was UG229E "GW2AR series of FPGA Products Package & Pinout User Guide" and UG206-1.1E "GW2A/GW2AR series of FPGA Products Schematic Manual" and neither gave a proper pin out. Resorted to the schematic of a development board they make. (DK_START_GW2AR-LV18EQ144PC8I7_V1.1) and made my own symbol in EasyEda.

Still a lot of work to be done, but here is a sample of the FPGA, ADC and DAC so far.

The connections between these IC's were easy. Just follow the traces on the top side and count the pins.

Next up is the processor and the connection to the user interface board.

[pcprogrammer]

@DavidAlfa: Hi David, have you ever tried to hook a SD card slot to the test points on the main board?

For as far as I can see and measure the SD card interface of the F1C100s is not used, and for me that seems a missed opportunity. Sure I know they are penny f..ers, but how much of a difference does it make. They could have used a xGB SD card instead of the winbond 25N01G FLASH chip. This would have meant a good amount of onboard storage for images and easier maintenance of the OS and firmware.

The test-point numbers are the actual pin numbers on the F1C100s.

[DavidAlfa]

Nope I haven't, thought about it then realized...why?
I still would have to deal with the kernel, devicetree, root data, filesystem... Nobody cares, why would I waste my time, f** it 

I don't think you need probing:

Here's the F1C200s pinout asignment:

PIN   GPIO         NAME    FUNCTION              CONNECTED TO

6      GPIO96      PD0      TWI0_SDA(I2C)      U9 5, LemonTree 118
7      GPIO97      PD1      LCD_D3                  LCD
8      GPIO98      PD2      LCD_D4                  LCD
9      GPIO99      PD3      LCD_D5                  LCD
10    GPIO100    PD4      LCD_D6                  LCD
11    GPIO101    PD5      LCD_D7                  LCD
12    GPIO102    PD6      LCD_D10                LCD
13    GPIO103    PD7      LCD_D11                LCD
14    GPIO104    PD8      LCD_D12                LCD
15    GPIO105    PD9      LCD_D13                LCD
16    GPIO106    PD10    LCD_D14                LCD
17    GPIO107    PD11    LCD_D15                LCD
18    GPIO108    PD12    TWI0_SCK(I2C)       U9 6, LemonTree 117
19    GPIO109    PD13    LCD_D19                LCD
21    GPIO110    PD14    LCD_D20                LCD
23    GPIO111    PD15    LCD_D21                LCD
24    GPIO112    PD16    LCD_D22                LCD
25    GPIO113    PD17    LCD_D23                LCD
26    GPIO114    PD18    LCD_CLK                LCD
27    GPIO115    PD19    LCD_DE                  LCD
28    GPIO116    PD20    LCD_HSYNC            LCD
29    GPIO117    PD21    LCD_VSYNC            LCD
37    GPIO140    PE12    PWM0                     LCD BACKLIGHT
38    GPIO139    PE11    Input                      R196, V USB detect from computer
39    GPIO138    PE10    SPI_MISO               LemonTree 87
40    GPIO137    PE9      SPI1_CLK               LemonTree 15
41    GPIO136    PE8      SPI1_MOSI             LemonTree 90
42    GPIO135    PE7      Output                   LemonTree 88
43    GPIO134    PE6      Input                      Buzzer signal from LemonTree 21, R19
44    GPIO133    PE5      Output                   LemonTree 20, R101
45    GPIO132    PE4      EINTE4                   LemonTree 22, R278
48    GPIO129    PE1      UART0_TX              UART0
49    GPIO128    PE0      UART0_RX              UART0
59    GPIO64      PC0      SPI0_CLK               SPI NAND FLASH U2
60    GPIO65      PC1      SPI0_CS                 SPI NAND FLASH U2
61    GPIO66      PC2      SPI0_MISO             SPI NAND FLASH U2
62    GPIO67      PC3      SPI0_MOSI             SPI NAND FLASH U2
63    GPIO3        PA3      UART1_TX              UART1
64    GPIO1        PA2      UART1_RX              UART1 
65    GPIO1        PA1      TP_X2                    ?_?
66    GPIO0        PA0      Output                   V OTG enable

GPIO Table: GPIO table (Page 14):

Code: [Select]

GPIOC
PC0    SPI0_CLK      SDC1_CLK
PC1    SPI0_CS       SDC1_CMD
PC2    SPI0_MISO     SDC1_D0
GPIOD
PD18   LCD_CLK       SPI0_CS EINTD18
PD19   LCD_DE        SPI0_MOSI EINTD19
PD20   LCD_HSYNC     SPI0_CLK EINTD20
PD21   LCD_VSYNC     SPI0_MISO EINTD21
GPIOF
PF0    SDC0_D1       DBG_MS
PF1    SDC0_D0       DBG_DI
PF2    SDC0_CLK      UART0_RX
PF3    SDC0_CMD      DBG_DO
PF4    SDC0_D3       UART0_TX
PF5    SDC0_D2       DBG_CK

So, SD0 pins seem to be free (PF5-PF0, pins 53-58).
There're no vias in these pads, and there's no space under the SoC to put them, so they seem to be completely unused.
Looks like they routed the unused pins to test points, just like UART1... good.

SD1 pins (PC0-PC2) are used by SPI0, for the SPI nand.
Alternative SPI0 pins are used for the LCD (PD18-PD21)

The easiest way to see the use of a pin is by reading Pn_CFG registers on the livesystem, then check the tables on the User manual (Page 117)

The registers can be accesed like normal memory from linux, so:
- PIO Base addr: 0x01C20800
- PF only has Configure Register 0 (Offset: 0xB4)

Code: [Select]

# devmem 0x01C208B4 32
0x00373733

Decoding 0x00373733:

Code: [Select]

RESV         DGB_CK    RESV    DIS    RESV    DGB_DO    RESV    DIS    RESV    DBG_DI    RESV    DBG_MS
000000000    011       0       111    0       011       0       111    0       011       0       011

So SD0 pins are used by the debugger. I don't think it's important, I'm sure you could set this register to interface the SD.
Reg bits for SD: 010  0  010  0  010  0  010  0  010  0  010

Code: [Select]

# devmem 0x01C208B4 32 0x222222

At least, I've tried and didn't got any issues.

[pcprogrammer]

Thanks David,

but my probing shows that

Code: [Select]

28    GPIO116    PD20    LCD_HSYNC            LCD
29    GPIO117    PD21    LCD_VSYNC            LCD

Are not connected to the LCD but to the touch panel as the reset and interrupt line. Apparently there are LCD panels that can operate without these sync signals. Have to verify it with both boards connected to be sure.

Also noticed that the other UART on the F1C100s is not used and fed into test points. They could have made a better design where the user interface hardware is not handled by the FPGA but with a separate MCU like FNIRSI did in the 1014D. Response would have been better for sure.

Your list does help on some pins I do not have yet, and confirm what I have so far.

Doing these reversals makes me wonder what designers are thinking. I can see better way's both in the Hantek and the FNIRSI's of doing things.

[pcprogrammer]

It is quite the job, but I'm getting along.

The digital side of the board is done, including the ADC and the DAC with it's amplifier circuit. Need to polish some sheets to finish things.

Verified that the LCD is indeed working without the vertical and horizontal sync signals. Pin 8 on the LCD connector is a mode pin that selects between just using the DE signal or the sync signals. Found the datasheet for it

This picture shows what I already incorporated into the schematics. Try to be accurate

[DavidAlfa]

AFAIK, I didn't probe the LCD signals, but extracted them from the config registers.
Check those pins with another dso to see if there're sync signals.
Sure, they might not be used or connected...

[pcprogrammer]

Did not do that yet, but have it on the list, because the touch panel won't like it if there is a signal on the reset line, and the MCU might not like being pulled low by the interrupt line of the touch panel when it is outputting a signal

I found some weird stuff done in the scope with the power supply TR line. Know it is a 50Hz signal (might be 60Hz in countries with this mains frequency) from the Hantek threads. It is routed to a 74 Schmitt trigger buffer and then routed to the FPGA on pin 128. Nothing weird there, but the output of the buffer is also used to control pull ups on the clock and load line for the led 74HC595 shift register. (U4 in the LED schematic)

Why I don't know, but it means they can only clock this shift register when the TR signal is high

[pcprogrammer]

For those interested, here is what I made of it so far.

On the FPGA I still need to fill in two pins which go to the analog part of the system.

What remains is the two analog channels with it's support hardware.

Edit: Fixed the capacitor polarity in the analog -5V supply.

[arturmariojr]

Wow! Great work! Many thanks for your big effort doing this!!!!

[pcprogrammer]

It is a bit of a mess that needs a lot of cleanup but here is the schematic for channel 1.

Was a bit of a job to find all the connections. Especially with these low value resistors beeping the connections is tricky. Have to look at the meter to see it being 0.000 instead of 0.005 or so.

I'm not very good with analog stuff so no idea if it all makes sense

[DavidAlfa]

Holy s..  , that's a lot of work!
Are you able to measure those pF...nF little caps?

[pcprogrammer]

Measuring the caps probably needs removing them from the board, which I don't want to do.

I have a cheap component tester (LCR meter) but doing in circuit measurements won't yield good results I think.

[morgan_flint]

Hello, pcprogrammer! Great job!!

If you think it's worth it, and after you consider the work is finished, maybe it would be a good idea to create a single .pdf with all the schematics where the labels, components, etc. would be in searchable text form. I'm not familiar with the program but maybe just printing to pdf from EasyEda would do the trick.

The main advantage would be that it would be possible to search for the different circuit labels so it would be fast and easy to follow the signal path between the different sheets.

Thank you very much for your work!!

[morgan_flint]

...I found some weird stuff done in the scope with the power supply TR line. Know it is a 50Hz signal (might be 60Hz in countries with this mains frequency) from the Hantek threads. It is routed to a 74 Schmitt trigger buffer and then routed to the FPGA on pin 128. Nothing weird there, but the output of the buffer is also used to control pull ups on the clock and load line for the led 74HC595 shift register. (U4 in the LED schematic)

Why I don't know, but it means they can only clock this shift register when the TR signal is high

Could this be some kind of 50-60 Hz PWM for the LEDs in the display board?

Talking about battery power conversions, I remember somebody posted on one of the other threads that, in the absence of the 50-60 Hz signal from the power supply, the scope wasn't working correctly. Maybe it's related to this strange use of the signal. But I also remember that I experimented with disconnecting the TR from the power supply to the main board and didn't notice any misfunctioning...

P.S: Here is the post where crysti reported the problem and here is the post where I said I did that experiment. The previous post includes a simplified power supply schematic

[pcprogrammer]

Hi morgan_flint,

you are welcome. and yes I can make a single PDF per board. I'm gathering datasheets in a github repository and will add the EasyEda files there too.
https://github.com/pecostm32/Hantek_DSO2000

But I have to finish the analog schematics first, which may take some time due to laying a terrace with "lauze" which are thin stones. A hell of a job that takes a lot of energy. Unfortunately the guy we found to do the job for cheap got a MRSA infection in his right hand and is no longer able to do the job, so have to do it myself.

Due to an overlap in component numbering I have to keep the two boards in separate projects, but I guess that is not such a big of a deal when one needs to work on the scope.

As soon as it is done I will post it here.

Regards,
Peter

[pcprogrammer]

...I found some weird stuff done in the scope with the power supply TR line. Know it is a 50Hz signal (might be 60Hz in countries with this mains frequency) from the Hantek threads. It is routed to a 74 Schmitt trigger buffer and then routed to the FPGA on pin 128. Nothing weird there, but the output of the buffer is also used to control pull ups on the clock and load line for the led 74HC595 shift register. (U4 in the LED schematic)

Why I don't know, but it means they can only clock this shift register when the TR signal is high

Could this be some kind of 50-60 Hz PWM for the LEDs in the display board?

Talking about battery power conversions, I remember somebody posted on one of the other threads that, in the absence of the 50-60 Hz signal from the power supply, the scope wasn't working correctly. Maybe it's related to this strange use of the signal. But I also remember that I experimented with disconnecting the TR from the power supply to the main board and didn't notice any misfunctioning...

P.S: Here is the post where crysti reported the problem and here is the post where I said I did that experiment. The previous post includes a simplified power supply schematic

I don't think it is a PWM for the LED's. It only affects the clock and load signal for the LED shift register. No idea what is done with the signal in the FPGA, but it might well be that if the signal is tied to VCC it just works. When tied to ground the LED's may or may not function. Depends on the output strength of the FPGA. Pull-ups versus pull-downs.

I ordered a longer flat cable for between the main board and the user interface board to be able to do measurements on the scope. Once it gets here I plan to look into these things.

[pcprogrammer]

Did channel 2 and hope the redrawing makes it more readable.

I'm not to familiar with the user interface and have a question about two of the control signals.

The first control signal switches the input relay and I named it CHANNEL2_FILTER, but I'm not sure to what menu item this belongs to. Then there is also a control signal I named CHANNEL2_X, which enables a capacitor to ground right after U28, so also looks like a filter. But again the question which menu item this belongs to.

Still need to cleanup channel 1 and the control signals sheet and number the sheets before it is done.

[tunk]

The first control signal switches the input relay and I named it CHANNEL2_FILTER, but I'm not sure to what menu item this belongs to.

Don't have a clue - could it possibly be the 20MHz bandwidth limit?

[pcprogrammer]

That was what I was thinking too, but then I noticed the other part with the cap to ground via the transistor. I guess that is an actual low pass filter.

Maybe when I start measuring on the thigh I can find out

[pcprogrammer]

Had to swap signal for the LCD on the connector between the two boards, so here are the latest schematics for the user interface board.

Also added the archive for EasyEda.

[pcprogrammer]

And here are the schematics for the main board.

[morgan_flint]

The first control signal switches the input relay and I named it CHANNEL2_FILTER, but I'm not sure to what menu item this belongs to.

Don't have a clue - could it possibly be the 20MHz bandwidth limit?

I also thought of that but, in that case, you should hear the really clicking when switching the bandwidth limiting on and off from the menus and, in my case, I can't hear it

[pcprogrammer]

I received the cable and have things setup to do measurements. Will see if I can find which setting controls this.

Edit: Found what is controlling that signal I named CHANNELx_FILTER. It has to do with the sensitivity. When you set the input sensitivity to 2 volts per division or below the relay is turned off. When you set it to 5 volts per division or above it turns on.

Looking at the schematic, it does add a resistive divider to the signal path. But also additional parallel capacitance. Guess I should rename the signal.

Edit2: The signal I named CHANNELx_X is indeed the 20MHz bandwidth limiting filter.

Also looked at the touch panel RESET and INT signals and these indeed have the LCD sync pulses on them. So to allow the touch panel to work within the Linux system a change to the LCD driver code or setup would be needed.

[DavidAlfa]

I tried disabling sync signals in PD config register 2 (PD20 & PD21 = disabled):

Code: [Select]

devmem 0x01C20874 32 0x00772222LCD kept working normally, so you can keep going.

Just to ensure the register was working, I disabled LCD_DE:

Code: [Select]

devmem 0x01C20874 32 0x00227222Then LCD_CLK :

Code: [Select]

devmem 0x01C20874 32 0x00222722
Both stopped the LCD from working correctly.
Disabling any Data pin affected the colors, as expected.

[pu6k1n]

Where did 1 GS/s come from if the ADC08D502 has a maximum conversion rate per 1 channel: 500 MSPS??? According to the scheme, the connection of both channels is absent. There is an input multiplexer inside the ADC, but is there a word about it in the datasheet?

[pcprogrammer]

That is why in the schematic the ADC08D500 is used. This one has the ability to sample one channel with both ADC's

The scope can only do 1GSa/s on a single channel. The moment you enable two channels the rate drops.

A copy of the datasheet is here:

https://raw.githubusercontent.com/pecostm32/Hantek_DSO2000/main/Datasheets/adc08d500.pdf

[pu6k1n]

What is the P5 "FEL" button for? Why stop memory?

[pcprogrammer]

The F1C100s MCU has a boot loader that can load code from FLASH (SPI), SD/MMC card or go into the so called FEL mode. In this FEL mode it is possible to connect the MCU to a computer via USB. On the PC there is a tool sunxi-fel, which runs under linux, with which it is possible to read or write the MCU registers and SRAM, but not the DRAM, because that needs initialization.

By disabling the FLASH the MCU will go into this FEL mode when powered up.

See the other threads about the Hantek for more information on this.

[pu6k1n]

Does anyone have a full nand w25n01g memory dump for dso2d15?

[DavidAlfa]

May I ask why do you need it?

[pu6k1n]

Look at how much the dumps in nand itself differ between models.

[DavidAlfa]

As far as I know, nothing else than cache/system.inf file.
Hantek platform-tools don't care about the model, rewrites the whole flash.
After that, you get unknown model, but all options become enabled.

Better you continue this in the hacking thread, this is only for schematic, let's keep everything tidy

[pu6k1n]

I copied the circuit completely from the DSO2C10 power supply unit, do not judge strictly 

[morgan_flint]

Hello, pcprogrammer!

I think I found an error in the schematics (Mainboard/External_Interfaces): R21 should be R16 and R16 should be R196.

I'm thinking of installing J4 for the serial port (or, maybe, a more practical connector), so I was inspecting this part of the board. BTW, I've been using the serial port extensively and SERIAL_READY signal seems to be unnecessary for it to work. What could be its purpose?

I've also noted that if the serial to USB is connected to the scope but not to the PC the boot procedure stops when showing the QR code and freezes there (maybe that's the purpose...).

Thanks for your (immense) work!

[pcprogrammer]

Hi morgan_flint, looks like you are onto something

Looking at the photo I used to do this work also shows that the connector is J2 instead of J4.

R21 needs to be named R16 indeed. Also noticed that R32 has a ohms value assigned, but since it is not on the board it will not be correct.

I will look into this further and modify the schematics.

The signal SERIAL_READY is connected to the F1C100s and I just named it as such because I think it is some handshake signal, but most likely not used in the software. The fact that the scope hangs when a USB to serial interface is connected, probably has to do with the boot loader. I have seen this happen on a Lichee nano too, when I was playing around with linux on a F1C100s. Not sure why this happens. Was in the time I was starting with the reverse engineering of the FNIRSI-1013D. Did not investigate it further since the FNIRSI scope does not use linux.

But good to know this, because I was thinking of integrating a CH340 USB to serial module in the scope, but if it would need to be connected to a PC to allow the scope to start is not what one wants

[pcprogrammer]

The schematic has been updated and uploaded to the repository.

https://github.com/pecostm32/Hantek_DSO2000/tree/main/Schematics

[DavidAlfa]

I'm convinced that what you call "serial ready" signal was actually used as some sort of system reset when the system hanged during development. Probably a hardware interrupt was set on pin value change.
The issue you're having is probably caused by the Rx line being pulled low by the unconnected (Thus unpowered) usb-ttl adaptor, causing random chars being received by the bootloader, entering the boot shell.

Also check there's a tiny via just over R32, in the trace going to the CPU.
It must be going somewhere else, your schematic seems to be lacking this.
I checked that back in the day, but can't remember, perhabs it also goes to the fpga reset pin (RECONFIG)?

[morgan_flint]

...The fact that the scope hangs when a USB to serial interface is connected, probably has to do with the boot loader. I have seen this happen on a Lichee nano too, when I was playing around with linux on a F1C100s. Not sure why this happens. Was in the time I was starting with the reverse engineering of the FNIRSI-1013D. Did not investigate it further since the FNIRSI scope does not use linux.

But good to know this, because I was thinking of integrating a CH340 USB to serial module in the scope, but if it would need to be connected to a PC to allow the scope to start is not what one wants

Just in case my memory was teasing me, I've just checked and it effectively hangs if powered on with the serial to USB not connected to the PC

I've also verified that if you connect it to the PC with the scope "hanged", the dialog that appears is the same that when you hit a key at the beginning of the boot procedure to stop it (see attached images, first one connecting USB after powering the scope and the second one keeping a key pressed during boot) so yes, it's the boot procedure that stops when USB is not connected (apparently this is equivalent to hit a key...).

Finally, this also may happen because the CH341A in my adapter is powered from the USB, not from the scope. I'll make an experiment on this and report back.

EDIT: Done! Tried powering up the scope with the CH314A connected to TX, RX and 3.3V but not to the PC and it didn't hang. I tested it three times because in one of the tests it also booted OK without 3.3V... maybe some loose connection or something, but most times it hangs on boot when TX and RX are connected to unpowered CH341. So maybe you can integrate the module into the scope as long as it's powered from the scope. I don't know if this will bring new problems when connecting USB to the PC with the scope on (of course, the module would have to be modified, removing the 5V to 3.3V regulator, for example)

EDIT 2: The CH341A module I'm using is the one known as "CH341A Mini Programmer (Black Edition)", modified for 3.3V interface

[pcprogrammer]

Also check there's a tiny via just over R32, in the trace going to the CPU.
It must be going somewhere else, your schematic seems to be lacking this.
I checked that back in the day, but can't remember, perhabs it also goes to the fpga reset pin (RECONFIG)?

It might well be that I missed that. I will see if I can trace it on the photos I have of the PCB. Not going to open up the scope though if it is not doable from the photos

[pcprogrammer]

I've also verified that if you connect it to the PC with the scope "hanged", the dialog that appears is the same that when you hit a key at the beginning of the boot procedure to stop it (see attached images, first one connecting USB after powering the scope and the second one keeping a key pressed during boot) so yes, it's the boot procedure that stops when USB is not connected (apparently this is equivalent to hit a key...).

This verifies what David wrote. A simple fix could also be to just ad a pull up resistor to the RX line without powering the module. But this is something for later to test.

Still very busy with the reversal of the FNIRSI FPGA.

[morgan_flint]

Also check there's a tiny via just over R32, in the trace going to the CPU.
It must be going somewhere else, your schematic seems to be lacking this.
I checked that back in the day, but can't remember, perhabs it also goes to the fpga reset pin (RECONFIG)?

It might well be that I missed that. I will see if I can trace it on the photos I have of the PCB. Not going to open up the scope though if it is not doable from the photos

Attached there is a photo of the bottom side of the PCB in that zone. Apparently, that via is not connected in the bottom side... Has this PCB intermediate layers?

[pcprogrammer]

Hi morgan_flint,

for as far as I know it is just a double layer PCB. I just checked it on the photos I used during the reverse engineering and found the same as you. Here is a capture from what I have with also the via marked where the trace continues in the direction of the MCU.

[DavidAlfa]

AFAIK it's 2-layer only, then it's a little layout bug made by the trainees at hantek 

[DavidAlfa]

Is it me, or the AWG output protection diode D5 placement was a VERY bad idea?
External peaks will go right away into the +-5V analog voltage without any limitation, potentially killing a lot of stuff.
The diode and/or traces/pcb will burn in no time, and if the diode opens the voltage will reach the amplifier anyways.

Such stupid design. Should be placed at the pin 6 of the amplifier, so R9, R11, R143 limit the current, yet protecting the amp.
In the worst case, the damage will be just a burnt resistor.

[pcprogrammer]

Yep would have been better. Always think twice before connecting something to this input/output.

[gnuarm]

Is it me, or the AWG output protection diode D5 placement was a VERY bad idea?
External peaks will go right away into the +-5V analog voltage without any limitation, potentially killing a lot of stuff.
The diode and/or traces/pcb will burn in no time, and if the diode opens the voltage will reach the amplifier anyways.

I'm confused.  There are resistors totaling 50 ohms in either path.  That's 100 mA if you apply 10V when using the AWG.  If using the external trigger, it's 100 mA at 8.3V. 

Such stupid design. Should be placed at the pin 6 of the amplifier, so R9, R11, R143 limit the current, yet protecting the amp.
In the worst case, the damage will be just a burnt resistor.

Am I looking at a modified schematic?  What you think it should be?  If so, I agree. 

Although, I have done exactly this on designs before.  If there is no option for series resistance, this is still an effective way to deal with static. 

Hmmm, you are making me rethink this.  The design I'm referring to runs the signals through an analog switch for isolation.  The diodes are to ±12V on the connector side.  The 12V supply is on the motherboard and is supplying 8 of these circuits plus the motherboard circuitry.  The -12V is very light.  The idea of sinking the excess voltage into the supply, is that the normal supply current is greater than the surge current.  The -12V rail likely has almost no current.  So that's not good.  I thought the switches were ESD protected internally, but I only find this for one of the part numbers used.  I guess that's why I added the diodes. 

This is to a connector used for serial ports of different standards (RS-232, 422, 449, etc), and audio.  Not likely to be driven by anything beyond ±12V other than static.  Are networking equipment rooms anti-static protected? 

I'm redesigning this card to replace EOL components.  I will need to take better notes this time.  They've asked me to use parts that are expected to be in production for 10 years.  Not sure how that's going to happen.  They have a service that evaluates parts for them.  It will be interesting to see what they come up with.

[pcprogrammer]

Am I looking at a modified schematic?  What you think it should be?  If so, I agree. 

Yep that is a modified schematic. The original is here: https://github.com/pecostm32/Hantek_DSO2000/blob/main/Schematics/Mainboard/Waveform%20Generator.png

[gnuarm]

Am I looking at a modified schematic?  What you think it should be?  If so, I agree. 

Yep that is a modified schematic. The original is here: https://github.com/pecostm32/Hantek_DSO2000/blob/main/Schematics/Mainboard/Waveform%20Generator.png

Ok, but 50 ohms is not going to make much diference really.  If the input is connected to +12V that's going to be 240 mA.  I use the diode clamp to prevent an ESD surge from reaching the chip inputs.  Fed into the power line means the capacitance of the power bus will absorb most of the surge.  The devices themselves typically have ESD diodes into the power rails, so in reality, the added diodes are just protecting the on chip diodes. 

[pcprogrammer]

And that is why the manual of the scope states that the allowed voltage on the trigger input is 0 - 3.3V only.

External: External trigger input, it is on the front panel of the oscilloscope. The external trigger signal must be a 0-3.3V [CMOS] waveform.

[DavidAlfa]

but 50 ohms is not going to make much diference really

Really? The +-5V supplies have a load of about +600, -250mA.
Without resistor, a wire moves, the clip snaps, briefly touching 12V, but you have very low impedance path to +5V through the diode, being such small diode it'll will blow apart, and pray nothing else gets damaged.
With 50R in series, you'll have (12-5)/50=140mA max, the resistor will survive a quick "touch" instead destroying your frontend.
And if you hold the connection for longer, the resistor will dissipate ~1W, will act as a fuse, limiting the damage.

[gnuarm]

destroying your frontend

Thank you for making my case.

[enot]

I drew a diagram of the power supply (new type, Batch202207)

[eurotips]

The TR signal in power supply adapter is the synchronization with the AC network.  I would like to power scope from a LiPo battery. Is it necessary ?

[morgan_flint]

The TR signal in power supply adapter is the synchronization with the AC network.  I would like to power scope from a LiPo battery. Is it necessary ?

Probably not, but read here