HDG2002B AWG Firmware Reverse Engineering

[alex.forencich]

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

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

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

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

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

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

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

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

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

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

[idpromnut]

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

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

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

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

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

Code: [Select]

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

Starting kernel ...

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

[alex.forencich]

Excellent progress! 

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

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

[idpromnut]

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

[andrija]

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

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

[alex.forencich]

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

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

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

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

[idpromnut]

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

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

[Cyber7]

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

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

[Cyber7]

@idpromnut: 

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

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

Here's the keypad info:

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

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

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

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

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

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

ScanCodes & bitmasks are attached.

[andrija]

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

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

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

[alex.forencich]

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

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

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

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

[idpromnut]

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

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

[fremen67]

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

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

[fremen67]

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

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

[Cyber7]

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

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

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

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

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

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

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

[idpromnut]

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

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

Pretty sure that was me freaking out about that bug initially

[idpromnut]

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

[Cyber7]

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


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

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

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

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

        s3c_device_fb.name = "s3c2443-fb";

        return sysdev_register(&s3c2416_sysdev);
}

[fremen67]

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

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

[idpromnut]

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


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

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

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

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

        s3c_device_fb.name = "s3c2443-fb";

        return sysdev_register(&s3c2416_sysdev);
}

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

[fremen67]

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

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

[alex.forencich]

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

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

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

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

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

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

[alex.forencich]

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

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

[tinhead]

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

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

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

[alex.forencich]

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

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

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

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