@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.
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
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..
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.
@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.
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.
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.
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.
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.
@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#msg3244488MY DG2052 UART log:
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.
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
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:
> 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
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).
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
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?
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.
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?
Does Rigel dc820 have a fixed and stable output up to two to three decimal places?
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.
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.
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
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
...
...
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?
@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.