Hantek - Tekway - DSO hack - get 200MHz bw for free

[tinhead]

here we go ...

A complette schematic of Hantek / Tekway hw revision 1.02 and 1.0.3

attached PDF file, if someone need it as Altium version please let me know.

In the schematics are all modules (from PSU to 1kHz out) included, double checked,
however if you find an error let me know please.

I hope i will find time to create similar schematics of HW revision 1.0.7, however not yet, i'm waiting
for these new BM/BMV models (as i think they hw 1.0.7 based)

Have fun!

[A Hellene]

This is a wonderful piece of work, tinhead!
Thank you!

Now, I guess that I will have to run to catch up with you, regarding my abandoned Rigol schematics project!


-George

[marmad]

Amazing work, Tinhead.

I am thinking right now of jumping to the Hantek scope (returning the damn flickering screen Rigol).  Do you know what the latest word is on the SDK?

[rf-loop]

This is wonderful  work!

This is really useful also for service these scopes.

Thank you tinhead!

------

Do anybody have any knowledge or experience about external monitor for this scope?
Something littlebit like this VGA Converter Module for mini2440 S3C2440 ARM9 Board
.  Is it possible to connect? Example in use where want more big display and not at all use own TFT.

[amigo]

tinhead,

[saturation]

A googol of thanks, tinhead, for the schematics! 

[colinbeeforth]

Ah! tinhead, you are such a gentleman!  Many thanks for the circuit information, it helps hugely to understand how this machine works.  Thank you again!
Colin

[Gall]

Many, many, many THANKS!!! Wonderful! I'm really impressed.

[ECL]

A complette schematic of Hantek / Tekway hw revision 1.02 and 1.0.3

Wow, a truly massive effort!!!

Thanks tinhead, for all of the parts you lifted, nights you spend buzzing out traces,
eye strain, mouse cramps, solder burns, blood loss, grumpy spouse(s), and most of all,
thanks for sharing! 

It will help us all to contribute, and piggy-back on your efforts,

ECL  -K

[tinhead]

yeah, it was a bit more work than expected, probably it would be easier and cheaper to
ask kikitronix (ebay 280312142026) instead of pinging two weeks long the PCB.

[Gall]

Hm. Why CPLD? Why not FPGA only? Did they save some pins? They seem to have XBUS which is quite wide.

[tinhead]

Hm. Why CPLD? Why not FPGA only? Did they save some pins? They seem to have XBUS which is quite wide.

pick one or more:

- FPGA full
- bigger FPGA costs more than extra CPLD
- Timing for SRAM important
- semi parallel data transfer
- FPGA not full but timing constraints not allowing to have these additional blocks within FPGA
- others (like Rigol) are using CPLD too (lazy developer? no i don't think so, but there is a reson)

Xbus seems to be 16 bit + 3 bit control, all these CPLD pins are on input (when i disable FPGA).
Address counter probably triggered by FPGA, i have to check that in detail.

[nukie]

Tinhead - I am speechless... all I could say is, thank you for your work and support to make this wide screen DSO so valuable.

[tinhead]

Tinhead - I am speechless... all I could say is, thank you for your work and support to make this wide screen DSO so valuable.

you welcome, all of you. To be very honest i'm not doing this because of money (i hope my fiancée never check
all these invoices of dev boards, jtag and so on ) or because i hope on nice gift from Hantek or Tekway
(not that i will reject one, ehm now after i published schematics i will be happy if i don't get an asskick ...)
but only because i think these DSOs are good value for money.

Additionaly (i think)  i'm somehow responsible for better sales numbers, where on the other side i know they losing
some money because of the hack, so therefore my support as a kind of compensation.

[Gall]

Xbus seems to be 16 bit + 3 bit control, all these CPLD pins are on input (when i disable FPGA).
Address counter probably triggered by FPGA, i have to check that in detail.

Maybe XBUS is a 16-bit muxed address/data bus, with r/w, strobe, and mode (or r/w, address strobe, data strobe), also in charge of access to the logic analyzer stuff?

Just my guess, though... You might have to put a logic sniffer to see what's going on between the FPGA and the CPLD.

The important thing is to know what's inside CPLD.

There is a possibility to write alternative software from scratch. Worst case scenario is developing FPGA firmware from scratch too. It is not possible for CPLD and it is unwise to reflash CPLD.

My first guess was that CPLD acts as a bridge between ADCs, MCU and SRAM while FPGA is doing control job. Now I see that it isn't. It is possible that XBUS is just multiplexed ADC output. But this does not explain why XBUS has only 16 wires and why it isn't connected directly to 32 bits of SRAM data bus.

I do not think that CPLD is doing some complex thing. More likely that it's just a couple of latches and/or demuxes or something like 8255.

The good thing is that there's no need to use CPLD to talk to the ADC. But there will be no memory buffer.

BTW, do these low-memory scopes have CPLD too? I noticed that Atten doesn't have a SRAM chip on the board, just empty place. Is it possible that CPLD is turned off in short-memory mode?

[tinhead]

There is a possibility to write alternative software from scratch. Worst case scenario is developing FPGA firmware from scratch too. It is not possible for CPLD and it is unwise to reflash CPLD.

as we speek about software, do you got my PM about SDK?

The good thing is that there's no need to use CPLD to talk to the ADC. But there will be no memory buffer.

in current design no because the data will be shifted over CPLD, there is no physical data bus connection
between SoC and FPGA.

BTW, do these low-memory scopes have CPLD too? I noticed that Atten doesn't have a SRAM chip on the board, just empty place. Is it possible that CPLD is turned off in short-memory mode?

no idea, i know that Atten CML does have one, but never saw the bottom side of CAL model.
Turned off for sure not, you will not find even single resistor which don't need to be populated.

[Gall]

as we speek about software, do you got my PM about SDK?

Now I did, thank you! Please see my reply.

The good thing is that there's no need to use CPLD to talk to the ADC. But there will be no memory buffer.

in current design no because the data will be shifted over CPLD, there is no physical data bus connection
between SoC and FPGA.

Oh really, now I see - LDATA doesn't go to the FPGA! SRAM does. Interesting.

BTW, do these low-memory scopes have CPLD too? I noticed that Atten doesn't have a SRAM chip on the board, just empty place. Is it possible that CPLD is turned off in short-memory mode?

no idea, i know that Atten CML does have one, but never saw the bottom side of CAL model.
Turned off for sure not, you will not find even single resistor which don't need to be populated.

There was even some cheaper than "CAL" model (CL? don't recall). I saw a photo of it's board (really poor soldering job!) and noticed that there is an unpopulated place instead of SRAM. Of course, there's a little possibility that the chip was just removed by the owner.

[walt]

tinhead

Can it be fixed booting  bug in the CPLD with
self-calibration relay ?

[tinhead]

heh, there are two "errors" in my schematics:
- FPGA sheet, U13 (Q. oscillator) have wrong value (QSMO_4200 - that's copy/paste error), should be 100MHz
- FPGA sheet, RA06_1 have no value, should be 4 x 1k
- many ferrite bead have no values, well go figure, from what i measured they Wuerth 742792038 could be good.
- on Front Panel sheet UF4 have no decoupling cap, should be 100nF

Someone asked my what are the LX1-LX7 on Power Distribution sheet - the answer is "nothing", that's just
the piece of wires between PSU and main PCB. 

tinhead

Can it be fixed booting  bug in the CPLD with
self-calibration relay ?

walt,

we don't have CPLD design from hw0 (where this is working) nor hw1007 (where seems to be bug inside)
and i doubt Hantek/Tekway will provide us one (because then you/others can easy clone their DSO).
But even if we would have both designs, there is no warranty that hw0 design will work on hw1007 board,
this can be only fixed/answered by HanTekway - and i doubt they will even answer it. Not because they
don't know/wish (what) to answer, but because what's next ? Recall action ? Definitely not, a simple
answer is just don't connect any signal while booting and your fine.

And if you really have to boot with signal connected to DSO (for what? the only case might be to be proteced while
DSO crashed) and wish to fix it now, then an inverted RC combination on 595 (in each input channel) will help you.

[A Hellene]

Ah, do not worry, tinhead! Copy mistakes are in order when reversing even a single-side PCB --not a six-layer one!

For example, I have also spotted a couple of these errors in the Rigol schematics I have posted: The Comparator Hysteresis driver in the "DAC, Demux, Sample & Hold and Buffer" sheet actually is a driver with a 5V0 to 3V3 level-shifter section implemented. By the way, I have de-soldered, cleaned-up and re-balled the Cyclone III FBGA chip, and when I will find some spare time I will draw the digital schematics sleets, too! You see, Rigol has a couple more DAC output signals (a 500.00mHz triangular (not sawtooth) waveform output and a waveform_start(?) signal extra circuitry that do not make any sence to exist in the analog section) that cannot be traced anywhere in the PCB; so, I removed the FPGA to see if these "blind" signals are fed into the Cyclone III.

Though I have not reversed the digital section of the Rigol yet, I think that the Lattice LUT (as well as the CLPD in your device) are RAM address lines generators for the FPGA configuration (which does not seem to have a dedicated address bus for the config. memory, so it probably clocks an external address-bus generator) and the BlackFin that cannot address the 22bit-wide boot-up Spansion FLASH memory alone because it has a 20-bit wide address bus hardware. But I could be wrong; I cannot really tell until I fully reverse the PCB...


-George

[ECL]

I would really appreciate a tutorial!

I stumbled across this video a while back.  It does a good job of outlining the process:



ECL  -K

[tinhead]

Nice thanks!

What about de/re-soldering the BGA, then?

i'm using hot air (if i'm lazy) or IR Rework Station (when BGA bigger and black) or
Hot Air/IR Reflow Oven (when BGA expensive or silver). For such Cyclone III hot air will work fine,
for soldering too (BGA not that big, pitch 1mm), IR rework + bottom heater of course too (because the BGA is black).

[A Hellene]

What?!?
I am curious to know how do you do that?

With patience!

Allright! Using my home equipment:

I think is is time for a short tutorial on the BGA and Flat Pachage rework process, using home equipment:

Equipment used: A hot-air rework station, a soldering iron, soldering wick (ERSA 2mm/3mm/4mm wide), flux paste (I prefer the RMA flavor but I've only found a no-clean syringe container at the local stores -that is fine for this job), SMD rework solder-wire (sub-millimeter Alpha-Fry 62/36/2) and flux soldering paste (EDSYN 62/36/2 no-clean).
Remember that the activated flux (RA/RMA) based products have only a few months self-life, even if stored in the refrigerator.

This is the rework strategy:
1. Preheat the PCB using 130 degrees hot air for 2-3 minutes, to avoid any thermal expansion artifacts,
2. Use conventional (kitchen) aluminium foil to protect the surrounding components, by cutting off a small window to expose ONLY the target chip to the hot air flow,
3. Desolder the BGA using 300..320 degrees hot air, remove the chip and wait for everything to cool down,
4. Clean the old solder, holding the BGA package in a small plastic vice using solder wick and lots of flux; always clean the used flux (I use medical alcohol of 95 degrees or better),
5. Clean the PCB, as above,
6. Reball the BGA with the soldering iron, Ag-containing solder-wire (I use 62/36/2) and lots of fresh flux; always clean the used flux,
7. [Optional step] Reverse the PCB (that takes tiiiiiiime...),
8. Reball the PCB pads as well, as in step (6), since chip re-balling has not provided the pads with enough solder,
9a. Carefully apply flux soldering paste on the PCB pads only and flux at the chip pads, or
9b. Apply flux in lack of flux soldering paste,
10. Carefully place the BGA package on the PCB (in a single move, if possible) and
11. Preheat the whole PCB area around the chip using 130 degrees hot air for 2-3 minutes,
12. Raise the hot air temperature at 280..300 degrees and apply it to the chip in a slow circular motion,
13. Wait for the molten solder surface tension to move the chip in place when the solder melts,
14. Tap the chip gently towards the PCB, to make sure that all its pads are in contact with the solder underneath,
15. Remove the hot air and wait for everything to cool down naturally (by themselves); always clean the used flux, and
16. Done! Power the device up.

Right now I am at the seventh step...


NOTE: It is not as difficult as it sounds to be; but you need to practice enough before daring to touch your actual device without destroying it!

A second note is about the chip size: As a rule of thumb, use a hot air nozzle of half the diameter of the chip size. For chips smaller than 20mm x 20mm you may skip the PCB preheating step, only if the PCB is very thin. Unfortunately, this is not the case with Rigol's mainboard.

A third and very important note: Always know what you are doing. Always use your common sense! Miracles happen only in fairy tales...

Finally, remember that a good tool is NEVER expensive enough to have it. Just consider the possible extra cost of a damage done by using cheap ("affordable" in the marketing jargon) tools...

-George


[EDIT]: Moved the last part, to avoid further hijacking of this thread.

[tinhead]

ahh, you using the ugly method (self-made "balls"). I tried it once, for K4S561633F because i didn't had right balls here.
The first run was "disaster" (because of the DIE encapsulat in the middle or the RAM chip), second run was finally
working - few weeks later this board started to crashing so i had to resolder again (with proper balls),
since them (more than a year) the board is working (24/7).

Therefore i can only say, buy proper balls, they didn't cost that much to risk the FPGA. Sure the best is to have reballing
set with stencil to place balls, but believe me, even without stencil you can easily place them one by one.
Just put a bit of flux on FPGA - note too much and they will "swim" away, to less and they will not stay in place when
using hot air - better is to use IR (or whatever oven for reballing) - watch them careful during this process, when one
starting to move around remove it and place new one (with tweezers or preheated soldering iron).

[A Hellene]

Thank you, tinhead!

This is a great idea! Re-balling manually the BGA chip with standard solder balls is the best solution, in order to have a homogeneous and uniform solder quantity on every pad! Without even the need of the special stencil equipment!

All I will have to do is to wait for the local stores to open after their summer break; or, to place an online order. But, something tells me than I may have not yet finished reversing the PCB...

Anyway, your idea is marvelous! Thank you, again, for the solution you gave me!


- George