HDG2002B AWG Firmware Reverse Engineering

[idpromnut]

What lives here will be the process of reverse engineering the firmware for both the SoC and FPGA on the HDG2002B. The result of this will be an open-source build environment, documentation and base firmware that should support most of the hardware features of the HDG2002B. A subsequent step would be to rebuild the AWG firmware UI + functionality for the 2002B.


Tools:

• Dev board: http://www.wayengineer.com/index.php?main_page=product_info&products_id=3066#.VExcjOcSVUU

Software/OS Details:

Looks like some variant of Android; there seems like support for the SC2416 SoC (To be confirmed)
DM9000 driver currently exists in some form in the Linux kernel
Kernel version: Linux anolis 3.2.35 #42 PREEMPT Wed Mar 26 12:49:52 CST 2014 armv5tejl GNU/Linux

[alex.forencich]

Let's get this party started!

GitHub repo is located here: https://github.com/alexforencich/hdg2000

Wiki is here: http://www.alexforencich.com/wiki/en/hdg2000/start

Reverse engineering repo is here: git@alexforencich.com:hdg2000re.git

(PM me for wiki and repo access)

Here are the hardware details so far:

Parts list:

J2: RJ-45 Ethernet
J3: MicroSD slot
J4: BNC (10 MHz in, FPGA T8)
J5: BNC (CH2)
J6: BNC (CH1)
J7: BNC (Mod in)
J8: BNC (10 MHz out)
J9: BNC (Sync out)
J10: BNC (Trigger, slow counter)
J11: BNC (Fast counter)
J702: FFC 10 pin (Keyboard)
J800: FFC 4 pin (unpopulated, touchscreen?)
J801: 1x5 header (SoC UART)
J900: FFC 40 pin (Display)
J901: 2x5 header (SoC JTAG?)
J902: USB host
J904: USB device
JP3: 1x6 0.1 inch header (U5 JTAG)
K1: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relay
K2: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relay
K3: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relay
K4: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relay
K5: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relay
K6: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relay
U3: Samsung S3C2416XH-40 SoC (ARM9 MCU, user interface)
U5: Xilinx XC6SLX16CSG324 FPGA (DSP and front end control)
U8: Micron MT47H64M16HR-25E:H 64Mx16 DDR2 SDRAM (FPGA)
U12: Micron MT47H64M16HR-25E:H 64Mx16 DDR2 SDRAM (FPGA)
U24: 74HC595 shift register (front end relay driver)
U25: LMX5080 prescaler (fast counter)
U26: 74HC595 shift register (front end relay driver)
U27: NXP 74HC4051 8-channel analog mux
U28: TI OPA140
U30: Unknown, presumed TI ADS8329 ADC
U32: Micron MT47H32M16HR-25E:G DRAM 32Mx16 DDR2 SDRAM (SoC)
U33: Analog Devices AD9747BCPZ 2 channel 16 bit 250 Msps TxDAC
U38: Samsung K9F1G08U0D 128Mx8 Flash (SoC)
U39: Davicom DM9000 100 Mbit ISA Ethernet controller (MAC and PHY)
Y1: 48 MHz osc for SoC
Y2: osc for DM9000
U3: 12 MHz osc for SoC
X2: 10 MHz osc for FPGA (FPGA pin T10)
X3: 10 MHz osc for FPGA (alternate)
X4: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relay
X5: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relay

Pinouts:

JP3: JTAG for U5
From marking end, +3V3, TCK, TDI, TDO, TMS, GND

Isolation/FPGA-SoC interconnection (U14/U13/P11)

FPGA pin - SoC pin

U14 mark

GND (R333)

(all RA10)
to FPGA
N9, R13 DIN - unknown
P12, R15 CCLK - unknown
P8 - unknown
GND - GND

U13 mark

GND (R334?)

(all RA9?)
to SoC
M10 - unknown
V17 DONE - unknown
U3 INIT - unknown
V2 PROGRAM_B_2 - unknown

+3V3 (R???)

+3V3 (R???)
GND (R???)
+1V8 (R???)
GND (R???)
+5V (R???)

J801: SoC UART
From marking: N/C, RX, TX, GND, +3V3

[alex.forencich]

Front end details:

FPGA clock source appears to be sourced from the 10 MHz reference oscillator.  Need to run ftjrev to figure out what pin. 

Cross isolation connection consists of 8 traces.  It appears the board is set up to use a pair of digital isolators, so four lines likely go one way and the other four go the other way.  The footprint U16 appears to be for a configuration flash.  R114 and R110 appear to isolate the configuration flash from the isolation pass through.  I presume that the isolation pass through is also connected to the FPGA configuration pins through R110 and R114 so that the SoC can configure the FPGA on boot. 

Front end relays are driven by U24 and U26 74HC595 shift registers, wired in series.  Relays are FTR-B3GB4.5Z-B10 DPDT single coil latching relays, so two pins are required per shift register per relay. 

FPGA is directly connected to DAC and both 64Mx16 memories.  I think if the FPGA configuration is built correctly, we could have a mode where one channel can get all 128M of memory.  That could be interesting. 

[alex.forencich]

Interesting document for how to implement a continuously variable fractional rate decimator: http://www.xilinx.com/support/documentation/application_notes/xapp936.pdf.  The reference design supports rates of 1/1 to 1/128.  This is almost exactly what would be needed to generate a variable output from the generator with a few changes. The idea is to take the arbitrary waveform (could be an internally generated standard waveform template) and convert the sample rate from whatever the user desires as an output sample rate to 250 MSa/sec.  Say if you have a waveform you want to play back at 10 MSa/sec, you need to upconvert it 25x to 250 MSa/sec and send it to the ADC.  This fractional decimator is designed to do the opposite for wireless communication purposes.  However, I think it will be possible to modify to do what is needed. 

Now, for standard waveforms, it would be useful to be able to go both ways.  A sinewave could be generated from a standard, say, 1024 point automatically generated waveform.  Upsampling (interpolating) by 2 would produce a 2048 point waveform that would end up being 1/2 of the original frequency.  Downsampling (decimating) by 1/2 would produce a 512 point waveform that would end up at 2x the original frequency. 

One very significant advantage of this sort of fractional rate decimator is that it becomes very easy to frequency modulate the output - just adjust the decimation factor by the modulating signal. 

[alex.forencich]

I now have a large number of FPGA pin assignments in a UCF file for the FPGA.  The only things I am missing are the RAMs and the ADC.  Does anyone have a board with an ADC (U30) that isn't missing its marking?

Edit: Hmm, the TI ADS8329 looks like a pinout match.  16 bit, 1 Msps SPI ADC.  Makes sense.  It's the fastest 16 bit ADC on digikey in 20-TSSOP, all the power and ground pins are in the right place, and the analog input is in the right place.  Seems like a match to me. 

I now have all of the FPGA pin assignments for everything but the two DDR2 64Mx16 memories.  That's going to be a fun one to figure out. 

[idpromnut]

@alex: didn't you already have the DAC part from the previous Hantek HDG thread?

Also, the DAC is not obscured: it is an Analog Devices TxDAC AD9747BCPZ.

Or is this a different DAC we're talking about?

[alex.forencich]

U30 is a small ADC on the board for the modulation input. It is not marked on my board or on the board images I found on the other thread. So I did a re-spec for it to see if I could get a match, and that ones was the only one that matched.

[alex.forencich]

Dang.  I probed a few pins on U8 with a very fine piece of wire, but gave up because it's a gigantic PITA.  Then I decided to run the MIG tool to see what the DDR2 example design looks like.  Turns out that the Spartan 6 FPGA has two DDR2 capable memory controllers built in.  And when I compared the pins I had probed to the ucf file in the example design, they matched exactly.  Looks like the board was designed to use the internal DDR2 controllers (not really all that surprising).  So I think we may be in business.  Also, it seems the internal DDR2 controllers support multiple ports (up to 6 32 bit ports per controller), which opens up a few interesting possibilities. 

[Cyber7]

Hi Alex, I've updated my parts list with yours and attached it below. For convenience, I've posted datasheets at: http://hdg2002b.simplesite.com/412251279. Also check this page for tools to dump the firmware via USB memstick or via JTAG and openOCD using my custom device config: http://hdg2002b.simplesite.com/412253302 Note that firmware 1.00.2 has a recovery option to restore the primary rootfs and kernel back to factory default within U-Boot. Works nicely.

Another alternate devkit is the FL2416: http://www.forlinx.net/?p=28&a=view&r=104 It includes a DM9000A for ether & a UDA1341TS for audio just like the Hantek AWG. Sadly there's no 2416 devkit emulation for for QEMU obb, though it would take some work to mod the mini2440 project into service.

I've traced one of the outputs the 74HC595 shift registers; I'll post schematics shortly. 2 pins per shift reg control the polarity of each relay coil. They select which amp stage is utilized of bypassed. X4/X5 turn the outputs on/off.

[Cyber7]

Guys, I suggest you look at Hantek's GPL source release for the DSO5000 series, as it is the same kernel rev 3.2.35.
See:http://www.hantek.org/asken/iaskdetail.aspx?id=2013051008532693] [url]http://www.hantek.org/asken/iaskdetail.aspx?id=2013051008532693[/url]

I'm not certain the AWG was built with an Android build per se; the only real android references I see are for the USB gadget framework for modules g_serial and g_android .

This AWG looks much like a Pontiac Fiero; the manufacturer had many spare parts on hand in their warehouse that were 2gen old, so they decided to build something that looks like a sports car...so long as you don't look too hard under the hood.

[Cyber7]

Here are my hand drawn output schematics. It does not include parts from the bottom of the PCB, which are largely decoupling caps or filters. The second page shows the relation between the relays and the HC595 pinout. I'm not sure about relay X? as I haven't traced the pads easily.

Oh, and in case someone has tools to do Boundary Scan analysis to spy on the 2416 (I don't), here's the BSDL too.

[lukier]

I like where HDG2002B is going  I've also got one two weeks ago and I'm quite impressed with it. I'm still waiting for the modding parts (LAN and HF counter).

Time permitting I would like to contribute as well, although rather on the firmware side, as my FPGA skills are rather basic and I suppose that's the place that would need the most work (memory controllers, DDS, digital outputs, counters, modulation ADC, all with careful place & route and a ton of simulations).

I didn't have a closer look on the HF counter yet (waiting for the frequency divider), but if I remember correctly the low frequency counter seems to be just typical input protection (2 diodes + resistor) going to some 74 series single gate (forgot which one, probably Schmidt) and then, presumably, straight to the FPGA. That seems unlike a typical frequency counter input with high impedance, attenuation, some opams, trigger offset setting etc. I suppose one cannot expect much from the instrument in this price range. Is the HF counter input any different?

With the new open source FPGA bitstream it would be great to have configurable gate time also below 1 s as well as AD9783 support (500 MSa/s replacement DAC).

On a side note: Now I'm also thinking about open source firmware for Hantek 4032L logic analyzer that I got recently. Hantek one is buggy and I couldn't get the original software to run under Wine, even with a mocked dll that's responsible for USB access. That's why I'm thinking about porting something like OLS Daemon Core  to HT4032L. This is also very capable hardware (plenty of sample memory), not only for the price but among USB logic analyzers. It has a Cypress EZ-USB chip, XC6SLX16 FPGA and two DDR memories, connected to built-in memory controller blocks (as in the waveform generator). There is a nice thread on the forum with a lot of reverse engineering done.

[idpromnut]

Guys, I suggest you look at Hantek's GPL source release for the DSO5000 series, as it is the same kernel rev 3.2.35.
See: [url]http://www.hantek.org/asken/iaskdetail.aspx?id=2013051008532693]http://www.hantek.org/asken/iaskdetail.aspx?id=2013051008532693] [url]http://www.hantek.org/asken/iaskdetail.aspx?id=2013051008532693[/url]

I'm not certain the AWG was built with an Android build per se; the only real android references I see are for the USB gadget framework for modules g_serial and g_android .

This AWG looks much like a Pontiac Fiero; the manufacturer had many spare parts on hand in their warehouse that were 2gen old, so they decided to build something that looks like a sports car...so long as you don't look too hard under the hood.

Yup, I saw that last night and I'm looking at that track as well. What I need to figure out is if there is an existing port for the 2416 for that kernel (and I think there is) as well as busybox. If so, we're in business

[fremen67]

Nice work guys ! I will try to find some spare time to help if I can.

The board that Hantek used as reference seems to be the TQ2416 (Information from Tinhead if I remember well) http://en.embedsky.com/product_info.php?cateid=112&id=179

Here is the dev board I have: http://www.armdesigner.com/EM2416.html
I bought it here :http://shop.kristech.pl/p/84/465/em2416-.html

QT Embedded seems to be distributed with a lot of S3C2440/2416 dev boards; This could also be a start for the fronthead.
http://qt-project.org/doc/qt-4.8/qt-embedded-linux.html

[idpromnut]

Speaking of the HF and LF counters, I would like to see if we can have at least one of them active along side the 2 outputs (rather than having to sacrifice your FGen to use its counter mode). This also brings up another point... we should probably collect the set of features that would be part of this effort, since I would see this going further than what Hantek did originally, not just "fixing it up" as it were.

@fremen67: sweet! I was hoping there would be a fairly standard SDK for the GUI. That dev board looks identical to the one I linked as well.

However, there is a downloadable firmware toolkit with the dev board you have... I wonder if it can build kernel images that work out of the box for the Hantek?  I'll give this a try I think.

[lukier]

Speaking of the HF and LF counters, I would like to see if we can have at least one of them active along side the 2 outputs (rather than having to sacrifice your FGen to use its counter mode). This also brings up another point... we should probably collect the set of features that would be part of this effort, since I would see this going further than what Hantek did originally, not just "fixing it up" as it were.

AFAIR Siglent generators do that, one of the outputs can be switched and works as a frequency counter input. With Hantek I believe there is no need to sacrifice anything because frequency counters, presumably, go to separate FPGA inputs (one with frequency divided with LMX5080M).

Speaking of frequency counters I don't understand why Hantek, with such a big LCD (for an AWG) doesn't display their readouts all the time somewhere in the corner or activated under one quick button and instead the user has to go to through settings, counter, enable etc and wait a second (gate time) to get a readout.

[fremen67]

However, there is a downloadable firmware toolkit with the dev board you have... I wonder if it can build kernel images that work out of the box for the Hantek?  I'll give this a try I think.

On the principle, I would think so. At least the nanddump of my HDG runs on this dev board. The problem would be for the missing drivers for the hardware which is specific to the HDG2002.

[idpromnut]

However, there is a downloadable firmware toolkit with the dev board you have... I wonder if it can build kernel images that work out of the box for the Hantek?  I'll give this a try I think.

On the principle, I would think so. At least the nanddump of my HDG runs on this dev board. The problem would be for the missing drivers for the hardware which is specific to the HDG2002.

That's the nifty thing.. all the basic stuff is there: I2C, SPI, LCD (assuming there is no hidden display driver on the board, but we should check that), SD, USB, RS232, it's all happening right on board the SoC itself. Good times.

[alex.forencich]

However, there is a downloadable firmware toolkit with the dev board you have... I wonder if it can build kernel images that work out of the box for the Hantek?  I'll give this a try I think.

On the principle, I would think so. At least the nanddump of my HDG runs on this dev board. The problem would be for the missing drivers for the hardware which is specific to the HDG2002.

That's the nifty thing.. all the basic stuff is there: I2C, SPI, LCD (assuming there is no hidden display driver on the board, but we should check that), SD, USB, RS232, it's all happening right on board the SoC itself. Good times.

Also, the connection between the FPGA and the SoC in the generator is only 7 wires.  It would be pretty easy to control the FPGA and analog front end from an external dev board - all you have to do is remove two resistor arrays and then attach some wires.  Not sure how useful that would be at this point, but it is something to consider.  (I did take of the resistor arrays on mine so the FPGA is isolated from the SoC for probing). 

[alex.forencich]

Speaking of the HF and LF counters, I would like to see if we can have at least one of them active along side the 2 outputs (rather than having to sacrifice your FGen to use its counter mode). This also brings up another point... we should probably collect the set of features that would be part of this effort, since I would see this going further than what Hantek did originally, not just "fixing it up" as it were.

That would be trivial.  It would also be possible to use both the LF and HF inputs at the same time. 

This also brings up another point... we should probably collect the set of features that would be part of this effort, since I would see this going further than what Hantek did originally, not just "fixing it up" as it were.

Sounds like a plan.  However, note that the Spartan 6 LX16 has only 32 hardware 18x18 multipliers.  So any filtering or other DSP operations will have to fit on to that.  One multiplier per channel will be consumed for amplitude vernier and AM modulation, leaving 15 per channel.  It should be trivial to add the channels together or AM modulate one with the other.  FM modulation is a completely different story - I will have to get fractional decimation figured out first.  But if that does what it is supposed to, then we should be able to feed one channel into the accumulator for that and get FM modulation.  It should also be possible to do I/Q modulation of some sort. 

[alex.forencich]

Speaking of the HF and LF counters, I would like to see if we can have at least one of them active along side the 2 outputs (rather than having to sacrifice your FGen to use its counter mode). This also brings up another point... we should probably collect the set of features that would be part of this effort, since I would see this going further than what Hantek did originally, not just "fixing it up" as it were.

AFAIR Siglent generators do that, one of the outputs can be switched and works as a frequency counter input. With Hantek I believe there is no need to sacrifice anything because frequency counters, presumably, go to separate FPGA inputs (one with frequency divided with LMX5080M).

Speaking of frequency counters I don't understand why Hantek, with such a big LCD (for an AWG) doesn't display their readouts all the time somewhere in the corner or activated under one quick button and instead the user has to go to through settings, counter, enable etc and wait a second (gate time) to get a readout.

The trigger/low frequency counter input is on FPGA pin V12 and the prescaled counter input is on FPGA pin T14.  So this would be trivial. 

[lukier]

Also, the connection between the FPGA and the SoC in the generator is only 7 wires.  It would be pretty easy to control the FPGA and analog front end from an external dev board - all you have to do is remove two resistor arrays and then attach some wires.  Not sure how useful that would be at this point, but it is something to consider.  (I did take of the resistor arrays on mine so the FPGA is isolated from the SoC for probing). 

It maybe useful to split the FPGA development from the firmware (after agreeing on some protocol) to reduce dependencies and parallelize work.

I don't have the board at hand, but I can take a guess that these 7 lines are probably SPI for communication, also working as Slave Serial bitstream upload and extra signals are probably things like PROG_B or INIT_B. If I'm correct then it would be possible to desolder resistor bridges and wire a FTDI High-Speed chip doing SPI and GPIO so for the FPGA testing can be done with a PC and scripts, not depending on SoC firmware and dealing with cross-compiling tests.

[alex.forencich]

Also, the connection between the FPGA and the SoC in the generator is only 7 wires.  It would be pretty easy to control the FPGA and analog front end from an external dev board - all you have to do is remove two resistor arrays and then attach some wires.  Not sure how useful that would be at this point, but it is something to consider.  (I did take of the resistor arrays on mine so the FPGA is isolated from the SoC for probing). 

It maybe useful to split the FPGA development from the firmware (after agreeing on some protocol) to reduce dependencies and parallelize work.

I don't have the board at hand, but I can take a guess that these 7 lines are probably SPI for communication, also working as Slave Serial bitstream upload and extra signals are probably things like PROG_B or INIT_B. If I'm correct then it would be possible to desolder resistor bridges and wire a FTDI High-Speed chip doing SPI and GPIO so for the FPGA testing can be done with a PC and scripts, not depending on SoC firmware and dealing with cross-compiling tests.

That is exactly what I was getting at.  The pin assignments along the isolation footprints are as follows:

FPGA pin - SoC pin

U14 mark

GND (R333)

(all RA10)
to FPGA
N9, R13 DIN - unknown
P12, R15 CCLK - unknown
P8 - unknown
GND - GND

U13 mark

GND (R334?)

(all RA9?)
to SoC
M10 - unknown
V17 DONE - unknown
U3 INIT - unknown
V2 PROGRAM_B_2 - unknown

+3V3 (R???)

+3V3 (R???)
GND (R???)
+1V8 (R???)
GND (R???)
+5V (R???)

Some of the pins are connected to two FPGA pins.  This is likely so that the FPGA configuration can be loaded from a config flash (not currently populated) at boot, and that interface will not interfere with the SoC interface. 

It's also possible to come in from a different interface altogether - e.g. the digital out port on the front.  It's connected directly to FPGA I/O pins via some resistor arrays. 

[idpromnut]

Also, the connection between the FPGA and the SoC in the generator is only 7 wires.  It would be pretty easy to control the FPGA and analog front end from an external dev board - all you have to do is remove two resistor arrays and then attach some wires.  Not sure how useful that would be at this point, but it is something to consider.  (I did take of the resistor arrays on mine so the FPGA is isolated from the SoC for probing). 

It maybe useful to split the FPGA development from the firmware (after agreeing on some protocol) to reduce dependencies and parallelize work.

I don't have the board at hand, but I can take a guess that these 7 lines are probably SPI for communication, also working as Slave Serial bitstream upload and extra signals are probably things like PROG_B or INIT_B. If I'm correct then it would be possible to desolder resistor bridges and wire a FTDI High-Speed chip doing SPI and GPIO so for the FPGA testing can be done with a PC and scripts, not depending on SoC firmware and dealing with cross-compiling tests.

Yup, that's the idea. There are three "big" pieces right now: the FPGA code, the firmware (UI, etc) and the OS/environment. Since the firmware is "more trivial" than getting either of the FPGA code or the OS/environment built, that was the focus first for a quick technical challenge de-risking perspective.

I know the firmware+UI will actually be a fairly complicated part (because of the damn details), but those parts are also what would be more likely to be written/modified/extended by someone else once the base is there. Also, I figure that the initial UI will look pretty crappy; it would go through a series of iterations to evolve towards the "final" release I would think.

[alex.forencich]

DAC works under FPGA control!  This is simply a 65536 level (16 bit) ramp on the 250 MHz clock. 

Right now, I am trying to figure out how to get reference clock switching working without resetting the memory controller.  I may have to run the DAC from it's own clock domain that can switch its ref clock, and then run everything else in a different (and slightly faster) clock domain.  Perhaps the DAC and DSP can be in one domain and the memory controller and SoC interface can sit in an unswitched domain, with FIFOs in between.  That may be the most sensible solution.