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. 

[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?

[alex.forencich]

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 )

None of us have a dev board or CD yet, AFAIK. 

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

We may need to write a few drivers.  There is a similar project for the Hantek DSOs that had to modify a few display-related things to get it to work.  Not sure exactly what they had to do. 

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?

I considered this, but the thing is that the unit has two frequency references - one internal and one external - and the FPGA needs to be able to switch between them without resetting the memory controller.  So the memory controller and some of the logic will run off of the internal osc, and the DSP/DDS/DAC logic will run off of a switched reference input.  Take a look at clock.v in the repo right now; I am in the process of getting all of the clock switching logic working right now. 

This should be relatively easy to arrange as the memory controller ports can all be placed in independent clock domains.  I also want to run the memory as fast as possible as there are multiple things that need to have access and I want to make sure nothing gets starved.  There should be enough memory bandwidth to run both DAC channels from one memory controller - wouldn't it be great to have an unequal split and have >64Mpts accessible to one channel while still being able to use the other channel?  That's basically what I'm hoping to do - anything can read from anywhere.  Also, I plan on supporting at least 4 internal channels - two main ones, and at least one more 'sub channel' per main channel for arbitrary AM, FM, PM, FSK, PSK, etc. modulation.  There is also the 16 bit digital output that will have to read from somewhere. 

Basically, I want to make this thing as close to as the Agilent TrueForm generators in functionality as possible.  I'm just hoping the FPGA is big enough. 

[idpromnut]

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

I should have the EmbedSky dev board in a few weeks, which includes a CD of stuff (and hopefully a full compileable source tree for Linux). In the mean time I've been trying to get a S3C2416 kernel built. It is in the main line, and it should work, however I'm getting an error right after the kernel is "decompressed" (I'm not compressing it so it's the step right after that). I will post the output in a sec GOT a kernel built and booting on the HDG   (using the uboot USB load a kernel option 't' and DNW (which I found via someone here, I think Tinhead in regards to hacking the DSO5000. Now I need to build it with the right options to boot an rootfs off the SDcard and we're sweet

Code: [Select]

Now, Downloading [ADDRESS:0xc0008000,TOTAL:0x20f098]
Please waiting ................................Download Done!!
Download Address: 0xc0008000, Download Filesize:0x20f098
Now, Checksum calculation..
Checksum O.K !!!
Boot with zImage

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
s3c24xx_serial_init(c041fd70,c041fdc0)
s3c24xx_serial_init(c041fdf4,c041fe44)
s3c24xx_serial_init(c041fe78,c041fec8)
s3c2440_serial_probe: dev=c04323bc
s3c24xx_serial_probe(c04323bc, c041fec8) 0
s3c24xx_serial_probe: initialising port c041f9c0...
s3c24xx_serial_init_port: port=c041f9e4, platdev=c04323bc
s3c24xx_serial_init_port: c041f9e4 (hw 0)...
resource c040e5a4 (50000000..50003fff)
port: map=50000000, mem=f7000000, irq=70 (70,71), clock=1
s3c2440_serial_resetport: port=c041f9e4 (50000000), cfg=c0432308
                                                                s3c24xx_serial_p                                     robe: adding port
s3c24xx_serial_console_setup: co=c041fd38 (0), (null)
s3c24xx_serial_console_setup: port=c041f9e4 (0)
s3c24xx_serial_get_options: port=c041f9e4
registers: ulcon=00000003, ucon=000003c5, ubdriv=00000023
calculated baud 115740
s3c24xx_serial_console_setup: baud 115740
selecting clock c0410004
config: 8bits/char
setting ulcon to 00000003, brddiv to 35, udivslot 00000000
uart: ulcon = 0x00000003, ucon = 0x000003c5, ufcon = 0x00000051
Linux version 3.2.63 (chris@hdgdev1) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12u                                     buntu1) ) #5 PREEMPT Wed Oct 29 21:36:16 EDT 2014
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: SMDK2416
Ignoring tag cmdline (using the default kernel command line)
Memory policy: ECC disabled, Data cache writeback
CPU S3C2416/S3C2450 (id 0x32450003)
S3C24XX Clocks, Copyright 2004 Simtec Electronics
CPU: MPLL on 800.000 MHz, cpu 400.000 MHz, mem 133.333 MHz, pclk 66.666 MHz
CPU: EPLL on 96.000 MHz, usb-bus 48.000 MHz
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: noinitrd ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs init=/                                     linuxrc console=ttySAC0 mem=64M
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 60444k/60444k available, 5092k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xc4800000 - 0xf6000000   ( 792 MB)
    lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .text : 0xc0008000 - 0xc03da000   (3912 kB)
      .init : 0xc03da000 - 0xc0402000   ( 160 kB)
      .data : 0xc0402000 - 0xc0431f40   ( 192 kB)
       .bss : 0xc0431f64 - 0xc045cd0c   ( 172 kB)
NR_IRQS:99
irq: clearing subpending status 00000003
irq: clearing subpending status 00000002
Console: colour dummy device 80x30
Calibrating delay loop... 199.47 BogoMIPS (lpj=498688)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
S3C2416: Initializing architecture
S3C2416: IRQ Support
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
s3c-i2c s3c2410-i2c: slave address 0x10
s3c-i2c s3c2410-i2c: bus frequency set to 65 KHz
s3c-i2c s3c2410-i2c: i2c-0: S3C I2C adapter
Advanced Linux Sound Architecture Driver Version 1.0.24.
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
NetWinder Floating Point Emulator V0.97 (extended precision)
JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 118
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
s3c2440-uart.0: ttySAC0 at MMIO 0x50000000 (irq = 70) is a S3C2440
console [ttySAC0] enabled
s3c2440_serial_probe: dev=c04122e4
s3c24xx_serial_probe(c04122e4, c041fec8) 1
s3c24xx_serial_probe: initialising port c041fa84...
s3c24xx_serial_init_port: port=c041faa8, platdev=c04122e4
s3c24xx_serial_init_port: c041faa8 (hw 1)...
resource c040e5dc (50004000..50007fff)
port: map=50004000, mem=f7004000, irq=73 (73,74), clock=1
s3c2440_serial_resetport: port=c041faa8 (50004000), cfg=c0432328
s3c24xx_serial_probe: adding port
s3c2440-uart.1: ttySAC1 at MMIO 0x50004000 (irq = 73) is a S3C2440
s3c2440_serial_probe: dev=c04123b4
s3c24xx_serial_probe(c04123b4, c041fec8) 2
s3c24xx_serial_probe: initialising port c041fb48...
s3c24xx_serial_init_port: port=c041fb6c, platdev=c04123b4
s3c24xx_serial_init_port: c041fb6c (hw 2)...
resource c040e614 (50008000..5000bfff)
port: map=50008000, mem=f7008000, irq=76 (76,77), clock=1
s3c2440_serial_resetport: port=c041fb6c (50008000), cfg=c0432348
s3c24xx_serial_probe: adding port
s3c2440-uart.2: ttySAC2 at MMIO 0x50008000 (irq = 76) is a S3C2440
s3c2440_serial_probe: dev=c0412484
s3c24xx_serial_probe(c0412484, c041fec8) 3
s3c24xx_serial_probe: initialising port c041fc0c...
s3c24xx_serial_init_port: port=c041fc30, platdev=c0412484
s3c24xx_serial_init_port: c041fc30 (hw 3)...
resource c040e64c (5000c000..5000ffff)
port: map=5000c000, mem=f700c000, irq=94 (94,95), clock=1
s3c2440_serial_resetport: port=c041fc30 (5000c000), cfg=c0432368
s3c24xx_serial_probe: adding port
s3c2440-uart.3: ttySAC3 at MMIO 0x5000c000 (irq = 94) is a S3C2440
lp: driver loaded but no devices found
ppdev: user-space parallel port driver
brd: module loaded
loop: module loaded
Uniform Multi-Platform E-IDE driver
ide-cd driver 5.00
S3C24XX NAND Driver, (c) 2004 Simtec Electronics
s3c24xx-nand s3c2412-nand: Tacls=3, 22ns Twrph0=8 60ns, Twrph1=3 22ns
s3c24xx-nand s3c2412-nand: System booted from NAND
s3c24xx-nand s3c2412-nand: NAND soft ECC
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bi                                     t)
Scanning device for bad blocks
Creating 8 MTD partitions on "NAND":
0x000000000000-0x000000004000 : "Boot Agent"
mtd: partition "Boot Agent" doesn't end on an erase block -- force read-only
0x000000000000-0x000000200000 : "S3C2410 flash partition 1"
0x000000400000-0x000000800000 : "S3C2410 flash partition 2"
0x000000800000-0x000000a00000 : "S3C2410 flash partition 3"
0x000000a00000-0x000000e00000 : "S3C2410 flash partition 4"
0x000000e00000-0x000001800000 : "S3C2410 flash partition 5"
0x000001800000-0x000003000000 : "S3C2410 flash partition 6"
0x000003000000-0x000008000000 : "S3C2410 flash partition 7"
vcan: Virtual CAN interface driver
slcan: serial line CAN interface driver
slcan: 10 dynamic interface channels.
CAN device driver interface
dm9000 Ethernet Driver, V1.31
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
s3c2410-ohci s3c2410-ohci: S3C24XX OHCI
s3c2410-ohci s3c2410-ohci: new USB bus registered, assigned bus number 1
s3c2410-ohci s3c2410-ohci: irq 42, io mem 0x49000000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
usbcore: registered new interface driver libusual
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
USB Serial support registered for FTDI USB Serial Device
usbcore: registered new interface driver ftdi_sio
ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
USB Serial support registered for pl2303
usbcore: registered new interface driver pl2303
pl2303: Prolific PL2303 USB to serial adaptor driver
S3C24XX RTC, (c) 2004,2006 Simtec Electronics
S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics
s3c2410-wdt s3c2410-wdt: watchdog inactive, reset disabled, irq disabled
ALSA device list:
  No soundcards found.
TCP vegas registered
NET: Registered protocol family 17
can: controller area network core (rev 20090105 abi 8)
NET: Registered protocol family 29
can: raw protocol (rev 20090105)
can: broadcast manager protocol (rev 20090105 t)
can: netlink gateway (rev 20101209)
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
s3c24xx_serial_startup: port=50000000 (f7000000,c041fcd0)
requesting tx irq...
s3c24xx_serial_startup ok
config: 8bits/char
setting ulcon to 00000003, brddiv to 35, udivslot 00000000
uart: ulcon = 0x00000003, ucon = 0x000003c5, ufcon = 0x00000051
VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00              16 mtdblock0  (driver?)
1f01            2048 mtdblock1  (driver?)
1f02            4096 mtdblock2  (driver?)
1f03            2048 mtdblock3  (driver?)
1f04            4096 mtdblock4  (driver?)
1f05           10240 mtdblock5  (driver?)
1f06           24576 mtdblock6  (driver?)
1f07           81920 mtdblock7  (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Backtrace:
Function entered at [<c00171c4>] from [<c034af5c>]
 r6:00008000 r5:c03742c0 r4:c043251c
Function entered at [<c034af44>] from [<c034b0a8>]
Function entered at [<c034b03c>] from [<c03dac64>]
 r3:00000000 r2:c3819e78 r1:c3819f74 r0:c03742c0
 r7:c03fae24
Function entered at [<c03daaf4>] from [<c03dafc8>]
Function entered at [<c03daf34>] from [<c03da8dc>]
 r5:c0401650 r4:c0401650
Function entered at [<c03da7e0>] from [<c002f8c0>]
 r5:c03da7e0 r4:00000000

[alex.forencich]

Excellent progress! 

I managed to get the reference clock switching working.  There may still be a few issues to work out wrt. stability, but it seems to work reasonably well with inputs within +/- 200 kHz around 10 MHz.  I need to pull out a reset line and put it on the scope for several hours to see if it actually is stable.  Oddly, at 10.3 MHz there seems to be a strange issue with locking.  Probably not a major issue as I don't think anybody would want to operate with a reference that far off of 10 MHz, though.  Also, the jitter on the ADC clock seems to have a spread of around 500 ps.  I will have to get a better differential probe on there later and see if I can get a better read on that.  The ref clock output seems to have some sort of 1ns wide quantization step (very bimodal distribution, with about 500 ps of jitter around each point).  However, the ref clock output is phase locked with the ADC clock very nicely (darn well better be as it comes from the same DCM). 

Also, does anyone know what the speed grade is of the FPGA in these things?  I have been assuming they use the -2, but they could very easily be using the faster -3.  Unfortunately, the only way to know for sure is to pull of the heatsink and read the marking on the chip.  AFAIK, it is not possible to check the speed grade via JTAG. 

[idpromnut]

@Cyber7: can you also post details on the LCD + controller if they are on the front panel?

[andrija]

A question about LAN - people say it does nothing but ping but shouldn't we be able to at least use it to telnet into the box? It's linux after all, a daemon (telnetd?) is all that needs to be started on the Hantek. Is that missing on the OS? The pins on the UART are not standard size so I had to improvise to connect and change the config file. For any further hacking etthernet would be far preferable, obviously.

Also, a bunch of diodes and a few other passives were not on my board but they go straight into the LAN jack. Is this same for everyone and can be ignored (e.g. power over Ethernet)?

[alex.forencich]

A question about LAN - people say it does nothing but ping but shouldn't we be able to at least use it to telnet into the box? It's linux after all, a daemon (telnetd?) is all that needs to be started on the Hantek. Is that missing on the OS? The pins on the UART are not standard size so I had to improvise to connect and change the config file. For any further hacking etthernet would be far preferable, obviously.

I'm not sure what services are running in the default firmware, but telnet/ssh would definitely be very convenient and probably one of the first things to stick on there once we get the boot image figured out. 

Also, a bunch of diodes and a few other passives were not on my board but they go straight into the LAN jack. Is this same for everyone and can be ignored (e.g. power over Ethernet)?

I think this is related to some sort of isolated serial connection that uses the RJ-45 port.  I think it's mutually exclusive (either isolated serial or LAN can be connected, but not both). 

[idpromnut]

A question about LAN - people say it does nothing but ping but shouldn't we be able to at least use it to telnet into the box? It's linux after all, a daemon (telnetd?) is all that needs to be started on the Hantek.

I will definitely add SSH support into the base firmware image as soon as I have it up and running. I will probably use BusyBox (Hantek used it as well) for the base system, and from there see what we can add. Ideally there would also be the option to support a USB keyboard from the front panel as well as a console on the LCD. Again, it would be nice if these options were able to be invoked when booting the firmware by holding a front panel key combination.

[Cyber7]

telnet is built into busybox, so all you have to do is remove the remark from /dso/etc/boot.sh
I have cross built SSH for the ARM5TE; just have not tried it yet.

The diodes/opto isolators near the RJ45 jack are for the opto-isolated serial option that can coexist with the ethernet port. The protection may be POE related, to avoid -48v damage.

[Cyber7]

@idpromnut: 

can you also post details on the LCD + controller if they are on the front panel?

The LCD is not attached to the front-panel uC; looks like an LVTTL adapter is used to attach it to the S3C2416. The 2416 has a built-in TFT controller well supported by Linux already. The only custom piece appears to be the backlight driver. I'll have a closer look into this shortly as soon as I can get my JTAG boundary scan running on the 2416 to verify pins and hunt for the i2c keypad control src.

Here's the keypad info:

Hantek HDG2002B AWG Front Panel KeyPad
--------------------------------------
 
Components:

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

Utilizes I2C Protocol on mainboard J702 pins 7 (SDA) & 9 (SCL)
SCL = 18.568 Khz

Pin out for J702:
-----     --------------------------------------------------
Pin1      Busy?    @ Keypad U26 Pin 43 P5.7 (Goes active high on kepress )
Pin2      ?? @ Keypad U26 Pin 51 P1.2 (seems always low)
Pin3      ?? @ 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      @ Keypad U26 Pin 46 P1.7 (seems always low)
Pin9      SCL to/from Keypad U26 Pin 49 P1.4 & U800 EEprom Pin 6
Pin10     GND 
-----     --------------------------------------------------

Pin1  - uC Busy? Active High Asserted ~1.5 SCL (173us) Before Scan Code, remains
        high ~2ms and Deasserted ~1.5 SCL before end of Scan Code. Not asserted
        for Release codes. Not asserted during LED code writes to display.
       
Read  - Key ScanCode    = 0x55 + (Keycode Byte)
Read  - Key ReleaseCode = Keycode & $80
Write - LED State       = 0x55 + (LED bitmask Byte1) + (LED bitmask Byte2)

Notes: 1. If LCD screensaver on screen, 1st key press generates no release code;
          it only serves to wake the unit. It appears the keypad enters a sleep
          state, however pins 2,3,8 are not asserted to indicate this condition.
          Perhaps a pre-programmed timeout is used.
       2. A release code follows a keypress after ~125.7ms. Release codes do NOT
          reflect the actual event of releasing a button.
       3. If the uC misses a keypress event, Pin 1 will remain asserted (uC Busy)
          until the next valid keypress, and the release code will not be sent.
       4. The Jog Dial does not generate release codes when turned, but does when
          pressed.
       5. Key codes 36d, 37d & 44d are note assigned to any keys.
       6. Near simultaneous keypresses will result in a rapid sequence of kepresses
          125ms apart.

ScanCodes & bitmasks are attached.

[andrija]

ssh is probably overkill as you don't need encryption and the overhead of doing it is not trivial but it certainly simplifies things ironically, as a plain telnet client is a rare beast these days.

telnet is built into busybox, so all you have to do is remove the remark from /dso/etc/boot.sh

That's what I was looking for, I will give it a go when I get home. Thanks everyone!

[alex.forencich]

I'll have a closer look into this shortly as soon as I can get my JTAG boundary scan running on the 2416 to verify pins and hunt for the i2c keypad control src.

When you do this, can you please probe the SoC side of the FPGA interconnections and see if you can figure out what the pin functions are?  I presume it is an SPI interface, possibly with a couple of additional GPIO pins.  There are 7 traces in total that connect the SoC to the FPGA, and at least two of these are dedicated FPGA config pins (program_b and init_b) so these will likely be connected to GPIO. 

U26  = Custom Ti MSP430F413 series microcontroller marked LSD4F8108 (aka MSP430V111IPM)

I'm not sure if it is actually a MSP430F413 series part or not, but that seems to be the only one on the TI site that comes in the same package.  I freaking hate unlisted part numbers like LSD4F8108.  I also can't find any mention of MSP430V, except as a cross-reference to LSD4F8108.  Such a PITA. 

[idpromnut]

@cyber7: awesome, just wanted to verify that they are indeed using the built in lcd controller. I bet the backlight is under software control because there are boot messages that pop up intially.. Easy way to "get rid of the boot up noise".

@andrija: sshd should be easy to setup; the real issue is the cpu and memory footprint, which is certainly larger than necessary.

[fremen67]

A question about LAN - people say it does nothing but ping but shouldn't we be able to at least use it to telnet into the box? It's linux after all, a daemon (telnetd?) is all that needs to be started on the Hantek. Is that missing on the OS?

Telnet is enabled and working "out of the box" on FW 1.00.1. I did not checked for FW 1.00.2. Very convenient to connect without opening the case.

[fremen67]

I bet the backlight is under software control because there are boot messages that pop up intially.. Easy way to "get rid of the boot up noise".

Yes it is. in FW 1.00.1 at least there is a small test tool to switch it on and off. If you look in the thread, you will see there was a bug that switched it off when trying to modify the startup defaut setup (black screen bug)

[Cyber7]

I'm not sure if it is actually a MSP430F413 series part or not, but that seems to be the only one on the TI site that comes in the same package.  I freaking hate unlisted part numbers like LSD4F8108.  I also can't find any mention of MSP430V, except as a cross-reference to LSD4F8108.  Such a PITA.

I saw an inquiry to TI that basically went "Are you sure LSD4F8108 is our part #?" All I could find were Chinese cross-refs and 1 Chinese article I translated that gave the properties of the LSD4F8108. Assuming the MSP430 prefix was correct, I the ran the para-metricized search on TI's site with those properties (flash size, lcd controller, serial port, ram, etc), and came out with the MSP430F413.

All in all, it really does not matter much as I can write a driver to communicate with it once I find what pins on the 2416 handle the i2c coms.

On that note: I am having problems getting TopJTAG Probe to work with the 2416. The BSDL is not official, and had a number of incompatibilities: duplicate pin #'s, bracketed port defs, mislabeled pins. Also the DeviceID is different. I now have the BSDL loading properly and the device package appears complete. However, a simple sampling probe shows no changes at all while the device is running (verified with serial term). 
I've attached my altered bsdl file and screen shot below.

The jtag I'm using is a FT2232D clone named "USB<=>JTAG&RS232" that I altered the eeprom config to conform with an Amontec JtagKey. Changed the VID/PID, mfg & name. Then loaded the Amontec drivers from Universal Scan. I coulnd't get US to work at all; it finds the JTAG key, but simply hangs the app. TopJTAG says everything is OK, but I get no valid data. I guess I'll set the key back to its original config and try the generic FT2232 config for TopJTAG.

PS: this is what openocd reports, which is the same ID that TopJTAG Probe reports:

JTAG tap: S3C2416.cpu tap/device found: 0x07926f0f (mfg: 0x787, part: 0x7926, ver: 0x0)
target state: halted
target halted in ARM state due to debug-request, current mode: User
cpsr: 0x60000010 pc: 0xffff0078
MMU: enabled, D-Cache: enabled, I-Cache: enabled
NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'.
NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'.
> halt
> scan_chain
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 S3C2416.cpu            Y     0x07926f0f 0x07926f0f     4 0x01  0x0f
> targets
    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0* S3C2416.cpu        arm926ejs  little S3C2416.cpu        halted

[idpromnut]

I bet the backlight is under software control because there are boot messages that pop up intially.. Easy way to "get rid of the boot up noise".

Yes it is. in FW 1.00.1 at least there is a small test tool to switch it on and off. If you look in the thread, you will see there was a bug that switched it off when trying to modify the startup defaut setup (black screen bug)

Pretty sure that was me freaking out about that bug initially

[idpromnut]

@Cyber7: there is an I2C driver in the kernel that the Hantek guys are using for this SoC, so you shouldn't need to write an I2C driver per se. However, a library to interface with the keypad will be needed I think.

[Cyber7]

@idpromnut: Yep, not a driver in the kernel sense, anymore than the backlight 'driver'. The datasheet seems to only show one i2c port, but the init code lists 2. (see below) I didn't spy any other messages when probing the keypad, so unless its being muxed somewhere, the are 2 ports.


int __init s3c2416_init(void)
{
        printk(KERN_INFO "S3C2416: Initializing architecture\n");

        s3c24xx_reset_hook = s3c2416_hard_reset;
        /* s3c24xx_idle = s3c2416_idle; */

        /* change WDT IRQ number */
        s3c_device_wdt.resource[1].start = IRQ_S3C2443_WDT;
        s3c_device_wdt.resource[1].end   = IRQ_S3C2443_WDT;

        /* the i2c devices are directly compatible with s3c2440 */
        s3c_i2c0_setname("s3c2440-i2c");
        s3c_i2c1_setname("s3c2440-i2c");

        s3c_device_fb.name = "s3c2443-fb";

        return sysdev_register(&s3c2416_sysdev);
}

[fremen67]

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.

Anyway the current u-boot version (FW1.00.2) is quite a pity and it will be easier to replace it with a modified one (tftp itself works but the new menus for file transfer are still buggy). Plus it is locked.
I got one version of TQ2416 u-boot sources on which I activated all the standard u-boot functionalities (console prompt with commands list) and which run on my dev board succesfully. I will try it on the HDG when back home (sunday).

[idpromnut]

@idpromnut: Yep, not a driver in the kernel sense, anymore than the backlight 'driver'. The datasheet seems to only show one i2c port, but the init code lists 2. (see below) I didn't spy any other messages when probing the keypad, so unless its being muxed somewhere, the are 2 ports.


int __init s3c2416_init(void)
{
        printk(KERN_INFO "S3C2416: Initializing architecture\n");

        s3c24xx_reset_hook = s3c2416_hard_reset;
        /* s3c24xx_idle = s3c2416_idle; */

        /* change WDT IRQ number */
        s3c_device_wdt.resource[1].start = IRQ_S3C2443_WDT;
        s3c_device_wdt.resource[1].end   = IRQ_S3C2443_WDT;

        /* the i2c devices are directly compatible with s3c2440 */
        s3c_i2c0_setname("s3c2440-i2c");
        s3c_i2c1_setname("s3c2440-i2c");

        s3c_device_fb.name = "s3c2443-fb";

        return sysdev_register(&s3c2416_sysdev);
}

Hmm, it mentions the 2440, I wonder if that one has two ports versus the 2416 maybe only having 1?

[fremen67]

On that note: I am having problems getting TopJTAG Probe to work with the 2416. The BSDL is not official, and had a number of incompatibilities: duplicate pin #'s, bracketed port defs, mislabeled pins. Also the DeviceID is different. I now have the BSDL loading properly and the device package appears complete. However, a simple sampling probe shows no changes at all while the device is running (verified with serial term). 
I've attached my altered bsdl file and screen shot below.

Did you try the one posted by Tinhead?: https://www.eevblog.com/forum/testgear/review-of-owon-sds7102/msg315938/#msg315938

[alex.forencich]

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?

I considered this, but the thing is that the unit has two frequency references - one internal and one external - and the FPGA needs to be able to switch between them without resetting the memory controller.  So the memory controller and some of the logic will run off of the internal osc, and the DSP/DDS/DAC logic will run off of a switched reference input.  Take a look at clock.v in the repo right now; I am in the process of getting all of the clock switching logic working right now. 

This should be relatively easy to arrange as the memory controller ports can all be placed in independent clock domains.  I also want to run the memory as fast as possible as there are multiple things that need to have access and I want to make sure nothing gets starved.  There should be enough memory bandwidth to run both DAC channels from one memory controller - wouldn't it be great to have an unequal split and have >64Mpts accessible to one channel while still being able to use the other channel?  That's basically what I'm hoping to do - anything can read from anywhere.  Also, I plan on supporting at least 4 internal channels - two main ones, and at least one more 'sub channel' per main channel for arbitrary AM, FM, PM, FSK, PSK, etc. modulation.  There is also the 16 bit digital output that will have to read from somewhere. 

Basically, I want to make this thing as close to as the Agilent TrueForm generators in functionality as possible.  I'm just hoping the FPGA is big enough.

Alright, after doing quite a bit of poking around, it turns out that the DCM modules can be instantiated two ways: either as a DCM_SP or as a DCM_CLKGEN.  And at least for converting 10 MHz to 250 MHz, the DCM_SP output has about 600 ps worth of jitter while the DCM_CLKGEN has about 216 ps worth of jitter.  A PLL_ADV cannot take 10 MHz as an input directly, it would have to be stepped up by a DCM first (min input freq is 19 MHz).  A PLL driven by a DCM_CLKGEN at 250 MHz and 0.054 UI of jitter (216 ps) that outputs 500 MHz and 250 MHz would have 121 ps jitter on the 500 MHz output and 136 ps jitter on the 250 MHz output.  216 ps is not all that much more than 136 ps (within a factor of 2 anyway), so I think the DCM_CLKGEN blocks may be sufficient for sourcing the 250 MHz clock.  I have updated the design to convert the two 10 MHz input DCMs to DCM_CLKGEN and I removed the output DCM that was generating the 10 MHz output reference (I figured out how to do that in the logic with a shift register and a DDR output register, so the 10 MHz output clock is no longer required). 

I don't think it's going to be possible to get a whole lot better than that without re-architecting the device.  The 'correct' solution would be to provide a high-stability external synthesizer and a clock buffer to drive the DAC clock and FPGA logic.  However, this is out of the question since we are stuck with the boards that Hantek has made. 

[alex.forencich]

At this point the reference clock switching logic is basically complete.  The idea is that some parts of the FPGA (memory controller) will always run on the internal 10 MHz oscillator, while the digital front end (DAC, DSP, DDS, etc.) will run on the external oscillator when available.  The FPGA will seamlessly (well, more or less) switch to the external oscillator when one is provided at the appropriate frequency, and then switch back to the internal oscillator when the signal is lost.  The clock module has a built-in frequency counter that measures the frequency of the reference oscillator input.  If it is within the correct limits for long enough, the logic will turn on the external reference DCM and then switch the digital front end over to that clock when it is stable.  If the signal disappears or goes out of range, then the clock switching logic will disable the external reference DCM and switch the digital front end back to the internal oscillator.  Unfortunately, when this happens the digital front end will be reset, so we will probably need to add some code on the ARM core to reload all of the parameters after a clock switchover.  However, since the memory controller is not affected, all 128 Mpts of arbitrary waveform memory should be in tact (if the memory controller gets reset for more than the refresh timer (around 8 us), then it is possible that some portions of memory will be corrupted).  It should also be possible to support seamless switching to 100 MHz on the ext ref in by adding a second window to the frequency counter and then adding logic to reconfigure the DCM on the fly.  Not sure if this would be a worthwhile feature or not, but it is certainly doable. 

Also, I pulled the heatsink off the board and confirmed the speed grade of the chip: it's a -2.  Full part number is XC6SLX16CSG324-2C.  So we won't be able to run the memory controller at 667 MHz as the -2 is only rated to 625 MHz.  The block RAM on a -2 will run up to 280 MHz and the DSP48 slices (18x18 multiplier + 48 bit adder) will run at 333 MHz. 

[tinhead]

On that note: I am having problems getting TopJTAG Probe to work with the 2416. The BSDL is not official, and had a number of incompatibilities: duplicate pin #'s, bracketed port defs, mislabeled pins. Also the DeviceID is different. I now have the BSDL loading properly and the device package appears complete. However, a simple sampling probe shows no changes at all while the device is running (verified with serial term). 
I've attached my altered bsdl file and screen shot below.

Did you try the one posted by Tinhead?: https://www.eevblog.com/forum/testgear/review-of-owon-sds7102/msg315938/#msg315938

actually my bsdl is nt working as well, one can not use it with e.g. universal scan (getting tons of syntax errors) and with topjtag is doing eact the same, meaning nothing, update on pins only during powerup but then no informations anymore.

[alex.forencich]

On that note: I am having problems getting TopJTAG Probe to work with the 2416. The BSDL is not official, and had a number of incompatibilities: duplicate pin #'s, bracketed port defs, mislabeled pins. Also the DeviceID is different. I now have the BSDL loading properly and the device package appears complete. However, a simple sampling probe shows no changes at all while the device is running (verified with serial term). 
I've attached my altered bsdl file and screen shot below.

Did you try the one posted by Tinhead?: https://www.eevblog.com/forum/testgear/review-of-owon-sds7102/msg315938/#msg315938

actually my bsdl is nt working as well, one can not use it with e.g. universal scan (getting tons of syntax errors) and with topjtag is doing eact the same, meaning nothing, update on pins only during powerup but then no informations anymore.

So is that the BSDL file or something strange about the JTAG interface on the chip?

[tinhead]

On that note: I am having problems getting TopJTAG Probe to work with the 2416. The BSDL is not official, and had a number of incompatibilities: duplicate pin #'s, bracketed port defs, mislabeled pins. Also the DeviceID is different. I now have the BSDL loading properly and the device package appears complete. However, a simple sampling probe shows no changes at all while the device is running (verified with serial term). 
I've attached my altered bsdl file and screen shot below.

Did you try the one posted by Tinhead?: https://www.eevblog.com/forum/testgear/review-of-owon-sds7102/msg315938/#msg315938

actually my bsdl is nt working as well, one can not use it with e.g. universal scan (getting tons of syntax errors) and with topjtag is doing eact the same, meaning nothing, update on pins only during powerup but then no informations anymore.

So is that the BSDL file or something strange about the JTAG interface on the chip?

well, hard to say. The bsdl provided by Cyber7 seems to be good (from TopJTAG point of view), and with little modification i was able to load it into UniversalScan (attached, i had to remove names of registers that does not have ports defined, like CAM interface which does not exist on S3C2416 but one the bigger brother S3C2450). However, still no pins updates in sample mode nor any action/reaction in extest mode. When i change boot mode (i'm testing on s3c2416 dev board) to illegal state and reset it, the SoC is starting and data shown on jtag (i can then even play with extest mode). So looks like something is blocking jtag. I thought it might be nand data, but without nand (i do have nand in socket on my dev board) same result - no pins scan etc. I can't test jtag boot mode due hardwired OM0 on my dev board), but that would still not do the job for you guys (as you can't "patch" pcb anyway).

I do have genuine JtagKey and Key2, as well other adapters, so not a jtag<->sw problem.

So whatever it is, i'm not getting jtag scan working :\ It might be still the bsdl, the quality of Samsung provided bsdl is really crap (at least s3c2450 and s3c2416 are not properly working).

[Cyber7]

@tinhead: How did you get the mcu into an illegal state on your devkit?

I don't think it's the jtag or the bsdl. I've been successful in dumping the nand via openocd, so I thought to check into the low-level boundary scan routines since the jtag appears to be working correctly in this instance. I borrowed some tcl routines (manual_bs.tcl) initially made for an STM32 target and altered the instruction opcodes to conform with the s3C24xx mcu's. While I was able to get the IDCODE, any SAMPLE attempt returned either all FF or 00 depending on the processor state. I attached my target board openocd cfg.

Manual attempts also failed with all 0's :

scan_chain

   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 S3C2416.cpu            Y     0x07926f0f 0x07926f0f     4 0x01  0x0f

targets

    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0* S3C2416.cpu        arm926ejs  little S3C2416.cpu        running
 
init
halt
poll off
sleep 4000
irscan S3C2416.cpu 14
drscan S3C2416.cpu 32 0

07926F0F     <---matches mcu IDcode
 
irscan S3C2416.cpu 3          <-- sample opcode
drscan S3C2416.cpu 685 0   <-- scan all 685 bits

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0xa0000013 pc: 0xc0267770
MMU: enabled, D-Cache: enabled, I-Cache: enabled

drscan S3C2416.cpu 685 0

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

[tinhead]

@tinhead: How did you get the mcu into an illegal state on your devkit?

i did setup project (topjtag or universalscan - openocd is not possible to open into that state),  with boot from iROM with NAND attached. Then changed to boot from OneNAND (which does not exists) and enabled eFuse. After reset, with extest enabled, i got access. The only probelm is, due floating input pins it's impossible to get "in" valus and "out" does only works when i/o got randomly switched to out (but the out value is the one i set with extest).
So that not the solution we need.

I don't think it's the jtag or the bsdl. I've been successful in dumping the nand via openocd, so I thought to check into the low-level boundary scan routines since the jtag appears to be working correctly in this instance.

i do not have any issues to access via H-JTAG USB. Sure, DEVICE_ID and BYPASS are working, however what BOUNDARY is doing is unclear for me. There are two possible "jtag modes" for s3c2416, one with OM0:OM4 set to 10001 (which i can't set on my dev board due hardwired pins under the bga, this is boot from jtag and jtag enabled) and OM0:OM4 set to x0010 (which is jtag enabled while irom boot set). But even if i set that mode (and regarding to SMDK2416 docs that should be ok) still no boundary scan

Manual attempts also failed with all 0's :

tried as well, with/without the iROM+JTAG boot option as described above, but no result :\

Unfortunately Samsung never responded to my questions about S3C2416 boundary scan (~ 2yrs ago).

[alex.forencich]

How important is the boundary scan on the device?  It seems like it will not be easy/possible to get working.  I had a similar issue on some Virtex 4 FPGAs - I could not get the pins to toggle under the control of the boundary scan, so I could not do pin mapping between multiple devices automatically.  It did work for external sources, just not another Virtex 4 - and there were 11 FPGAs on one board I was trying to get sorted out. 

I think most of the pins aren't really all that important to look at - the memory and display connections are already made at fixed locations, etc. Perhaps what we should do is just write some test code to toggle pins and then check with the scope to see what pin is toggling.  A few educated guesses go a long way - we're mainly interested in SPI and I2C, no?  Those pin locations are indicated in the datasheet.  I'm not sure if we're going to be able to do much better than that without cracking our heads against the wall for a long time. 

[Cyber7]

Well, it would have been nice to have full control of both the fpga & soc. The original SMDK seems to have allowed full access to the OM selector via dip switch. Would have made life easier.

The SDRAM arrangement does indeed look correct. I've also found a schematic with the exact same devices which confirms the pinouts on Banks 1/3.

Since TopJTAG does not work with the Xilinx platform USB cable, I had to rig my Altera USB blaster to work with the onboard xilinx jtag pinout. It actually does work!

I unremarked the SDRAM's from the contraint file and imported it to name the pins. That way I could eliminate them as knowns. Then I set watches on all remaining un-named pins. I wish pins could be masked out so they can easily be ignored on the led pin display.

I reset the FPGA, keeping all input pins in hi-z, then ran /dso/app/test_cmd which sends no command without an SCPI parameter, however it always initializes the front end relays. I noted transitions on FPGA pins P8 ( 70 ), R13 ( 14 ), R15 ( 8 ). P8 may be sdi or sck from the SOC. The sampling rate from the Altera BB doesn't allow for accurate waveforms. Time to break out the scope and check the shunted isolation bridge for contemporaneous transitions.

[alex.forencich]

What schematic did you pull those from?  I have been trying to confirm the RZQ and ZIO pins.  The RZQ pin should be connected to GND through a resistor and the ZIO pin should be no connect.  They can be any unused pin in the same bank.  I think the RZQ pins are C2 and C18, but I am not sure about the ZIO pins.  Best guess so far is L6 and M14.  The schematic you have shows C2 and L6.  Does that schematic show another DDR2 memory connection?  If so, which RZQ and ZIO pins are being used? 

Also, which board rev do you have?  I have 1004, but it is possible there are FPGA pinout differences between the boards. 

R13 and R15 are DIN and CCLK, so whatever is connected to R13 would have to be MOSI and R15 would have to be SCK.  However, I am not sure if those pins can be assigned in the UCF file. On my board, N9 and R13 are connected and P12 and R15 are also connected so N9 and P12 are likely to be the actual MOSI and SCK pins.  P8 I was not sure about, it could be chip select or reset.  In the other direction, M10 seems to be the most likely candidate for MISO as the other three pins through that isolator are DONE, INIT, and PROGRAM_B. 

[Cyber7]

They're schems from an Opal Kelly dev board http://www.opalkelly.com/products/xem6006/ They do not show the bank 1 connections.

I think the RZQ pins are C2 and C18, but I am not sure about the ZIO pins.  Best guess so far is L6 and M14.

The schem agrees with bank 3 C2/L6, I also have another schem from a Siga SPartan 6 dev kit with only 1 SDRAM on bank 3 that also agrees with the same pinout.

There's continuous traffic on C2/C18, even if the SOC is halted, unless I reboot the SOC and prevent the fpga bitstream from being loaded.

My board is rev 1004.

I have seen R13 and R15 on another UCF declared as:

NET "FPGA_D0_DIN_MISO_MISO1"  LOC = "R13";
NET "FPGA_CCLK" LOC = "R15";

Will continue inspection tomorrow. P8 looks too chatty when i issue a command for a cs/rst; looks more like a clk/mosi.

[alex.forencich]

They're schems from an Opal Kelly dev board http://www.opalkelly.com/products/xem6006/ They do not show the bank 1 connections.

I think the RZQ pins are C2 and C18, but I am not sure about the ZIO pins.  Best guess so far is L6 and M14.

The schem agrees with bank 3 C2/L6, I also have another schem from a Siga SPartan 6 dev kit with only 1 SDRAM on bank 3 that also agrees with the same pinout.

There's continuous traffic on C2/C18, even if the SOC is halted, unless I reboot the SOC and prevent the fpga bitstream from being loaded.

These pins are used for calibrating the local termination impedance for the DDR2 interface.  I have no idea exactly how it works, but supposedly it is run continuously to adjust for voltage and temperature variations.  So if you are seeing chatter on C18, that indicates my guess is probably correct. 

My board is rev 1004.

I have seen R13 and R15 on another UCF declared as:

NET "FPGA_D0_DIN_MISO_MISO1"  LOC = "R13";
NET "FPGA_CCLK" LOC = "R15";

Will continue inspection tomorrow. P8 looks too chatty when i issue a command for a cs/rst; looks more like a clk/mosi.

It may be possible to access those pins from the fabric.  It is not possible on all of the FPGAs - I tried to use CCLK as an input on a Virtex 4, and it gave me an error. 

R15 is called IO_L1P_CCLK_2 and and R13 is called IO_L3P_D0_DIN_MISO_MISO1_2, so it seems like those can be used as general I/O in bank 2.  On the Virtex 4 it is just called CCLK_0 and the bank is undefined.  Accessing these pins from user logic may be possible. 

Also, can you check for activity on P12, N9, and M10?  These are listed in the UCF file as cntrl_sck, cntrl_mosi, and cntrl_miso.  Not sure if you are ignoring activity on these at the moment or not. 
On the bottom of the board, near the isolators - are these populated on your board?  R110, R114, RA6. 

[Cyber7]

These pins are used for calibrating the local termination impedance for the DDR2 interface.  I have no idea exactly how it works, but supposedly it is run continuously to adjust for voltage and temperature variations.  So if you are seeing chatter on C18, that indicates my guess is probably correct.

I believe you are right. See page 33 of the Spartan 6 Memory Controller guide (link below). The guide should prove useful in setting up the SDRAM parameters for synthesizing the controllers with the Xilinx MIG. I need to look into this and write up some simple pattern/walk tests.

http://www.xilinx.com/support/documentation/user_guides/ug388.pdf

Here's a nice guide: http://www.xilinx.com/support/documentation/boards_and_kits/xtp039.pdf

Also, can you check for activity on P12, N9, and M10?

I recall seeing some duplicate traffic to R13/R15. I wasn't looking at documented pins, so I'll check again. Wish I could get more than 3-400samps/sec out of this jtag.

[alex.forencich]

These pins are used for calibrating the local termination impedance for the DDR2 interface.  I have no idea exactly how it works, but supposedly it is run continuously to adjust for voltage and temperature variations.  So if you are seeing chatter on C18, that indicates my guess is probably correct.

I believe you are right. See page 33 of the Spartan 6 Memory Controller guide (link below). The guide should prove useful in setting up the SDRAM parameters for synthesizing the controllers with the Xilinx MIG. I need to look into this and write up some simple pattern/walk tests.

What do you think I have been reading forwards and backwards for the past week?  Right now I am working on a MyHDL model of a multiport memory with Spartan 6 MCB-style interfaces so the core logic can be tested without having to simulate the entire memory controller.  The MCB 'classic' interface is a bit lighter-weight than a full AXI interface, which is important for this application due to the limited size of the FPGA.  Especially because the classic interface requires no additional logic - it is a direct connection to the hard IP memory controller - while the AXI interfaces are implemented as a wrapper on top of the hard core interfaces, so using AXI interfaces requires a larger overhead in LUTs. 

http://www.xilinx.com/support/documentation/user_guides/ug388.pdf

Here's a nice guide: http://www.xilinx.com/support/documentation/boards_and_kits/xtp039.pdf

Dang, that's for an old version of ISE...I have 14.7 system edition installed...

I have a core generated, I'm just in the process of figuring out how I'm going to verify that it works correctly.  I may just have to put in a chip scope instance to look at the error signals. 

Also, can you check for activity on P12, N9, and M10?

I recall seeing some duplicate traffic to R13/R15. I wasn't looking at documented pins, so I'll check again. Wish I could get more than 3-400samps/sec out of this jtag.

Those pins go through the resistor arrays that bridge over the isolator footprints.  You can easily put a scope probe on those pins and capture the SPI data. 

[idpromnut]

Quick update on the Penguin end of things:

• I have been dicking around with UBoot (the boot loader for the HDG2000), and it looks like either there will be some work to integrate the modifications that were posted by Hantek (in the DSO5000 drop they did) into the most recent version of UBoot. The other option (which I need to try out tonight) is to build their UBoot tree and see if I get useable output. If so, I will probably just leave the boot loader alone for a bit and focus elsewhere.
• The "elsewhere" will be getting the Linux kernel that I have booting now to boot the NAND flash with the existing Hantek Firmware. This will let me do a couple of things:
  
  • have a way of "sanity checking" that a linux build works
  • check that I'm not missing built in drivers that are needed for the HDG2000
• After getting a kernel booting the existing firmware, I will focus on booting from SD; that will let me build and test this whole beast while leaving the stock firmware in-place.
  
• A distant third on this list will be exploring Hantek's firmware upgrade process (har har har) and seeing if I can alter the UBoot options from the linux environment and save them so I can create an "upgrade" firmware package that will allow you to change the target boot to the SD or back to the internal NAND. This will facilitate other people when developing and testing firmware releases.
  

[alex.forencich]

I have one DDR2 controller operational at 625 MHz.  I just modified the example design to run with a 10 MHz input clock, set the pins in the UCF file, and dropped it on the board.  Interestingly, it seems there is some sort of a startup transient error condition - the testbench error output goes high immediately after the calibration sequence completes.  I'm not sure why this is.  Reading out the port 0 status information with chipscope after startup indicates no compare errors.  However, if I reset the design continuously and grab a trace with chipscope, then I do see a short stream of compare errors at the beginning of the trace.  However, after this settles down, the core seems to work perfectly.  I tested both the standard address-as-data mode as well as the hammer and neighbor modes that look for crosstalk.  I have yet to see any errors after startup.  Next step is to try the other controller. 

[alex.forencich]

Trace of one of the data lines between U5 and U8 while running PRBS test data.  Signal integrity looks decent.  I'm not triggering on the absolutely most correct signal for this to be perfect, so there are lots of overlapped traces with different patterns and offsets. 

[alex.forencich]

The other channel (U12) also works correctly.  Same transient startup error, but it is fine after that with hammer, neighbor and PRBS test modes. 

[Cyber7]

That's good news! Can you post your MIG options summary? What percentage of the device's LUT's are utilized per controller?

On the bottom of the board, near the isolators - are these populated on your board?  R110, R114, RA6.

Yes. See attached image.

I ran short on time today, but I've built a makeshift tap for the isolation bus data pins and put my logic analyzer on it. Seems a negative Slave Select initiates an SPI transaction, See attached image for tentative pinout, and snippet from a transaction. The bytewise interpretation may not be correct. I'll see about backtracking miso to the fgpa.

Edit: M10 = MISO confirmed
        Looks to me like P8 = MOSI

[alex.forencich]

I just finished writing a new MCB wrapper script that is a bit more cleaned up and doesn't automatically pull in a PLL.  And I take back what I said before, it seems like it is possible for one PLL to drive two BUFPLL_MCB on opposite sides of the device.  I have one PLL_ADV instance driving two BUFPLL_MCB to drive the MCBs, and it synthesized without any errors.  So I will probably go ahead and stick a PLL in the 250 MHz clock for the DAC and DSP components. 

Here is the current utilization:

Code: [Select]

Device Utilization Summary:

Slice Logic Utilization:
  Number of Slice Registers:                   763 out of  18,224    4%
    Number used as Flip Flops:                 763
    Number used as Latches:                      0
    Number used as Latch-thrus:                  0
    Number used as AND/OR logics:                0
  Number of Slice LUTs:                      1,160 out of   9,112   12%
    Number used as logic:                    1,146 out of   9,112   12%
      Number using O6 output only:             826
      Number using O5 output only:              72
      Number using O5 and O6:                  248
      Number used as ROM:                        0
    Number used as Memory:                       1 out of   2,176    1%
      Number used as Dual Port RAM:              0
      Number used as Single Port RAM:            0
      Number used as Shift Register:             1
        Number using O6 output only:             1
        Number using O5 output only:             0
        Number using O5 and O6:                  0
    Number used exclusively as route-thrus:     13
      Number with same-slice register load:      3
      Number with same-slice carry load:        10
      Number with other load:                    0

Slice Logic Distribution:
  Number of occupied Slices:                   440 out of   2,278   19%
  Number of MUXCYs used:                       200 out of   4,556    4%
  Number of LUT Flip Flop pairs used:        1,293
    Number with an unused Flip Flop:           574 out of   1,293   44%
    Number with an unused LUT:                 133 out of   1,293   10%
    Number of fully used LUT-FF pairs:         586 out of   1,293   45%
    Number of slice register sites lost
      to control set restrictions:               0 out of  18,224    0%

  A LUT Flip Flop pair for this architecture represents one LUT paired with
  one Flip Flop within a slice.  A control set is a unique combination of
  clock, reset, set, and enable signals for a registered element.
  The Slice Logic Distribution report is not meaningful if the design is
  over-mapped for a non-slice resource or if Placement fails.

IO Utilization:
  Number of bonded IOBs:                       177 out of     232   76%
    Number of LOCed IOBs:                      177 out of     177  100%
    IOB Flip Flops:                             34
    IOB Master Pads:                             1
    IOB Slave Pads:                              1

Specific Feature Utilization:
  Number of RAMB16BWERs:                         0 out of      32    0%
  Number of RAMB8BWERs:                          0 out of      64    0%
  Number of BUFIO2/BUFIO2_2CLKs:                 0 out of      32    0%
  Number of BUFIO2FB/BUFIO2FB_2CLKs:             0 out of      32    0%
  Number of BUFG/BUFGMUXs:                       6 out of      16   37%
    Number used as BUFGs:                        4
    Number used as BUFGMUX:                      2
  Number of DCM/DCM_CLKGENs:                     2 out of       4   50%
    Number used as DCMs:                         0
    Number used as DCM_CLKGENs:                  2
  Number of ILOGIC2/ISERDES2s:                   0 out of     248    0%
  Number of IODELAY2/IODRP2/IODRP2_MCBs:        48 out of     248   19%
    Number used as IODELAY2s:                    0
    Number used as IODRP2s:                      4
    Number used as IODRP2_MCBs:                 44
  Number of OLOGIC2/OSERDES2s:                 124 out of     248   50%
    Number used as OLOGIC2s:                    34
    Number used as OSERDES2s:                   90
  Number of BSCANs:                              0 out of       4    0%
  Number of BUFHs:                               0 out of     128    0%
  Number of BUFPLLs:                             0 out of       8    0%
  Number of BUFPLL_MCBs:                         2 out of       4   50%
  Number of DSP48A1s:                            0 out of      32    0%
  Number of ICAPs:                               0 out of       1    0%
  Number of MCBs:                                2 out of       2  100%
  Number of PCILOGICSEs:                         0 out of       2    0%
  Number of PLL_ADVs:                            1 out of       2   50%
  Number of PMVs:                                0 out of       1    0%
  Number of STARTUPs:                            0 out of       1    0%
  Number of SUSPEND_SYNCs:                       0 out of       1    0%

TL;DR: we still have about 80% of the FPGA available for the rest of the logic. 

[alex.forencich]

That's good news! Can you post your MIG options summary? What percentage of the device's LUT's are utilized per controller?

MIG project file is in the repo.  I think you can run it with the webpack license.  Just run 'make' in the coregen subdirectory.  The LUT utilization is very low as the MCB is a hard core.  The LUTs it requires directly are only for calibrating the termination impedance. 

On the bottom of the board, near the isolators - are these populated on your board?  R110, R114, RA6.

Yes. See attached image.

I believe the CCLK and DIN pins connect through these components to the SoC so they can be isolated if an external config flash is used for the FPGA.  Initially I thought your board must be different from mine because you did not list any activity on the pins I had guessed were for the SPI port in the design. 

I ran short on time today, but I've built a makeshift tap for the isolation bus data pins and put my logic analyzer on it. Seems a negative Slave Select initiates an SPI transaction, See attached image for tentative pinout, and snippet from a transaction. The bytewise interpretation may not be correct. I'll see about backtracking miso to the fgpa; I'll also look into cntrl_sck, cntrl_mosi, and cntrl_miso.

Edit: M10 = MISO

This is exactly what I had guessed.  From what you have in your image, it should match the UCF file exactly.  Also, I went ahead and added the CS pin to the UCF file as well. 

[Cyber7]

For greater resolution than that available via jtag: Do you think it possible to write a dummy fpga project, with a modified UCF setting all pins to tristate except the pins we wish to probe for input & use Chipscope to record the waveforms?

[alex.forencich]

For greater resolution than that available via jtag: Do you think it possible to write a dummy fpga project, with a modified UCF setting all pins to tristate except the pins we wish to probe for input & use Chipscope to record the waveforms?

Well, there are a few options.  We could use chipscope, but you need a license for that.  Another possibility is to route interesting signals through to the digital output connector on the front and then connect a logic analyzer to that.  Any pin not allocated will end up being tristated, possibly with a weak pull-up. 

However, I think I have probed just about everything there is to probe from the FPGA side.  I know what all the pins are to control the front end components, DACs, DDR2, digital out, ADC, etc.  The specifics of the protocols can be gleaned from the part datasheets.  Besides, what is there to probe once you remove the FPGA configuration?  And we're going to be rewriting the SPI interface anyway, so the specifics of that aren't really all that important, unless you want to be able to control the default FPGA configuration. 

The main mystery I have been stuck on is what the other pins on the analog mux (U27) go to.  One input comes from the modulation input, and the output goes to the TI ADC.  However, the analog mux has 7 other inputs, and I have no clue what they are connected to.  Poking around with a multimeter did not turn up anything interesting.  JTAG won't be of any help with that, though. 

[Cyber7]

Another possibility is to route interesting signals through to the digital output connector on the front

Now there's an awesome idea I didn't consider!

For me, it would be a good exercise, since I've little flight time on FPGAs. I'm also more familiar with the Altera tool chain; I find it easier to work with and faster than Xilinx ISE too.

Good to know that the DDR2 logic for both banks will take less than 25% of the device.

Fortunately, as you say, there's little use to decode the SOC<->FPGA SPI comms. It is a bit of a curiosity given the repetitive chatter when running a 'simple'  /dso/app/test_cmd. It overflows the buffer on my analyzer due to all the sck transitions even with transitional compression.

U27 is a PITA. I've overlaid the top/bot PCB images and at least 4 of the Y inputs end in blind vias. Any idea if the chip selects source from the FPGA? Also, what's with all the inductors on the ADC?

Also, Have you verified the front end serial shift registers that operate the relays?

I just ordered an TQ2416 dev kit from Wayengineer.com, so I can work on the Linux side of things while at the office. Hopefully it will come with schematics.

[alex.forencich]

Another possibility is to route interesting signals through to the digital output connector on the front

Now there's an awesome idea I didn't consider!

For me, it would be a good exercise, since I've little flight time on FPGAs. I'm also more familiar with the Altera tool chain; I find it easier to work with and faster than Xilinx ISE too.

Fortunately, as you say, there's little use to decode the SOC<->FPGA SPI comms. It is a bit of a curiosity given the repetitive chatter when running a 'simple'  /dso/app/test_cmd. It overflows the buffer on my analyzer due to all the sck transitions.

U27 is a PITA. I've overlaid the top/bot PCB images and at least 4 of the Y inputs end in blind vias. Any idea if the chip selects source from the FPGA? Also, what's with all the inductors on the ADC?

Also, Have you verified the front end serial shift registers that operate the relays?

Check the UCF file!  I probed all of those pins already. 

Code: [Select]

# U24/U26 front end relay control
NET "ferc_dat"      LOC = "B3"  | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 0, IO_L4P_0,                  U24.14
NET "ferc_clk"      LOC = "B2"  | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 0, IO_L2P_0,                  U24.11, U25.11
NET "ferc_lat"      LOC = "A2"  | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 0, IO_L2N_0,                  U24.12, U25.11

# U27 Analog Mux
NET "mux_s<0>"      LOC = "T12" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L19P_2,                 U27.11
NET "mux_s<1>"      LOC = "V13" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L14N_D12_2,             U27.10
NET "mux_s<2>"      LOC = "U13" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L14P_D11_2,             U27.9

# U30 ADC
NET "adc_sclk"      LOC = "V16" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L2N_CMPMOSI_2,          U30.15
NET "adc_sdo"       LOC = "U11" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L23P_2,                 U30.13
NET "adc_sdi"       LOC = "U15" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L5P_2,                  U30.12
NET "adc_cs"        LOC = "V15" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L5N_2,                  U30.11
NET "adc_eoc"       LOC = "V14" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L12N_D2_MISO3_2,        U30.10
NET "adc_convst"    LOC = "U16" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L2P_CMPCLK_2,           U30.9

All of the select pins on U27 are routed to the FPGA via ferrite beads (L46-48).  The ADC connections to the FPGA are also routed via ferrites (L49-54).  The front end control shift registers are also connected via ferrites (L40-42).  I believe they put the ferrites in there to prevent noise from the FPGA coupling into the analog components over the signal lines.  Not a bad idea, I suppose. 

On U27 there seem to be two analog inputs that are connected to caps on the other side of the board.  I have no idea if there is a trace on the inner layer that runs off somewhere for those inputs.  I'm hoping that there is a way to route the arb outputs back around to the ADC for self calibration or self test purposes.  It's possible they're connected to one of the front end relays, perhaps the unknown ones X4 and X5.  It's possible that's how Hantek implemented some of the modulation - send it out the door and back in again to save on the routing in the FPGA.  I did not really play around with the modulation much before tearing it apart, so I'm not really sure what it's capable of, at least in terms of one channel modulating the other one.  A bit idiotic if they did it that way, but whatever. 

[Cyber7]

Have you verified the front end serial shift registers that operate the relays?

Sorry, I wasn't clear: Have you verified positive control of the relays match my output schematic and logic table, not just the pin routing to the shift regs?

[alex.forencich]

Have you verified the front end serial shift registers that operate the relays?

Sorry, I wasn't clear: Have you verified positive control of the relays match my output schematic and logic table, not just the pin routing to the shift regs?

Ah, I have not done that.  I figured that could be done later once there is a method of driving those pins nicely from the FPGA. 

I just finished soldering a header on to my board so I can use a Bus Pirate to control the FPGA.  Next step is to start building the FPGA side of that link and perhaps look in to some sort of cosimulation interface for testing (control software talks to either the MyHDL simulation or the bus pirate, hopefully without channelling Rube Goldberg too much).   

[Cyber7]

I know what you mean; but sometimes you can't avoid one thing leading to another. I actually had to build one in a freshman competition, with the final stage inflating a Space Shuttle inflatable.

Wouldn't the front digital IO ports make for a nice cosim IF for the BP? Perhaps 4 bits as an I2C channel for C&C, 4 bits direct status and the other 8 for pass-through IO.

[alex.forencich]

I know what you mean; but sometimes you can't avoid one thing leading to another. I actually had to build one in a freshman competition, with the final stage inflating a Space Shuttle inflatable.

Wouldn't the front digital IO ports make for a nice cosim IF for the BP? Perhaps 4 bits as an I2C channel for C&C, 4 bits direct status and the other 8 for pass-through IO.

Well, I removed the resistor arrays from my board so I don't have to muck around with the SoC.  So what I'm planning on doing is just using the bus pirate in SPI mode to talk to the FPGA through the same pins that the SoC would use.  But what I want to be able to do is write a high-level control script in python and be able to test that against not only the design on the actual FPGA through the bus pirate, but also connect it to the MyHDL/Verilog cosimulation through some form of interprocess communication.  I might have to use sockets, not sure at this point.  Right now the digital out port is connected to my MSO7104 so I can send out test signals and look at stuff in real time.  I can certainly forward out the SPI interface and decode it on the scope if need be, and then mix and match other internal signals as necessary. 

[alex.forencich]

I'm trying to figure out an SPI protocol for controlling the FPGA, and I am looking at the SPI protocol for an ST microelectronics 128 Mbit flash chip for reference.  The fast read command on the ST part consists of an instruction byte, followed by 3 address bytes, and a dummy byte, at which point the data starts streaming out.  Here's the issue: with a 50 MHz SPI bus frequency, that's 8 * 20 = 160 ns to issue a read request to DDR2 and get the first word back.  Worst case (precharge/activate required) read latency for a single port MCB is 32 clocks @ 312.5 MHz = 102.4 ns.  However, it is possible that another read operation will be in progress on another port.  If there is currently a 32 word read operation taking place that also requires precharge/activate, then that could add 32 + 16 + 25.6 ns (precharge + CAS + transfer) = 73.6 ns.  So overall worst case might be 102.4 + 73.6 = 176 ns.  Unfortunately, 176 > 160, so there is a chance that the read will be corrupted if the data is not ready in time. 

There are a couple of possible solutions:

1. run the SPI interface slower.  40 MHz would be 200 ns per byte, leaving 24 ns (6 250 MHz clock cycles) extra.  Running at 50 MHz is preferable because it should be possible to upload a 128 Mpt waveform in ~43 seconds.  At 40 MHz that would take ~54 seconds. 
2. send more than one dummy byte.  2 dummy bytes would be 320 ns, which would give a larger 'buffer'.
3. don't use a fixed number of dummy bytes, instead send a start of read data indication.  This might be the best option as latency issue is completely decoupled, just discard leading zero bytes + 1.  However, reads may have to read a few extra bytes to make sure the entire read completes before CS is lowered. 
4. use a completely different protocol that avoids this problem entirely by decoupling the read request from the read data transfer. 

Also note that this is only really a problem for reading, writing is not affected since the incoming data words can simply be stuffed in a FIFO until the memory is ready (actually, this is how the MCB works: there is a command FIFO, a read FIFO, and a write FIFO - to write, stuff the data in the write FIFO and then stuff the address in the command FIFO; to read stuff the address in the command FIFO and wait for data in the read FIFO). 

Has anyone measured the default SPI clock rate to the FPGA?  I know the SoC is capable of 50 MHz, but did Hantek actually try to use it at that speed?

[Cyber7]

Hi Alex,

Clock source selection to generate HS_SPI clock-out can be: PCLK, USBCLK, EPLL clk.

Assuming PCLK, and High_speed_en set in the config reg, this can be 66.666Mhz as per the SOC boot up logs. USBCLK is a paltry 12Mhz, while I'm uncertain about EPLL without consulting the guide.

The SPI captures I made at the isolation tap point, which initialized the front end, had a 60ns sck cycle (16.66Mhz ) when enabled. This could hardly be the case if the entire SDRAM is read when TTsource performs a 'read' operation, as it does not take very long. Frankly I don't recall offhand if I had the entire buffer populated; I was more interested in getting arb waveforms loaded into SDRAM. I'll look over the SCPI commands logged to see if this is the case, and do a few caps during r/w ops for arb waveforms.

[alex.forencich]

Hi Alex,

Clock source selection to generate HS_SPI clock-out can be: PCLK, USBCLK, EPLL clk.

Assuming PCLK, and High_speed_en set in the config reg, this can be 66.666Mhz as per the SOC boot up logs. USBCLK is a paltry 12Mhz, while I'm uncertain about EPLL without consulting the guide.

The SPI captures I made at the isolation tap point, which initialized the front end, had a 60ns sck cycle (16.66Mhz ) when enabled. This could hardly be the case if the entire SDRAM is read when TTsource performs a 'read' operation, as it does not take very long. Frankly I don't recall offhand if I had the entire buffer populated; I was more interested in getting arb waveforms loaded into SDRAM. I'll look over the SCPI commands logged to see if this is the case, and do a few caps during r/w ops for arb waveforms.

66.66 MHz?  Well, I think a 15ns cycle time can be synced to the 4ns system clock period without too much trouble.  That would take the transfer time of all 128 M points to 32 seconds.  At the default 16.66 MHz clock, the transfer time is around 130 seconds.  I suppose it's really not that huge of a difference, but one of the strong points of this thing is the gigantic sample memory, so it would be nice to be able to access that at a reasonable speed.  It's more the write speed than the read speed that's important, though, as transferring a waveform in to the unit is much more useful than transferring it out. 

[Cyber7]

TTSource has no data read option. The read config option actually has no SOC<->FPGA SPI traffic. I can see traffic when I change any setting, or bulk transfers when writing.

I did see a reference in the Hantek code for the DSO5000 that seems to limit the SPI clk to 48Mhz. Then again, the max SPI speed as per the device structs are 1Mhz for spidev & <500khz for spi for fpga cfg:

static struct spi_board_info s3c2416_spi_board_info[] __initdata = {
   [0] = {
      .modalias   = "spidev",
      .max_speed_hz   = 1000000,
      .bus_num   = 0,
      .chip_select   = 0,
      .irq = IRQ_SPI0,
      .controller_data = &csinfo
   },
   [1] = {
      .modalias   = "AFG3050_fpga_cfg",
      .max_speed_hz   = 499000,
      .bus_num   = 0,
      .chip_select   = 1,
      .irq = IRQ_SPI0,
      .controller_data = &csinfo
   },
};

However, this is not in anyway written in stone as the DSO5000 fpga config utility overrides this to 2.5Mhz:

   spi->mode = SPI_MODE_0;
   spi->bits_per_word = 8;
   spi->max_speed_hz = 2500000;
   fpga_cfg = AFG3050_fpga_cfg_create(spi);

The specs are vague on the upper limit. I've seen a reference to 50MBits/s, but nothing to substantiate that.

Mode 0 (format A) is the original Microwire spec. 8 bits per frame. Each bit is 60ns wide.

For MOSI, they appear to use a page consisting of a 2 byte header + 16byte payload + 2 zero bytes. Each page being 5ms apart.

So there appears to be a delay or timeout that balances CPU resources vs throughput; TRX must be fulfilled while waiting for the RXD FIFO to drain.

See images below.

Here are some limitations on the Linux SPI device API. Nothing onerous, save the max page transfer size is not defined. I think its 256 bytes/page. Thats ~120us for the page at the current Hantek defined data rate.

    - At this time there is no async I/O support; everything is purely
      synchronous.

    - There's currently no way to report the actual bit rate used to
      shift data to/from a given device.

    - From userspace, you can't currently change the chip select polarity;
      that could corrupt transfers to other devices sharing the SPI bus.
      Each SPI device is deselected when it's not in active use, allowing
      other drivers to talk to other devices.

    - There's a limit on the number of bytes each I/O request can transfer
      to the SPI device.  It defaults to one page, but that can be changed
      using a module parameter.

    - Because SPI has no low-level transfer acknowledgement, you usually
      won't see any I/O errors when talking to a non-existent device.

[alex.forencich]

The Spartan 6 DC and switching DS (DS162) lists the max CCLK frequency at 80 MHz.  So the upper limit for configuring the FPGA in slave serial mode will either be the range of the SoC baud rate generator or board signal integrity.  The limit for a custom SPI implementation in LUTs will likely be synchronization.  I would suggest taking a look at the config user guide (ug380) if you haven't already, since we will eventually need to load the FPGA config via slave serial. 

Basically, there are two main ways to implement an SPI slave on the FPGA.  The first is to use SCK as a clock and feed this directly to the CLK inputs of the flops in the receive shift register.  Then higher-level signals will need to be synchronized to the local clock domain.  This is not necessarily the best idea.  The other method is to register all of the SPI signals into a local fast clock domain (in this case, 250 MHz / 4 ns) and then do rising edge detection with an additional flop.  Since 66.7 MHz has a period of 15 ns and the receive clock domain has a period of 4 ns, I think this might be doable.  7.5ns on, 7.5ns off will end up being 1 to 2 clock periods in the local clock domain.  To test the integrity, we should transfer large blocks into SRAM or DRAM and then read them back out and make sure no bits got flipped.  It is possible that we'll have to slow down the clock a bit.  50 MHz has a period of 20 ns and a half period of 10 ns, so each half period should end up being 2 to 3 clocks in the local clock domain.  With this method, no additional synchronization is required since it's already in the local clock domain.  In our case, there will have to be some method for crossing over to the switched 250 MHz clock domain, though this will be relatively low bandwidth (primarily configuration and status registers). 

[alex.forencich]

Clock source selection to generate HS_SPI clock-out can be: PCLK, USBCLK, EPLL clk.

Right, I saw that in the manual.  The question is, how fast are these different clock sources?

Assuming PCLK, and High_speed_en set in the config reg, this can be 66.666Mhz as per the SOC boot up logs. USBCLK is a paltry 12Mhz, while I'm uncertain about EPLL without consulting the guide.

Is PCLK 66.667 MHz or is the SPI module capable of running at 66.667 MHz when driven by PCLK?  If PCLK is 66.667 MHz, then I suppose we could just run the SPI interface at 33.333 MHz.  That would mean a byte would transfer in 320 ns, which would probably alleviate the latency issue out of DDR2. 

[Cyber7]

PCLK is the source for the SPI clock. As per bootup msgs and source structs:


S3C24XX Clocks, Copyright 2004 Simtec Electronics
CPU: MPLL on 800.000 MHz, cpu 400.000 MHz, mem 133.333 MHz, pclk 66.666 MHz
CPU: EPLL on 96.000 MHz, usb-bus 48.000 MHz

///

struct s3c_cpufreq_info s3c2440_cpufreq_info = {
   .max      = {
      .fclk   = 400000000,
      .hclk   = 133333333,
      .pclk   =  66666666,
   },

///

The desired baud rate is software selectable, however, without the source for the user mode app, we can't be certain what value is selected.

baud_rate = PCLK / (2 * ( prescaler + 1) )

ie:

if PCLK = 50000000, and desired baud_rate = 2500000 ( 2.5Mbps is the hantek default for spi fgpa config) ==> the prescaler = 9

The prescaler works out to a nice even number. This is not the case for PCLK = 66666666 as it yields 12.333, however the setting in the driver is the *maximum*, so it could well be the the user mode app is selecting any smaller value. Lets examine the observed baud rate of 16.666667Mhz:

if PCLK = 66666666 , and desired baud_rate = 16666666 ( 16.67Mbps ) ==> the prescaler = 1

However if we desire a baudrate = 33333333, then the prescaler becomes 0

Assuming 0 is a valid value, then this is the max baud rate with the given PCLK of 66.67Mhz.

If we utilized the EPLL = 96Mhz source clock instead, then the max baud rate, with a 0 value prescaler,  becomes 48Mbps.
I believe this clock is termed S3C2416_SPI_SRCCLK_48M within the source:


CPU S3C2416/S3C2450 (id 0x32450003)

#define S3C2416_SPI_SRCCLK_PCLK      0
#define S3C2416_SPI_SRCCLK_SPIBUS   1
#define S3C2416_SPI_SRCCLK_48M      2
static char *spi_src_clks[] = {
   [S3C2416_SPI_SRCCLK_PCLK] = "pclk",
   [S3C2416_SPI_SRCCLK_SPIBUS] = "spi-bus",
   [S3C2416_SPI_SRCCLK_48M] = "spi_48m",
};

...
s3c64xx_spi_set_info(0,0,2);
...

void __init s3c64xx_spi_set_info(int cntrlr, int src_clk_nr, int num_cs)
{
   struct s3c64xx_spi_info *pd;

   /* Reject invalid configuration */
   if (!num_cs || src_clk_nr < 0
         || src_clk_nr > S3C2416_SPI_SRCCLK_48M) {
      printk(KERN_ERR "%s: Invalid SPI configuration\n", __func__);
      return;
   }

   pd = &s3c64xx_spi0_pdata;
   pd->num_cs = num_cs;
   pd->src_clk_nr = src_clk_nr;
   pd->src_clk_name = spi_src_clks[src_clk_nr];
}

[Cyber7]

@Idpromnut:

Been walking like a penguin and have the DSO5000 u-boot and kernel cross-compiled with arm-none-linux-gnueabi-gcc (Sourcery CodeBench Lite 2014.05-29) 4.8.3 20140320. I copied permissions from original uboot/linux distros as the hantek source was zipped. Had to alter a header reference and add a video driver, but it otherwise compiled without a hitch. They did make a few tweaks regarding the s3C2416 and the LCD display.

I'll try the existing uboot with the new kernel on an ext4 SDcard, and let you know how it does.

mach-hantek2416.c has proved very interesting as it has many GPIO pin & device definitions, including SPI defines + initialization! Hopefully they were kept the same on the AWG.

[idpromnut]

@Cyber7:

I was looking at that source file last night. My approach was going to be to take a diff between Hantek's 3.2.35 source tree and the current tree that I'm working with, 3.2.63 and create a patch using that. But yes, I think we would be better off reusing their modifications to the kernel to get the various bits and pieces of hardware working.


EDIT: I just looked at the result of my "patched" linux-3.2.35 kernel with a patch generated from the DSO5000 kernel tree and so far, it looks like the build succeeded. I will try booting my HDG2002 tonight with it and see what goes "boom".   

EDIT, supplemental: I got that kernel to boot, but it segfaulted somewhere while booting the rootfs, but that's ok!  Just means the binaries all need to be compiled together (with the correct deps, etc). As an aside, I got some text on the screen when it segfaulted, so the framebuffer is working!

[idpromnut]

I'll create a patch and dump it in git a bit later tonight. The patch is created against a stock 3.2.35 Linux kernel, so it should make it easy to compile a run-able kernel.

[Cyber7]

@Idpromnut: Can you tell me how you prepared your rootfs and which fs you're using? I tried using nandsim to mount the rootfs nanddumps to no avail, ubinized or no, with/without OOB, with/without  bad blks. So, I then mounted the rootfs / as /mnt/backup and tarballed the whole thing. Then, I untared the entire contents to an ext3 partition (#2) on an sd card. But I get this....

Code: [Select]

 
Kernel command line: noinitrd console=ttySAC0 init=/linuxrc rootfstype=ext3 root=/dev/mmcblk0p2 rw rootwait lcd=X480Y272
...
VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2)
Please append a correct "root=" boot option; here are the available partitions:
1f00            1024 mtdblock0  (driver?)
1f01            2048 mtdblock1  (driver?)
1f02            4096 mtdblock2  (driver?)
1f03          123904 mtdblock3  (driver?)
b300         7761920 mmcblk0  driver: mmcblk
  b301            8192 mmcblk0p1 00000000-0000-0000-0000-000000000000
  b302          131072 mmcblk0p2 00000000-0000-0000-0000-000000000000
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)

 
Edit: Looks like the default hantek kernel build options baked out many file systems. I'll enable them and try again.

Code: [Select]

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4_FS is not set

[idpromnut]

@Cyber7:

Ah, I was just focusing on getting a kernel that could boot the original hantek rootfs in the nand flash. I had not tried rolling my own rootfs yet. However hantek have indeed striped back many "common" kernel options so we will need to modify the config as we go most likely.

[Cyber7]

@Idpromnut:

Did you get any of the boot params to actually persist & save to the NAND? Looks to me like all settings are uboot src header hardcode defaults. If I make changes, reboot and nanddump mtd1 it yields all 'FF' and all settings revert. 

Guess it's time to risk flashing a new uboot.bin from the Hantek src via uboot opt 1, and keep the backup & jtag handy...

EDIT: Adding kernel support for EXT3/EXT4 solved the boot issue. I also removed the NAND support, since I'm not using it at the moment. The fs statup does fault while starting. I do note some failures (namely driver failure messages), like the inability to 'download' the FPGA bit file, serial and keybord errors, DBUS, etc...

Code: [Select]

FPGA CONFIGURE DATA DOWN finish.0x0, 0
FPGA CONFIGURE timeout.
fpga firmware /lib/firmware/htg1000.bit write failed: -1
ln: /dso/app/etc/etc: File exists
ln: /dso/app/home/home: File exists
ln: /dso/app/root/root: File exists
ln: /dso/app/mnt/udisk/udisk: File exists
ln: /dso/app/mnt/sd/sd: File exists
anolis_set_app_init_fun:1172 fun != NULL failed.
anolis_set_app_exit_fun:1179 fun != NULL failed.
open usbd_serial device error !!!!
open kbd error
dbus is valid and addr is unix:path=/tmp/dbus-zegXRYLz8E,guid=d1b4438527287abd42fe94675459d030

[tinhead]

i've spoke with Hantek, they released the GPL sources now for the HDG's

http://www.hantek.com/download/HDG.zip

There are as well all sources of the custom drivers and some control/test apps,
not only for HDG AWGs but as well other S3C2416-SoC based Hantek gears.

[idpromnut]

Did you get any of the boot params to actually persist & save to the NAND? Looks to me like all settings are uboot src header hardcode defaults. If I make changes, reboot and nanddump mtd1 it yields all 'FF' and all settings revert.

No, I haven't tried modifying anything yet; I think I'd rather play around with the dev board first (I don't feel confident enough that I can "un-brick" my AWG if I do something un-good to it just yet). And yes, the boot params are stored in the u-boot partition, but I haven't tried to modify them yet. I might give that a shot tonight.

I also wanted to investigate the upgrade mechanism that Hantek use; I think that will be the best way to hook into the HDG2002 and do backups, restores, and upgrade with custom firmware.  Assuming that they actually implemented a firmware upgrade.   

[idpromnut]

i've spoke with Hantek, they released the GPL sources now for the HDG's

http://www.hantek.com/download/HDG.zip

There are as well all sources of the custom drivers and some control/test apps,
not only for HDG AWGs but as well other S3C2416-SoC based Hantek gears.

Wow, Hantek, if you're listening, thank you very much for the support!

EDIT: Double wow… I need to try and rebuild it, but from a quick check over the sources, this will help a lot when trying to figure out the custom hardware that Hantek has put into the HDG2002 (for the keyboard, etc). I will check and see, but if we can build a bootable image from this, perhaps we can start from this and focus on just the UI and FPGA parts of the firmware. I will check and see what license Hantek released the sources to their custom test and drivers in this package.

[tinhead]

I will check and see what license Hantek released the sources to their custom test and drivers in this package.

as long you use it with Hantek hardware it's anyway free to use , but seriously, it's under GPL v2.
As you said, these sources are really cool, not only for HDGs but as well all the handhelds/DSOs.,
not only for keyboard but as well things like DMM in handheld. I was hoped to get such sources from
Hantek / Tekway for a long time.

[alex.forencich]

Here is an interesting feature idea, courtesy of thewyliestcoyote: streaming data from a PC.  Now, this won't work for the full sample rate, but I think it would be possible to do this at 1 or 2 MSa/sec and then use it as, say, a modulation signal.  It would even be possible to stream I/Q data for digital modulation.  The carrier would be generated with high rate DDS modules inside the FPGA, then the streaming data could be used to modulate the high rate carrier (AM, FM, PM, FSK, PSK, BPSK, QPSK, QAM, etc.).  Space permitting, it might be possible to build an arbitrary I/Q modulator inside that would take in digital data and generate I/Q samples for modulation.  Arbitrary digital modulation at 30-40 Mbit/sec from data streamed from a PC could be very interesting. 

[idpromnut]

Here is an interesting feature idea, courtesy of thewyliestcoyote: streaming data from a PC.  Now, this won't work for the full sample rate, but I think it would be possible to do this at 1 or 2 MSa/sec and then use it as, say, a modulation signal.  It would even be possible to stream I/Q data for digital modulation.  The carrier would be generated with high rate DDS modules inside the FPGA, then the streaming data could be used to modulate the high rate carrier (AM, FM, PM, FSK, PSK, BPSK, QPSK, QAM, etc.).  Space permitting, it might be possible to build an arbitrary I/Q modulator inside that would take in digital data and generate I/Q samples for modulation.  Arbitrary digital modulation at 30-40 Mbit/sec from data streamed from a PC could be very interesting.

I like it!  Again, I think we need to aggregate all the features (accepted and/or proposed), perhaps in one of the first two posts in this thread. If everyone is ok with this, I'll go ahead and sift through this thread and gather all the proposed features together + add the obvious ones in the existing firmware.

[Cyber7]

There are as well all sources of the custom drivers and some control/test apps,
not only for HDG AWGs but as well other S3C2416-SoC based Hantek gears.

AWESOME! Its like an early Christmas present. Eagerly awaiting the 500MB download.

Space permitting, it might be possible to build an arbitrary I/Q modulator inside that would take in digital data and generate I/Q samples for modulation.

Nice idea. Regarding logic space: we can strip out unneeded logic add the specific function/mode, reload the FPGA with from the SOC with the different bit logic for the specialized sub function, and switch back bit sets when done.

To add to the feature set: a closed-loop automated way to calibrate the front end by VISA/VXI control of a scope and the AWG. I don't think we want to spend two hours taking and entering sample sets!
 

[alex.forencich]

Space permitting, it might be possible to build an arbitrary I/Q modulator inside that would take in digital data and generate I/Q samples for modulation.

Nice idea. Regarding logic space: we can simply strip out unneeded logic add the specific function/mode, reload the FPGA with from the SOC with the different bit logic for the specialized sub function, and switch back bit sets when done.

Well, we shall see.  The main thing I am worried about is the availability of DSP48 slices.  Most of these will be taken up by the polyphase filter for the fractional up/down converter.  Everything else will have to fight over what's left over after that.  I presume this will not take up very much space, but we shall see.  One other issue is that running complex logic at 250 MHz is likely to require a lot of pipelining, which will consume a lot of registers.  It may end up being necessary to swap bitfiles for certain configurations. 

To add to the feature set: a closed-loop automated way to calibrate the front end by VISA/VXI control of a scope and the AWG. I don't think we want to spend two hours taking and entering sample sets!

Well, that's a no-brainer.  I was hoping to be able to do some sort of self cal with the onboard ADC, but I don't know if the signal routing is set up for that.  I did some investigating, but didn't turn up anything useful. 

If we run Python IVI on the AWG, then it could connect to a scope via USB or Ethernet and control it remotely to automate the measurement procedure.  Not sure if that would be worth the trouble; a standalone calibration script would work just as well and would be easier to maintain. 

[idpromnut]

RE: the onboard ADC... there is a driver for that in the sourceball that Hantek made available.. I wonder if the ADCs are accessed directly from the SoC and not through the FPGA?

[alex.forencich]

RE: the onboard ADC... there is a driver for that in the sourceball that Hantek made available.. I wonder if the ADCs are accessed directly from the SoC and not through the FPGA?

There is no direct connection between the ADC and the SoC, so it can only be accessed through the FPGA. 

[idpromnut]

RE: the onboard ADC... there is a driver for that in the sourceball that Hantek made available.. I wonder if the ADCs are accessed directly from the SoC and not through the FPGA?

There is no direct connection between the ADC and the SoC, so it can only be accessed through the FPGA.

What about the SoC onboard ADCs? Are they connected out to the two channel outputs?

[alex.forencich]

RE: the onboard ADC... there is a driver for that in the sourceball that Hantek made available.. I wonder if the ADCs are accessed directly from the SoC and not through the FPGA?

There is no direct connection between the ADC and the SoC, so it can only be accessed through the FPGA.

What about the SoC onboard ADCs? Are they connected out to the two channel outputs?

Nope.  The board has footprints for digital isolators, and the only signals that cross those are power and SPI to configure and control the FPGA.  Nothing else. 

[Cyber7]

I think the onboard ADC's were possibly used for the optional LCD touchscreen. From s3c2416_adc.c :

Code: [Select]

		if (temp >= 4)
		{
			printk(" %d is already reserved for TouchScreen\n", _adc.adc_port);
		}
		else

[alex.forencich]

I have been looking at the FPGA-related drivers in the source archive, and I can't make any sense of them.  It looks like all of the cfg drivers use SPI, while the others are using the external memory controller?  Are these holdovers from the Hantek DSOs?  Or am I missing something here?

[alex.forencich]

RE: the onboard ADC... there is a driver for that in the sourceball that Hantek made available.. I wonder if the ADCs are accessed directly from the SoC and not through the FPGA?

Actually, there are multiple ADCs.  There is one inside the SoC and then there is a second discrete ADC on the other side of the isolation for the modulation input.  The ADC on the SoC seems to be designed for use with touch screens; see ch. 22 of the datasheet.

[Cyber7]

Looks to me like they are using the hi-speed serial port like the prior DSO sources and mapping the device to a SOC SDRAM buffer to facilitate DMA.

EDIT: That does look DSO related however. The pertinent code is in: /drivers/htg_drivers/fpga_cfg/

[Cyber7]

For a moment there I thought the keypad was on the FPGA..but that is DSO related. They keypad is indeed on the SOC i2C:

Code: [Select]

static int AFG3050_read(struct i2c_client *client, char *buf ,int count)
{
	return i2c_master_recv(client,buf ,count);
}

static int AFG3050_write(struct i2c_client *client, char *buf ,int count)
{
	return i2c_master_send(client,buf ,count);
}

And the ID tag for the uC is a TI MSP430:

Code: [Select]

static const struct i2c_device_id AFG3050_id[] = {
	{ "msp430", 0 },
	{ }
};

[alex.forencich]

Looks to me like they are using the hi-speed serial port like the prior DSO sources and mapping the device to a SOC SDRAM buffer to facilitate DMA.

No, I seriously doubt this.  The SMC seems to be a pretty standard external memory controller.  The idea is you can hang multiple memory devices on the system address/data bus and then the SMC will select and communicate with one of them at a time based on the memory mapping.  The only reason to use the SMC is if the FPGA itself is sitting on the memory bus and emulating an SRAM interface of some sort.  Which in this case it isn't; the only connection to the SoC is via SPI.  In the DSOs, they may be using the parallel memory bus connection to the FPGA for faster data transfer - simply performing a memcpy will go out over the bus to the FPGA.  I do not believe this is possible with SPI.

Also, in the htg_drivers folder, there is only the fpga_cfg driver that access the FPGA over SPI.  No drivers in that folder access the SMC.  Is it possible that the AWG app opens the SPI interface directly? 

[Cyber7]

The utility to load the firmware is here: /drivers/htg_drivers/fpga_cfg/cfg_fpga.c

It simply writes the bit file to the driver exposed at dev/fpga_cfg

[alex.forencich]

The utility to load the firmware is here: /drivers/htg_drivers/fpga_cfg/cfg_fpga.c

It simply writes the bit file to the driver exposed at dev/fpga_cfg

It actually doesn't even write the bit file, it writes the bit file NAME to /dev/fpga_cfg, which then passes it to request_firmware.  request_firmware then goes and reads in the file (not sure exactly how this works, will have to read up on it).  Then the file content is copied into kernel space, the FPGA is reset, and then the file is dumped over SPI to the FPGA.  Interesting that they can just dump the file verbatim, I thought they would have to at least strip off the header.  I suppose the configuration logic on the FPGA will just ignore the header, though. 

[Cyber7]

Well, after some tweaks, adding zlib and a patch or two + moving a number of hardcoded cross compiler settings to the top level config.mak, I can do a 'make all' successfully. Since we are missing certain libs, execs and base configs from the src, I merged the resultant rootfs with the differences (missing libs, configs, execs) in the official 1.00.2 firmware. I copied this to an ext3 partition on a sdcard, recompiled kernel with ext3 support and booted it via uboot with these options: bootargs=noinitrd console=ttySAC0 init=/linuxrc rootfstype=ext3 root=/dev/mmcblk0p1 rw rootwait

Moments later the system booted completely with the familiar click of the relays after the fpga firmware loads. Boot log attached. I need to attach the LCD/keypad to verify its operation.

@idpromnut: I can post a diff of my mods if you would like. There's certainly room for improvement, and I'm not certain some .config embedded settings are addressed properly to reflect the crosscompiler. I need to check up on this. I used the Sourcery CodeBench Lite 2014.05-29 compiler.

With a working toolchain, now I can focus on some SPI tests.

[idpromnut]

Well, after some tweaks, adding zlib and a patch or two + moving a number of hardcoded cross compiler settings to the top level config.mak, I can do a 'make all' successfully. Since we are missing certain libs, execs and base configs from the src, I merged the resultant rootfs with the differences (missing libs, configs, execs) in the official 1.00.2 firmware. I copied this to an ext3 partition on a sdcard, recompiled kernel with ext3 support and booted it via uboot with these options: bootargs=noinitrd console=ttySAC0 init=/linuxrc rootfstype=ext3 root=/dev/mmcblk0p1 rw rootwait

Moments later the system booted completely with the familiar click of the relays after the fpga firmware loads. Boot log attached. I need to attach the LCD/keypad to verify its operation.

@idpromnut: I can post a diff of my mods if you would like. There's certainly room for improvement, and I'm not certain some .config embedded settings are addressed properly to reflect the crosscompiler. I need to check up on this. I used the Sourcery CodeBench Lite 2014.05-29 compiler.

With a working toolchain, now I can focus on some SPI tests.

Very nice! Why don't you put your patch/diff into the GIT repo, and throw a pull request to Alex. I'll grab the changes from there.

So if I understand, you can compile the whole kernel+OS environment from Hantek's tarball, and you add in the original FW binaries and you have a fully working FW image that runs off SD?

[idpromnut]

Also, I was going to try getting the gcc-arm tool chain working, so we at least have a working path now, which is good!

[Cyber7]

...you can compile the whole kernel+OS environment from Hantek's tarball, and you add in the original FW binaries and you have a fully working FW image that runs off SD?

Yes. However, I am setting the bootparams each time with uboot, and loading the kernel via its USB test facility. The kernel has been modified to include EXT3 support. The bootparams inform the kernel to initialize from the 1st EXT3 partition on the sdcard.

Unfortunately, we cannot boot from sdcard, since the SOC is configured to copy the 1st 8K from NAND and start the 1st level bootloader. This bootstrap eventually initializes SOC SDRAM, loads u-boot and starts it up. The existing Uboot does not persist boot params, hence the tedious uboot process. My TQ2416 devkit won't arrive until next week, so, I guess I'm at the point of risking replacing the existing uboot, and placing the kernel on another EXT3 sdcard partition.

I finished some cleanup on the cross-compiler build flags, so you should only need to change 2 parameters prior to a build, not counting any changes to the kernel. I'll post my diff package to Alex's private repo for the project momentarily.

[Cyber7]

@idpromnut:

If you haven't already, PM your public key to Alex for access to the private repo. It only supports git via SSH. The src patch is now on the repo under /src/patches . Be sure to also pick up /src/tarballs/fs_base.tar.gz as it contains the missing configs/binaries for the rev 1.00.2 fw release. The makefile will integrate them into the resulting rootfs. See the README.

Still to do: fix the NAND image part of the build process.

I also consolidated some docs & related devkit schematics into the repo.

PS: If you havent seen 'Interstellar', go see it in 70mm IMAX, it is well worth the $12!

[idpromnut]

@Cyber7:

Awesome, I'll fire off my key tp Alex asap. My dev board should be arriving today.

[idpromnut]

Got my dev board; seems to contain a lot of stuff, too bad all of the documentation is in Chinese  :/   Although that was expected. There does seem to be a utility for building SDcard images however...

PS: Alex, can you update my ssh key with the updated one I PM'd you a little while ago?  Thanks!

[fremen67]

Got my dev board; seems to contain a lot of stuff, too bad all of the documentation is in Chinese  :/   Although that was expected. There does seem to be a utility for building SDcard images however...

I bought an EM2416 in May (http://www.armdesigner.com/EM2416.html) which is very similar to the TQ2416. The toolchain provided with the board is Cross-4.2.2-eabi. I made some u-boot building tests with the DSO5000P sources provided by Hantek. The sources had an already compile u-boot_nand.bin file included in the archive. I tested it on my dev board and everything seemed OK with this precompiled file. When I compiled the sources and transfered the new u-boot_nand.bin to my dev board, the lan was not working anymore. I spent some time with wireshark to find out that some data where corrupted in the ethernet frames (ping) and had to slow down the communication between the SOC and the DM9000 so that it worked. I just though that maybe some parameters where missing in the sources.

Now that Hantek released a new set of files including the HDG, I did the test again... with the same results 
I am not able to compile a u-boot with working lan.
I think now that the problem could be my toolchain. As Hantek used the TQ2416 as a base, I would find it logical to use the same Tools/versions they are using. They seem to use a toolchain based on GCC 4.3.3 (EABI-4.3.3_EmbedSky_20100610.tar.bz2 ??) but had not luck finding it on internet.

Could you check what is included on your TQ2416 support DVD?

[Cyber7]

They seem to use a toolchain based on GCC 4.3.3 (EABI-4.3.3_EmbedSky_20100610.tar.bz2 ??) but had not luck finding it on internet.

Here it is, albeit a slow connection: http://pan.baidu.com/wap/shareview?&shareid=4065305958&uk=707448433&dir=%2F&page=1&num=20&fsid=221503121476276&third=0

I haven't tried the GCC toolset, or u-boot LAN support yet on the AWG. 

@idpromnut: Did the support DVD include schematics?

[idpromnut]

@idpromnut: Did the support DVD include schematics?

Yes, however there are a few revisions of what seem to be the same set of schematics. I suspect I will need to check my actual board to see if there is a version number or something that match what the schematics are labelled.

@fremen67: I can shoot you the GCC (that is what they are using) package, as well as the u-boot source that came with my dev CD. I have not tried to compile them yet, as all the documentation on how to unpack and set up the environment is all in Chinese. I was going to give that a shot tonight.

[fremen67]

Here it is, albeit a slow connection: http://pan.baidu.com/wap/shareview?&shareid=4065305958&uk=707448433&dir=%2F&page=1&num=20&fsid=221503121476276&third=0

What a shame  4th result on Google but I was unable to read with internet explorer... no problem with Firefox. Thank's a lot!
And ... it works ! I tried with DSO5000P u-boot sources and with the new HDG u-boot sources. Both are working with a working lan on my dev board.
Now serious things are beginning. There are some bugs to correct (you can download u-boot via tftp but it won't write it, even on the HDG with the original firmware, ...). I will see tomorrow.

[fremen67]

@fremen67: I can shoot you the GCC (that is what they are using) package, as well as the u-boot source that came with my dev CD. I have not tried to compile them yet, as all the documentation on how to unpack and set up the environment is all in Chinese. I was going to give that a shot tonight.

Well... is the dev CD a big one?  . But yes, thank you, at least the dev Tools (with Qtopia).
The toolchain is easy to install (in fact no install at all). You just have to uncompress  in / and add the /opt/EmbedSky/4.3.3/bin path in your .bashrc (for ubuntu)

if you just want to compile u-boot, go to the "u-boot-2009.11_TQ2416" directory of the HDG sources and

make distclean
make TQ2416_config
make all

u-boot will be "u-boot_nand.bin"

[idpromnut]

@fremen67: I can shoot you the GCC (that is what they are using) package, as well as the u-boot source that came with my dev CD. I have not tried to compile them yet, as all the documentation on how to unpack and set up the environment is all in Chinese. I was going to give that a shot tonight.

Well... is the dev CD a big one?  . But yes, thank you, at least the dev Tools (with Qtopia).
The toolchain is easy to install (in fact no install at all). You just have to uncompress  in / and add the /opt/EmbedSky/4.3.3/bin path in your .bashrc (for ubuntu)

if you just want to compile u-boot, go to the "u-boot-2009.11_TQ2416" directory of the HDG sources and

make distclean
make TQ2416_config
make all

u-boot will be "u-boot_nand.bin"

Thanks!  I am wondering if I should bother getting this all working... you all have this solved!   I should probably start getting the actual UI etc started.

[Cyber7]

@fremen67: Have you tried uboot to mount the kernel & rootfs via NFS from your PC? I think this would be the best dev scenario.

The nfs client support on the default kernel works; I've mounted my Ubuntu Eclipse Cross Arm C/C++ workspace from the awg via:

Code: [Select]

mount -t nfs -o nolock,vers=2 {host pc ip}:/root/workspace/ /mnt/nfs

A quick test after setting the compiler flags:

Code: [Select]

[root@Hantek /mnt/nfs/hello/Debug]#./hello
Hello ARM World!

[fremen67]

@fremen67: Have you tried uboot to mount the kernel & rootfs via NFS from your PC? I think this would be the best dev scenario.

The nfs client support on the default kernel works; I've mounted my Ubuntu Eclipse Cross Arm C/C++ workspace from the awg via:

Code: [Select]

mount -t nfs -o nolock,vers=2 {host pc ip}:/root/workspace/ /mnt/nfs

A quick test after setting the compiler flags:

Code: [Select]

[root@Hantek /mnt/nfs/hello/Debug]#./hello
Hello ARM World!

No I did not. I just used NFS on my MSO5062D, which is based on the same SoC and linux version, but only after it was running. I mounted the NFS share to overwrite my USB drive  so that when I push the "Save to USB" button, the image is stored directly on the NFS server. But you will only have NFS support after having loaded the kernel, not before... I did not see NFS support in uboot. When uboot is loaded, you have access to usb, nand, tftp server and SD... and even if there was NFS support in Uboot, I think you would loose it as soon as the kernel would start loading, when the ethernet uboot driver is replaced with the linux one. So I doubt it is possible to mount the kernel using NFS via  uboot. But maybe I am wrong.
Mounting rootfs via NFS after the kernel has been loaded maybe?

As for tftp, it is now working on the HDG. It was a bug related to the new MTD layout where the name "bios" had been replaced with "uboot". I modified cmd_menu.c in /common so that it works now in any case.
tftp is very convenient for updating nand partition and should be enough for testing. Don't you think?
There are also hidden menus which allow updating from SD. I will investigate that point too. Plus I think it should be possible to boot from the SD if we don't want to burn the nand to often.

Code: [Select]

#####    Boot for SKY2416/TQ2416 Main Menu      #####
#####     EmbedSky TFTP download mode     #####

[1] Download u-boot.bin to Nand Flash
[2] Download LOGO (logo.bin) to Nand Flash
[3] Erase the MISC partion
[4] Download Kernel (kernel.bin) to Nand Flash
[5] Download UBIFS image (rootfs.ubi) to Nand Flash
[6] Download Kernel_bk (kernel_bk.bin) to Nand Flash
[7] Download UBIFS image (recover.ubi) to Nand Flash
[8] normal start!
[9] recover start!
[0] Set the boot parameters
[f] Format the Nand Flash
[a] Download User Program
[c] Download Config(config.ubi).
[n] Set TFTP parameters(PC IP,SKY2416/TQ2416 IP,Mask IP...)
[p] Test network (TQ2416 Ping PC's IP)
[r] Reboot u-boot
[s] Download STEPLDR.nb1 to Nand Flash
[t] Test Linux Image (zImage)
[q] Return main Menu
Enter your selection: 1
test_dm9000 i/o: 0x20000300, id: 0x90000a46
DM9000: running in 16 bit mode
MAC: 10:23:45:67:89:ab
operating at 100M half duplex mode
Using dm9000 device
TFTP from server 192.168.1.100; our IP address is 192.168.1.101
Filename 'u-boot.bin'.
Load address: 0xc0000000
Loading: #########################
done
Bytes transferred = 362388 (58794 hex)

NAND erase: device 0 offset 0x0, size 0x100000
Erasing at 0xe0000 -- 100% complete.
OK

NAND write: device 0 offset 0x0, size 0x58800
Writing data at 0x58800 -- 100% complete.
 362496 bytes written: OK

#####    Boot for SKY2416/TQ2416 Main Menu      #####
#####     EmbedSky TFTP download mode     #####

[1] Download u-boot.bin to Nand Flash
[2] Download LOGO (logo.bin) to Nand Flash
[3] Erase the MISC partion
[4] Download Kernel (kernel.bin) to Nand Flash
[5] Download UBIFS image (rootfs.ubi) to Nand Flash
[6] Download Kernel_bk (kernel_bk.bin) to Nand Flash
[7] Download UBIFS image (recover.ubi) to Nand Flash
[8] normal start!
[9] recover start!
[0] Set the boot parameters
[f] Format the Nand Flash
[a] Download User Program
[c] Download Config(config.ubi).
[n] Set TFTP parameters(PC IP,SKY2416/TQ2416 IP,Mask IP...)
[p] Test network (TQ2416 Ping PC's IP)
[r] Reboot u-boot
[s] Download STEPLDR.nb1 to Nand Flash
[t] Test Linux Image (zImage)
[q] Return main Menu
Enter your selection:

[Cyber7]

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

[alex.forencich]

Damn; I am having a bear of a time getting timing closure with some basic SPI-MCB interface code on the FPGA.  4 ns is very little to work with on a speed grade 2 Spartan 6.  With around 0.5 to 1 ns per net and 0.3 ns per LUT passthrough, it's not really feasible to go through more than two or three LUTs in each clock cycle at 250 MHz.  It certainly does not help that the MCB outputs have a rather large clock-to-output delay, so much so that it's basically unusable unless it's registered manually. 

I'm getting stuff like this, even after doing a lot of reorganizing and adding/removing/adjusting register locations:

Code: [Select]

Slack:                  -0.295ns (requirement - (data path - clock path skew + uncertainty))
  Source:               spi_slave_inst/input_axis_tready_reg (FF)
  Destination:          soc_interface_inst/port0_cmd_en_reg (FF)
  Requirement:          4.000ns
  Data Path Delay:      4.109ns (Levels of Logic = 3)
  Clock Path Skew:      -0.043ns (0.498 - 0.541)
  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: spi_slave_inst/input_axis_tready_reg to soc_interface_inst/port0_cmd_en_reg
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    SLICE_X20Y30.DQ      Tcko                  0.476   spi_slave_inst/input_axis_tready_reg
                                                       spi_slave_inst/input_axis_tready_reg
    SLICE_X21Y30.A2      net (fanout=4)        1.064   spi_slave_inst/input_axis_tready_reg
    SLICE_X21Y30.A       Tilo                  0.259   soc_interface_inst/output_axis_tvalid_reg
                                                       soc_interface_inst/data_valid_reg_rd_empty_AND_65_o1
    SLICE_X18Y36.B5      net (fanout=5)        0.929   soc_interface_inst/data_valid_reg_rd_empty_AND_65_o
    SLICE_X18Y36.B       Tilo                  0.254   soc_interface_inst/port1_cmd_en_reg
                                                       soc_interface_inst/Mmux_port0_cmd_en_next12
    SLICE_X17Y37.C6      net (fanout=2)        0.754   soc_interface_inst/Mmux_port0_cmd_en_next12
    SLICE_X17Y37.CLK     Tas                   0.373   soc_interface_inst/port0_cmd_en_reg
                                                       soc_interface_inst/Mmux_port0_cmd_en_next21
                                                       soc_interface_inst/port0_cmd_en_reg
    -------------------------------------------------  ---------------------------
    Total                                      4.109ns (1.362ns logic, 2.747ns route)
                                                       (33.1% logic, 66.9% route)

That's a fail of 295 ps  while going through only 2 LUTs!

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

[kazam]

I see. Well, it looks like a viable option once the open firmware gets underway but that seems to be a bit longer then. Rusty case? Hm.

Good luck with the effort! I will follow your progress.

[markone]

Rusty case? Hm.

Yep, internal shielding chassis edges are rusty, because they cut the metal after the galvanization treatment.

[alex.forencich]

Alright, since I have not posted anything here in a while, here are some updates.

I have been doing quite a bit of work on the FPGA architecture to create a very powerful synthesizer platform.  Just yesterday I tested a very simple DDS that played back a 1024 point sinewave from an FPGA block RAM at 250 MSa/sec with the phase accumulator set up for a 1 MHz output frequency.  I only checked the direct DAC output as I do not have control over the front-end relays yet, so the output had quite a bit of 250 MHz noise on it from the DAC.  Otherwise, the frequency and shape were accurate.  This noise should be filtered out in the front end signal chain. 

The plan I have right now is to instantiate 6 DDS engines inside the FPGA.  Two will be basic DDS engines that can read from DRAM but do not support modulation.  Two will be the same, but will support full rate (250 MSa/sec) AM and FM.  The last two will be quadrature sine/cos DDS units with compressed tables (18 bit truncated phase = 256k entries, too big for block RAM without compression).  The quadrature sine/cos DDS units will support full rate FM and I/Q AM.  Then there will be some sort of routing network (crosspoint or collection of MUXes) to interconnect everything. 

The DDS units will operate in 3 modes.  One is with an internal memory addressed by the phase accumulator.  This will support fixed-length waveforms (1024, 2048, 4096, or 8192 points, block RAM resources permitting) and the frequency will be determined by the phase accumulator rollover rate and can be used to upsample or downsample the waveform.  The second two modes will output one sample per phase accumulator rollover, so the rollover rate determines the sample rate, not the repetition frequency.  This can be used to upsample only to play back at a lower rate (no point skipping).  The difference between these two modes is that one will use the internal buffer, and the other will stream from the DRAM, thus bypassing DRAM for short waveforms. 

This architecture will allow for quite a bit of fun stuff.  For example, you can trivially AM and FM modulate a sinewave or an arbitrary waveform with an arbitrary waveform.  You can have one channel modulate the other channel, or add the two together.  Or you can have two completely independent QAM modulators running with completely arbitrary inputs.  I'm also going to look at getting a high bandwidth random number generator installed (Mersenne twister, if I can get it to run fast enough) and a uniform-to-normal converter so it is possible to output very wideband noise, or add noise to the output or to a modulating signal. 

[tridentsx]

I don't know if you seen that the source code for the HDG2002b is available at hanteks webpage. There is a link not that obvious saying that it runs linux "click here for more info". When doing that it downloads the source in a zip file.

The source is Including the backlight and keyboard drivers fpga loader etc. Right now my HDG2002b is bricked will try and make a custom
image if and when I resurrect it.

[alex.forencich]

Yeah, that was posted here previously.  I downloaded it a while back.  Aside from the keypad drivers, there isn't really much interesting in there.  The AWG app itself is not in there. 

The reverse-engineering is more or less complete at this point, and the goal is to build an open source firmware for the unit with a much better synthesizer and more features, not to mention more stable. 

[alex.forencich]

I just finished implementing the configuration path into the switched 250 MHz clock domain.  To do this, I wrote Wishbone wrappers for the MCBs and I converted the SoC interface module to interface with wishbone instead of to the MCBs directly.  Next, I added a wishbone mux and async register to cross into the switched clock domain.  I have a RAM as a stand-in for the control registers right now, and this is reliably accessible over SPI.  The next step is to connect this to the DDS units so they can be controlled over the SPI interface. 

[alex.forencich]

Quadrature DDS with compressed lookup table is now working in Python.  Each instance should consume 2 block RAMs and 2 DSP slices and will provide highly accurate quadrature sine and cosine outputs.  Two more DSP slices will allow for independent full rate amplitude modulation of the quadrature outputs.  Phase resolution is 18 bits, output resolution is 16 bits.  The 'equivalent' lookup table requires 256K entries, which will not fit on the FPGA.  Instead, three lookup tables are used, two are 512x16 stored in one 512x32 block RAM and the other is 256x8.  That's 18kb instead of 4Mb, a savings of 227x.  The two wide tables store coarse sine and cosine while the last table stores fine sine and then they are combined with sin(A+B) = sin(A) + cos(A)*sin(B) and cos(A+B) = cos(A) - sin(A)*sin(B) where A and B come from dividing the input phase into 3 segments, 1 + 9 + 8 bits.  The highest MSB at the input determines the sign of the output while the rest of the bits index the lookup tables.  When testing with an output frequency of 62.500625 MHz (1.00001 * Fs/4), the output SFDR is around 97.6 dBc.  Which is about 20dB better than the DAC can do at around 70 to 80 dBc.  The equivalent brute force lookup table has an output SFDR of around 104.7 dBc at the same test frequency. 

[tridentsx]

Thanks for all the hard work thats been done seems that a lot of progress was made. I hope this does continue.
Wish I had the skillset to contribute.

[smgvbest]

Thanks for all the hard work thats been done seems that a lot of progress was made. I hope this does continue.
Wish I had the skillset to contribute.

Same here.  Wish I did.  if there is something a beginner could help with I'd be happy to give it a try FWIW

[alex.forencich]

Mainly we need people to work on the software running on the SoC.  The FPGA code is coming together little by little, and that will end up being a very powerful arbitrary waveform generator platform.  However, there needs to be a nice way to control it, both from the front panel and from the USB and Ethernet interfaces.  We need to write some sort of program or collection of programs to do this.  I'm not quite sure how to go about doing that myself, unfortunately, as I don't have much experience with embedded linux. 

[lukier]

I had a conference paper deadline recently, so I couldn't do much work on HDG2002B. I also have my HT4032L firmware project on a backburner. In the coming weeks I'm planning to get EM2416 devboard and start building embedded Linux with Qt-embedded libraries for the UI.

I thought it would be good to use ZeroMQ/NanoMSG as the internal interface between components, this way we could split the core app (service) responsible for AWG control and FPGA communications from the UI app and Ethernet/USBTMC interfacing apps.

The nice thing about these libraries is that they are very performant, portable and flexible and have bindings to many languages (including Python, so it may be possible to reuse Alex's Python code for VXI/USBTMC to do the  communications stuff instead of reimplementing it in C++). Also, for initial development & testing, it would be helpful because we could develop the UI on the PC first and it would communicate to the core app running on the HDG.

I also thought that the core app should have switchable backend interface to the FPGA, so for early testing, instead of Samsung SoC, I would solder FTDI dongle (SPI mode + some GPIO I believe) to the to-be-optoisolated lines that control the FPGA and therefore could develop and test the core app on the PC as well. Doing everything on embedded SoC from the very beginning is a pain in the ....

BTW few weeks ago I was playing with HDG a bit, I dumped the entire flash with OpenOCD and so on. I was also testing the network interface and while it seems to work fine with my old 10/100Mbit Linksys router switch in my lab it didn't work with D-Link 1Gb switch. In dmesg it said connection established, leds blinking, and then after a second it would disconnect and everything repeats. I wonder if maybe JTAG pins are shared somehow and interfere or is it some Hantek kernel peculiarity  or DM9000 chip issue. Did anyone experienced similar problems?

BTW2 I didn't check that, maybe someone remembers. Does Hantek's U-boot supports NFS? This is extremely handy when building/testing embedded Linux root filesystem and kernel.

[alex.forencich]

Wellll....we're probably going to have to write the VXI-11/USBTMC stuff from scratch because the Python versions only implement the client side, not the server side.  The VXI-11 side probably won't be all that bad as it's just a TCP server, but the USBTMC stuff will involve figuring out how to interface with the USB stack on the SoC to set up a USB device correctly, which may be a bit involved.  And that will almost certainly have to be developed on the SoC. 

[idpromnut]

BTW few weeks ago I was playing with HDG a bit, I dumped the entire flash with OpenOCD and so on. I was also testing the network interface and while it seems to work fine with my old 10/100Mbit Linksys router switch in my lab it didn't work with D-Link 1Gb switch. In dmesg it said connection established, leds blinking, and then after a second it would disconnect and everything repeats. I wonder if maybe JTAG pins are shared somehow and interfere or is it some Hantek kernel peculiarity  or DM9000 chip issue. Did anyone experienced similar problems?

I have my HDG plugged into a 1Gb switch (Procurve) and it is working well. I Have not tested the NFS boot but yes, it supposedly supports it. I have a SC2416 development board (it looks a LOT like Hantek used the one I have to do their development for the HDG & oscilloscopes) but I have not yet got a working bootloader on it yet. I am rather new to the embedded side of things, being primarily a server software developer (plus some client-side application stuff). My intent was to help with the UI side for this project, but I have been rather busy as of late.

[smgvbest]

Mainly we need people to work on the software running on the SoC.  The FPGA code is coming together little by little, and that will end up being a very powerful arbitrary waveform generator platform.  However, there needs to be a nice way to control it, both from the front panel and from the USB and Ethernet interfaces.  We need to write some sort of program or collection of programs to do this.  I'm not quite sure how to go about doing that myself, unfortunately, as I don't have much experience with embedded linux. 

Since you mentioned it I found this SCPI Library
http://www.the-control-freak.com/SCPI/SCPI.htm
I haven't fully looked at it yet but should be able to port to Linux which I could try working on if there would be interest in that

[alex.forencich]

Mainly we need people to work on the software running on the SoC.  The FPGA code is coming together little by little, and that will end up being a very powerful arbitrary waveform generator platform.  However, there needs to be a nice way to control it, both from the front panel and from the USB and Ethernet interfaces.  We need to write some sort of program or collection of programs to do this.  I'm not quite sure how to go about doing that myself, unfortunately, as I don't have much experience with embedded linux. 

Since you mentioned it I found this SCPI Library
http://www.the-control-freak.com/SCPI/SCPI.htm
I haven't fully looked at it yet but should be able to port to Linux which I could try working on if there would be interest in that

Here is another SCPI parser worth looking at: https://github.com/j123b567/scpi-parser .

The SCPI parser is a part of the system.  The tricky part will be building the VXI-11 and USBTMC interfaces that will allow external applications to send SCPI commands to the parser.  Actually, the really tricky part will probably be defining and implementing all of the commands. 

[smgvbest]

Here is another SCPI parser worth looking at: https://github.com/j123b567/scpi-parser .

The SCPI parser is a part of the system.  The tricky part will be building the VXI-11 and USBTMC interfaces that will allow external applications to send SCPI commands to the parser.  Actually, the really tricky part will probably be defining and implementing all of the commands.

I guess one question is do we want to start implementing the command currently used in the HDG2000's or start from scratch
I would say IMHO start by implementing the what we already have command wise then add more if we want.

If that's the case the deciding on a parser (I do like the one you found as it has built in callbacks and written for Linux already)
We could define all the callback to implement the current commands which would get us started

[alex.forencich]

Here is another SCPI parser worth looking at: https://github.com/j123b567/scpi-parser .

The SCPI parser is a part of the system.  The tricky part will be building the VXI-11 and USBTMC interfaces that will allow external applications to send SCPI commands to the parser.  Actually, the really tricky part will probably be defining and implementing all of the commands.

I guess one question is do we want to start implementing the command currently used in the HDG2000's or start from scratch
I would say IMHO start by implementing the what we already have command wise then add more if we want.

If that's the case the deciding on a parser (I do like the one you found as it has built in callbacks and written for Linux already)
We could define all the callback to implement the current commands which would get us started

I say duplicate the Agilent commands for their TrueForm generators.  The command set for the HDG2000 sucks. 

[smgvbest]

Here is another SCPI parser worth looking at: https://github.com/j123b567/scpi-parser .

The SCPI parser is a part of the system.  The tricky part will be building the VXI-11 and USBTMC interfaces that will allow external applications to send SCPI commands to the parser.  Actually, the really tricky part will probably be defining and implementing all of the commands.

I like that. A decision.  you're obviously not in managment

I guess one question is do we want to start implementing the command currently used in the HDG2000's or start from scratch
I would say IMHO start by implementing the what we already have command wise then add more if we want.

If that's the case the deciding on a parser (I do like the one you found as it has built in callbacks and written for Linux already)
We could define all the callback to implement the current commands which would get us started

I say duplicate the Agilent commands for their TrueForm generators.  The command set for the HDG2000 sucks.

[alex.forencich]

Here is another SCPI parser worth looking at: https://github.com/j123b567/scpi-parser .

The SCPI parser is a part of the system.  The tricky part will be building the VXI-11 and USBTMC interfaces that will allow external applications to send SCPI commands to the parser.  Actually, the really tricky part will probably be defining and implementing all of the commands.

I like that. A decision.  you're obviously not in managment

I guess one question is do we want to start implementing the command currently used in the HDG2000's or start from scratch
I would say IMHO start by implementing the what we already have command wise then add more if we want.

If that's the case the deciding on a parser (I do like the one you found as it has built in callbacks and written for Linux already)
We could define all the callback to implement the current commands which would get us started

I say duplicate the Agilent commands for their TrueForm generators.  The command set for the HDG2000 sucks.

Your reply was misplaced.  Anyway, since we're rebuilding the core of the generator (the FPGA) I don't think we're really limited to what the original FPGA design could (or couldn't) do.  For instance, originally the FPGA DDS completely sucked (I recall seeing some posts about really bad phase noise) and the arb could only generate output samples with an extremely limited selection of sample rates.  I believe this was due to a crappy architecture.  This will not be an issue with the new architecture, so we might as well start with a command set that does not have these limitations. 

[lukier]

I say duplicate the Agilent commands for their TrueForm generators.  The command set for the HDG2000 sucks.

I too was thinking about starting with HDG functionality replicated, but you're right, Agilent command set is probably more useful. The UI, however, probably will have to follow Hantek in some shape or form because of the front panel layout.

USBTMC could be done with linux kernel USB gadget subsystem API in user space (with libusbg - https://github.com/libusbg/libusbg). Kernel has some gadget drivers built-in (ether, cdc acm, mass storage, even midi) but I don't recall TM class. Fortunately, USBTMC is probably the simplest of all the USB classes.

I think we should decide on SCPI commands because these will largely reflect the main interface API calls.

With the API defined we could implement the interface for clients (e.g. wrapped Apache Thrift over NanoMSG) and then more or less all modules (in bold) can be developed separately:
- API Interface server part -> Core App -> FPGA (over SoC, over FTDI)
- USBTMC (libusbg)/VXI11 (socket) -> SCPI parser -> API Interface client part
- Qt-embedded UI -> API Interface client part

[smgvbest]

Keysight has stuff including a legacy UBMTMC driver along with LXI samples FWIW
http://www.keysight.com/main/editorial.jspx?cc=US&lc=eng&ckey=1189290&nid=-34952.0.00&id=1189290&cmpid=20586

Wish they'd stop changing names

[alex.forencich]

Keysight has stuff including a legacy UBMTMC driver along with LXI samples FWIW
http://www.keysight.com/main/editorial.jspx?cc=US&lc=eng&ckey=1189290&nid=-34952.0.00&id=1189290&cmpid=20586

I think that's also a host side driver, so I'm not  sure how much use that would be.  I believe that driver might now be included in the linux kernel. 

Wish they'd stop changing names

Sigh.......

[smgvbest]

I think that's also a host side driver, so I'm not  sure how much use that would be.  I believe that driver might now be included in the linux kernel. 

Looking at the code it is a device driver

Hopefully the kernel used will be a fixed version and this is a moot point

[alex.forencich]

I think that's also a host side driver, so I'm not  sure how much use that would be.  I believe that driver might now be included in the linux kernel. 

Looking at the code it is a device driver

Hopefully the kernel used will be a fixed version and this is a moot point

Device driver as in a kernel driver for controlling a device that implements USBTMC, not a driver for the 'device' end of the link.  "This kernel module allows you to control your USB instruments through a character device driver."  Hence it is not very useful for what we are trying to accomplish, as we need what this driver connects to at the other end of the USB cable. 

[tridentsx]

I used my google fu and the only projetcs I came accross that has implemented the device side of USB-TMC are

http://labs.ti.bfh.ch/gecko/wiki/systems/gecko3com/start

and

https://github.com/karlp/discotmc

Both of them in a firmware without an OS, don't know if that's usefull or not, maybe need to do this from scratch.

[alex.forencich]

Well, any existing design might be useful, if only for reference. 

[tridentsx]

I have been looking for a reasonable priced PCI USB perephial card online and today I found one on ebay
http://www.ebay.com/itm/LOT-OF-2-PLX-2280BC-F-USB-DUET-PCI-ADAPTERS-/271691946991?pt=LH_DefaultDomain_0&hash=item3f421a1bef

If I have time I will try to get libusbg https://github.com/libusbg/libusbg and scpi-parser https://github.com/j123b567/scpi-parser to work together to implement the perephial side of USBTMC

[alex.forencich]

I have been looking for a reasonable priced PCI USB perephial card online and today I found one on ebay
http://www.ebay.com/itm/LOT-OF-2-PLX-2280BC-F-USB-DUET-PCI-ADAPTERS-/271691946991?pt=LH_DefaultDomain_0&hash=item3f421a1bef

If I have time I will try to get libusbg https://github.com/libusbg/libusbg and scpi-parser https://github.com/j123b567/scpi-parser to work together to implement the perephial side of USBTMC

Looks like that could be a good route.  I did not realize that they made PCI cards for the USB device side.  I suppose I shouldn't be too surprised; I think the high end Agilent scopes use something similar to provide their USBTMC interfaces as well. 

I'm getting optimistic about this project again.  I am under a deadline for a 10G Ethernet project right now, but once that's out of the way I should be able to do some more work on the FPGA for this thing. 

[tridentsx]

I received the cards today, and I found out that my Linux box doesn't have a PCI slot.
Going to a surplus computer place tomorrow to see if I can find some cheap old computer.

Is there any specifications that shows what commands a Function generator should support ?
Would be fun to somehow test the implementation with a tool that believes its talking to a real
instrument.

[alex.forencich]

I received the cards today, and I found out that my Linux box doesn't have a PCI slot.
Going to a surplus computer place tomorrow to see if I can find some cheap old computer.

Well, that's a minor set back. 

Is there any specifications that shows what commands a Function generator should support ?
Would be fun to somehow test the implementation with a tool that believes its talking to a real
instrument.

I would suggest looking at the programming manual for the Agilent trueform generators.  That's more or less what I think we should be shooting for in terms of capabilities. 

[smgvbest]

Very Nice update

[tridentsx]

It seems TMC is not supported as a gadget in Linux Kernel!
First step is to investigate what it would take to create a driver for TMC and for 488

http://lxr.free-electrons.com/source/drivers/usb/gadget/function/

I don't have much experience from Linux kernel development.

[alex.forencich]

Yeah, I figured it wouldn't be supported out of the box.  Probably the hard part would be figuring out what the user-facing API needs to be.  It looks like there is some good reference code in there, might as well start with the serial interface and see if you can get that operational as an exercise. 

[lukier]

I was playing with my HDG2002B a bit in the last week.

It seems we might be stuck with Hantek old crappy u-boot and kernel for now. S3C2416 is an old platform that is not actively maintained by the OS community.

From what I've seen in current mainline u-boot s3c24xx is supported in general, but booting doesn't seem to work. s3c24xx has a special boot process where it loads and executes first 4kB from flash for the early stage bootloader and this bootloader has to load the rest. In u-boot case this is called "SPL", but this part doesn't cover s3c24xx.

Embedsky wrote these routines (loading rest of the u-boot from flash) by hand in their old u-boot (2009, the one Hantek uses).

With linux kernel situation is similar, but slightly better.

Nowadays the way to configure linux kernel for a particular board is to use Device Trees. Before each board designer added a bunch of source and header files for each and every possible arm board and Linus got mad merging this mess.

So now there are little scripts called Flattened Device Trees that are compiled into binary form and kernel parses them on boot and loads and configures peripherals appropriately.
Again, s3c24xx is poorly maintained and while many s3c peripheral drivers migrated to new device tree configuration (interrupt controller, pin controller, pwm, uarts, spi, i2c, hs-mmc, dm9000) there are few crucial things that need the old approach (framebuffer, nand, dma engine).

Other than that linux-4.x seems to boot fine over tftp/NFS on the HDG2002B. For now I'm trying to limit the number of kernel warnings/errors and get all peripherals properly detected (figuring out GPIO pins and EINT lines). Later I'll test them in practice one by one.

Current boot log:
http://pastebin.com/Tf3cKspW

[alex.forencich]

It looks like there might be a way to do a user-space USB gadget driver.  This is probably what hantek did.  Might be more portable between kernel versions, since it seems like we may be stuck with the current kernel that's on there rather than the latest version.  See http://www.linux-usb.org/gadget/ near the bottom of the page.

It's great to see some activity on the software side of things!

[tridentsx]

Yes I have been looking at that possibility too, however I really wanted a composite device where I can run serial console on same USB connection. I didn't get my Ethernet to work thats why I am focused on USB. It didn't seem possible to create a composite device using GadgetFS but I found a presentation that shows how a composite device can be created with GadgetFS and FunctionFS


http://events.linuxfoundation.org/sites/events/files/slides/USB%20Gadget%20Configfs%20API_0.pdf

[fremen67]

In the coming weeks I'm planning to get EM2416 devboard and start building embedded Linux with Qt-embedded libraries for the UI.

I got one of them. It is more like a TQ2440 rather than a TQ2416 from a hardware point of view : DM9000EP instead of DM9000A, other interrupt numbers... you will have to modify the Hantek uboot and kernel so that it works on it (mainly for the DM9000EP which has INT7 instead of INT4 and needs nWait to be activated). I have a working modified hantek uboot/kernel for the EM2416 I can give you.

BTW2 I didn't check that, maybe someone remembers. Does Hantek's U-boot supports NFS? This is extremely handy when building/testing embedded Linux root filesystem and kernel.

The Hantek u-boot version (2009) is supposed to support NFS but it does not work. There is a problem in the time out handling. Not a big deal as you can always load the kernel via tftp.

Edit: I also modifed the hantek uboot version so that:
- tftp works
- you can update u-boot or kernel via SD
- you can exit the default Hantek menu and type user command at the prompt.

Maybe I could post the sources on Alex server.

[fremen67]

With the API defined we could implement the interface for clients (e.g. wrapped Apache Thrift over NanoMSG) and then more or less all modules (in bold) can be developed separately:
- API Interface server part -> Core App -> FPGA (over SoC, over FTDI)
- USBTMC (libusbg)/VXI11 (socket) -> SCPI parser -> API Interface client part
- Qt-embedded UI -> API Interface client part

That makes sense.
What about DBus for inter process communication? Seems to be well supported in Qt...

[fremen67]

I was playing with my HDG2002B a bit in the last week.

It seems we might be stuck with Hantek old crappy u-boot and kernel for now. S3C2416 is an old platform that is not actively maintained by the OS community.

From what I've seen in current mainline u-boot s3c24xx is supported in general, but booting doesn't seem to work. s3c24xx has a special boot process where it loads and executes first 4kB from flash for the early stage bootloader and this bootloader has to load the rest. In u-boot case this is called "SPL", but this part doesn't cover s3c24xx.

Embedsky wrote these routines (loading rest of the u-boot from flash) by hand in their old u-boot (2009, the one Hantek uses).

With linux kernel situation is similar, but slightly better.

Nowadays the way to configure linux kernel for a particular board is to use Device Trees. Before each board designer added a bunch of source and header files for each and every possible arm board and Linus got mad merging this mess.

So now there are little scripts called Flattened Device Trees that are compiled into binary form and kernel parses them on boot and loads and configures peripherals appropriately.
Again, s3c24xx is poorly maintained and while many s3c peripheral drivers migrated to new device tree configuration (interrupt controller, pin controller, pwm, uarts, spi, i2c, hs-mmc, dm9000) there are few crucial things that need the old approach (framebuffer, nand, dma engine).

Other than that linux-4.x seems to boot fine over tftp/NFS on the HDG2002B. For now I'm trying to limit the number of kernel warnings/errors and get all peripherals properly detected (figuring out GPIO pins and EINT lines). Later I'll test them in practice one by one.

Current boot log:
http://pastebin.com/Tf3cKspW

As the HDG (and other DSO/MSO from Hantek) are based on the TQ2416, I think this would be easier to stick with the TQ2416 Tools, at least for u-boot and the kernel, and stick to linux 3.2.35, unless there are good reasons to change it.
You will find on the TQ2416 DVD:
- the 4.3.3 toolchain (compiles Hantek uboot and kernel without any problem)
- Qt 4.5 + QT Creator 1.3.0
I set up a Fedora 10 VMware image with those tools and was able to compile and run some QT examples on the HDG and on my EM2416 (with touch screen support)

If we want to use the latest Qt version for the S3c2416, the 4.8.6 seems to one to choose. But then we would need to change the toolchain as the 4.3.3 can't compile it.
FriendlyARM has a s3c2416 dev board (Tiny2416) which is provided with the 4.4.3 toolchain and Qt 4.8.5.
I tried with Qt 4.8.6 compiled with the 4.4.3 toolchain and this also works on the HDG.

[fremen67]

It looks like there might be a way to do a user-space USB gadget driver.  This is probably what hantek did.

Yes I think they did. Some time ago when digging in the Hantek GPL kernel sources, I saw something on the USB TMC server part. I will have another look but I think there is a module for that written by Hantek in those sources.

[smgvbest]

It looks like there might be a way to do a user-space USB gadget driver.  This is probably what hantek did.

Yes I think they did. Some time ago when digging in the Hantek GPL kernel sources, I saw something on the USB TMC server part. I will have another look but I think there is a module for that written by Hantek in those sources.

If it is in there maybe they gave it a open source license and we can use it?   if not maybe we can learn from it and write a new one.  assume the source is there.

[fremen67]

If it is in there maybe they gave it a open source license and we can use it?   if not maybe we can learn from it and write a new one.  assume the source is there.

Attached the f-tmc.c file I saw in the GPL sources: AFG_hdg2000b\src\linux-3.2.35\drivers\usb\gadget\f-tmc.c

Plus the USB declaration in mach-hantek2416.c where you find the PID/VID of the USB TMC port, those you can see in Agilent connection expert:

Code: [Select]

...
#ifdef CONFIG_HK_USBD_ANDROID 
//android gadget
#include <linux/usb/android_composite.h>
static char *usb_functions_ums[] = {
	"mass_storage",
};
static char *usb_functions_serial[] = {
	"serial",
};
static char *usb_functions_tmc[] = {
	"tmc",
};

#define PRODUCT_ID (0x505b)
static struct android_usb_product usb_products[] = 
{
	{
		.product_id	= PRODUCT_ID,
		.num_functions	= ARRAY_SIZE(usb_functions_tmc),
		.functions	= usb_functions_tmc,
	},
	{
		.product_id	= PRODUCT_ID,
		.num_functions	= ARRAY_SIZE(usb_functions_serial),
		.functions	= usb_functions_serial,
	},
	{
		.product_id	= 0x0ff9,
		.num_functions	= ARRAY_SIZE(usb_functions_ums),
		.functions	= usb_functions_ums,
	},
};

static char *usb_functions_all[] = 
{
	"tmc",
	"serial",
	"mass_storage",
};

static struct android_usb_platform_data android_usb_pdata = 
{
	.vendor_id	= 0x049f,
	.product_id	= PRODUCT_ID,
	.version	= 0x0100,
	.product_name		= "hdg",
	.manufacturer_name	= "hantek",
	.serial_number = "HTG10000522222",
	.num_products = ARRAY_SIZE(usb_products),
	.products = usb_products,
	.num_functions = ARRAY_SIZE(usb_functions_all),
	.functions = usb_functions_all,
	.update_pid_and_serial_num = NULL,
	//.usb_id_pin_gpio = ELITE_GPIO_USB_ID1,
	.fserial_init_string = "tty:serial",
	.nluns		= 3,
};
static struct platform_device android_usb_device = {
	.name	= "android_usb",
	.id	= -1,
	.dev	= {
		.platform_data = &android_usb_pdata,
	},
};
#endif
...

[lukier]

That makes sense.
What about DBus for inter process communication? Seems to be well supported in Qt...

I never used d-bus, need to check how it works. Not sure about the performance. On the other hand it has RPC mechanism already done (instead of using something like Thrift on top of ZeroMQ transport layer).

As the HDG (and other DSO/MSO from Hantek) are based on the TQ2416, I think this would be easier to stick with the TQ2416 Tools, at least for u-boot and the kernel, and stick to linux 3.2.35, unless there are good reasons to change it.
You will find on the TQ2416 DVD:
- the 4.3.3 toolchain (compiles Hantek uboot and kernel without any problem)
- Qt 4.5 + QT Creator 1.3.0
I set up a Fedora 10 VMware image with those tools and was able to compile and run some QT examples on the HDG and on my EM2416 (with touch screen support)

If we want to use the latest Qt version for the S3c2416, the 4.8.6 seems to one to choose. But then we would need to change the toolchain as the 4.3.3 can't compile it.
FriendlyARM has a s3c2416 dev board (Tiny2416) which is provided with the 4.4.3 toolchain and Qt 4.8.5.
I tried with Qt 4.8.6 compiled with the 4.4.3 toolchain and this also works on the HDG.

I don't know, for me this would be last resort to use Hantek's archaic custom versions. These things are years away from the stuff I have currently installed on my development machine. Sticking with old versions would make it more difficult to develop and maintain open source firmware in the long run.

Anyhow, I would probably settle on Hantek's flash partition scheme and u-boot (not a big issue, it cannot boot with device tree I believe but device trees can be appended to kernel binary - for old bootloaders).

Currently I use just HDG, didn't buy EM2416 in the end and I can compile Hantek's u-boot and kernel. Could you share your modified u-boot?

Also, are HDG2002B flash dumps available somewhere? I might have messed up my flash contents. I have some dd if=/dev/ubi* backups as well as backup of the entire flash via OpenOCD (took hours) but I wonder if someone uploaded flash image somewhere so I could have second source.

[tridentsx]

Which minimum version of u-boot is required to support device tree ? I found some patches from end of 2012 that implements s3c2416 in U-Boot.

http://patchwork.ozlabs.org/patch/185880/

[lukier]

Which minimum version of u-boot is required to support device tree ? I found some patches from end of 2012 that implements s3c2416 in U-Boot.

http://patchwork.ozlabs.org/patch/185880/

Looks very interesting, NAND boot done in a proper modernish u-boot way (SPL). It may be even possible to apply this patch to the current mainline. I might have a go at it over the weekend.

[tridentsx]

I had a quick look at the u-boot patches and looked at u-boot versions all the way back to late 2010 and the patches doesn't match the source trees. There are many dependent includes files used by the patches that I can't find in any of the u-boot source releases.  Its almost like the original designer worked against another set of patches containing the architecture stuff and the bootstrap code for s3c24xx. I sent an email with some questions to the original author to see if he could shed some light.



Ok I got my answer I had the wrong patch,
The below patch is the complete final version with all the files

http://patchwork.ozlabs.org/patch/185884/

[fremen67]

I don't know, for me this would be last resort to use Hantek's archaic custom versions. These things are years away from the stuff I have currently installed on my development machine. Sticking with old versions would make it more difficult to develop and maintain open source firmware in the long run.

Anyhow, I would probably settle on Hantek's flash partition scheme and u-boot (not a big issue, it cannot boot with device tree I believe but device trees can be appended to kernel binary - for old bootloaders).

You are right but even if u-boot is quite old, as long as it has enough functionalities for restoring nand and booting test kernels, this should be OK.
Regarding the kernel, the GPL one provided by Hantek has already all the drivers included for the HDG and is just ready to go. We could of course change it later on when needed but as is, it will allow us to start developping the front end and the other modules which is IMHO what we should focus on.

I setup a Fedora 20 Vmware image with QT Creator 3.2.2, Qt 4.8.6 and a 4.4.3 arm toolchain. Everything seems to work fine up to now. I hope I will have some time this week to start something regarding a possible UI. I will also investigate with Qt Quick.

Currently I use just HDG, didn't buy EM2416 in the end and I can compile Hantek's u-boot and kernel. Could you share your modified u-boot?

Also, are HDG2002B flash dumps available somewhere? I might have messed up my flash contents. I have some dd if=/dev/ubi* backups as well as backup of the entire flash via OpenOCD (took hours) but I wonder if someone uploaded flash image somewhere so I could have second source.

You will find the files needed to rebuild a 1.00.3 firmware in my OneDrive in the "04-Firmware 1.00.3 Nand Recover" directory. The u-boot there is the modified one.

[fremen67]

@Alex:
I have a PCB 1002 version, I think you worked on a PCB 1004 version for your FPGA development and now Hantek is shipping at least PCB 1004.1
All those versions have specific firmwares which are not compatible together and I suppose that your development will only work on PCB 1004.
What is the best method to update the data you posted on the FPGA links to other components for PCB 1002 and PCB 1004.1?
I tried with TopJTAG and was able to find some differences (connections to the front end relays f.e.) but most of the connections are hard to trace (at least for me  ). As you already did this, could you explain you methodology?
I think this will help also others having 1004.1 to take part to this.
Do you think it could be a problem to maintain different hardware configurations? I suppose that Hantek had good reason to change their design.

[alex.forencich]

Depends on what the changes are.  The SDRAM should not be different as those pins cannot be reassigned.  If things like shift register bits are different, then that can be handled in software on the SoC - I'm just going to pass that through directly, the FPGA configuration will not depend on certain bits being in certain places.  It's not going to be smart enough to configure itself, the software on the SoC will take care of that.  Any changes in things like output amplifier gain steps will be handled in software on the SoC, not on the FPGA.  Pretty much everything else off of the FPGA could be modified in some way, though I'm not sure if they did or not.  I can think up some good solutions for this once we figure out exactly what's different about the boards - it's possible all you need is a different UCF file for the FPGA. 

For probing the FPGA pins, I used the ftjrev utility that's in my github repo.  I think I did have to pop off a couple of ferrite beads to check a couple of connections from the ADC, but other than that you should be able to probe everything.  Everything except the SDRAM, anyway. 

[fremen67]

@Alex: find attached the UCF file for the PCB 1002 FPGA, plus  ftjrev.c modified for my OpenJtag cable (www.100ask.net) in case someone need it (updated with PID/VID and nTRST used for iprobe). I also attached an excel sheet with the différences I saw between PCB1002 & 1004.

The sync DAC doesn't exist on my board so I removed it from the UCF file.
I also added in comment some test points linked to the FPGA.
As I don't know the FPGA side, I am afraid that's all I can do on that part 

Do you think you could create a firmware file like the existing htg1000.bin that we could download to the FPGA using the same way? That would be the easiest solution for testings and later on for firmware updates.

[alex.forencich]

That's interesting.  If the sync DAC isn't there, then how is the sync output being driven?  Also, on my board, the DAC drives an inverter chip, so we could probably just simplify that down to driving just the R2R ladder MSB for the sync output. 

[fremen67]

Well, precisely the R308 to 315 resistors described in the UCF file for the sync DAC are not on my board. Maybe I made a shortcut when I said there is none on my board...

[alex.forencich]

Well, something has to drive the sync output BNC.  Did you figure out what pin that is?

[fremen67]

Well, something has to drive the sync output BNC.  Did you figure out what pin that is?

Yes, just got it with TopJTAG probe: C15.
Edit : It is not a direct connection (output 0->5V) so I could not see it with ftjrev.

[tridentsx]

I have a newbie question!
What tool would I use to flash the hantek with a custom compiled u-boot ? I managed to compile a custom s3c2416 based 15.04 u-boot from the patches I linked before. I have an olimex usb jtag its ftdi based.

I need to start testing on real h/w. As soon as I have something working I will post the patches, maybe we should have a git repository for all of the combined code?

[tridentsx]

Is the TQ2416 and hdg2002b configured the same way when it comes to the boot options on OM0 ... OM4 & GPC5 ... GPC7?
Has anyone traced out what those are set to on the hdg2002b ?
I am just trying to understand the boot sequence on the hdg2002 and if its the same as the TQ2416, and I guess I am lazy to open up my hdg2002b one more time.

[tridentsx]

I managed to get the patches to compile with support for Serial, Nand and DM9000 MAC on u-boot v15.04.

Now I unsure what the next steps are to test the image, there is the small spl image and then the u-boot image, how do I create a combined image to flash on my tq2416 board ? Is it just a matter of concatenate the images with padding to make sure that there is 8k from start of spl to start of u-boot ? Would I use openocd and the config provided in this thread to flash my image ? Sorry I am new to this and not as smart ad you guys I am however quite stubborn.

[lukier]

I managed to get the patches to compile with support for Serial, Nand and DM9000 MAC on u-boot v15.04.

Now I unsure what the next steps are to test the image, there is the small spl image and then the u-boot image, how do I create a combined image to flash on my tq2416 board ? Is it just a matter of concatenate the images with padding to make sure that there is 8k from start of spl to start of u-boot ? Would I use openocd and the config provided in this thread to flash my image ? Sorry I am new to this and not as smart ad you guys I am however quite stubborn.

SPL has to be at the address that S3C (Steppingstone) fetches at boot, I don't remember off the top of my head, but I think you're right, it's first 8K. Then I suppose when you compile SPL it contains hardcoded address of its big brother (main u-boot) as it has to load and execute it. That's just a guess, I haven't tested that as I still use Hantek's u-boot.

[fremen67]

Would I use openocd and the config provided in this thread to flash my image ? Sorry I am new to this and not as smart ad you guys I am however quite stubborn.

If you have access to a windows PC with a parallel port, then I would recommend using H-JTAG with a wiggler JTAG cable like this one:
https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG/
You will find H-JTAG here: http://www.hjtag.com/en/product.asp?typeid=9
It is fast and it just works... as long as you have windows XP or Win7 32bits.
For the rest, I just used the original TQ2416 u-boot and Hantek u-boot (which is based on the TQ2416 one).

[tridentsx]

I finally got the cable to connect to the TQ2416, I also found that I already had a jtag adapter in an old box in my garage. The device I have is the following https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD/

But now I am banging my head, because when I use openocd I can write the u-boot to nand, I can verify the nand, but after I reset the board and I dump the nand that I had verified its all 0x00.

>nand probe 0                             
NAND flash device 'NAND 256MiB 3.3V 8-bit (unknown)' found
> nand write 0 "../u-boot-with-spl.bin" 0x00000000
wrote file ../u-boot-with-spl.bin to NAND flash 0 up to offset 0x00038000 in 148.598999s (1.498 KiB/s)
> nand verify 0 "../u-boot-with-spl.bin" 0x00000000
>reset run

Hence I decided to try urjtag but I get some error already when I do the detect

jtag> cable ARM-USB-OCD
Connected to libftdi driver.
jtag> detect
warning: TDO seems to be stuck at 1

I have attached my compiled u-boot had to rename it hex.

Are there any commercial tools both s/w and h/w that are better? Seems to me that openocd is a bit flakey, had to restart many times lower the speed of adapter to 500 kHz to reliably be able to halt the cpu.

[tridentsx]

After doing it all over for the 5th time I was able to write my u-boot spl to flash. Had to set the clock really slow to get the init_2416 procedure to work. I think that was the problem the whole time.

After I rebooted the board I didn't get any output on the serial port which I kind of expected since it was the first time and I still probably have loads of bugs to fix.

However when I dumped the ram (iram)  from 0x400000000 and 8192 bytes it was all 0x00. Even if I put garbage at nand 0x0 to 0x2000 I would expect that that garbage is loaded to SRAM 0x400000000 ? It seems to me either the ram get cleared when I connect the jtag or the irom boot loader isn't loading my BL1 code from nand.

Any pointers in how to troubleshoot ?

[fremen67]

Some updates about the UI development.

It's always a matter of finding time but things are moving on. I am working with Qt 4.8.7 Embedded. The HDG keyboard and leds handling are functionnal and I am now working on a simplified UI (reduced set of menus) to finalise main classes development.
It is working directly on the hdg with only few modifications (had only a problem with a shared Library that needed to be updated). That means that the application should be able to be installed simply via the standard update procedure of the HDG.
At the moment I launch it from the NFS drive I have attached to the HDG as it is more convenient for development.

There is still a lot of work to do on the hidden part of the iceberg but I hope I could post some kind of "preview" in the next weeks. This could run from a SD or USB stick without modifying the HDG.

The next step would be the interface with the FPGA and to be able to see a least something going out...
I will keep you updated.

@Alex
Any progress on the FPGA configuration via file transfer?
If I could have some information on the SPI protocol you foresee for the communication, I could start working on it from the UI side...

[timofonic]

Is this alive? Any interest in this project?

I'm more interested as it may become the future of a OSHW oscilloscope

https://github.com/MParygin/v.scope80
https://github.com/Razer6/welecw2000a
https://github.com/baldengineer/Mixed-Signal-Oscilloscope-Demo-Board
https://github.com/mdebski/oscilloscope
https://github.com/agural/FPGA-Oscilloscope
https://github.com/analogdevicesinc/iio-oscilloscope
https://github.com/gabonator/DS203

[fremen67]

Is this alive? Any interest in this project?

I'm more interested as it may become the future of a OSHW oscilloscope

https://github.com/MParygin/v.scope80
https://github.com/Razer6/welecw2000a
https://github.com/baldengineer/Mixed-Signal-Oscilloscope-Demo-Board
https://github.com/mdebski/oscilloscope
https://github.com/agural/FPGA-Oscilloscope
https://github.com/analogdevicesinc/iio-oscilloscope
https://github.com/gabonator/DS203

Yes still alive. I am back from holidays so I will keep on working on the GUI on my spare time. Standard waveforms, modulations, sweep and burst are almost over. I am now working on the utility menu. Next part will be the ARB part but I am not sure wether I will do it on the HDG or directly on the PC.

I have upgraded my HDG with a touch screen and the GUI can use it

No link at the moment between the GUI and the FPGA.

[tridentsx]

Do you have any details on how you did that upgrade to support touch screen?

[fremen67]

Do you have any details on how you did that upgrade to support touch screen?

Sorry I missed your post.
The touch screen modification is straight forward. You need:
- a 7" touchscreen (165mmx100mm, active area 154mmx86mm at least)
- a connector for the mainboard (solder on J800), 4 pos 1mm (649-SFW4S-2STE1LF @ mouser for example)
- a FCC cable extension

The touch screen I used has an active area which is 2 mm too short horizontally and 1 mm too short vertically.
I bought it here http://www.aliexpress.com/item/Free-shipping-7-inch-new-touch-screen-digitizer-for-AT070TN90-AT070TN92-AT070TN93-AT070TN94-quality-100-guarranty/585764980.html

The kernel already includes drivers for the touchscreen. You just have to add TsLib and modify /etc/profile and you are good to go.
Of course you will only be able to use it with a program that handles a mouse ...

[smgvbest]

Yes still alive. I am back from holidays so I will keep on working on the GUI on my spare time. Standard waveforms, modulations, sweep and burst are almost over. I am now working on the utility menu. Next part will be the ARB part but I am not sure wether I will do it on the HDG or directly on the PC.

I have upgraded my HDG with a touch screen and the GUI can use it

No link at the moment between the GUI and the FPGA.

I realize this might be a bit soon but would love to see images on your gui work if you felt like sharing???

[tridentsx]

Will this alternative s/w be open source ? Is there a repo where the source will be available ?

[timofonic]

Will this alternative s/w be open source ? Is there a repo where the source will be available ?

It would be great if the firmware goes FOSS and published in GitHub! Please consider it!.

Also, it can be an interesting software for a possible future lab grade OSHW oscilloscope. I hope OSHW goes to collaborative projects like in FOSS, making possible to have complex projects.

I would be more interested in a good managed and community reviewed OSHW oscilloscope than buying a chinese one with buggy software of hardware. If the design is open and interesting enough, I'm sure there will be manufacturers selling it over ebay and such. That would be a big slap to most low end oscilloscopes and become a disruptive change

[tridentsx]

Is this effort dead ? I hope not seemed like so much progress was made.

[tridentsx]

I found a page online with the SMDK software kit and exampoles for s3c2416 and s3c2450 which is almost identical to s3c2416.
Thought it could be helpful. Maybe this whole alternative Firmware is stale.

http://latlon.org/~jek/samsung/627451S3C2450_SMDK_Base_Codes.zip
http://latlon.org/~jek/samsung/smdk2416/

[Scratch.HTF]

I wish to revive this topic since I am in need for improved firmware; see my topic https://www.eevblog.com/forum/testgear/hantek-hdg2000-series-firmware-enhancements/ for more details.