HDG2002B AWG Firmware Reverse Engineering - Page 1
Forum section: electronics / testgear

author: idpromnut
author_rank: Unknown
timestamp: October 26, 2014, 02:43:47 am
content: 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#.VExcjOcSVUUSoftware/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 kernelKernel version: Linux anolis 3.2.35 #42 PREEMPT Wed Mar 26 12:49:52 CST 2014 armv5tejl GNU/Linux

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 26, 2014, 02:48:36 am
content: Let's get this party started!GitHub repo is located here:https://github.com/alexforencich/hdg2000Wiki is here:http://www.alexforencich.com/wiki/en/hdg2000/startReverse 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 EthernetJ3: MicroSD slotJ4: 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 hostJ904: USB deviceJP3: 1x6 0.1 inch header (U5 JTAG)K1: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relayK2: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relayK3: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relayK4: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relayK5: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relayK6: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relayU3: 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 muxU28: TI OPA140U30: Unknown, presumed TI ADS8329 ADCU32: Micron MT47H32M16HR-25E:G DRAM 32Mx16 DDR2 SDRAM (SoC)U33: Analog Devices AD9747BCPZ 2 channel 16 bit 250 Msps TxDACU38: Samsung K9F1G08U0D 128Mx8 Flash (SoC)U39: Davicom DM9000 100 Mbit ISA Ethernet controller (MAC and PHY)Y1: 48 MHz osc for SoCY2: osc for DM9000U3: 12 MHz osc for SoCX2: 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 relayX5: Fujitsu FTR-B3GB4.5Z-B10 DPDT 4.5v latching relayPinouts:JP3: JTAG for U5From marking end, +3V3, TCK, TDI, TDO, TMS, GNDIsolation/FPGA-SoC interconnection (U14/U13/P11)FPGA pin - SoC pinU14 markGND (R333)(all RA10)to FPGAN9, R13 DIN - unknownP12, R15 CCLK - unknownP8 - unknownGND - GNDU13 markGND (R334?)(all RA9?)to SoCM10 - unknownV17 DONE - unknownU3 INIT - unknownV2 PROGRAM_B_2 - unknown+3V3 (R???)+3V3 (R???)GND (R???)+1V8 (R???)GND (R???)+5V (R???)J801: SoC UARTFrom marking: N/C, RX, TX, GND, +3V3

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 26, 2014, 03:31:41 am
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 26, 2014, 04:34:36 am
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 26, 2014, 08:33:26 am
content: 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.

author: idpromnut
author_rank: Unknown
timestamp: October 26, 2014, 02:15:11 pm
content: @alex: didn't you already have the DAC part from the previous Hantek HDG thread?QuoteOr is this a different DAC we're talking about?

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 26, 2014, 05:21:14 pm
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 26, 2014, 09:03:56 pm
content: 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: October 26, 2014, 10:59:33 pm
content: 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/412253302Note 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=104It 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: October 26, 2014, 11:33:34 pm
content: 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] http://www.hantek.org/asken/iaskdetail.aspx?id=2013051008532693I'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.

author: Cyber7
author_rank: Regular Contributor
timestamp: October 27, 2014, 12:00:02 am
content: 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.

author: lukier
author_rank: Unknown
timestamp: October 27, 2014, 12:17:28 am
content: I like where HDG2002B is goingI'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.

author: idpromnut
author_rank: Unknown
timestamp: October 27, 2014, 12:23:12 am
content: Quote from: Cyber7 on October 26, 2014, 11:33:34 pmYup, 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

author: fremen67
author_rank: Frequent Contributor
timestamp: October 27, 2014, 12:25:15 am
content: 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=179Here is the dev board I have:http://www.armdesigner.com/EM2416.htmlI bought it here :http://shop.kristech.pl/p/84/465/em2416-.htmlQT 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

author: idpromnut
author_rank: Unknown
timestamp: October 27, 2014, 12:30:41 am
content: 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.

author: lukier
author_rank: Unknown
timestamp: October 27, 2014, 12:40:52 am
content: Quote from: idpromnut on October 27, 2014, 12:30:41 amAFAIR 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.

author: fremen67
author_rank: Frequent Contributor
timestamp: October 27, 2014, 12:43:46 am
content: Quote from: idpromnut on October 27, 2014, 12:30:41 amOn 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.

author: idpromnut
author_rank: Unknown
timestamp: October 27, 2014, 01:02:47 am
content: Quote from: fremen67 on October 27, 2014, 12:43:46 amThat'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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 27, 2014, 01:12:31 am
content: Quote from: idpromnut on October 27, 2014, 01:02:47 amAlso, 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).

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 27, 2014, 01:22:17 am
content: Quote from: idpromnut on October 27, 2014, 12:30:41 amThat would be trivial. It would also be possible to use both the LF and HF inputs at the same time.Quote from: idpromnut on October 27, 2014, 12:30:41 amSounds 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 27, 2014, 01:25:59 am
content: Quote from: lukier on October 27, 2014, 12:40:52 amThe 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.

author: lukier
author_rank: Unknown
timestamp: October 27, 2014, 01:28:47 am
content: Quote from: alex.forencich on October 27, 2014, 01:12:31 amIt 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 27, 2014, 01:33:46 am
content: Quote from: lukier on October 27, 2014, 01:28:47 amThat is exactly what I was getting at. The pin assignments along the isolation footprints are as follows:FPGA pin - SoC pinU14 markGND (R333)(all RA10)to FPGAN9, R13 DIN - unknownP12, R15 CCLK - unknownP8 - unknownGND - GNDU13 markGND (R334?)(all RA9?)to SoCM10 - unknownV17 DONE - unknownU3 INIT - unknownV2 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.

author: idpromnut
author_rank: Unknown
timestamp: October 27, 2014, 03:07:49 am
content: Quote from: lukier on October 27, 2014, 01:28:47 amYup, 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 27, 2014, 04:26:32 am
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 27, 2014, 05:07:57 am
content: Quote from: alex.forencich on October 27, 2014, 04:26:32 amScratch 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!

author: Cyber7
author_rank: Regular Contributor
timestamp: October 27, 2014, 08:17:21 am
content: 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.3VPin5 +3.3VPin6 GNDPin7 SDA to/from Keypad U26 Pin 50 P1.3 & U800 EEprom Pin 5Pin8 unknown @ Keypad U26 Pin 46 P1.7Pin9 SCL to/from Keypad U26 Pin 49 P1.4 & U800 EEprom Pin 6Pin10 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

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 27, 2014, 09:59:05 am
content: 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?

author: idpromnut
author_rank: Unknown
timestamp: October 27, 2014, 12:12:34 pm
content: @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.

author: Marco
author_rank: Super Contributor
timestamp: October 27, 2014, 04:54:15 pm
content: Quote from: alex.forencich on October 27, 2014, 09:59:05 amTo get sub-clock-cycle time resolution.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 27, 2014, 05:14:55 pm
content: Quote from: lukier on October 27, 2014, 12:17:28 amGate 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 27, 2014, 05:50:40 pm
content: Quote from: idpromnut on October 27, 2014, 12:12:34 pmRepo is here:https://github.com/alexforencich/hdg2000

author: lukier
author_rank: Unknown
timestamp: October 27, 2014, 09:47:15 pm
content: Quote from: alex.forencich on October 27, 2014, 05:14:55 pmI 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

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 27, 2014, 09:57:07 pm
content: Quote from: lukier on October 27, 2014, 09:47:15 pmThe 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.QuoteWhat 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.QuoteTake 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.

author: idpromnut
author_rank: Unknown
timestamp: October 27, 2014, 10:36:47 pm
content: 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).

author: Cyber7
author_rank: Regular Contributor
timestamp: October 28, 2014, 04:16:54 am
content: 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 tohttps://github.com/Cyber7/hdg2000, added my documentation and I2C session logs to:https://github.com/Cyber7/hdg2000/tree/master/doc/Front%20Panel/KeypadI 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

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 28, 2014, 04:34:09 am
content: Quote from: Cyber7 on October 28, 2014, 04:16:54 amWe 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 28, 2014, 04:45:27 am
content: 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/startPM 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: October 28, 2014, 06:24:38 am
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 28, 2014, 06:37:35 am
content: Quote from: Cyber7 on October 28, 2014, 06:24:38 amActually, 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!

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 28, 2014, 07:18:55 am
content: 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.

author: idpromnut
author_rank: Unknown
timestamp: October 28, 2014, 12:54:08 pm
content: @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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 28, 2014, 05:07:28 pm
content: 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.

author: idpromnut
author_rank: Unknown
timestamp: October 28, 2014, 11:47:42 pm
content: 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

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 29, 2014, 12:07:56 am
content: Quote from: idpromnut on October 28, 2014, 11:47:42 pmSweet. 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_Oszihttps://github.com/prpplague/das_oszi_kernel/tree/das_oszi_mini2440

author: idpromnut
author_rank: Unknown
timestamp: October 29, 2014, 12:44:58 am
content: 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).

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 29, 2014, 12:52:10 am
content: 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.

author: idpromnut
author_rank: Unknown
timestamp: October 29, 2014, 01:15:03 am
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 29, 2014, 08:57:46 pm
content: 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.....

author: lukier
author_rank: Unknown
timestamp: October 30, 2014, 02:21:55 am
content: 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?

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 30, 2014, 02:35:23 am
content: Quote from: lukier on October 30, 2014, 02:21:55 amNone of us have a dev board or CD yet, AFAIK.QuoteWe 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.QuoteI 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.

author: idpromnut
author_rank: Unknown
timestamp: October 30, 2014, 04:11:09 am
content: Quote from: lukier on October 30, 2014, 02:21:55 amI 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'vebeen 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 secGOT 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 sweetCode:Now, Downloading [ADDRESS:0xc0008000,TOTAL:0x20f098]Please waiting ................................Download Done!!Download Address: 0xc0008000, Download Filesize:0x20f098Now, Checksum calculation..Checksum O.K !!!Boot with zImageStarting 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=c04323bcs3c24xx_serial_probe(c04323bc, c041fec8) 0s3c24xx_serial_probe: initialising port c041f9c0...s3c24xx_serial_init_port: port=c041f9e4, platdev=c04323bcs3c24xx_serial_init_port: c041f9e4 (hw 0)...resource c040e5a4 (50000000..50003fff)port: map=50000000, mem=f7000000, irq=70 (70,71), clock=1s3c2440_serial_resetport: port=c041f9e4 (50000000), cfg=c0432308s3c24xx_serial_p robe: adding ports3c24xx_serial_console_setup: co=c041fd38 (0), (null)s3c24xx_serial_console_setup: port=c041f9e4 (0)s3c24xx_serial_get_options: port=c041f9e4registers: ulcon=00000003, ucon=000003c5, ubdriv=00000023calculated baud 115740s3c24xx_serial_console_setup: baud 115740selecting clock c0410004config: 8bits/charsetting ulcon to 00000003, brddiv to 35, udivslot 00000000uart: ulcon = 0x00000003, ucon = 0x000003c5, ufcon = 0x00000051Linux 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 2014CPU: ARM926EJ-S  revision 5 (ARMv5TEJ), cr=00053177CPU: VIVT data cache, VIVT instruction cacheMachine: SMDK2416Ignoring tag cmdline (using the default kernel command line)Memory policy: ECC disabled, Data cache writebackCPU S3C2416/S3C2450 (id 0x32450003)S3C24XX Clocks, Copyright 2004 Simtec ElectronicsCPU: MPLL on 800.000 MHz, cpu 400.000 MHz, mem 133.333 MHz, pclk 66.666 MHzCPU: EPLL on 96.000 MHz, usb-bus 48.000 MHzBuilt 1 zonelists in Zone order, mobility grouping on. Total pages: 16256Kernel command line: noinitrd ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs init=/ linuxrc console=ttySAC0 mem=64MPID 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 totalMemory: 60444k/60444k available, 5092k reserved, 0K highmemVirtual 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:99irq: clearing subpending status 00000003irq: clearing subpending status 00000002Console: colour dummy device 80x30Calibrating delay loop... 199.47 BogoMIPS (lpj=498688)pid_max: default: 32768 minimum: 301Mount-cache hash table entries: 512CPU: Testing write buffer coherency: okNET: Registered protocol family 16S3C2416: Initializing architectureS3C2416: IRQ Supportbio: create slab <bio-0> at 0SCSI subsystem initializedusbcore: registered new interface driver usbfsusbcore: registered new interface driver hubusbcore: registered new device driver usbs3c-i2c s3c2410-i2c: slave address 0x10s3c-i2c s3c2410-i2c: bus frequency set to 65 KHzs3c-i2c s3c2410-i2c: i2c-0: S3C I2C adapterAdvanced Linux Sound Architecture Driver Version 1.0.24.NET: Registered protocol family 2IP 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 registeredUDP hash table entries: 256 (order: 0, 4096 bytes)UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)NET: Registered protocol family 1RPC: 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 118io scheduler noop registeredio scheduler deadline registeredio scheduler cfq registered (default)Serial: 8250/16550 driver, 4 ports, IRQ sharing enableds3c2440-uart.0: ttySAC0 at MMIO 0x50000000 (irq = 70) is a S3C2440console  enableds3c2440_serial_probe: dev=c04122e4s3c24xx_serial_probe(c04122e4, c041fec8) 1s3c24xx_serial_probe: initialising port c041fa84...s3c24xx_serial_init_port: port=c041faa8, platdev=c04122e4s3c24xx_serial_init_port: c041faa8 (hw 1)...resource c040e5dc (50004000..50007fff)port: map=50004000, mem=f7004000, irq=73 (73,74), clock=1s3c2440_serial_resetport: port=c041faa8 (50004000), cfg=c0432328s3c24xx_serial_probe: adding ports3c2440-uart.1: ttySAC1 at MMIO 0x50004000 (irq = 73) is a S3C2440s3c2440_serial_probe: dev=c04123b4s3c24xx_serial_probe(c04123b4, c041fec8) 2s3c24xx_serial_probe: initialising port c041fb48...s3c24xx_serial_init_port: port=c041fb6c, platdev=c04123b4s3c24xx_serial_init_port: c041fb6c (hw 2)...resource c040e614 (50008000..5000bfff)port: map=50008000, mem=f7008000, irq=76 (76,77), clock=1s3c2440_serial_resetport: port=c041fb6c (50008000), cfg=c0432348s3c24xx_serial_probe: adding ports3c2440-uart.2: ttySAC2 at MMIO 0x50008000 (irq = 76) is a S3C2440s3c2440_serial_probe: dev=c0412484s3c24xx_serial_probe(c0412484, c041fec8) 3s3c24xx_serial_probe: initialising port c041fc0c...s3c24xx_serial_init_port: port=c041fc30, platdev=c0412484s3c24xx_serial_init_port: c041fc30 (hw 3)...resource c040e64c (5000c000..5000ffff)port: map=5000c000, mem=f700c000, irq=94 (94,95), clock=1s3c2440_serial_resetport: port=c041fc30 (5000c000), cfg=c0432368s3c24xx_serial_probe: adding ports3c2440-uart.3: ttySAC3 at MMIO 0x5000c000 (irq = 94) is a S3C2440lp: driver loaded but no devices foundppdev: user-space parallel port driverbrd: module loadedloop: module loadedUniform Multi-Platform E-IDE driveride-cd driver 5.00S3C24XX NAND Driver, (c) 2004 Simtec Electronicss3c24xx-nand s3c2412-nand: Tacls=3, 22ns Twrph0=8 60ns, Twrph1=3 22nss3c24xx-nand s3c2412-nand: System booted from NANDs3c24xx-nand s3c2412-nand: NAND soft ECCNAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bi t)Scanning device for bad blocksCreating 8 MTD partitions on "NAND":0x000000000000-0x000000004000 : "Boot Agent"mtd: partition "Boot Agent" doesn't end on an erase block -- force read-only0x000000000000-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 driverslcan: serial line CAN interface driverslcan: 10 dynamic interface channels.CAN device driver interfacedm9000 Ethernet Driver, V1.31ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Drivers3c2410-ohci s3c2410-ohci: S3C24XX OHCIs3c2410-ohci s3c2410-ohci: new USB bus registered, assigned bus number 1s3c2410-ohci s3c2410-ohci: irq 42, io mem 0x49000000hub 1-0:1.0: USB hub foundhub 1-0:1.0: 2 ports detectedusbcore: registered new interface driver libusualusbcore: registered new interface driver usbserialUSB Serial support registered for genericusbcore: registered new interface driver usbserial_genericusbserial: USB Serial Driver coreUSB Serial support registered for FTDI USB Serial Deviceusbcore: registered new interface driver ftdi_sioftdi_sio: v1.6.0:USB FTDI Serial Converters DriverUSB Serial support registered for pl2303usbcore: registered new interface driver pl2303pl2303: Prolific PL2303 USB to serial adaptor driverS3C24XX RTC, (c) 2004,2006 Simtec ElectronicsS3C2410 Watchdog Timer, (c) 2004 Simtec Electronicss3c2410-wdt s3c2410-wdt: watchdog inactive, reset disabled, irq disabledALSA device list:No soundcards found.TCP vegas registeredNET: Registered protocol family 17can: controller area network core (rev 20090105 abi 8)NET: Registered protocol family 29can: 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 okconfig: 8bits/charsetting ulcon to 00000003, brddiv to 35, udivslot 00000000uart: ulcon = 0x00000003, ucon = 0x000003c5, ufcon = 0x00000051VFS: 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:c043251cFunction entered at [<c034af44>] from [<c034b0a8>]Function entered at [<c034b03c>] from [<c03dac64>]r3:00000000 r2:c3819e78 r1:c3819f74 r0:c03742c0r7:c03fae24Function entered at [<c03daaf4>] from [<c03dafc8>]Function entered at [<c03daf34>] from [<c03da8dc>]r5:c0401650 r4:c0401650Function entered at [<c03da7e0>] from [<c002f8c0>]r5:c03da7e0 r4:00000000

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 30, 2014, 08:35:28 am
content: 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.

author: idpromnut
author_rank: Unknown
timestamp: October 30, 2014, 02:15:55 pm
content: @Cyber7: can you also post details on the LCD + controller if they are on the front panel?

author: andrija
author_rank: Regular Contributor
timestamp: October 30, 2014, 04:50:46 pm
content: 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)?

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 30, 2014, 04:56:00 pm
content: Quote from: andrija on October 30, 2014, 04:50:46 pmI'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.QuoteI 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).

author: idpromnut
author_rank: Unknown
timestamp: October 30, 2014, 05:12:25 pm
content: Quote from: andrija on October 30, 2014, 04:50:46 pmI 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: October 30, 2014, 06:02:29 pm
content: telnet is built into busybox, so all you have to do is remove the remark from /dso/etc/boot.shI 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 thatcan coexistwith the ethernet port. The protection may be POE related, to avoid -48v damage.

author: Cyber7
author_rank: Regular Contributor
timestamp: October 30, 2014, 06:11:05 pm
content: @idpromnut:QuoteThe 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 interfaceUtilizes I2C Protocol on mainboard J702 pins 7 (SDA) & 9 (SCL)SCL = 18.568 KhzPin 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.3VPin5 +3.3VPin6 GNDPin7 SDA to/from Keypad U26 Pin 50 P1.3 & U800 EEprom Pin 5Pin8@ Keypad U26 Pin 46 P1.7 (seems always low)Pin9 SCL to/from Keypad U26 Pin 49 P1.4 & U800 EEprom Pin 6Pin10 GND----- --------------------------------------------------Pin1 - uC Busy? Active High Asserted ~1.5 SCL (173us) Before Scan Code, remainshigh ~2ms and Deasserted ~1.5 SCL before end of Scan Code. Not assertedfor Release codes. Not asserted during LED code writes to display.Read - Key ScanCode = 0x55 + (Keycode Byte)Read - Key ReleaseCode = Keycode & $80Write - 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 sleepstate, 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 NOTreflect 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 whenpressed.5. Key codes 36d, 37d & 44d are note assigned to any keys.6. Near simultaneous keypresses will result in a rapid sequence of kepresses125ms apart.ScanCodes & bitmasks are attached.

author: andrija
author_rank: Regular Contributor
timestamp: October 30, 2014, 06:16:45 pm
content: 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.QuoteThat's what I was looking for, I will give it a go when I get home. Thanks everyone!

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 30, 2014, 06:37:45 pm
content: Quote from: Cyber7 on October 30, 2014, 06:11:05 pmWhen 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.QuoteI'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.

author: idpromnut
author_rank: Unknown
timestamp: October 30, 2014, 08:05:24 pm
content: @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.

author: fremen67
author_rank: Frequent Contributor
timestamp: October 30, 2014, 11:24:58 pm
content: Quote from: andrija on October 30, 2014, 04:50:46 pmTelnet 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.

author: fremen67
author_rank: Frequent Contributor
timestamp: October 30, 2014, 11:30:46 pm
content: Quote from: idpromnut on October 30, 2014, 08:05:24 pmYes 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)

author: Cyber7
author_rank: Regular Contributor
timestamp: October 30, 2014, 11:35:56 pm
content: QuoteI 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: haltedtarget halted in ARM state due to debug-request, current mode: Usercpsr: 0x60000010 pc: 0xffff0078MMU: enabled, D-Cache: enabled, I-Cache: enabledNOTE! 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_chainTapName Enabled IdCode Expected IrLen IrCap IrMask-- ------------------- -------- ---------- ---------- ----- ----- ------0 S3C2416.cpu Y 0x07926f0f 0x07926f0f 4 0x01 0x0f> targetsTargetName Type Endian TapName State-- ------------------ ---------- ------ ------------------ ------------0* S3C2416.cpu arm926ejs little S3C2416.cpu halted

author: idpromnut
author_rank: Unknown
timestamp: October 30, 2014, 11:37:08 pm
content: Quote from: fremen67 on October 30, 2014, 11:30:46 pmPretty sure that was me freaking out about that bug initially

author: idpromnut
author_rank: Unknown
timestamp: October 30, 2014, 11:39:06 pm
content: @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.

author: Cyber7
author_rank: Regular Contributor
timestamp: October 30, 2014, 11:47:06 pm
content: @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.start = IRQ_S3C2443_WDT;s3c_device_wdt.resource.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);}

author: fremen67
author_rank: Frequent Contributor
timestamp: October 30, 2014, 11:50:25 pm
content: Quote from: alex.forencich on October 29, 2014, 12:52:10 amAnyway 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).

author: idpromnut
author_rank: Unknown
timestamp: October 30, 2014, 11:52:30 pm
content: Quote from: Cyber7 on October 30, 2014, 11:47:06 pmHmm, it mentions the 2440, I wonder if that one has two ports versus the 2416 maybe only having 1?

author: fremen67
author_rank: Frequent Contributor
timestamp: October 31, 2014, 12:02:59 am
content: Quote from: Cyber7 on October 30, 2014, 11:35:56 pmDid you try the one posted by Tinhead?:https://www.eevblog.com/forum/testgear/review-of-owon-sds7102/msg315938/#msg315938

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 31, 2014, 12:30:59 am
content: Quote from: alex.forencich on October 30, 2014, 02:35:23 amAlright, 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 31, 2014, 05:03:06 am
content: 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.

author: tinhead
author_rank: Super Contributor
timestamp: October 31, 2014, 09:29:16 am
content: Quote from: fremen67 on October 31, 2014, 12:02:59 amactually 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: October 31, 2014, 09:34:34 am
content: Quote from: tinhead on October 31, 2014, 09:29:16 amSo is that the BSDL file or something strange about the JTAG interface on the chip?

author: tinhead
author_rank: Super Contributor
timestamp: October 31, 2014, 07:00:33 pm
content: Quote from: alex.forencich on October 31, 2014, 09:34:34 amwell, 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).

author: Cyber7
author_rank: Regular Contributor
timestamp: November 02, 2014, 03:40:06 am
content: @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_chainTapName Enabled IdCode Expected IrLen IrCap IrMask-- ------------------- -------- ---------- ---------- ----- ----- ------0 S3C2416.cpu Y 0x07926f0f 0x07926f0f 4 0x01 0x0ftargetsTargetName Type Endian TapName State-- ------------------ ---------- ------ ------------------ ------------0* S3C2416.cpu arm926ejs little S3C2416.cpu runninginithaltpoll offsleep 4000irscan S3C2416.cpu 14drscan S3C2416.cpu 32 007926F0F <---matches mcu IDcodeirscan S3C2416.cpu 3 <-- sample opcodedrscan S3C2416.cpu 685 0 <-- scan all 685 bits0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000halttarget state: haltedtarget halted in ARM state due to debug-request, current mode: Supervisorcpsr: 0xa0000013 pc: 0xc0267770MMU: enabled, D-Cache: enabled, I-Cache: enableddrscan S3C2416.cpu 685 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

author: tinhead
author_rank: Super Contributor
timestamp: November 02, 2014, 06:47:23 pm
content: Quote from: Cyber7 on November 02, 2014, 03:40:06 ami 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.Quote from: Cyber7 on November 02, 2014, 03:40:06 ami 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 scanQuote from: Cyber7 on November 02, 2014, 03:40:06 amtried 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).

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 02, 2014, 08:53:08 pm
content: 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 03, 2014, 06:35:11 am
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 03, 2014, 06:51:56 am
content: 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 03, 2014, 07:33:57 am
content: They're schems from an Opal Kelly dev boardhttp://www.opalkelly.com/products/xem6006/They do not show the bank 1 connections.QuoteThe 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 03, 2014, 08:28:49 am
content: Quote from: Cyber7 on November 03, 2014, 07:33:57 amThese 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.QuoteIt 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 03, 2014, 09:14:37 am
content: QuoteI 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.pdfHere's a nice guide:http://www.xilinx.com/support/documentation/boards_and_kits/xtp039.pdfQuoteI 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 03, 2014, 09:26:26 am
content: Quote from: Cyber7 on November 03, 2014, 09:14:37 amWhat 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.QuoteDang, 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.QuoteThose 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.

author: idpromnut
author_rank: Unknown
timestamp: November 03, 2014, 12:44:47 pm
content: 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 workscheck that I'm not missing built in drivers that are needed for the HDG2000After 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 04, 2014, 12:24:45 am
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 04, 2014, 01:00:05 am
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 04, 2014, 01:34:37 am
content: The other channel (U12) also works correctly. Same transient startup error, but it is fine after that with hammer, neighbor and PRBS test modes.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 04, 2014, 06:15:15 am
content: That's good news! Can you post your MIG options summary? What percentage of the device's LUT's are utilized per controller?QuoteYes. 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 confirmedLooks to me like P8 = MOSI

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 04, 2014, 06:18:02 am
content: 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:Device Utilization Summary:Slice Logic Utilization:Number of Slice Registers: 763 out of 18,224 4%Number used as Flip Flops: 763Number used as Latches: 0Number used as Latch-thrus: 0Number used as AND/OR logics: 0Number 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: 826Number using O5 output only: 72Number using O5 and O6: 248Number used as ROM: 0Number used as Memory: 1 out of 2,176 1%Number used as Dual Port RAM: 0Number used as Single Port RAM: 0Number used as Shift Register: 1Number using O6 output only: 1Number using O5 output only: 0Number using O5 and O6: 0Number used exclusively as route-thrus: 13Number with same-slice register load: 3Number with same-slice carry load: 10Number with other load: 0Slice 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,293Number 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 lostto control set restrictions: 0 out of 18,224 0%A LUT Flip Flop pair for this architecture represents one LUT paired withone Flip Flop within a slice. A control set is a unique combination ofclock, reset, set, and enable signals for a registered element.The Slice Logic Distribution report is not meaningful if the design isover-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: 34IOB Master Pads: 1IOB Slave Pads: 1Specific 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: 4Number used as BUFGMUX: 2Number of DCM/DCM_CLKGENs: 2 out of 4 50%Number used as DCMs: 0Number used as DCM_CLKGENs: 2Number of ILOGIC2/ISERDES2s: 0 out of 248 0%Number of IODELAY2/IODRP2/IODRP2_MCBs: 48 out of 248 19%Number used as IODELAY2s: 0Number used as IODRP2s: 4Number used as IODRP2_MCBs: 44Number of OLOGIC2/OSERDES2s: 124 out of 248 50%Number used as OLOGIC2s: 34Number used as OSERDES2s: 90Number 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 04, 2014, 06:57:15 am
content: Quote from: Cyber7 on November 04, 2014, 06:15:15 amMIG 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.QuoteI 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.QuoteThis 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 04, 2014, 07:10:34 am
content: 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?

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 04, 2014, 07:20:14 am
content: Quote from: Cyber7 on November 04, 2014, 07:10:34 amWell, 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 04, 2014, 09:25:37 pm
content: QuoteNow 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 04, 2014, 09:38:50 pm
content: Quote from: Cyber7 on November 04, 2014, 09:25:37 pmCheck the UCF file! I probed all of those pins already.Code:# U24/U26 front end relay controlNET "ferc_dat" LOC = "B3" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 0, IO_L4P_0, U24.14NET "ferc_clk" LOC = "B2" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 0, IO_L2P_0, U24.11, U25.11NET "ferc_lat" LOC = "A2" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 0, IO_L2N_0, U24.12, U25.11# U27 Analog MuxNET "mux_s<0>" LOC = "T12" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L19P_2, U27.11NET "mux_s<1>" LOC = "V13" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L14N_D12_2, U27.10NET "mux_s<2>" LOC = "U13" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L14P_D11_2, U27.9# U30 ADCNET "adc_sclk" LOC = "V16" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L2N_CMPMOSI_2, U30.15NET "adc_sdo" LOC = "U11" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L23P_2, U30.13NET "adc_sdi" LOC = "U15" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L5P_2, U30.12NET "adc_cs" LOC = "V15" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L5N_2, U30.11NET "adc_eoc" LOC = "V14" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L12N_D2_MISO3_2, U30.10NET "adc_convst" LOC = "U16" | IOSTANDARD=LVCMOS33 | SLEW=SLOW | DRIVE=8; # Bank = 2, IO_L2P_CMPCLK_2, U30.9All 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 04, 2014, 10:20:42 pm
content: QuoteSorry, 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?

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 04, 2014, 10:25:13 pm
content: Quote from: Cyber7 on November 04, 2014, 10:20:42 pmAh, 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).

author: Cyber7
author_rank: Regular Contributor
timestamp: November 04, 2014, 10:52:13 pm
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 04, 2014, 10:59:30 pm
content: Quote from: Cyber7 on November 04, 2014, 10:52:13 pmWell, 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 05, 2014, 05:46:41 am
content: 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?

author: Cyber7
author_rank: Regular Contributor
timestamp: November 05, 2014, 06:30:54 am
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 05, 2014, 07:35:53 am
content: Quote from: Cyber7 on November 05, 2014, 06:30:54 am66.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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 05, 2014, 09:00:09 am
content: 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 = { = {.modalias = "spidev",.max_speed_hz = 1000000,.bus_num = 0,.chip_select = 0,.irq = IRQ_SPI0,.controller_data = &csinfo}, = {.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 purelysynchronous.- There's currently no way to report the actual bit rate used toshift 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, allowingother drivers to talk to other devices.- There's a limit on the number of bytes each I/O request can transferto the SPI device. It defaults to one page, but that can be changedusing a module parameter.- Because SPI has no low-level transfer acknowledgement, you usuallywon't see any I/O errors when talking to a non-existent device.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 05, 2014, 09:30:12 am
content: 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).

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 05, 2014, 07:19:52 pm
content: Quote from: Cyber7 on November 05, 2014, 06:30:54 amRight, I saw that in the manual. The question is, how fast are these different clock sources?QuoteIs 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 06, 2014, 03:47:35 am
content: PCLK is the source for the SPI clock. As per bootup msgs and source structs:S3C24XX Clocks, Copyright 2004 Simtec ElectronicsCPU: MPLL on 800.000 MHz, cpu 400.000 MHz, mem 133.333 MHz,pclk 66.666 MHzCPU: 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 = 9The 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 = 1However if we desire a baudrate = 33333333, then the prescaler becomes 0Assuming 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 2static char *spi_src_clks[] = { = "pclk", = "spi-bus", = "spi_48m",};...s3c64xx_spi_set_info(0,0,2);...void __init s3c64xx_spi_set_info(int cntrlr, intsrc_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;}

author: Cyber7
author_rank: Regular Contributor
timestamp: November 06, 2014, 07:32:31 am
content: @Idpromnut:Been walking like a penguin and have the DSO5000 u-boot and kernel cross-compiled witharm-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.

author: idpromnut
author_rank: Unknown
timestamp: November 06, 2014, 01:36:20 pm
content: @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!

author: idpromnut
author_rank: Unknown
timestamp: November 06, 2014, 11:26:59 pm
content: 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 07, 2014, 10:50:10 am
content: @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: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: mmcblkb301 8192 mmcblk0p1 00000000-0000-0000-0000-000000000000b302 131072 mmcblk0p2 00000000-0000-0000-0000-000000000000Kernel 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:## File systems## CONFIG_EXT2_FS is not set# CONFIG_EXT3_FS is not set# CONFIG_EXT4_FS is not set

author: idpromnut
author_rank: Unknown
timestamp: November 07, 2014, 12:08:09 pm
content: @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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 07, 2014, 12:29:46 pm
content: @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:FPGA CONFIGURE DATA DOWN finish.0x0, 0FPGA CONFIGURE timeout.fpga firmware /lib/firmware/htg1000.bit write failed: -1ln: /dso/app/etc/etc: File existsln: /dso/app/home/home: File existsln: /dso/app/root/root: File existsln: /dso/app/mnt/udisk/udisk: File existsln: /dso/app/mnt/sd/sd: File existsanolis_set_app_init_fun:1172 fun != NULL failed.anolis_set_app_exit_fun:1179 fun != NULL failed.open usbd_serial device error !!!!open kbd errordbus is valid and addr is unix:path=/tmp/dbus-zegXRYLz8E,guid=d1b4438527287abd42fe94675459d030

author: tinhead
author_rank: Super Contributor
timestamp: November 07, 2014, 03:53:54 pm
content: i've spoke with Hantek, they released the GPL sources now for the HDG'shttp://www.hantek.com/download/HDG.zipThere 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.

author: idpromnut
author_rank: Unknown
timestamp: November 07, 2014, 03:54:32 pm
content: Quote from: Cyber7 on November 07, 2014, 12:29:46 pmNo, 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.

author: idpromnut
author_rank: Unknown
timestamp: November 07, 2014, 03:55:12 pm
content: Quote from: tinhead on November 07, 2014, 03:53:54 pmWow, 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.

author: tinhead
author_rank: Super Contributor
timestamp: November 07, 2014, 07:24:48 pm
content: Quote from: idpromnut on November 07, 2014, 03:55:12 pmas 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 fromHantek / Tekway for a long time.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 07, 2014, 10:11:40 pm
content: 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.

author: idpromnut
author_rank: Unknown
timestamp: November 07, 2014, 10:19:02 pm
content: Quote from: alex.forencich on November 07, 2014, 10:11:40 pmI 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 07, 2014, 11:08:18 pm
content: QuoteAWESOME!Its like an early Christmas present. Eagerly awaiting the 500MB download.QuoteNice 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!

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 07, 2014, 11:16:11 pm
content: Quote from: Cyber7 on November 07, 2014, 11:08:18 pmWell, 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.QuoteWell, 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.

author: idpromnut
author_rank: Unknown
timestamp: November 07, 2014, 11:23:53 pm
content: 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?

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 07, 2014, 11:39:29 pm
content: Quote from: idpromnut on November 07, 2014, 11:23:53 pmThere is no direct connection between the ADC and the SoC, so it can only be accessed through the FPGA.

author: idpromnut
author_rank: Unknown
timestamp: November 07, 2014, 11:43:51 pm
content: Quote from: alex.forencich on November 07, 2014, 11:39:29 pmWhat about the SoC onboard ADCs? Are they connected out to the two channel outputs?

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 07, 2014, 11:47:50 pm
content: Quote from: idpromnut on November 07, 2014, 11:43:51 pmNope. 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 07, 2014, 11:49:32 pm
content: I think the onboard ADC's were possibly used for the optional LCD touchscreen. From s3c2416_adc.c :Code:if (temp >= 4){printk(" %d is already reserved for TouchScreen\n", _adc.adc_port);}else

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 08, 2014, 12:39:40 am
content: 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?

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 08, 2014, 12:48:46 am
content: Quote from: idpromnut on November 07, 2014, 11:23:53 pmActually, 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 08, 2014, 12:54:57 am
content: 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/

author: Cyber7
author_rank: Regular Contributor
timestamp: November 08, 2014, 01:01:48 am
content: 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: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:static const struct i2c_device_id AFG3050_id[] = {{ "msp430", 0 },{ }};

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 08, 2014, 01:03:40 am
content: Quote from: Cyber7 on November 08, 2014, 12:54:57 amNo, 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?

author: Cyber7
author_rank: Regular Contributor
timestamp: November 08, 2014, 01:09:03 am
content: The utility to load the firmware is here: /drivers/htg_drivers/fpga_cfg/cfg_fpga.cIt simply writes the bit file to the driver exposed at dev/fpga_cfg

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 08, 2014, 01:11:35 am
content: Quote from: Cyber7 on November 08, 2014, 01:09:03 amIt 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 09, 2014, 09:21:49 am
content: 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 rootwaitMoments 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.

author: idpromnut
author_rank: Unknown
timestamp: November 09, 2014, 02:20:11 pm
content: Quote from: Cyber7 on November 09, 2014, 09:21:49 amVery 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?

author: idpromnut
author_rank: Unknown
timestamp: November 09, 2014, 02:22:30 pm
content: 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!

author: Cyber7
author_rank: Regular Contributor
timestamp: November 10, 2014, 06:52:04 am
content: QuoteYes. 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 10, 2014, 09:13:29 am
content: @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!

author: idpromnut
author_rank: Unknown
timestamp: November 10, 2014, 01:16:29 pm
content: @Cyber7:Awesome, I'll fire off my key tp Alex asap. My dev board should be arriving today.

author: idpromnut
author_rank: Unknown
timestamp: November 11, 2014, 01:05:58 am
content: 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!

author: fremen67
author_rank: Frequent Contributor
timestamp: November 11, 2014, 05:58:16 pm
content: Quote from: idpromnut on November 11, 2014, 01:05:58 amI 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 resultsI 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?

author: Cyber7
author_rank: Regular Contributor
timestamp: November 11, 2014, 06:33:15 pm
content: QuoteHere 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=0I haven't tried the GCC toolset, or u-boot LAN support yet on the AWG.@idpromnut: Did the support DVD include schematics?

author: idpromnut
author_rank: Unknown
timestamp: November 11, 2014, 07:46:52 pm
content: Quote from: Cyber7 on November 11, 2014, 06:33:15 pmYes, 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.

author: fremen67
author_rank: Frequent Contributor
timestamp: November 11, 2014, 08:00:52 pm
content: Quote from: Cyber7 on November 11, 2014, 06:33:15 pmWhat a shame4th 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.

author: fremen67
author_rank: Frequent Contributor
timestamp: November 11, 2014, 08:17:45 pm
content: Quote from: idpromnut on November 11, 2014, 07:46:52 pmWell... 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 andmake distcleanmake TQ2416_configmake allu-boot will be "u-boot_nand.bin"

author: idpromnut
author_rank: Unknown
timestamp: November 11, 2014, 09:49:05 pm
content: Quote from: fremen67 on November 11, 2014, 08:17:45 pmThanks! 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.

author: Cyber7
author_rank: Regular Contributor
timestamp: November 11, 2014, 11:19:38 pm
content: @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:mount -t nfs -o nolock,vers=2 {host pc ip}:/root/workspace/ /mnt/nfsA quick test after setting the compiler flags:Code:[root@Hantek /mnt/nfs/hello/Debug]#./helloHello ARM World!

author: fremen67
author_rank: Frequent Contributor
timestamp: November 12, 2014, 12:54:30 am
content: Quote from: Cyber7 on November 11, 2014, 11:19:38 pmNo 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:##### Boot for SKY2416/TQ2416 Main Menu ########## EmbedSky TFTP download mode ##### Download u-boot.bin to Nand Flash Download LOGO (logo.bin) to Nand Flash Erase the MISC partion Download Kernel (kernel.bin) to Nand Flash Download UBIFS image (rootfs.ubi) to Nand Flash Download Kernel_bk (kernel_bk.bin) to Nand Flash Download UBIFS image (recover.ubi) to Nand Flash normal start! recover start! Set the boot parameters Format the Nand Flash Download User Program Download Config(config.ubi). Set TFTP parameters(PC IP,SKY2416/TQ2416 IP,Mask IP...) Test network (TQ2416 Ping PC's IP) Reboot u-boot Download STEPLDR.nb1 to Nand Flash Test Linux Image (zImage) Return main MenuEnter your selection: 1test_dm9000 i/o: 0x20000300, id: 0x90000a46DM9000: running in 16 bit modeMAC: 10:23:45:67:89:aboperating at 100M half duplex modeUsing dm9000 deviceTFTP from server 192.168.1.100; our IP address is 192.168.1.101Filename 'u-boot.bin'.Load address: 0xc0000000Loading: #########################doneBytes transferred = 362388 (58794 hex)NAND erase: device 0 offset 0x0, size 0x100000Erasing at 0xe0000 -- 100% complete.OKNAND write: device 0 offset 0x0, size 0x58800Writing data at 0x58800 -- 100% complete.362496 bytes written: OK##### Boot for SKY2416/TQ2416 Main Menu ########## EmbedSky TFTP download mode ##### Download u-boot.bin to Nand Flash Download LOGO (logo.bin) to Nand Flash Erase the MISC partion Download Kernel (kernel.bin) to Nand Flash Download UBIFS image (rootfs.ubi) to Nand Flash Download Kernel_bk (kernel_bk.bin) to Nand Flash Download UBIFS image (recover.ubi) to Nand Flash normal start! recover start! Set the boot parameters Format the Nand Flash Download User Program Download Config(config.ubi). Set TFTP parameters(PC IP,SKY2416/TQ2416 IP,Mask IP...) Test network (TQ2416 Ping PC's IP) Reboot u-boot Download STEPLDR.nb1 to Nand Flash Test Linux Image (zImage) Return main MenuEnter your selection:

author: Cyber7
author_rank: Regular Contributor
timestamp: November 12, 2014, 06:18:51 am
content: 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-systemnboot - boot from NAND devicenfs - boot image via network using NFS protocolnm - memory modify (constant address)ping - send ICMP ECHO_REQUEST to network hostprintenv- print environment variablesThere 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...

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 12, 2014, 08:14:39 am
content: 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: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.000nsData 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.000nsDestination Clock: clk_250mhz_int rising at 4.000nsClock Uncertainty: 0.143nsClock Uncertainty: 0.143ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PETotal System Jitter (TSJ): 0.070nsTotal Input Jitter (TIJ): 0.000nsDiscrete Jitter (DJ): 0.216nsPhase Error (PE): 0.000nsMaximum Data Path at Slow Process Corner: spi_slave_inst/input_axis_tready_reg to soc_interface_inst/port0_cmd_en_regLocation Delay type Delay(ns) Physical ResourceLogical Resource(s)------------------------------------------------- -------------------SLICE_X20Y30.DQ Tcko 0.476 spi_slave_inst/input_axis_tready_regspi_slave_inst/input_axis_tready_regSLICE_X21Y30.A2 net (fanout=4) 1.064 spi_slave_inst/input_axis_tready_regSLICE_X21Y30.A Tilo 0.259 soc_interface_inst/output_axis_tvalid_regsoc_interface_inst/data_valid_reg_rd_empty_AND_65_o1SLICE_X18Y36.B5 net (fanout=5) 0.929 soc_interface_inst/data_valid_reg_rd_empty_AND_65_oSLICE_X18Y36.B Tilo 0.254 soc_interface_inst/port1_cmd_en_regsoc_interface_inst/Mmux_port0_cmd_en_next12SLICE_X17Y37.C6 net (fanout=2) 0.754 soc_interface_inst/Mmux_port0_cmd_en_next12SLICE_X17Y37.CLK Tas 0.373 soc_interface_inst/port0_cmd_en_regsoc_interface_inst/Mmux_port0_cmd_en_next21soc_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!

author: fremen67
author_rank: Frequent Contributor
timestamp: November 12, 2014, 08:43:45 am
content: Quote from: Cyber7 on November 12, 2014, 06:18:51 amI 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 ubootI will have a look a it.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 23, 2014, 08:20:56 pm
content: 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:================================================================================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 endpoint1 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.000nsData 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.000nsDestination Clock: clk_250mhz_int rising at 4.000nsClock Uncertainty: 0.143nsClock Uncertainty: 0.143ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PETotal System Jitter (TSJ): 0.070nsTotal Input Jitter (TIJ): 0.000nsDiscrete Jitter (DJ): 0.216nsPhase Error (PE): 0.000nsMaximum 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_17Location Delay type Delay(ns) Physical ResourceLogical Resource(s)------------------------------------------------- -------------------MCB_X1Y1.P0RDDATA17 Tmcbcko_RDDATA 2.700 ddr2_ram2_inst/memc_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/samc_0ddr2_ram2_inst/memc_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/samc_0SLICE_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)

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 24, 2014, 06:10:24 am
content: 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 !!!!

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 25, 2014, 09:52:26 am
content: 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:Address space0 0000 0000 - 0 07ff ffff channel 1 memory1 0000 0000 - 1 07ff ffff channel 2 memoryF 0000 0000 - f ffff ffff control and configurationCommands1010 bbbb - read to bank b1011 bbbb - write from bank bread command exampleRead AA BB CC DD from bank 0 (channel 1 memory) at address 0x00001234Read data start indicated by leading nonzero byteMOSI A0 00 00 12 34 00 00 00 00 00 00 00 00MISO 00 00 00 00 00 00 01 AA BB CC DD xx xxwrite command exampleWrite AA BB CC DD to bank 0 (channel 1 memory) at address 0x00001234MOSI B0 00 00 12 34 AA BB CC DDMISO 00 00 00 00 00 00 00 00 00Currently, 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.

author: lukier
author_rank: Unknown
timestamp: November 25, 2014, 03:52:46 pm
content: 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 orhttps://github.com/lukier/Pipistrello_ols_verilog.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 25, 2014, 07:36:41 pm
content: Quote from: lukier on November 25, 2014, 03:52:46 pmYou 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.QuoteThat 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 25, 2014, 08:06:08 pm
content: 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: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.000nsData 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.000nsDestination Clock: clk_250mhz_int rising at 4.000nsClock Uncertainty: 0.169nsClock Uncertainty: 0.169ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PETotal System Jitter (TSJ): 0.070nsTotal Input Jitter (TIJ): 0.100nsDiscrete Jitter (DJ): 0.216nsPhase Error (PE): 0.000nsMaximum 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_0Location Delay type Delay(ns) Physical ResourceLogical Resource(s)------------------------------------------------- -------------------MCB_X1Y1.P0RDDATA24 Tmcbcko_RDDATA 2.700 ddr2_ram2_inst/memc_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/samc_0ddr2_ram2_inst/memc_wrapper_inst/mcb_ui_top_inst/mcb_raw_wrapper_inst/samc_0SLICE_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 reportsCode: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.

author: lukier
author_rank: Unknown
timestamp: November 25, 2014, 08:19:35 pm
content: Quote from: alex.forencich on November 25, 2014, 07:36:41 pmThanks 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: November 25, 2014, 09:45:12 pm
content: 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.

author: tridentsx
author_rank: Regular Contributor
timestamp: December 14, 2014, 07:05:06 am
content: I haven't seen any activity in this thread for a while, did this project die ?

author: alex.forencich
author_rank: Frequent Contributor
timestamp: December 14, 2014, 07:13:28 am
content: 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.

author: mb300sd
author_rank: Contributor
timestamp: December 26, 2014, 05:49:12 pm
content: 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.

author: rdg
author_rank: Contributor
timestamp: December 29, 2014, 01:17:59 am
content: 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 theoriginal postdoesn'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 asthis?Thanks.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: December 29, 2014, 03:55:28 am
content: Quote from: mb300sd on December 26, 2014, 05:49:12 pmI 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.

author: idpromnut
author_rank: Unknown
timestamp: December 29, 2014, 04:35:49 am
content: 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.

author: mb300sd
author_rank: Contributor
timestamp: December 29, 2014, 08:27:12 am
content: 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.

author: fremen67
author_rank: Frequent Contributor
timestamp: January 03, 2015, 12:03:21 am
content: Quote from: rdg on December 29, 2014, 01:17:59 amI 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).

author: fremen67
author_rank: Frequent Contributor
timestamp: January 03, 2015, 12:08:34 am
content: Quote from: mb300sd on December 29, 2014, 08:27:12 amNice, I hope you will get a new software versionKeep us updated !

author: smgvbest
author_rank: Unknown
timestamp: January 08, 2015, 03:15:45 am
content: 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.

author: mb300sd
author_rank: Contributor
timestamp: January 08, 2015, 07:14:28 pm
content: Quote from: fremen67 on January 03, 2015, 12:08:34 amSoftware 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.

author: andrija
author_rank: Regular Contributor
timestamp: January 08, 2015, 10:38:11 pm
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: January 08, 2015, 10:52:26 pm
content: 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.

author: smgvbest
author_rank: Unknown
timestamp: January 09, 2015, 04:25:05 am
content: 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>

author: kazam
author_rank: Regular Contributor
timestamp: January 10, 2015, 05:29:29 pm
content: 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.

author: markone
author_rank: Frequent Contributor
timestamp: January 11, 2015, 11:13:34 am
content: 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.

author: kazam
author_rank: Regular Contributor
timestamp: January 11, 2015, 11:18:34 pm
content: 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.

author: markone
author_rank: Frequent Contributor
timestamp: January 12, 2015, 01:49:04 am
content: Quote from: kazam on January 11, 2015, 11:18:34 pmYep, internal shielding chassis edges are rusty, because they cut the metalafterthe galvanization treatment.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: January 21, 2015, 04:42:32 am
content: 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.

author: tridentsx
author_rank: Regular Contributor
timestamp: February 01, 2015, 08:26:11 am
content: 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 customimage if and when I resurrect it.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: February 01, 2015, 08:49:55 am
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: February 03, 2015, 01:35:25 am
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: February 04, 2015, 08:36:35 am
content: 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.

author: tridentsx
author_rank: Regular Contributor
timestamp: March 20, 2015, 08:09:00 am
content: 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.

author: smgvbest
author_rank: Unknown
timestamp: March 22, 2015, 02:07:48 am
content: Quote from: tridentsx on March 20, 2015, 08:09:00 amSame here. Wish I did. if there is something a beginner could help with I'd be happy to give it a try FWIW

author: alex.forencich
author_rank: Frequent Contributor
timestamp: March 22, 2015, 02:20:29 am
content: 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.

author: lukier
author_rank: Unknown
timestamp: March 22, 2015, 02:47:04 am
content: 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: March 22, 2015, 03:25:48 am
content: 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.

author: idpromnut
author_rank: Unknown
timestamp: March 22, 2015, 04:07:58 am
content: Quote from: lukier on March 22, 2015, 02:47:04 amI 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.

author: smgvbest
author_rank: Unknown
timestamp: March 22, 2015, 04:55:57 am
content: Quote from: alex.forencich on March 22, 2015, 02:20:29 amSince you mentioned it I found this SCPI Libraryhttp://www.the-control-freak.com/SCPI/SCPI.htmI 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

author: alex.forencich
author_rank: Frequent Contributor
timestamp: March 22, 2015, 05:00:36 am
content: Quote from: smgvbest on March 22, 2015, 04:55:57 amHere 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.

author: smgvbest
author_rank: Unknown
timestamp: March 22, 2015, 07:15:45 am
content: Quote from: alex.forencich on March 22, 2015, 05:00:36 amI guess one question is do we want to start implementing the command currently used in the HDG2000's or start from scratchI 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

author: alex.forencich
author_rank: Frequent Contributor
timestamp: March 22, 2015, 07:17:41 am
content: Quote from: smgvbest on March 22, 2015, 07:15:45 amI say duplicate the Agilent commands for their TrueForm generators. The command set for the HDG2000 sucks.

author: smgvbest
author_rank: Unknown
timestamp: March 22, 2015, 07:20:55 am
content: Quote from: alex.forencich on March 22, 2015, 07:17:41 am

author: alex.forencich
author_rank: Frequent Contributor
timestamp: March 22, 2015, 07:25:42 am
content: Quote from: smgvbest on March 22, 2015, 07:20:55 amYour 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.

author: lukier
author_rank: Unknown
timestamp: March 22, 2015, 11:52:51 am
content: Quote from: alex.forencich on March 22, 2015, 07:17:41 amI 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

author: smgvbest
author_rank: Unknown
timestamp: March 22, 2015, 04:26:33 pm
content: Keysight has stuff including a legacy UBMTMC driver along with LXI samples FWIWhttp://www.keysight.com/main/editorial.jspx?cc=US&lc=eng&ckey=1189290&nid=-34952.0.00&id=1189290&cmpid=20586Wish they'd stop changing names

author: alex.forencich
author_rank: Frequent Contributor
timestamp: March 22, 2015, 05:42:42 pm
content: Quote from: smgvbest on March 22, 2015, 04:26:33 pmI 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.QuoteSigh.......

author: smgvbest
author_rank: Unknown
timestamp: March 24, 2015, 01:33:28 am
content: Quote from: alex.forencich on March 22, 2015, 05:42:42 pmLooking at the code it is a device driverHopefully the kernel used will be a fixed version and this is a moot point

author: alex.forencich
author_rank: Frequent Contributor
timestamp: March 24, 2015, 01:52:12 am
content: Quote from: smgvbest on March 24, 2015, 01:33:28 amDevice 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.

author: tridentsx
author_rank: Regular Contributor
timestamp: March 24, 2015, 06:20:23 am
content: I used my google fu and the only projetcs I came accross that has implemented the device side of USB-TMC arehttp://labs.ti.bfh.ch/gecko/wiki/systems/gecko3com/startandhttps://github.com/karlp/discotmcBoth of them in a firmware without an OS, don't know if that's usefull or not, maybe need to do this from scratch.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: March 24, 2015, 06:26:29 am
content: Well, any existing design might be useful, if only for reference.

author: tridentsx
author_rank: Regular Contributor
timestamp: March 26, 2015, 08:26:27 pm
content: I have been looking for a reasonable priced PCI USB perephial card online and today I found one on ebayhttp://www.ebay.com/itm/LOT-OF-2-PLX-2280BC-F-USB-DUET-PCI-ADAPTERS-/271691946991?pt=LH_DefaultDomain_0&hash=item3f421a1befIf I have time I will try to get libusbghttps://github.com/libusbg/libusbgand scpi-parserhttps://github.com/j123b567/scpi-parserto work together to implement the perephial side of USBTMC

author: alex.forencich
author_rank: Frequent Contributor
timestamp: March 27, 2015, 01:36:19 am
content: Quote from: tridentsx on March 26, 2015, 08:26:27 pmLooks 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.

author: tridentsx
author_rank: Regular Contributor
timestamp: April 03, 2015, 01:31:57 am
content: 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 realinstrument.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: April 03, 2015, 01:56:16 am
content: Quote from: tridentsx on April 03, 2015, 01:31:57 amWell, that's a minor set back.QuoteI 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.

author: smgvbest
author_rank: Unknown
timestamp: April 15, 2015, 11:45:53 pm
content: Very Nice update

author: tridentsx
author_rank: Regular Contributor
timestamp: April 20, 2015, 06:51:04 pm
content: 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 488http://lxr.free-electrons.com/source/drivers/usb/gadget/function/I don't have much experience from Linux kernel development.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: April 20, 2015, 06:55:22 pm
content: 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.

author: lukier
author_rank: Unknown
timestamp: April 21, 2015, 01:51:43 pm
content: 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

author: alex.forencich
author_rank: Frequent Contributor
timestamp: April 21, 2015, 08:10:19 pm
content: 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. Seehttp://www.linux-usb.org/gadget/near the bottom of the page.It's great to see some activity on the software side of things!

author: tridentsx
author_rank: Regular Contributor
timestamp: April 21, 2015, 08:57:19 pm
content: 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 FunctionFShttp://events.linuxfoundation.org/sites/events/files/slides/USB%20Gadget%20Configfs%20API_0.pdf

author: fremen67
author_rank: Frequent Contributor
timestamp: April 22, 2015, 12:24:00 am
content: Quote from: lukier on March 22, 2015, 02:47:04 amI 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.Quote from: lukier on March 22, 2015, 02:47:04 amThe 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.

author: fremen67
author_rank: Frequent Contributor
timestamp: April 22, 2015, 12:30:39 am
content: Quote from: lukier on March 22, 2015, 11:52:51 amThat makes sense.What about DBus for inter process communication? Seems to be well supported in Qt...

author: fremen67
author_rank: Frequent Contributor
timestamp: April 22, 2015, 12:51:35 am
content: Quote from: lukier on April 21, 2015, 01:51:43 pmAs 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.0I 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.

author: fremen67
author_rank: Frequent Contributor
timestamp: April 22, 2015, 12:55:18 am
content: Quote from: alex.forencich on April 21, 2015, 08:10:19 pmYes 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.

author: smgvbest
author_rank: Unknown
timestamp: April 22, 2015, 01:15:47 am
content: Quote from: fremen67 on April 22, 2015, 12:55:18 amIf 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.

author: fremen67
author_rank: Frequent Contributor
timestamp: April 22, 2015, 01:43:07 am
content: Quote from: smgvbest on April 22, 2015, 01:15:47 amAttached the f-tmc.c file I saw in the GPL sources: AFG_hdg2000b\src\linux-3.2.35\drivers\usb\gadget\f-tmc.cPlus 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:...#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...

author: lukier
author_rank: Unknown
timestamp: April 22, 2015, 01:47:04 pm
content: Quote from: fremen67 on April 22, 2015, 12:30:39 amI 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).Quote from: fremen67 on April 22, 2015, 12:51:35 amI 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.

author: tridentsx
author_rank: Regular Contributor
timestamp: April 22, 2015, 03:48:05 pm
content: 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/

author: lukier
author_rank: Unknown
timestamp: April 22, 2015, 05:36:26 pm
content: Quote from: tridentsx on April 22, 2015, 03:48:05 pmLooks 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.

author: tridentsx
author_rank: Regular Contributor
timestamp: April 23, 2015, 05:17:23 am
content: 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 fileshttp://patchwork.ozlabs.org/patch/185884/

author: fremen67
author_rank: Frequent Contributor
timestamp: April 28, 2015, 12:01:42 am
content: Quote from: lukier on April 22, 2015, 01:47:04 pmYou 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.Quote from: lukier on April 22, 2015, 01:47:04 pmYou will find the files needed to rebuild a 1.00.3 firmware in myOneDrivein the "04-Firmware 1.00.3 Nand Recover" directory. The u-boot there is the modified one.

author: fremen67
author_rank: Frequent Contributor
timestamp: April 28, 2015, 12:25:19 am
content: @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.1All 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: April 28, 2015, 01:59:46 am
content: 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.

author: fremen67
author_rank: Frequent Contributor
timestamp: May 01, 2015, 08:42:08 pm
content: @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 partDo 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.

author: alex.forencich
author_rank: Frequent Contributor
timestamp: May 01, 2015, 08:44:31 pm
content: 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.

author: fremen67
author_rank: Frequent Contributor
timestamp: May 01, 2015, 09:02:22 pm
content: 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...

author: alex.forencich
author_rank: Frequent Contributor
timestamp: May 01, 2015, 09:13:12 pm
content: Well, something has to drive the sync output BNC. Did you figure out what pin that is?

author: fremen67
author_rank: Frequent Contributor
timestamp: May 01, 2015, 09:50:42 pm
content: Quote from: alex.forencich on May 01, 2015, 09:13:12 pmYes, 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.

author: tridentsx
author_rank: Regular Contributor
timestamp: May 05, 2015, 05:38:47 pm
content: 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?

author: tridentsx
author_rank: Regular Contributor
timestamp: May 06, 2015, 07:14:27 pm
content: 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.

author: tridentsx
author_rank: Regular Contributor
timestamp: May 12, 2015, 08:32:11 am
content: 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.

author: lukier
author_rank: Unknown
timestamp: May 12, 2015, 11:38:11 am
content: Quote from: tridentsx on May 12, 2015, 08:32:11 amQuote from: tridentsx on May 12, 2015, 08:32:11 amSPL 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.

author: fremen67
author_rank: Frequent Contributor
timestamp: May 12, 2015, 11:53:51 am
content: Quote from: tridentsx on May 12, 2015, 08:32:11 amIf 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=9It 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).

author: tridentsx
author_rank: Regular Contributor
timestamp: May 19, 2015, 07:57:51 am
content: 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 followinghttps://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 0NAND flash device 'NAND 256MiB 3.3V 8-bit (unknown)' found> nand write 0 "../u-boot-with-spl.bin" 0x00000000wrote 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 runHence I decided to try urjtag but I get some error already when I do the detectjtag> cable ARM-USB-OCDConnected to libftdi driver.jtag> detectwarning: TDO seems to be stuck at 1I 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.

author: tridentsx
author_rank: Regular Contributor
timestamp: May 19, 2015, 04:34:58 pm
content: 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 ?

author: fremen67
author_rank: Frequent Contributor
timestamp: June 20, 2015, 10:12:34 pm
content: 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.@AlexAny 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...

author: timofonic
author_rank: Frequent Contributor
timestamp: August 19, 2015, 02:19:21 am
content: Is this alive? Any interest in this project?I'm more interested as it may become the future of a OSHW oscilloscopehttps://github.com/MParygin/v.scope80https://github.com/Razer6/welecw2000ahttps://github.com/baldengineer/Mixed-Signal-Oscilloscope-Demo-Boardhttps://github.com/mdebski/oscilloscopehttps://github.com/agural/FPGA-Oscilloscopehttps://github.com/analogdevicesinc/iio-oscilloscopehttps://github.com/gabonator/DS203

author: fremen67
author_rank: Frequent Contributor
timestamp: August 25, 2015, 12:09:04 am
content: Quote from: Circuiteromalaguito on August 19, 2015, 02:19:21 amYes 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 itNo link at the moment between the GUI and the FPGA.

author: tridentsx
author_rank: Regular Contributor
timestamp: August 25, 2015, 03:44:25 am
content: Do you have any details on how you did that upgrade to support touch screen?

author: fremen67
author_rank: Frequent Contributor
timestamp: September 01, 2015, 12:08:03 am
content: Quote from: tridentsx on August 25, 2015, 03:44:25 amSorry 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 extensionThe touch screen I used has an active area which is 2 mm too short horizontally and 1 mm too short vertically.I bought it herehttp://www.aliexpress.com/item/Free-shipping-7-inch-new-touch-screen-digitizer-for-AT070TN90-AT070TN92-AT070TN93-AT070TN94-quality-100-guarranty/585764980.htmlThe 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 ...

author: smgvbest
author_rank: Unknown
timestamp: October 25, 2015, 07:51:24 pm
content: Quote from: fremen67 on August 25, 2015, 12:09:04 amI realize this might be a bit soon but would love to see images on your gui work if you felt like sharing???

author: tridentsx
author_rank: Regular Contributor
timestamp: October 26, 2015, 02:15:13 pm
content: Will this alternative s/w be open source ? Is there a repo where the source will be available ?

author: timofonic
author_rank: Frequent Contributor
timestamp: November 08, 2015, 09:58:54 pm
content: Quote from: tridentsx on October 26, 2015, 02:15:13 pmIt 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

author: tridentsx
author_rank: Regular Contributor
timestamp: January 25, 2016, 06:41:09 am
content: Is this effort dead ? I hope not seemed like so much progress was made.

author: tridentsx
author_rank: Regular Contributor
timestamp: February 02, 2017, 08:47:26 am
content: 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.ziphttp://latlon.org/~jek/samsung/smdk2416/

author: Scratch.HTF
author_rank: Regular Contributor
timestamp: October 30, 2017, 12:31:18 am
content: I wish to revive this topic since I am in need for improved firmware; see my topichttps://www.eevblog.com/forum/testgear/hantek-hdg2000-series-firmware-enhancements/for more details.