New Rigol 16-bit function generators DG800/900 series

[ToThePub]

@Sonicsx Why don't you just try it and let us know. Just use :PROJ:MODE DG2102 instead. Let us know as I want to get the DG2000 (due to the format) if I can turn a DG2052 to a DG2102.

[Candid]

I wrote an email to support about the missing waveforms with firmware 2.0.6 and got a quick response, that they could replicate the problem and that it has been reported to R&D department. So hopefully we will se a news firmware version soon. Didn't do this someone else before? As far as I could research no one did before?

Candid

[frozenfrogz]

Couple of days ago, the trigger output of my DG812 went tits up. :/
I am now seeing a constant +3.36V on the output. My guess would be a fried FET, though I have no idea how this happened.

Steps already taken:
-> Firmware downgrade to 1.08 and back to 2.06, to see if it could be a software issue.
-> took a look inside and checked for visible damage

Both turned up nothing so far.

Are there any schematics floating around the web?
Anyone having fixed a similar issue?

Edit:
Trigger output seems to consist of various ESD / clamp diodes, a HC4053M multiplexer for both channels and a TI buffer/line driver (HA125 is 74AHC125PWR?) per channel. Since both outputs show the same behavior, my guess would be the multiplexer - just a first guess though..

[beddy]

I was the enabler that helped but the true discoverer of this alternative method was bulba99. 

(when he told me the simple operation he had tried I was sure that he had solved it...)

I crafted this script so that all who were waiting this last step can finish the 2.04 upgrade.

This is a supplement to the rest of the upgrade process not a replacement!

This file is work with my DG2052, changed to DG992. The problem is the keybord of the device is not same, some of them can't work anymore.
Could you tell the logic of the hack file, or change something help me to upgrade to DG2102? Thanks a lot.

[JimKnopf]

@beddy Does your network card still work?

I got the DG2052 too and tried the step in 2021 already without luck. I ended up with a 992 looking device without ethernet.

At the moment i figure out the JTAG connectivity. It's a bit tricky. I got it to work with a CJMCU-232h and a TIAO tumpa adapter. My Olimex Tiny H and a Segger Jlink can't establish tap access.  I used a Jtagulator to find the JTAG pins. They are located on the 2x10 pin-holes. I removed the long pins below the board. They are not connected to any line. They only prevent access to the pin-holes.

[beddy]

The network can't work now. But a good news is if I update the fw to 2.2, the device will go back to DG2052, and update to fw 2.6 will change to DG992. Very strange.

[Njk]

Looks like you used not the original FW but a FW from this forum. Perhaps the latter incorporates some unix script, which was manufactured by tv84 specifically for those not able to type :proj:model. And 992 is "hardcoded" there. Nothing is strange. That's what I think. On the other hand, thanks for sharing this. DG8xx/9xx/2xxx all uses the same Sitara SoC that has Ethernet on-board. So it was not clear what will happen if to populate DG/8/9 with LAN socket manually. Now we know that it'll make no sense as LAN is disabled in FW.

[tv84]

You all must be aware that my DG800/900 investigations precede the release of the DG2000 model.

As such, it was never guaranteed to work with the new model even if using the same FW.

Rigol did introduce/correct some countermeasures in the FW to make harder the DG900 migration let alone a migration to DG2000.

As I remember there were some members who tried the DG2000 migration with some help from me and by lack of time, interest, etc., I wasn't able to solve their rollback.

Nonetheless, I'm completely sure that a solution can be found. One of these days I might step in to help some ongoing effort but, for now, I don't have time for this quest.

[tv84]

Could you tell the logic of the hack file, or change something help me to upgrade to DG2102? Thanks a lot.

Just a small hint from memory: the public procedure involved an old FW release that allowed the SCPI commands to change model. Those old FW releases (prior to the DG2000 rollout) didn't have the DG2000 models designations.

So, once you force an unknown model designation in the old FW (exclusive to DG800/900) the device gets into an unstable situation where it doesnt know how to properly behave for all the settings that are based on it model designation.

AFAIR, that is what you guys are dealing with. Of course there is always the direct access to the FRAM to change the model designation back.

[JimKnopf]

@Njk Seems the nic is disabled in FW yes. If i compare my UART log file with the content TurboTom posted here: https://www.eevblog.com/forum/testgear/new-rigol-16-bit-function-generators-dg800900-series/msg3244488/?topicseen#msg3244488

MY DG2052 UART log:

Code: [Select]

Welcome to RIGOL DG800 system

rigol login: [    5.004776] sardine-adc TI-am335x-adc: initialized
[    5.085171] fram 0-000a: initialized
[    5.145170] beep pwm:beeper,hwpwm:0,period:2000,polarity:0
[    5.158296] pwmdev-beeper beeper.7: initialized
[    5.215597] gpio-led led.8: initialized
[    5.904847] ts-ft6336U 2-0038: ts_ft_i2c_write i2c write error.
[    5.911376] ts-ft6336U 2-0038: ts_ft_i2c_write i2c write error.
[    5.917707] ts-ft6336U 2-0038: ts_ft_i2c_write i2c write error.
[    5.924679] read: i2c_transfer error!
[    5.928601] ts-ft6336U 2-0038: ts_ft_i2c_write i2c write error.
[    5.935278] read: i2c_transfer error!
[    5.939202] ts-ft6336U 2-0038: ts_ft_i2c_write i2c write error.
[    5.945754] read: i2c_transfer error!
[    5.950566] input: Rigol-FocalTech TS as /devices/ocp.3/4819c000.i2c/i2c-2/2-0038/input/input0
[    6.042928] input: rigol keyboard as /devices/ocp.3/48022000.serial/input/input1
[    6.075187] rigol-kbd 48022000.serial: initialized!
[    6.160813] usbcore: registered new interface driver usbtmc
[    6.235207] usbcore: registered new interface driver asix
[    6.285194] usbcore: registered new interface driver r8152
rmmod: can't unload module 'usbtmc_dev': No such file or directory
rmmod: can't unload module 'libcomposite': No such file or directory
[   21.373285] Rigol Device gadget: Usb device Gadget, version: 2016 July 26
[   21.380595] Rigol Device gadget: Rigol Device ready
[   21.478966] usbcore: deregistering interface driver usbtmc
[   21.585188] usbcore: registered new interface driver usbtmc
[   21.618089] net eth0: initializing cpsw version 1.12 (0)
[   21.725121] net eth0: phy found : id is : 0x221561
[   24.094660] Boot process: boot process end!
[   24.601829] boot_process_stop: boot process stop = 1 
[   31.360636] random: nonblocking pool is initialized

The "net eth0" lines are missing in TurboTom's log-output. Same chips, same  firmware.
@beddy Can you provide a UART boot log output from your fake DG992 status?
I'm curious if the net eth0 line  is present.

[Njk]

The "net eth0" lines are missing in TurboTom's log-output. Same chips, same  firmware.
@beddy Can you provide a UART boot log output from your fake DG992 status?
I'm curious if the net eth0 line  is present.

That's an interesting questions indeed. According to the previous reports, someone was able to log in to u-boot console using known credentials. If eth0 is enabled there? If the device tree structure is the same for all the DGs? Is it possible to log in to system console to see all the config details?

Anyway AM3352 is a good chip. It's not from a copy-past Asian vendor, it's directly from TI. There is a mature literature department, so a first class documentation, a bare metal SDKs, a Linux SDKs, support forum, etc. And it's not a new chip, most errata are known. Also, the BeagleBone boards are based on almost similar chip. The design seems a good target. It's not clear why the calibration data are not yet investigated here

[JimKnopf]

This are the JTAG Pins. The test-pads on the bottom side are not regognized as JTAG by Jtagulator. They have Signals and are connected to the Pinheader as shown in the Picture.

The exposed JTAG pins on the Mainboard near the Spartan 6 have strong pullup resistors. The JTAG pins on the CPU-board have much higher resistance values and are less usable. Maybe thats why i have  reset problems in openocd. I'm a newbie in jtag stuff. TopJTAG Probe could find the AM3552 with my Olimex Tiny H. In openocd i had less problems with a CJMCU-232H or (the better choice) a TIAO tumpa board.

To get JTAG access with openocd, i had to stop the boot process in uboot. Another way is, preventing the system from reading the W25X40 SPI eeprom by shorting pin 2 (DO) to pin 4 (GND) (see picture).

In openocd i startet the server with "openocd -d3 -f interface/ftdi/tumpa.cfg -f target/am335x.cfg"
and connected with "telnet localhost 4444" to it.

In openocd it looks like:

Code: [Select]

> scan_chain
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 am335x.tap             Y     0x00000000 0x4b6b902f     4 0x01  0x0f
 1 am335x.m3_tap          n     0x00000000 0x4b6b902f     4 0x01  0x0f
 2 am335x.jrc             Y     0x2b94402f 0x*b94402f     6 0x01  0x3f

> targets   
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0  am335x.m3          cortex_m   little am335x.m3_tap      tap-disabled
 1* am335x.cpu         cortex_a   little am335x.tap         running

> halt

[JimKnopf]

Maybe the electrical characteristic of some pins might be of interest for someone.

I attach a LibreCalc table. Rename the file to .ods.
Btw. the JTAGulator doesn't found JTAG pins on the 2x5 pin-holes on the Frontboard (keyboard).

[SMB784]

That's an interesting questions indeed. According to the previous reports, someone was able to log in to u-boot console using known credentials. If eth0 is enabled there? If the device tree structure is the same for all the DGs? Is it possible to log in to system console to see all the config details?

Anyway AM3352 is a good chip. It's not from a copy-past Asian vendor, it's directly from TI. There is a mature literature department, so a first class documentation, a bare metal SDKs, a Linux SDKs, support forum, etc. And it's not a new chip, most errata are known. Also, the BeagleBone boards are based on almost similar chip. The design seems a good target. It's not clear why the calibration data are not yet investigated here

The calibration data has been investigated (by me, TV84, etc), see this post

[Njk]

The calibration data has been investigated (by me, TV84, etc), see this post

Yes I've seen that. Actually, the information is distributed along the thread with low density. To figure out the status, let me to provide a quick summary here.

1. Calibration data. Currently, we have the data files for DG811 device. To my understanding, the promotion procedure does not alter the data, while the respective files for a true DG9xx device are still not available. Also, we have two sets of the cal files for the DG2052 model. That's all.

2. Key findings:

Well, CalibrationInfo.dat files from DG2052s are precisely the same file as in a DG811. The only difference is the date. The mac.dat shows the difference of MAC addresses. So all actual differences are in CalibrationData.dat. Nonetheless it is very similar.

I just uploaded Hobbit13's first set of CAL files onto my DG811+++, and indeed now get a pretty accurate amplitude up to 100MHz, yet with a DC offset of a few tens of millivolts.

At least, switching CAL files finally proves that the hardware of the DG800 series is absolutely capable of produceing a flat output up to 100MHz.

I compared the CAL files more thoroughly and as it seems, there's more to it than just copying some contents of the DG2052 cal file over the existing "zeros" of the DG800's. The structure is the same, as is the size, but it seems that some blocks contain identical byte sequences but placed at different offsets. So there may be "table descriptors" that are relocated which will make a blind copying of values futile.

What you're seeing in my pixelized images are just half of the original .dat files content, because the halfs are similar. And each the half has its CRC at the beginning (i think it's an crc). As we see in the pics, each the half, in turn, consists of 2 similar halves, which I suppose are the calibration data for 2 different channel.

According to the Chinese Service Guides, the Motherboard part numbers (2010004229) in the DG800 and DG900 are identical. The DG8xx models isn't calibrated all the way up to 100MHz and apparently also has fewer calibration points in the low frequency region. One would need to do a full calibration after upgrading. However, there is no comprehensive DIY calibration guide (yet).

The investigation got stuck at that stage because of the conclusion that the calibration data format can't be understood without disassembling and analyzing of the code that generates and uses that data (what a surprise). If i missed something?

[JimKnopf]

I now think the 2x10 pin holes are a Compact TI JTAG pinout. I don't know how do deal with EMU0 and EMU1 pin. Maybe pullup pulldown resistor can help. I will try that later.

[SMB784]

The investigation got stuck at that stage because of the conclusion that the calibration data format can't be understood without disassembling and analyzing of the code that generates and uses that data (what a surprise). If i missed something?

Yes that appears to be the state of the investigation at the moment.  I am happy to learn that the cal files are the same between models, that solves one mystery that I did not realize had been solved.  So, it appears the only thing left to do is figure out the cal commands via SCPI.  I know you can change the calibration date using an SCPI command, and there's a list of SCPI commands floating around in the thread.  Maybe thats a good place to restart the investigation: track down the possible SCPI commands and see what they do to the calibration file.

Thoughts?

[kavehm]

Does Rigel dc820 have a fixed and stable output up to two to three decimal places?

[Njk]

Yes that appears to be the state of the investigation at the moment.  I am happy to learn that the cal files are the same between models, that solves one mystery that I did not realize had been solved.  So, it appears the only thing left to do is figure out the cal commands via SCPI.  I know you can change the calibration date using an SCPI command, and there's a list of SCPI commands floating around in the thread.  Maybe thats a good place to restart the investigation: track down the possible SCPI commands and see what they do to the calibration file.

Indeed. On the one hand, all the SCPI commands are already extracted from the FW. And some interesting commands are identified

Calibration stuff (I can't read anything back, seems like its just write commands?)

:SOURce<n>:CALibration:RANGNUM
:SOURce<n>:CALibration:SETVALUE
:SOURce<n>:CALibration:MEASVALUE
:SOURce<n>:CALibration:STORE
:SOURce<n>:CALibration:RECALL
:SOURce<n>:CALibration:PRESet
:SOURce<n>:CALibration:DATE
:SOURce<n>:CALibration:HIGHest

On the other hand, according to another post, it's possible to log in using SSH via the debug UART port, and to grab whole file system (including the cal files) in that way. Use jtag for that purpose would be an overkill, imho.

So the next step would be obvious: to enter each CAL command and to check the effect from that action on the data in the calibration file.

BTW I don't have the device but from the debug console log that was provided here early, it seems the FW is based on the very first version of the TI Processor Linux SDK (3.14.26-rt25 kernel, that corresponds to the SDK version 01.00.00 of Apr 2015, the RT patch could be applied later). It's too old and I was not able to find it at TI. A link would be appreciated. Perhaps it'll make sense to explore that sdk as the platform baseline used by Rigol.

[JimKnopf]

Connecting EMU0 and EMU1 on the Compact TI JTAG pin-holes to ground turns on 2 LED's (D2, D3) next to the golden Rigol logo.

I don't know how, but at some point the device booted with chinese text on the display. TurboTom wrote about 4 Boot Modes:

Boot Mode 2, pressing Trig repeadly while booting --> LCD/Button testmode

The DG2052 has the Trig key and also the  Help/Local key as 2nd function on Ramp and Arb key. Can anyone provide a picture of the LCD Test screen please?
Has anyone ever had Chinese characters on the display? They disappeared at the next boot.

[tv84]

The DG2052 has the Trig key and also the  Help/Local key as 2nd function on Ramp and Arb key. Can anyone provide a picture of the LCD Test screen please?
Has anyone ever had Chinese characters on the display? They disappeared at the next boot.

Like this?

[Njk]

I now think the 2x10 pin holes are a Compact TI JTAG pinout.

It must be so, I guess. BTW, for conventional pin count, check Table 13 of SPRU655I "Emulation and Trace Headers" technical reference manual at TI

[JimKnopf]

I played around with jtag port, openocd and some interfaces like:

• Segger Jlink
• TIAO Tumpa
• Olimex ARM USB Tiny-H
• CJMCU-232H

i couldn't get openocd to work with the AM335x target. At the very moment U-Boot loads the kernel, i get errors and the connection is lost and can't get back working. Even reset won't work.

I then tried Segger JLinkCommander. It works like a charm.

Here's the log:

SEGGER J-Link Commander V7.20b (Compiled May 21 2021 17:06:40)
DLL version V7.20b, compiled May 21 2021 17:05:23

Connecting to J-Link via USB...O.K.
Firmware: J-Link V9 compiled May  7 2021 16:26:12
Hardware version: V9.60
S/N: 123456789
License(s): RDI, GDB, FlashDL, FlashBP, JFlash
VTref=3.319V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: AM3352
Type '?' for selection dialog
Device>
Please specify target interface:
  J) JTAG (Default)
  S) SWD
  T) cJTAG
TIF>
Device position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect
JTAGConf>
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "AM3352" selected.


Connecting to target via JTAG
InitTarget() start
TotalIRLen = 6, IRPrint = 0x01
TotalIRLen = 6, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x2B94402F, IRLen: 06, TI ICEPick
AM335x reset: Core did not halt after reset. Halting core manually...
InitTarget() end
TotalIRLen = 10, IRPrint = 0x0011
JTAG chain detection found 2 devices:
 #0 Id: 0x3BA00477, IRLen: 04, CoreSight JTAG-DP
 #1 Id: 0x2B94402F, IRLen: 06, TI ICEPick
DPv0 detected
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[1]: APB-AP (IDR: Not set)
AP[2]: JTAG-AP (IDR: Not set)
Using preconfigured AP[1] as APB-AP
AP[1]: APB-AP found
Found Cortex-A8 r3p2
6 code breakpoints, 2 data breakpoints
Debug architecture ARMv7.0
Data endian: little
Main ID register: 0x413FC082
I-Cache L1: 32 KB, 128 Sets, 64 Bytes/Line, 4-Way
D-Cache L1: 32 KB, 128 Sets, 64 Bytes/Line, 4-Way
Unified-Cache L2: 256 KB, 512 Sets, 64 Bytes/Line, 8-Way
System control register:
  Instruction endian: little
  Level-1 instruction cache enabled
  Level-1 data cache disabled
  MMU disabled
  Branch prediction enabled
Memory zones:
  Zone: Default Description: Default access mode
  Zone: AHB-AP (AP0) Description: DMA like acc. in AP0 addr. space
  Zone: APB-AP (AP1) Description: DMA like acc. in AP1 addr. space
Cortex-A8 identified.
J-Link>
Unknown command. '?' for help.
J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Toggle reset pin and halt CPU core.
ResetTarget() start
AM335x reset: Core did not halt after reset. Halting core manually...
ResetTarget() end
J-Link>h
PC: (R15) = 402F82C8, CPSR = 200001B3 (SVC mode, THUMB IRQ dis.)
Current:
     R0 =80A80000, R1 =00000000, R2 =01000000, R3 =00000000
     R4 =00EF3A40, R5 =80B8C5C4, R6 =00000002, R7 =4030CB7C
     R8 =4030CDCC, R9 =81FFFF28, R10=00029940, R11=00029940, R12=402F0400
     R13=81FFFF14, R14=402F149D, SPSR=0000000A
USR: R8 =4030CDCC, R9 =81FFFF28, R10=00029940, R11=00029940, R12=402F0400
     R13=00000000, R14=00000000
FIQ: R8 =DAF7797B, R9 =A8577F75, R10=55C1FFE0, R11=FB05DFFD, R12=E56D03BE
     R13=00000000, R14=00000000, SPSR=00000000
IRQ: R13=C082B5C0, R14=C05AFD00, SPSR=00000000
SVC: R13=81FFFF14, R14=402F149D, SPSR=00000000
ABT: R13=00000000, R14=00000000, SPSR=00000000
UND: R13=C082B5D8, R14=C05AFD60, SPSR=00000000
J-Link>savebin e:\dump.bin 0x80000000 0x10000000
Opening binary file for writing... [e:\dump.bin]
Reading 268435456 bytes from addr 0x80000000 into file...O.K.
J-Link>

--- Log Beginn ---
T1CE4 000:000.606 SEGGER J-Link V7.20b Log File
T1CE4 000:000.766 DLL Compiled: May 21 2021 17:05:23
T1CE4 000:000.775 Logging started @ 2023-02-19 15:09
T1CE4 000:000.981 JLINK_GetDLLVersion()
T1CE4 000:000.998 - 0.020ms returns 72002
T1CE4 000:001.014 JLINK_GetCompileDateTime()
T1CE4 000:001.022 - 0.011ms
T1CE4 000:001.260 JLINK_SetWarnOutHandler(...)
T1CE4 000:001.275 - 0.019ms
T1CE4 000:001.289 JLINK_OpenEx(...)
T1CE4 000:014.934   Firmware: J-Link V9 compiled May  7 2021 16:26:12
T1CE4 000:015.701   Firmware: J-Link V9 compiled May  7 2021 16:26:12
T1CE4 000:016.115   Decompressing FW timestamp took 346 us
T1CE4 000:024.119   Hardware: V9.60
T1CE4 000:024.154   S/N: 123456789
T1CE4 000:024.167   OEM: SEGGER
T1CE4 000:024.179   Feature(s): RDI, GDB, FlashDL, FlashBP, JFlash
T1CE4 000:026.041   TELNET listener socket opened on port 19021
T1CE4 000:026.261   WEBSRV Starting webserver
T1CE4 000:026.442   WEBSRV Webserver running on local port 19080
T1CE4 000:026.460 - 25.176ms returns "O.K."
T1CE4 000:026.690 JLINK_GetFirmwareString(...)
T1CE4 000:026.709 - 0.022ms
T1CE4 000:027.062 JLINK_GetHardwareVersion()
T1CE4 000:027.094 - 0.036ms returns 96000
T1CE4 000:027.253 JLINK_GetSN()
T1CE4 000:027.269 - 0.019ms returns 69640395
T1CE4 000:027.644 JLINK_GetOEMString(...)
T1CE4 000:027.665 JLINK_EMU_HasCapEx(0x00000026)
T1CE4 000:027.674 - 0.013ms returns 0
T1CE4 000:027.687 JLINK_EMU_GetProductId()
T1CE4 000:027.711 - 0.028ms
T1CE4 000:027.721 JLINK_GetHardwareVersion()
T1CE4 000:027.728 - 0.011ms returns 96000
T1CE4 000:027.738 JLINK_GetFirmwareString(...)
T1CE4 000:027.745 - 0.011ms
T1CE4 000:027.756 JLINK_GetEmuCaps()
T1CE4 000:027.763 - 0.011ms returns 0xB9FF7BBF
T1CE4 000:027.773 JLINK_GetEmuCaps()
T1CE4 000:027.781 - 0.011ms returns 0xB9FF7BBF
T1CE4 000:027.793 JLINK_GetHWStatus(...)
T1CE4 000:028.170 - 0.387ms returns 0
T1CE4 000:028.209 JLINK_EMU_HasCapEx(0x00000044)
T1CE4 000:028.218 - 0.012ms returns 1
T1CE4 000:028.230 JLINK_ReadEmuConfigMem(..., Off = 0x9A, NumBytes = 0x01)
T1CE4 000:028.238 - 0.012ms returns 0
T1CE4 005:329.380 JLINK_Api_MRU_GetList()
T1CE4 005:343.984 - 14.645ms returns 0
T1CE4 005:673.105 JLINK_DEVICE_GetIndex(sDeviceName = AM3352)
T1CE4 005:702.921   XML file found at: C:\Program Files (x86)\SEGGER\JLink\JLinkDevices.xml
T1CE4 005:704.856   C:\Program Files (x86)\SEGGER\JLink\JLinkDevices.xml evaluated successfully.
T1CE4 005:765.143 - 92.058ms returns 7585
T1CE4 005:765.193 JLINK_DEVICE_GetInfo(DeviceIndex = 7585)
T1CE4 005:765.203 - 0.013ms returns 0
T1CE4 006:278.005 JLINK_ConfigJTAG(IRPre = -1, DRPre = -1)
T1CE4 006:278.087 - 0.097ms
T1CE4 006:421.718 JLINK_ExecCommand("device=AM3352", ...).
T1CE4 006:424.416   Device "AM3352" selected.
T1CE4 006:425.789 - 4.026ms returns 0x00
T1CE4 006:425.994 JLINK_EnableLog(...)
T1CE4 006:426.053 - 0.073ms
T1CE4 006:426.720 JLINK_GetEmuCaps()
T1CE4 006:426.779 - 0.074ms returns 0xB9FF7BBF
T1CE4 006:426.827 JLINK_TIF_GetAvailable(...)
T1CE4 006:427.708 - 0.936ms
T1CE4 006:427.846 JLINK_TIF_Select(JLINKARM_TIF_JTAG)
T1CE4 006:431.806 - 4.016ms returns 0x00
T1CE4 006:432.575 JLINK_IsConnected()
T1CE4 006:432.654 - 0.094ms returns FALSE
T1CE4 006:432.725 JLINK_SetSpeed(4000)
T1CE4 006:433.331 - 0.643ms
T1CE4 006:433.407 JLINK_Connect()
T1CE4 006:435.580   InitTarget() start
T1CE4 006:435.684    J-Link Script File: Executing InitTarget()
T1CE4 006:442.563   TotalIRLen = 6, IRPrint = 0x01
T1CE4 006:448.893   TotalIRLen = 6, IRPrint = 0x01
T1CE4 006:451.810   JTAG chain detection found 1 devices:
T1CE4 006:456.453    #0 Id: 0x2B94402F, IRLen: 06, TI ICEPick
T1CE4 006:679.814   AM335x reset: Core did not halt after reset. Halting core manually...
T1CE4 006:688.085   InitTarget() end
T1CE4 006:691.846   TotalIRLen = 10, IRPrint = 0x0011
T1CE4 006:697.466   JTAG chain detection found 2 devices:
T1CE4 006:700.702    #0 Id: 0x3BA00477, IRLen: 04, CoreSight JTAG-DP
T1CE4 006:703.202    #1 Id: 0x2B94402F, IRLen: 06, TI ICEPick
T1CE4 006:712.026   DPv0 detected
T1CE4 006:713.696   AP map detection skipped. Manually configured AP map found.
T1CE4 006:715.166   AP[0]: AHB-AP (IDR: Not set)
T1CE4 006:716.213   AP[1]: APB-AP (IDR: Not set)
T1CE4 006:717.132   AP[2]: JTAG-AP (IDR: Not set)
T1CE4 006:718.262   Using preconfigured AP[1] as APB-AP
T1CE4 006:719.281   AP[1]: APB-AP found
T1CE4 006:727.296   Found Cortex-A8 r3p2
T1CE4 006:728.125   6 code breakpoints, 2 data breakpoints
T1CE4 006:728.775   Debug architecture ARMv7.0
T1CE4 006:752.993   Data endian: little
T1CE4 006:757.482   Main ID register: 0x413FC082
T1CE4 006:782.354   I-Cache L1: 32 KB, 128 Sets, 64 Bytes/Line, 4-Way
T1CE4 006:783.086   D-Cache L1: 32 KB, 128 Sets, 64 Bytes/Line, 4-Way
T1CE4 006:791.590   Unified-Cache L2: 256 KB, 512 Sets, 64 Bytes/Line, 8-Way
T1CE4 006:800.124   System control register:
T1CE4 006:800.847     Instruction endian: little
T1CE4 006:801.383     Level-1 instruction cache enabled
T1CE4 006:803.828     Level-1 data cache disabled
T1CE4 006:804.368     MMU disabled
T1CE4 006:805.123     Branch prediction enabled
T1CE4 006:819.360   -- Max. mem block: 0x00010AA0
T1CE4 006:819.675 - 386.284ms returns 0x00
T1CE4 006:819.718 JLINK_GetIdData(pIdData)
T1CE4 006:821.240   pIdData->ScanLen=10
T1CE4 006:821.264   
T1CE4 006:821.272   pIdData->NumDevices=2
T1CE4 006:821.283   
T1CE4 006:821.291   pIdData->aId[0]=0x3BA00477
T1CE4 006:821.301   
T1CE4 006:821.309   pIdData->aIrRead[0]=0
T1CE4 006:821.320   
T1CE4 006:821.327   pIdData->aScanLen[0]=4
T1CE4 006:821.338   
T1CE4 006:821.346   pIdData->aScanRead[0]=0
T1CE4 006:821.356   
T1CE4 006:821.364 - 1.650ms
T1CE4 006:821.399 JLINK_GetMemZones(...)
T1CE4 006:821.409 - 0.014ms returns 3
T1CE4 006:823.442 JLINK_HasError()
T1CE4 006:823.496 JLINK_CORE_GetFound()
T1CE4 006:823.510 - 0.020ms returns 0x80000FF
T1CE4 051:352.015 JLINK_GetResetTypeDesc
T1CE4 051:352.137 - 0.144ms
T1CE4 051:357.952 JLINK_SetResetDelay(0)
T1CE4 051:358.024 - 0.086ms
T1CE4 051:358.063 JLINK_Reset()
T1CE4 051:437.275   ResetTarget() start
T1CE4 051:437.313    J-Link Script File: Executing ResetTarget()
T1CE4 051:674.793   AM335x reset: Core did not halt after reset. Halting core manually...
T1CE4 051:682.551   ResetTarget() end
T1CE4 051:686.008 - 327.989ms
T1CE4 052:821.106 JLINK_Halt()
T1CE4 052:822.119 - 1.063ms returns 0x00
T1CE4 052:822.240 JLINK_GetDeviceFamily
T1CE4 052:822.270 - 0.044ms returns 8
T1CE4 052:822.307 JLINK_CORE_GetFound()
T1CE4 052:822.335 - 0.040ms returns 0x80000FF
T1CE4 052:822.395 JLINK_ReadRegs(NumRegs = 17, Indexes: 9, 8, 0, 1, 2, 3, 4, 5, 6, 7, 74, 75, 76, 77, 78, 79, 80)
T1CE4 052:826.319    -- R15 (PC)=0x402F82C8, CPSR=0x200001B3, R0=0x80A80000, R1=0x00, R2=0x1000000, R3=0x00, R4=0xEF3A40, R5=0x80B8C5C4, R6=0x02, R7=0x4030CB7C, R8=0x4030CDCC, R9=0x81FFFF28, R10=0x29940, R11=0x29940, R12=0x402F0400, R13=0x81FFFF14, R14=0x402F149D
T1CE4 052:826.460 - 4.079ms returns 0x00
T1CE4 052:826.508 JLINK_ReadRegs(NumRegs = 7, Indexes: 10, 11, 12, 13, 14, 15, 16)
T1CE4 052:826.562    -- R8_USR=0x4030CDCC, R9_USR=0x81FFFF28, R10_USR=0x29940, R11_USR=0x29940, R12_USR=0x402F0400, R13_USR=0x00, R14_USR=0x00
T1CE4 052:826.624 - 0.131ms returns 0x00
T1CE4 052:826.664 JLINK_ReadRegs(NumRegs = 8, Indexes: 18, 19, 20, 21, 22, 23, 24, 17)
T1CE4 052:828.794    -- R8_FIQ=0xDAF7797B, R9_FIQ=0xA8577F75, R10_FIQ=0x55C1FFE0, R11_FIQ=0xFB05DFFD, R12_FIQ=0xE56D03BE, R13_FIQ=0x00, R14_FIQ=0x00, SPSR_FIQ=0x00
T1CE4 052:828.890 - 2.245ms returns 0x00
T1CE4 052:828.943 JLINK_ReadRegs(NumRegs = 3, Indexes: 32, 33, 31)
T1CE4 052:830.465    -- R13_IRQ=0xC082B5C0, R14_IRQ=0xC05AFD00, SPSR_IRQ=0x00
T1CE4 052:830.612 - 1.685ms returns 0x00
T1CE4 052:830.659 JLINK_ReadRegs(NumRegs = 3, Indexes: 26, 27, 25)
T1CE4 052:830.703    -- R13_SVC=0x81FFFF14, R14_SVC=0x402F149D, SPSR_SVC=0x00
T1CE4 052:830.742 - 0.096ms returns 0x00
T1CE4 052:830.831 JLINK_ReadRegs(NumRegs = 3, Indexes: 29, 30, 28)
T1CE4 052:832.277    -- R13_ABT=0x00, R14_ABT=0x00, SPSR_ABT=0x00
T1CE4 052:832.344 - 1.528ms returns 0x00
T1CE4 052:832.389 JLINK_ReadRegs(NumRegs = 3, Indexes: 35, 36, 34)
T1CE4 052:834.090    -- R13_UND=0xC082B5D8, R14_UND=0xC05AFD60, SPSR_UND=0x00
T1CE4 052:834.200 - 1.825ms returns 0x00
T1CE4 055:519.332 JLINK_ReadMemEx(0x80000000, 0x10000000 Bytes, Flags = 0x00000000)
T1CE4 055:520.171   CPU_ReadMem(268435456 bytes @ 0x80000000)
T1CE4 1172:110.284   Data:  63 61 63 68 65 5F 73 65 74 3A 20 63 6F 75 6C 64 ...
T1CE4 1172:110.454 - 1116591.144ms returns 268435456 (0x10000000)
T0808 1415:640.472 JLINK_Close()
T0808 1415:683.188 - 42.770ms
T0808 1415:683.263   
T0808 1415:683.290   Closed
--- Log End ---

The dump.bin file has 268.435.456 bytes of data.
Binwalk shows the content that i expected:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
656           0x290           Unix path: /var/run/nscd/socket
674217        0xA49A9         Certificate in DER format (x509 v3), header length: 4, sequence length: 4610
722893        0xB07CD         Certificate in DER format (x509 v3), header length: 4, sequence length: 1284
1836025       0x1C03F9        Certificate in DER format (x509 v3), header length: 4, sequence length: 4612
2797709       0x2AB08D        Certificate in DER format (x509 v3), header length: 4, sequence length: 4355
3487273       0x353629        Certificate in DER format (x509 v3), header length: 4, sequence length: 3
3487773       0x35381D        Certificate in DER format (x509 v3), header length: 4, sequence length: 3
3489889       0x354061        Certificate in DER format (x509 v3), header length: 4, sequence length: 3
3490121       0x354149        Certificate in DER format (x509 v3), header length: 4, sequence length: 3
3492077       0x3548ED        Certificate in DER format (x509 v3), header length: 4, sequence length: 3
5492153       0x53CDB9        Certificate in DER format (x509 v3), header length: 4, sequence length: 1332
5852517       0x594D65        Certificate in DER format (x509 v3), header length: 4, sequence length: 5376
5936605       0x5A95DD        Certificate in DER format (x509 v3), header length: 4, sequence length: 12291
5984352       0x5B5060        Linux kernel version 3.14.2
5997896       0x5B8548        gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
6213216       0x5ECE60        DES SP2, little endian
6213984       0x5ED160        DES SP1, little endian
6420638       0x61F89E        Unix path: /var/run/rpcbind.sock
6422654       0x62007E        Unix path: /var/run/gssproxy.sock
6511538       0x635BB2        MPEG transport stream data
6512106       0x635DEA        MPEG transport stream data
6512530       0x635F92        MPEG transport stream data
6512554       0x635FAA        MPEG transport stream data
7364304       0x705ED0        Unix path: /home/s/yangao/Sardine/kernel/linux-3.14.26-g2489c02/init/main.c
...
...

[Njk]

The dump.bin file has 268.435.456 bytes of data.

What's the FW version that file is from?

BTW, could you to clarify a couple of more things:
1. There is 3-pin debug UART port on the Core board. What is the power voltage for this port, 1.8V or 3.3V?
2. As far as I understand, the device USB host does not support a USB hubs. So only one host port is available. Is that correct?

[JimKnopf]

@Njk

I use Firmware 2.06 on my DG2052.

The UART has 3,3V. I led the three wires trough the side. For this I have designed a hole lining and printed with a 3D printer. It fits into the hole for the stand and ensures that the cables do not slip inside. So i can use UART when ever i want.

What i read, the Chip supports 2 USB Ports, but only one is exposed in Hostmode.