HDG2002B AWG Firmware Reverse Engineering

[fremen67]

There are quite a few 'hidden' commands in Hantek uboot. The normal distro 'u-boot-2009.11.tar.bz2' isn't hobbled and will give you a nice long help prompt result. Among them:

nand   - NAND sub-system
nboot   - boot from NAND device
nfs   - boot image via network using NFS protocol
nm   - memory modify (constant address)
ping   - send ICMP ECHO_REQUEST to network host
printenv- print environment variables

There is a barebones src file based on tftp at net/nfs.c that adds nfs protocol support. With a little more digging we should be able to figure it out, but TFTP would do fine for the kernel. Then the kernel bootargs can boot the rootfs via NFS with something like this: "setenv bootargs noinitrd init=/linuxrc console=ttySAC0 root=/dev/nfs nfsroot=%s:%s ip=%s:%s:%s:%s:www.embedsky.com:eth0:off". This way we can recompile/debug files from the host system directly on the target's rootfs. Couple that with and IDE with GDB support for a S3C2416 JTAG, should hopefully make debugging an interactive experience. I've only done this with x86/x64 arch targets, and the directions for my cheapo ARM jtag for doing this with Eclipse are in Chinese...

I should have slept before answering  . There are two separeted things: what uboot does and what the kernel does. The link between the two beeing the parameters uboot gives to the kernel.
- As long as uboot has NFS support, it can grab the kernel via that protocol, load it in memory , launch it with parameters... and die
- As long as the kernel has support support for NFS, it can mount external partition via NFS using the parameters it received from uboot

I will have a look a it.

[alex.forencich]

Hooo, finally managed to get timing closure on this thing at 250 MHz.  The discrete jitter from the DCM_CLKGEN is rather high (216 ps) so the overall clock uncertainty is 143 ps.  Not too great, but I'm not sure it's going to be possible to get that any better.  This significantly eats in to the 4ns clock period.  The biggest problem is that Tmcbcko_RDDATA is 2.7 ns (c'mon, really?).  Tmcbcko_RDDATA is the clock-to-output delay of the MCB RDDATA port.  This value is how long you have to wait after a clock edge before the data is valid.  This is before the data even enters the FPGA fabric, as the MCB is a hard core.  After this gigantic delay and the clock uncertainly, the remaining slack is 1.157 ns, not counting the flip-flop setup time.  Turns out that PAR has a VERY hard time placing flip flops close enough to the MCBs to meet timing.  I finally managed to find a set of placements that work for RDDATA on port 0.  This could be a gigantic pain later to get the other ports working, but it seems like it may well be doable with a sufficient amount of head banging. 

I thought the MCB is not too bad to interface with because there weren't any timing issues with the example design, but it turns out they cheated and drove the MCB internal ports at 40 MHz instead of MCB clock/2.  Sigh. 

This is what I call 'close, but no cigar':

Code: [Select]

================================================================================
 Timing constraint: TS_clock_inst_clk_250mhz_int_dcm = PERIOD TIMEGRP         "clock_inst_clk_250mhz_int_dcm" TS_clk_10mhz_int / 25 HIGH 50%;
 For more information, see Period Analysis in the Timing Closure User Guide (UG612).
  3289 paths analyzed, 1518 endpoints analyzed, 1 failing endpoint
  1 timing error detected. (1 setup error, 0 hold errors, 0 component switching limit errors)
  Minimum period is   4.018ns.
 --------------------------------------------------------------------------------
 
 Paths for end point soc_interface_inst/port1_rd_data_reg_17 (SLICE_X36Y29.BX), 1 path
 --------------------------------------------------------------------------------
 Slack (setup path):     -0.018ns (requirement - (data path - clock path skew + uncertainty))
   Source:               ddr2_ram2_inst/memc_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/samc_0 (CPU)
   Destination:          soc_interface_inst/port1_rd_data_reg_17 (FF)
   Requirement:          4.000ns
   Data Path Delay:      3.861ns (Levels of Logic = 0)
   Clock Path Skew:      -0.014ns (0.349 - 0.363)
   Source Clock:         clk_250mhz_int rising at 0.000ns
   Destination Clock:    clk_250mhz_int rising at 4.000ns
   Clock Uncertainty:    0.143ns
 
   Clock Uncertainty:          0.143ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
     Total System Jitter (TSJ):  0.070ns
     Total Input Jitter (TIJ):   0.000ns
     Discrete Jitter (DJ):       0.216ns
     Phase Error (PE):           0.000ns
 
   Maximum Data Path at Slow Process Corner: ddr2_ram2_inst/memc_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/samc_0 to soc_interface_inst/port1_rd_data_reg_17
     Location             Delay type         Delay(ns)  Physical Resource
                                                        Logical Resource(s)
     -------------------------------------------------  -------------------
     MCB_X1Y1.P0RDDATA17  Tmcbcko_RDDATA        2.700   ddr2_ram2_inst/memc_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/samc_0
                                                        ddr2_ram2_inst/memc_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/samc_0
     SLICE_X36Y29.BX      net (fanout=1)        1.047   ram2_p0_rd_data<17>
     SLICE_X36Y29.CLK     Tdick                 0.114   soc_interface_inst/port1_rd_data_reg<19>
                                                        soc_interface_inst/port1_rd_data_reg_17
     -------------------------------------------------  ---------------------------
     Total                                      3.861ns (2.814ns logic, 1.047ns route)
                                                        (72.9% logic, 27.1% route)
 
 --------------------------------------------------------------------------------



Timing fail of 18 ps with the FF all the way on the edge of the fabric! (X36, last column on this device is X37)

[alex.forencich]

I just accidentally stumbled across something really strange that basically solves all the timing problems with the MCBs.  Previously, when I was attempting to get timing closure between one port on each MCB (on oppposite sides of the FPGA) and a 32 bit MUX, I started adding layers of registers so the placer could spread them out on the chip so the routes between them would be short.  Each register output had the KEEP attribute set to prevent XST from collapsing them into an SRL16 shift register, preventing them from getting spread out by the placer in the process.  After adding a register before and after the mux, adding more registers didn't really seem to help at all.  This is due to the huge clock to output delay of the MCB - the placer was putting the registers as close to the MCB as it could, but the timing was still failing on the first register in the chain.  I spent many hours adding LOC constraints to assign the registers to specific slices in an attempt to get the setup times to meet.  Finally, I managed to find a configuration that worked.  So, I decided to move the first level of registers into the MCB wrapper module for convenience.  After adding the registers and renaming the LOC constraints, PAR could not find the registers identified by the constraints!  I didn't realize why initially, so I removed the constraints so I could run PAR to completion and look at the design in planahead.  However, after PAR and TRACE ran, the timing requirements were met!  ??  Turns out that I had removed all of the KEEP constraints, so XST had merged the registers into an SRL16 followed by a register.  And for whatever reason, it was able to route connections to the SRL16 instances more easily than the slice registers.  Very strange!  However, the timing of the MCB connection is now very good - worst is 0.153 ns positive slack.  More than enough to work with.  Interestingly, the SRL16/register combinations are all in a nice line a ways in from the edge of the chip, as opposed to the registers which were all clustered near one edge.  I would have guessed that flip-flops would have achieved much better timing performance than a LUT configured as a shift register, but perhaps the way the MCB is connected to the fabric allows it to connect more easily to LUTs than to registers. 

Spartan 6 CLB flip-flop Tdick = 470 ps (data in to clock setup time)
Spartan 6 CLB distributed RAM Tds = 730 ps (data in to clock setup time)
Spartan 6 CLB shift register Tds = 90 ps !!!!

[alex.forencich]

Big news on the FPGA front!

BUFGMUX instances cause hell with timing constraints.  Adding a PLL did nothing to change the output phase noise, which is not correct.  The problem was caused by the BUFGMUX used to switch between the internal external reference clocks, post-250 MHz DCM.  Adding a timing ignore (TIG) constraint to the external reference connection fixed the constraint propagation issue.  With the PLL, the overall timing uncertainty is less than 100 ps in the switched 250 MHz clock domain. 

The MCB interface to DDR2 and the SPI SoC interface are both up and running.  I have been able to successfully write to and read from both DDR2 chips from the new SPI interface with my bus pirate.  There are some signal integrity issues occasionally, but they are likely due to using rather long flying leads off of my bus pirate.  Adjusting the lead positioning significantly affects the reliability of the connection.  This should not be an issue on the PCB.  Currently the SoC interface uses an oversampled SPI implementation that won't be able to reliably run faster than perhaps 30 or 40 MHz.  I'm going to look in to rewriting that to be source-synchronous so we can crank up the speed. 

The SPI protocol that I implemented is a little bit funky, but here is how it works so far:

Code: [Select]

Address space

0 0000 0000 - 0 07ff ffff channel 1 memory
1 0000 0000 - 1 07ff ffff channel 2 memory
F 0000 0000 - f ffff ffff control and configuration

Commands

1010 bbbb - read to bank b
1011 bbbb - write from bank b

read command example

Read AA BB CC DD from bank 0 (channel 1 memory) at address 0x00001234
Read data start indicated by leading nonzero byte

MOSI A0 00 00 12 34 00 00 00 00 00 00 00 00
MISO 00 00 00 00 00 00 01 AA BB CC DD xx xx

write command example

Write AA BB CC DD to bank 0 (channel 1 memory) at address 0x00001234

MOSI B0 00 00 12 34 AA BB CC DD
MISO 00 00 00 00 00 00 00 00 00


Currently, only banks 0 and 1 are accessible (bank 0 accesses U8 and bank 1 accesses U12).  To write, send 0xB0 or 0xB1, followed by the address, MSB first, followed by the data.  To read, send 0xA0 or 0xA1, followed by the address, MSB first.  The data will then come out following the first nonzero byte.  This is the only way I could think of to get all of the timing to work out.  The reply comes back after an undefined time (wrt. number of bytes), but it's usually going to be a delay of one byte (you get one 0, then a 1, then the read data).  The delay is necessary as DDR2 accesses through the MCB are relatively high latency (~30 clocks at 250 MHz), and this can vary due to contention between multiple MCB ports.  The addresses are 32 bit.  Eventually I will add another bank for configuring the logic - DDS/DSP, modulation, frequency counters, etc. 

[lukier]

Great job Alex!

I've just compiled the bitstream and hope to test it soon. Now I'm a bit busy with writing a paper, but hopefully in December there will be a lot more spare time and I'll try to get an OS image with QtEmbedded running on the generator. For now I might try using bits and bobs from Hantek released source code to do a couple of simple SPI tests (FPGA bitstream loading, memory read/write).

I should get a book on Verilog (I've tried VHDL before, but never got time to learn this properly) and I'm going trough your code as it might be really useful (timing and MCBs) for my side project - that is writing OpenSource FPGA bitstream for my Hantek HT4032L logic analyzer. It's essentially the same FPGA, 2 x 128 MB DDR2, some DAC for voltage threshold and Cypress HighSpeed USB chip. Maybe I'll try porting something like OpenBenchSniffer or https://github.com/lukier/Pipistrello_ols_verilog.

[alex.forencich]

Great job Alex!

I've just compiled the bitstream and hope to test it soon. Now I'm a bit busy with writing a paper, but hopefully in December there will be a lot more spare time and I'll try to get an OS image with QtEmbedded running on the generator. For now I might try using bits and bobs from Hantek released source code to do a couple of simple SPI tests (FPGA bitstream loading, memory read/write).

You probably didn't get timing closure; I haven't committed all of the adjustments yet.  Check fpga.twr and see if there are any violations.  I am in the process of reworking the read path from the MCB.  What I had before only works for low bandwidths.  Higher speeds require a bit more logic, which I just about have finished. 

I should get a book on Verilog (I've tried VHDL before, but never got time to learn this properly) and I'm going trough your code as it might be really useful (timing and MCBs) for my side project - that is writing OpenSource FPGA bitstream for my Hantek HT4032L logic analyzer. It's essentially the same FPGA, 2 x 128 MB DDR2, some DAC for voltage threshold and Cypress HighSpeed USB chip. Maybe I'll try porting something like OpenBenchSniffer or https://github.com/lukier/Pipistrello_ols_verilog.

That looks like a pretty interesting unit.  Dirt simple, though - they probably come in with a stack of IDDR2 input registers with the core clocked at 200 MHz.  That will give you 32 bits at 400 MSa/sec, coming out in the fabric on a 64 bit wide bus at 200 MHz.  Each memory will give you 16*2 bits per clock cycle.  If that board can also run the memories at 625 MHz, then 312.5*2*16*2 > 200*64 and it will work.  Actually, 312.5*2*16*2 > 250*64, so you might be able to get it running at 500 MSa/sec if you can get the inputs to sample fast enough.  Looks like ISERDES2 can run at 250 MHz.  With 1:2 serdes ratio, that would be 500 MSa/sec.  An IDDR2 can also run at up to 750 Mb/sec, or 375 MHz fabric clock, which is more than fast enough.  I may have to pick up one of those.  I'm not familiar at all with the Cypress chips, though. 

They probably have a DAC driving the vref pin of the input IOB.  Should be pretty straightforward to get figured out. 

[alex.forencich]

Latest RTL changes pushed.  I inserted special SRL-based FIFO registers into the MCB read data path so that there aren't any issues with delays between the read enable and empty signals.  I can't use a full SRL-based FIFO as Tmcbcko_RDEMPTY is 2.27 ns, so the empty signal from the MCB cannot be used without first being registered.  The SRL-based FIFO registers can hold 1 or 2 data words, depending on the bus transaction history (two back-to-back writes will store 2 words, two separate writes will store one and hold the second).  Worst slack is currently +57ps. 

Code: [Select]

Paths for end point fpga_core_inst/ram2_p0_rd_fifo/Mshreg_read_data_24_0 (SLICE_X34Y28.DX), 1 path
 --------------------------------------------------------------------------------
 Slack (setup path):     0.057ns (requirement - (data path - clock path skew + uncertainty))
   Source:               ddr2_ram2_inst/memc_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/samc_0 (CPU)
   Destination:          fpga_core_inst/ram2_p0_rd_fifo/Mshreg_read_data_24_0 (FF)
   Requirement:          4.000ns
   Data Path Delay:      3.756ns (Levels of Logic = 0)
   Clock Path Skew:      -0.018ns (0.345 - 0.363)
   Source Clock:         clk_250mhz_int rising at 0.000ns
   Destination Clock:    clk_250mhz_int rising at 4.000ns
   Clock Uncertainty:    0.169ns
 
   Clock Uncertainty:          0.169ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
     Total System Jitter (TSJ):  0.070ns
     Total Input Jitter (TIJ):   0.100ns
     Discrete Jitter (DJ):       0.216ns
     Phase Error (PE):           0.000ns
 
   Maximum Data Path at Slow Process Corner: ddr2_ram2_inst/memc_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/samc_0 to fpga_core_inst/ram2_p0_rd_fifo/Mshreg_read_data_24_0
     Location             Delay type         Delay(ns)  Physical Resource
                                                        Logical Resource(s)
     -------------------------------------------------  -------------------
     MCB_X1Y1.P0RDDATA24  Tmcbcko_RDDATA        2.700   ddr2_ram2_inst/memc_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/samc_0
                                                        ddr2_ram2_inst/memc_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/samc_0
     SLICE_X34Y28.DX      net (fanout=1)        1.156   ram2_p0_rd_data<24>
     SLICE_X34Y28.CLK     Tds                  -0.100   fpga_core_inst/soc_interface_inst/port1_rd_data_reg<28>
                                                        fpga_core_inst/ram2_p0_rd_fifo/Mshreg_read_data_24_0
     -------------------------------------------------  ---------------------------
     Total                                      3.756ns (2.600ns logic, 1.156ns route)
                                                        (69.2% logic, 30.8% route)

Trace reports

Code: [Select]

All constraints were met.

Sweet. 

It also reports that the minimum period is 32 ns, which is complete bullshit.  This is probably due to the TIG constraint for the reference clock switching BUFGMUX.  The derived minimum period is 99.938ns, which should be the correct number.  This is only about 6 kHz off of 10 MHz.  Hopefully nobody uses an external reference that's that far off.

[lukier]

That looks like a pretty interesting unit.  Dirt simple, though - they probably come in with a stack of IDDR2 input registers with the core clocked at 200 MHz.  That will give you 32 bits at 400 MSa/sec, coming out in the fabric on a 64 bit wide bus at 200 MHz.  Each memory will give you 16*2 bits per clock cycle.  If that board can also run the memories at 625 MHz, then 312.5*2*16*2 > 200*64 and it will work.  Actually, 312.5*2*16*2 > 250*64, so you might be able to get it running at 500 MSa/sec if you can get the inputs to sample fast enough.  Looks like ISERDES2 can run at 250 MHz.  With 1:2 serdes ratio, that would be 500 MSa/sec.  An IDDR2 can also run at up to 750 Mb/sec, or 375 MHz fabric clock, which is more than fast enough.  I may have to pick up one of those.  I'm not familiar at all with the Cypress chips, though. 

Thanks for the tips. There is a thread with a lot of reverse engineering done already:
https://www.eevblog.com/forum/testgear/hantek-ht4032l-logic-analyser/

As is typical with Hantek the hardware is pretty neat (FPGA, bandwith, plenty of sample memory), especially for the price, but the firmware is buggy and the software only runs on Windows.

[alex.forencich]

Here is a tested bit file with SPI and MCB operational, if anyone wants to experiment with the interface as it is right now.  The DAC outputs are tied to 16 bit counters running on the 250 MHz clock. 

[tridentsx]

I haven't seen any activity in this thread for a while, did this project die ?

[alex.forencich]

I have been a bit busy over the past few weeks, so I have not had too much time to put in to this.  However, I am toying around with some high-level architectures for the DSP chain in the FPGA - DDS, sample rate conversion, modulation, filtering, etc.  I have been looking at efficient implementations of CIC and FIR filtering, for starters a clean way to convert the 1 MSa/sec ADC output to 250 MSa/sec.  Interpolating 250x without gobs of aliasing and without taking up the whole FPGA is not so easy.  I'm also looking at how implement AM, FM, and PM (and the associated ASK, FSK, PSK, and IQ modulations) efficiently with the minimum number of DSP slices.  I can't just start cranking out HDL without a high-level plan first.  I should have a lot more time starting in the next week or two, though. 

Not sure about the Linux side of things, though. I have not heard anything in a while. 

[mb300sd]

Following this closely. Is everyone still alive? I'm considering buying one of these soon since I need a signal generator, but can't justify anything more expensive since I really only need sine and square waves up to 10MHz or so but still want all the features to play with...

I would love to contribute if I pick one up but I don't know how much use I'd be.

[rdg]

Hi all,

After being on the back-burner for a long time, I am starting to get back to hacking on my HDG. Have just caught up with this thread -- looks like many exciting developments.

I was wondering if someone can post Cyber7's openOCD device config. The link on the original post doesn't seem to be working. To un-brick my device I need to re-flash the SoC. So far I can't get a working configuration with openOCD and my bus blaster. From what I can see it doesn't look like openOCD has support for the 2416 and NAND driver.

Also, it would be great if someone could confirm the pinout of the 10-pin soc jtag connector, is it the same as this?

Thanks.

[alex.forencich]

Following this closely. Is everyone still alive? I'm considering buying one of these soon since I need a signal generator, but can't justify anything more expensive since I really only need sine and square waves up to 10MHz or so but still want all the features to play with...

I would love to contribute if I pick one up but I don't know how much use I'd be.

I have been working on the FPGA design at a high level (testing out DSP components in Python) but I am waiting until I hear some more progress from the folks working on the SoC/kernel/UI before I sink too much more time into it. 

[idpromnut]

I'm still alive, but with the holiday and a few projects that have come my way, it will be a few weeks until I can put time on this.

[mb300sd]

Well, I pulled the trigger on one tonight.. will hopefully be here in a week or so, and I went ahead and ordered the ethernet chip. The magnetics and jack can wait for my next order from digikey... Hopefully it still comes with the frequency counter IC installed.

[fremen67]

I was wondering if someone can post Cyber7's openOCD device config. The link on the original post doesn't seem to be working. To un-brick my device I need to re-flash the SoC. So far I can't get a working configuration with openOCD and my bus blaster. From what I can see it doesn't look like openOCD has support for the 2416 and NAND driver.

Also, it would be great if someone could confirm the pinout of the 10-pin soc jtag connector, is it the same as this?

Thanks.

I don't have them but you will find attached the configuration files that work with OpenOCD on my HDG and EM2416 dev board, plus the JTAG J901 pinout (from a TQ2416 board which is the same).

[fremen67]

Well, I pulled the trigger on one tonight.. will hopefully be here in a week or so, and I went ahead and ordered the ethernet chip. The magnetics and jack can wait for my next order from digikey... Hopefully it still comes with the frequency counter IC installed.

Nice, I hope you will get a new software version  Keep us updated !

[smgvbest]

I've got a HDG2002B coming but apparently china customs had an issue's and it went back to be reshipped.   
I've still waiting to hear when it will be reshipped, hopefully soon.

[mb300sd]

Well, I pulled the trigger on one tonight.. will hopefully be here in a week or so, and I went ahead and ordered the ethernet chip. The magnetics and jack can wait for my next order from digikey... Hopefully it still comes with the frequency counter IC installed.

Nice, I hope you will get a new software version  Keep us updated !

Software 1.0.2, FPGA 20, so same as some others. Have it open right now and don't want to put it back together until my chips arrive, so I can't remember the other numbers.

[andrija]

Does anyone have 1.0.2 firmware as an update? Mine shipped with 1.0 and I believe even some features are missing, never mind bugs. I don't think they published the files. I'm talking official update, not doing it via hacking. There's nothing on their official webiste.

[alex.forencich]

I don't think they ever released any of the firmware update packages.  Which is part of the reason we're trying to build an alternate firmware; Hantek does not really seem terribly interested in supporting their own product. 

[smgvbest]

Now that's sad.   I hope they don't expect to stay in business long if that's true.

<note>
I know Rigol released their fix to the jitter problems on the DS1000/DS2000 scopes.  I know it takes time to figure out the cause of the problem and a proper fix but Rigol Did and even had them supply it on this site.   That to me is customer service.
</note>

[kazam]

I'm kind of looking for an AWG.  The official firmware seems unstable almost to the point of being useless though. Worth picking one up and seeing where this goes? Maybe I could help out a little too although I'm not really fluent in embedded programming.

[markone]

Kazam, in your place i would hold on.

I bought one a couple of months ago relying on open source project and/or Hantek's update, with current FW it's IMHO pretty useless and sure not ready to be sold.

It's unstable, it does not keep settings, it applies wrong signal modulation, some functions are not working at all, it has rusty metal chassis, if you really need a decent device save some bucks more and take a look elsewhere.

Right now it's resting in it's cardboad box.

I'm wondering if Hantek behaves in this way with its other products.