HDG2002B AWG Firmware Reverse Engineering

[alex.forencich]

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.

Scratch that, each port of the memory controller can sit in its own clock domain, and the clock domain crossing FIFOs are already contained in the memory controller.  This means that the actual memory controller can run from a completely different clock source than the rest of the logic.  So that means the FPGA can be configured so that the memory controller always runs off of the internal oscillator, and the rest of the logic can flip-flop over to the external reference when it is applied.  Sweet!

[Cyber7]

I've worked out most of the front panel keypad scan codes & LED control by placing a logic analyzer on J702. It uses I2C for comms. I'll post the ScanCodes & a couple of traces tomorrow. Funny thing is the U800 EEprom; perhaps it is a record/playback FIFO for the scancodes?

Hantek HDG2002B AWG Front Panel KeyPad Protocol
-----------------------------------------------

I2C Protocol on J702 pins 7 (SDA) & 9 (SCL)

Read  - Key ScanCode = 0x55 + (Keycode Byte)
Write - LED State    = 0x55 + (LEDcode Byte)

Pin out for J702:
-----     --------------------------------------------------
Pin1      Keypress @ Keypad U26 Pin 43 P5.7 (Goes active high on kepress)
Pin2      unknown  @ Keypad U26 Pin 51 P1.2 (seems always low)
Pin3      unknown  @ Keypad U26 Pin 45 P2.0 (seems always low)
Pin4      +3.3V
Pin5      +3.3V
Pin6      GND
Pin7      SDA to/from Keypad U26 Pin 50 P1.3 & U800 EEprom Pin 5
Pin8      unknown  @  Keypad U26 Pin 46 P1.7
Pin9      SCL to/from Keypad U26 Pin 49 P1.4 & U800 EEprom Pin 6
Pin10     GND 
-----     --------------------------------------------------

U26  = Custom MSP430F413 series microcontroller marked LSD4F8108 (aka MSP430V111IPM)
U800 = Microchip 4L64I EEPROM 64 Kbit K x 8-bit memory with a 2-wire I2C interface

[alex.forencich]

So, it looks like they have a whole 8 bit R2R DAC on the board for the sync out. Unfortunately, it seems to be connected to the sync out through a comparator and not an amplifier, so it can really only produce square waves.  Sigh.  The device in question is U44 marking code C14A in a SOT23-5 package.  Appears to be an LMV7219 comparator.  Why bother installing 16 resistors and a two stage LC filter if you're just going to chuck the output through a comparator? 

[idpromnut]

@alex: can you suggest a reasonable repo layout (since you've written both software and "hardware" before)? I can set up the repo if you want, or you can, up to you.

[Marco]

So, it looks like they have a whole 8 bit R2R DAC on the board for the sync out. Unfortunately, it seems to be connected to the sync out through a comparator and not an amplifier, so it can really only produce square waves.  Sigh.  The device in question is U44 marking code C14A in a SOT23-5 package.  Appears to be an LMV7219 comparator.  Why bother installing 16 resistors and a two stage LC filter if you're just going to chuck the output through a comparator?

To get sub-clock-cycle time resolution.

[alex.forencich]

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).

Gate time is trivial, but AD9783 support is simply not possible.  The board itself is not wired for LVDS support.  The data traces are not routed in length matched pairs and the pins they are connected to are not paired off correctly.  For example, P1D0 is connected to IO_L33N_0 and P1D1 is connected to IO_L34P_GCLK19_0.  P1D0 corresponds to D8N and P1D1 corresponds to D8P.  L33N can be paired with L33P, but not with L34P.  So it is simply not possible to switch the DACs without laying out a new board. 

[alex.forencich]

@alex: can you suggest a reasonable repo layout (since you've written both software and "hardware" before)? I can set up the repo if you want, or you can, up to you.

Repo is here: https://github.com/alexforencich/hdg2000

[lukier]

Gate time is trivial, but AD9783 support is simply not possible.  The board itself is not wired for LVDS support.  The data traces are not routed in length matched pairs and the pins they are connected to are not paired off correctly.  For example, P1D0 is connected to IO_L33N_0 and P1D1 is connected to IO_L34P_GCLK19_0.  P1D0 corresponds to D8N and P1D1 corresponds to D8P.  L33N can be paired with L33P, but not with L34P.  So it is simply not possible to switch the DACs without laying out a new board.

I remember someone mentioning AD9783 being pin compatible, that's why I thought it may be possible to use this part with the open source firmware. Too bad the traces don't match, thanks for checking that.

On the repo I think we may need multiple repositories linked together with git submodules. One for the FPGA stuff, other for base OS (u-boot, kernel, libraries etc) services and another one for the actual Qt software. Each of these submodules would have subdirectories for components (for FPGA, e.g: memory interface, PicoBlaze (?), DDS, Frequency Counter etc., for the firmware, e.g.: GUI, Hardware Access API, Remote Protocols API (USB - TMC/ETH - LXI) etc.). Each submodule and preferably component would have tests subdirectory for GTest/GMock unit/components tests. FPGA has simulation testbenches for that.

We might need to be careful with putting Xilinx CoreGen outputs in GitHub, I remember I saw one open source project that had to remove them as Xilinx generated stuff is under different license. Shouldn't be a problem to keep precompiled bitsteams I suppose.

I'm thinking about getting this dev. board next month and I'll try to cross-compile minimal Gentoo and see how this embedded Qt works. Or, if I remember correctly from the original thread, the u-boot in the AWG allows booting from the microSD - might be good for initial tests of the base OS image and I would save some money this way

[alex.forencich]

I remember someone mentioning AD9783 being pin compatible, that's why I thought it may be possible to use this part with the open source firmware. Too bad the traces don't match, thanks for checking that.

The pins are physically in the same locations, but unfortunately the electrical requirements are very different.  The faster DAC requires LVDS differential pairs.  The slower DAC is single ended LVCMOS.  If you route differential pairs, then you can have issues with crosstalk if you try to use LVCMOS over it.  Also, getting the required data rate out of a spartan 6 is not going to be fun, and it likely wouldn't be possible to do the polyphase filtering required for a very clean output. 

On the repo I think we may need multiple repositories linked together with git submodules. One for the FPGA stuff, other for base OS (u-boot, kernel, libraries etc) services and another one for the actual Qt software. Each of these submodules would have subdirectories for components (for FPGA, e.g: memory interface, PicoBlaze (?), DDS, Frequency Counter etc., for the firmware, e.g.: GUI, Hardware Access API, Remote Protocols API (USB - TMC/ETH - LXI) etc.). Each submodule and preferably component would have tests subdirectory for GTest/GMock unit/components tests. FPGA has simulation testbenches for that.

What about subdirectories?  Personally, unless there is a very compelling reason to separate the components into completely independent projects, I see no reason against using one large monolithic repository.  Also, I hate git submodules.  Whenever I need to import another repo, I use a subtree.  This way you only need to pull down one repo.  Then I add a small script to push and pull changes to the subtree directory wrt. the subtree repo.  It works very well and integrates better with git than submodules. 

We might need to be careful with putting Xilinx CoreGen outputs in GitHub, I remember I saw one open source project that had to remove them as Xilinx generated stuff is under different license. Shouldn't be a problem to keep precompiled bitsteams I suppose.

Take a look at the repo I set up; it's set up to only distribute the xco files for cores and then run coregen locally to generate the cores themselves.  This is all managed with makefiles.  I try not to include generated files in repos wherever possible. 

[idpromnut]

I agree on the single repo with the 3 sub directories containing the big pieces. It will make automating and release less of a pain in the butt. Also, there will be dependencies between at least the FPGA at the UI (and possibly any drivers that need to be written; Hantek seem to have written a driver to interface the UI with the front panel).

[Cyber7]

Not sure which is the best way to contribute into Github. I guess a fork then pull req to Alex?

Figured the keypad is low hanging fruit and in need of some I2C spying as the uC is a custom TI MSP. 

I've forked the project to https://github.com/Cyber7/hdg2000, added my documentation and I2C session logs to: https://github.com/Cyber7/hdg2000/tree/master/doc/Front%20Panel/Keypad I then reworked the docs section according to sub-unit of the AWG instead of vendor, then added all the datasheets and user guides I have.

I'll see about the custom kb driver next. BTW, is the project going to use DBUS for IPC like the official FW? http://www.freedesktop.org/wiki/Software/dbus/

Regarding the repo,

I can see the need for: --> U-Boot
                                    --> kernel
                                    --> fpga
                                    --> awg
                                           --> apps
                                                 --> test
                                                 --> vxi
                                           --> daemons
                                           --> drivers
                                           

[alex.forencich]

Not sure which is the best way to contribute into Github. I guess a fork then pull req to Alex?

Figured the keypad is low hanging fruit and in need of some I2C spying as the uC is a custom TI MSP. 

I've forked the project to https://github.com/Cyber7/hdg2000, added my documentation and I2C session logs to: https://github.com/Cyber7/hdg2000/tree/master/doc/Front%20Panel/Keypad I then reworked the docs section according to sub-unit of the AWG instead of vendor, then added all the datasheets and user guides I have.

I'll see about the custom kb driver next. BTW, is the project going to use DBUS for IPC like the official FW? http://www.freedesktop.org/wiki/Software/dbus/

Regarding the repo,

I can see the need for: --> U-Boot
                                    --> kernel
                                    --> fpga
                                    --> awg
                                           --> apps
                                                 --> test
                                                 --> vxi
                                           --> drivers
                                         

We can just pull from each other's repos with git.  All you need to do is add each one as a remote and then pull from it and everything will get merged.  For now I think that's the most straightforward method.  We could do pull requests later once we get more stuff working. 

As for the datasheets, I was trying to keep the repo size down by only adding ones which might be directly useful - the ones we're going to need to reference to develop the hardware and software. 

[alex.forencich]

I'm also thinking it might be a good idea to keep most of the reverse engineering notes separate from the repo.  The point is to make the repo into an alternative open source firmware, not a large repository of notes, board pictures, firmware dumps, and bus traces. 

I created a page on my wiki here: http://www.alexforencich.com/wiki/en/hdg2000/start

PM me your email addresses and I will set you up with write access.  I think putting these sorts of notes on a common wiki would be a bit better than shoving everything in the git repo. 

[Cyber7]

Understood; your's will be the final rep, and clutter should be reduced to a minimum. I just find an repo best suited as a poor-man's knowledge base/research library and note keeper, particularly when binary intermediary products, traces, images, etc are involved. Some wiki's don't make binary inclusion a friendly task.

ftjrev looks fairly nice; looks like it can do most of what can be done with Universal Scan, albeit, without the bells and whistles. And src to boot.

Glad to see you are using Verilog! I finally bit the bullet started into it 6 months ago with some waveshare devkits, and a dozen books. I've most of the bugs worked out of my first project: read DMX data and control 128 1amp channels of incandescent/led Christmas lights per Spartan 3E device.

[alex.forencich]

Understood; your's will be the final rep, and clutter should be reduced to a minimum. I just find an repo best suited as a poor-man's knowledge base/research library and note keeper, particularly when binary intermediary products, traces, images, etc are involved. Some wiki's don't make binary inclusion a friendly task.

ftjrev looks fairly nice; looks like it can do most of what can be done with Universal Scan, albeit, without the bells and whistles. And src to boot.

Glad to see you are using Verilog! I finally bit the bullet started into it 6 months ago with some waveshare devkits, and a dozen books. I've most of the bugs worked out of my first project: read DMX data and control 128 1amp channels of incandescent/led Christmas lights per Spartan 3E device.

Actually, perhaps what we should do with the repo is create multiple branches.  Then all of the reverse engineering notes can be stored in a separate branch, apart from the main code.  That could work nicely. 

I did not write ftjrev, I only modified it to add a few very important features.  I used ftjrev iprobe to piece together the ucf file currently in the repo.  I'm not familiar with universal scan, so I don't really know what it is capable of.  Basically, ftjrev iprobe lets me go poke around the board with a wire connected to the JTAG cable DBGRQ pin and it will tell me what pin that the wire is connected to.  So I can probe out connectors and interchip connections quite quickly.  I have not tried connecting it to the SoC yet, though - the JTAG connector is an odd pin pitch. 

VHDL is too verbose for my tastes.  I have been playing around with MyHDL a bit as well, though.  I don't think I will ever use MyHDL on an FPGA, but it is absolutely excellent for test benches.  Take a look at my other repos for some examples; I have a couple of verilog IP cores posted (UART and Mersenne Twister PRNG).  One project that I am currently working on is based on a Virtex 6 HXT 565 and it takes several hours to synthesize.  You don't want to have a problem in the internal logic somewhere as it is more or less impossible to debug on the FPGA!

[alex.forencich]

OK, I created a new branch called re and I am pushing all of the datasheets up there (81 MB).  Let's keep all of the reverse-engineering-related stuff in there instead of in the master branch. 

[idpromnut]

@Cyber7: I like the project structure!  And thanks for taking up the RE on the front panel!

I also like having RE documents live in the same place as the project code, but that can be done later. I will be buying a dev board in the next few days. I will let you know which one I pick up.

[alex.forencich]

Some concerns were brought to my attention about the ability to distribute certain materials (e.g. datasheets) so I think it would be wise to keep the reverse engineering notes and what not in a completely separate repo.  I have a repo set up on my VPS here: git@alexforencich.com:hdg2000re.git .  Please PM me your SSH public key (or keys, if you have multiple computers) and I will add it to gitolite so you can access the repo. 

[idpromnut]

Ok I just ordered the TQ2416 dev board from wayengineer.com, so we will see if that works out, or if I'm out 100$    That should be the exact board that the hantek dudes used, as it is built by the same company, EmbedSky. As a bonus, the kit I ordered is supposed to come with a CD full of documentation, schematics, code, and love. Well maybe not love, but I'm hoping

[alex.forencich]

Ok I just ordered the TQ2416 dev board from wayengineer.com, so we will see if that works out, or if I'm out 100$    That should be the exact board that the hantek dudes used, as it is built by the same company, EmbedSky. As a bonus, the kit I ordered is supposed to come with a CD full of documentation, schematics, code, and love. Well maybe not love, but I'm hoping

Sweet.  I'm wondering if it would be possible to simply boot the unit from a micro SD card or a flash drive so we don't have to bother with a dev board.  The schematics could be handy, though. 

It seems there is an existing project based on the Hantek DSO5000 series that might be worth looking at as well:

http://elinux.org/Das_Oszi

https://github.com/prpplague/das_oszi_kernel/tree/das_oszi_mini2440

[idpromnut]

Neat... different chip, but probably not too much so to be useless.  I'll have a look at it. And the idea would be to be able to use the HDG, but I want to be able to scrap the dev environment initially and not wreck ma HDG. The other thing would be to package the firmware to be able to take advantage of the upgrade mechanism in the HDG to initially "bootstrap" our firmware from an existing HDG without having to open it up and hack into the RS-232 console (to get access to the UBoot menu).

[alex.forencich]

Well, it would be really sweet if there was a way we could just boot it from the micro SD card. Not sure if it is possible to do that without screwing with the bootloader, though.

[idpromnut]

I'll definitely have a look at it. That would be preferable. Worst case, it is supposed to be able to boot from via tftp, but I couldn't get uboot to ping my server.

[alex.forencich]

Dang it...I want to use a PLL to do jitter filtering on the 250 MHz clock for the DACs, but the FPGA only has two PLLs and they are required for the memory controller blocks (MCBs).  The memory controllers are on opposite sides of the FPGA and each one needs a 667 MHz differential clock, but the global clock routing network is not fast enough to route a 667 MHz clock across the chip.  The DCMs cannot be used either as they are not capable of producing a 667 MHz clock.  It would be far too logical for Xilinx to add a dedicated high speed clock route interconnecting the MCBs.....

[lukier]

Do you guys know where to find S3C2416 BSP online? The only place I see this mentioned are sales pages for these development boards where they say they provide this on a CD.

Can any owner of such devboard share the contents of the CD? (WinCE BSP is irrelevant and sharing this might make MS a bit angry )

I saw this SoC mentioned in the kernel docs, so it seems it should be supported by the mainline. I need to check U-Boot as well, haven't got time to play with the AWG recently, still waiting for the frequency divider and Pulse transformer.

I wonder what might be missing in the vanilla mainline sources and what is provided extra on this CD (drivers for some peripherals perhaps).

About the FPGA clocks, this is probably a stupid question as I'm a FPGA noob, but anyway, I'll learn something. 667 MHz is the typical speed for the DDR SDRAM, but would it be possible to run it at 500 MHz, and then use one of the PLL block outputs (I suppose MCB doesn't need all of them) configured to divide by 2 and therefore we would have 250 MHz clock for the DAC?