just reversed the crc on the firmware files for the DG4000 ;-)
its actually a packaging format, that contains multiple segments which get loaded into the flash then (the loader addresses are still a bit off) anyhow i attach a link to the splitted files.
the big 2MB file is the main code - u can load it into LDRViewer and it dismantle it without a hitch, other stuff are help system files, etc ..
so theoretically it should now be possible to modify code, stuff it back together, crc it - and flash it ;-)
http://www.filedropper.com/dumpfilestarQuote./gelfile ./DG4000Update.GEL
hdr_buf: RIGOL:DG4:UPDATE FILE ALL
fwr: CRC:7A57 ADDR:20040000 LEN:00228EF0 00000004 00000004
-> dumped dump_20040000.bin (2264816 bytes)
fwr: CRC:8CE7 ADDR:20300000 LEN:000C3DF6 00000008 00000008
-> dumped dump_20300000.bin (802294 bytes)
fwr: CRC:8C44 ADDR:20400000 LEN:00001661 00000008 00000008
-> dumped dump_20400000.bin (5729 bytes)
fwr: CRC:0611 ADDR:20440000 LEN:00000252 00000010 00000010
-> dumped dump_20440000.bin (594 bytes)
fwr: CRC:8845 ADDR:20440400 LEN:00002855 00000010 00000010
-> dumped dump_20440400.bin (10325 bytes)
fwr: CRC:D973 ADDR:20443400 LEN:00000252 00000010 00000010
-> dumped dump_20443400.bin (594 bytes)
fwr: CRC:BDC8 ADDR:20443800 LEN:000019FE 00000010 00000010
-> dumped dump_20443800.bin (6654 bytes)
fwr: CRC:8570 ADDR:20460000 LEN:00000206 00000010 00000010
-> dumped dump_20460000.bin (518 bytes)
fwr: CRC:3CB3 ADDR:20460400 LEN:0000F081 00000010 00000010
-> dumped dump_20460400.bin (61569 bytes)
fwr: CRC:D5A9 ADDR:2046FC00 LEN:00000206 00000010 00000010
-> dumped dump_2046fc00.bin (518 bytes)
fwr: CRC:0259 ADDR:20470000 LEN:000091B6 00000010 00000010
-> dumped dump_20470000.bin (37302 bytes)
fwr: CRC:219D ADDR:205B0000 LEN:00169DE8 00000020 00000020
-> dumped dump_205b0000.bin (1482216 bytes)
fwr: CRC:A299 ADDR:207B0000 LEN:0003D6C4 00000040 00000040
-> dumped dump_207b0000.bin (251588 bytes)
fwr: CRC:63BD ADDR:20830000 LEN:0004BB9C 00000040 00000040
-> dumped dump_20830000.bin (310172 bytes)
fwr: CRC:0000 ADDR:209B0000 LEN:00480000 00000080 00000080
-> dumped dump_209b0000.bin (2097152 bytes)
-> dumped dump_20bb0000.bin (2097152 bytes)
-> dumped dump_20db0000.bin (524288 bytes)
Device: DS2202
Version: 00.01.00.00.03
| No. | Size (B) | Location | Target | CRC | Type | Dev. B_A |
|-----|------------|------------|------------|----------------|------|-----------|
| 1 | 0x00378f9c | 0x00000220 | 0x20040000 | 0x27e9427e (V) | 0 | 0x00_0x01 |
| 2 | 0x0017cca8 | 0x003791bc | 0x20000000 | 0x5a3ac3c3 (V) | 6 | 0x00_0x05 |
| 3 | 0x00010f60 | 0x004f5e64 | 0x20000000 | 0x52c1a46b (V) | 2 | 0x00_0x0a |
| 4 | 0x000321aa | 0x00506dc4 | 0x20020000 | 0x6c49f38a (V) | 2 | 0x00_0x0b |
| 5 | 0x0000245a | 0x00538f6e | 0x200d6000 | 0xcd2a7325 (V) | 2 | 0x00_0x0c |
| 6 | 0x00007fb4 | 0x0053b3c8 | 0x200c8000 | 0x4cac7870 (V) | 4 | 0x00_0x0e |
| 7 | 0x000663f4 | 0x0054337c | 0x200f0000 | 0x454d5a80 (V) | 4 | 0x00_0x0f |
| 8 | 0x00001d54 | 0x005a9770 | 0x20120000 | 0xbcb8589e (V) | 2 | 0x00_0x10 |
| 9 | 0x0006dc62 | 0x005ab4c4 | 0x20000000 | 0x885a8c98 (V) | 4 | 0x00_0x11 |
| 10 | 0x000032d8 | 0x00619126 | 0x20040000 | 0xb7481d18 (V) | 3 | 0x00_0x13 |
| 11 | 0x00000b64 | 0x0061c3fe | 0x20000000 | 0xd2b695f5 (V) | 5 | 0x00_0x14 |
| 12 | 0x0003c598 | 0x0061cf62 | 0x20000c00 | 0x3f1c1bcc (V) | 5 | 0x00_0x15 |
| 13 | 0x00000118 | 0x006594fa | 0x201e4c00 | 0x1af2df9d (V) | 5 | 0x00_0x15 |
| 14 | 0x00009010 | 0x00659612 | 0x2003d400 | 0x550735a2 (V) | 5 | 0x00_0x15 |
| 15 | 0x00001661 | 0x00662622 | 0x201fd800 | 0x5161cee1 (V) | 3 | 0x00_0x15 |
| 16 | 0x000bb808 | 0x00663c83 | 0x20045000 | 0x4b530b40 (V) | 3 | 0x00_0x15 |
| 17 | 0x00046ef0 | 0x0071f48b | 0x20100000 | 0x52c4edfb (V) | 7 | 0x00_0x15 |
| 18 | 0x00000000 | 0x0076637b | 0x20122800 | 0x00000000 (V) | 2 | 0x00_0x32 |
|-----|------------|------------|------------|----------------|------|-----------|
Funny thing, I've just done the same for the DS2000 firmware and this is what I got:Code: [Select]Device: DS2202
Version: 00.01.00.00.03
| No. | Size (B) | Location | Target | CRC | Type | Dev. B_A |
|-----|------------|------------|------------|----------------|------|-----------|
| 1 | 0x00378f9c | 0x00000220 | 0x20040000 | 0x27e9427e (V) | 0 | 0x00_0x01 |
| 2 | 0x0017cca8 | 0x003791bc | 0x20000000 | 0x5a3ac3c3 (V) | 6 | 0x00_0x05 |
| 3 | 0x00010f60 | 0x004f5e64 | 0x20000000 | 0x52c1a46b (V) | 2 | 0x00_0x0a |
| 4 | 0x000321aa | 0x00506dc4 | 0x20020000 | 0x6c49f38a (V) | 2 | 0x00_0x0b |
| 5 | 0x0000245a | 0x00538f6e | 0x200d6000 | 0xcd2a7325 (V) | 2 | 0x00_0x0c |
| 6 | 0x00007fb4 | 0x0053b3c8 | 0x200c8000 | 0x4cac7870 (V) | 4 | 0x00_0x0e |
| 7 | 0x000663f4 | 0x0054337c | 0x200f0000 | 0x454d5a80 (V) | 4 | 0x00_0x0f |
| 8 | 0x00001d54 | 0x005a9770 | 0x20120000 | 0xbcb8589e (V) | 2 | 0x00_0x10 |
| 9 | 0x0006dc62 | 0x005ab4c4 | 0x20000000 | 0x885a8c98 (V) | 4 | 0x00_0x11 |
| 10 | 0x000032d8 | 0x00619126 | 0x20040000 | 0xb7481d18 (V) | 3 | 0x00_0x13 |
| 11 | 0x00000b64 | 0x0061c3fe | 0x20000000 | 0xd2b695f5 (V) | 5 | 0x00_0x14 |
| 12 | 0x0003c598 | 0x0061cf62 | 0x20000c00 | 0x3f1c1bcc (V) | 5 | 0x00_0x15 |
| 13 | 0x00000118 | 0x006594fa | 0x201e4c00 | 0x1af2df9d (V) | 5 | 0x00_0x15 |
| 14 | 0x00009010 | 0x00659612 | 0x2003d400 | 0x550735a2 (V) | 5 | 0x00_0x15 |
| 15 | 0x00001661 | 0x00662622 | 0x201fd800 | 0x5161cee1 (V) | 3 | 0x00_0x15 |
| 16 | 0x000bb808 | 0x00663c83 | 0x20045000 | 0x4b530b40 (V) | 3 | 0x00_0x15 |
| 17 | 0x00046ef0 | 0x0071f48b | 0x20100000 | 0x52c4edfb (V) | 7 | 0x00_0x15 |
| 18 | 0x00000000 | 0x0076637b | 0x20122800 | 0x00000000 (V) | 2 | 0x00_0x32 |
|-----|------------|------------|------------|----------------|------|-----------|
The 'Type' and 'Device' fields are not verified, just my guess. The first block is the LDR and the second is for the FPGAs.
All the 'Type' 2 blocks seem to be more application code.
Funny thing, I've just done the same for the DS2000 firmware and this is what I got:Code: [Select]Device: DS2202
Version: 00.01.00.00.03
| No. | Size (B) | Location | Target | CRC | Type | Dev. B_A |
|-----|------------|------------|------------|----------------|------|-----------|
| 1 | 0x00378f9c | 0x00000220 | 0x20040000 | 0x27e9427e (V) | 0 | 0x00_0x01 |
| 2 | 0x0017cca8 | 0x003791bc | 0x20000000 | 0x5a3ac3c3 (V) | 6 | 0x00_0x05 |
| 3 | 0x00010f60 | 0x004f5e64 | 0x20000000 | 0x52c1a46b (V) | 2 | 0x00_0x0a |
| 4 | 0x000321aa | 0x00506dc4 | 0x20020000 | 0x6c49f38a (V) | 2 | 0x00_0x0b |
| 5 | 0x0000245a | 0x00538f6e | 0x200d6000 | 0xcd2a7325 (V) | 2 | 0x00_0x0c |
| 6 | 0x00007fb4 | 0x0053b3c8 | 0x200c8000 | 0x4cac7870 (V) | 4 | 0x00_0x0e |
| 7 | 0x000663f4 | 0x0054337c | 0x200f0000 | 0x454d5a80 (V) | 4 | 0x00_0x0f |
| 8 | 0x00001d54 | 0x005a9770 | 0x20120000 | 0xbcb8589e (V) | 2 | 0x00_0x10 |
| 9 | 0x0006dc62 | 0x005ab4c4 | 0x20000000 | 0x885a8c98 (V) | 4 | 0x00_0x11 |
| 10 | 0x000032d8 | 0x00619126 | 0x20040000 | 0xb7481d18 (V) | 3 | 0x00_0x13 |
| 11 | 0x00000b64 | 0x0061c3fe | 0x20000000 | 0xd2b695f5 (V) | 5 | 0x00_0x14 |
| 12 | 0x0003c598 | 0x0061cf62 | 0x20000c00 | 0x3f1c1bcc (V) | 5 | 0x00_0x15 |
| 13 | 0x00000118 | 0x006594fa | 0x201e4c00 | 0x1af2df9d (V) | 5 | 0x00_0x15 |
| 14 | 0x00009010 | 0x00659612 | 0x2003d400 | 0x550735a2 (V) | 5 | 0x00_0x15 |
| 15 | 0x00001661 | 0x00662622 | 0x201fd800 | 0x5161cee1 (V) | 3 | 0x00_0x15 |
| 16 | 0x000bb808 | 0x00663c83 | 0x20045000 | 0x4b530b40 (V) | 3 | 0x00_0x15 |
| 17 | 0x00046ef0 | 0x0071f48b | 0x20100000 | 0x52c4edfb (V) | 7 | 0x00_0x15 |
| 18 | 0x00000000 | 0x0076637b | 0x20122800 | 0x00000000 (V) | 2 | 0x00_0x32 |
|-----|------------|------------|------------|----------------|------|-----------|
The 'Type' and 'Device' fields are not verified, just my guess. The first block is the LDR and the second is for the FPGAs.
All the 'Type' 2 blocks seem to be more application code.
nize stuff, im also looking into the DS2000 atm - but you are a step ahead as it seems.
for the DG the bootloader stream is in 0x2000 0000 - the application is in 0x2000 4000 - looking at your GEL listing, i would assume its the same with the DS2k.
the bootloaders gets overwritten during boot (0xffa0 0000 segment) and in the 0x0-0x01fff ffff range so best to dump it while it sits in the bootloader ...
did u already find/implement the CRC check ? looks different then the DG one.
16 Bytes - MSB first - ASCII - Device name
16 Bytes - MSB first - ASCII - Version number
4 Bytes - LSB first - UInt - Fields per entry (Each field is 32b UInt, LSB first)
4 Bytes - LSB first - UInt - Number of entries
List of block descriptor entries, each entry with the following fields:
SIZE - Number of bytes in block
LOCATION - Offset to the block in the .GEL file
CRC - Standard CRC32
TYPE* - Some kind of type code
TARGET - Target address
CODE_A* - Looks like device code
CODE_B* - Always 0
00000000 44 53 32 32 30 32 00 00 00 00 00 00 00 00 00 00 |DS2202..........|
00000010 30 30 2e 30 30 2e 30 31 2e 30 30 2e 30 35 00 00 |00.00.01.00.05..|
00000020 [color=orange]07 00 00 00[/color] [color=red]11 00 00 00[/color] b4 3d 31 00 04 02 00 00 |.........=1.....|
loc_1FD6B0A: R0 = [P5]; // P5 = ptr to file handle P1 = [FP -0x8]; // P1 = ptr to file data buffer (containing first 0x28 bytes) R2 = [P1 + 0x24]; R2 *= R7; // R7 =0x1C CALL FILE_fread_sub_1FF0982; [FP -0x4] = R0; CC = (R0 == -0x1); |
Subject: Getting a newer FPGA version for DG4000.
I have a new DG4000 that I just received a week ago, but I have been seeing posts from people with older units that have more current software/firmware.
This is my 'System Info': Device Model - DG4062, Serial Number - DG4D152xxxxxx, Software (I believe we generally refer to this as Firmware (?) ) - 00.01.06.00.02, FPGA* - 00.01.07.09, Hard - 01.03, Keyboard - 05.01, and Enc FPGA – 06
My concern is with the FPGA* version, which for me is 00.01.07.09, because I see that some other owners have version 00.01.08.xx. Is there anyway for me to upgrade to the FPGA version 00.01.08.xx? Is the FPGA Firmware every included, or is it even possible to be provided along with a newer Software/Firmware version from Rigol?I installed FW update 00.01.07.00.03 with some hesitation due to it having a couple serious bugs, but I decided that it would be worth it to find out if it had a FPGA update embedded in it or not. It did, now I have Software Ver. 00.01.07.00.03, as well as FPGA Ver. 00.01.08.03. So now I'm happy to have my unit up to date. I'll just wait for Rigol to release the next version of software to correct the flaws in 07.
Reference the following for info on Software 07 bugs:
Re: Rigol DG4xxx ppulse and npulse
« Reply #5 on: October 22, 2013, 09:25:30 PM »
https://www.eevblog.com/forum/testgear/rigol-dg4xxx-ppulse-and-npulse/
Rigol confirmed it is a bug.This update also fully resolved the problem I was having with the DG4000 Screen Saver. Where as before it would be flaky about 20% of the time, although it did still blanked the screen.
while ((*p++ = toupper(*p)));
So it might work or not, depending on the compiler/version/arch... It doesn't work with the compiler I use:$ gcc --version
gcc (Debian 4.8.2-5) 4.8.2
It is easily fixed with:while ((*p = toupper(*p))) p++;
http://www.filedropper.com/dumpfilestarI may be doing something wrong, but I believe it says the linked file is 0 kB?Just checked, works fine for me. Filezize: 9.740 kB
I've got a "new" DG4062 and it has a serial # with an "E" not a "D" in the 4th char. I had to modify the src [..]
I've got a "new" DG4062 and it has a serial # with an "E" not a "D" in the 4th char. I had to modify the src [..]So I was too slow ... just did more or less the same thing and came back here to post it also works with the 'E'-type serials. I believe it might be ok to allow both variants in the original source by Cybernet. Until then a 's/DG4D1/DG4E1/g' will do the job as well.
LG Daniel
I'm unlucky ... I have a DG4102 with a serial number starting with DG4B1. cybernet's program requires DG4D1..
Guess I have to take the JTAG route.. Anyway, thanks for your work!!
I've got a "new" DG4062 and it has a serial # with an "E" not a "D" in the 4th char. I had to modify the src [..]So I was too slow ... just did more or less the same thing and came back here to post it also works with the 'E'-type serials. I believe it might be ok to allow both variants in the original source by Cybernet. Until then a 's/DG4D1/DG4E1/g' will do the job as well.Allowing D and E isn't enough, as elCap already reported earlier in this topic having one with a serial number starting with DG4B1 [..]
if (strncmp(cur_serial,"DG4D1", strlen("DG4D1"))) { printf("invalid <CURRENT_SERIAL> type\n"); help(); }
Anyone got Firmware 00.01.07.00.03 ?
The one in this topic is saying corrupt by winrar.
Nice work Cybernet!
Attached is the latest firmware (00.01.07.00.03)This file gives an error when trying to extract? (only empty folders)
edit: it does work with 7zip, not with winRAR or Windows 7 zip, Thanks for sharing
corrupt by winrar.I got same error, you need a newer winzip.exe program .
Anyone got Firmware 00.01.07.00.03 ?
The one in this topic is saying corrupt by winrar.Try to extract the zip-archive online here, it looks like this works: http://b1.org/online
Edit: I have unzipped it online here, where you can download the .GEL file: http://wobzip.org/file/aWTQIIIQ
The file will only be kept by Wobzip for 3 days.
"Download as zip" doesn't work for this file, but you can zip it in WinRAR once downloaded.
Otherwise you can install 7zip, this seems to work with this archive. But if you don't want to install another zip archiver, try the online tool first.
B1 also have an installable zip archiver: http://b1.orgNice work Cybernet!
Attached is the latest firmware (00.01.07.00.03)This file gives an error when trying to extract? (only empty folders)
edit: it does work with 7zip, not with winRAR or Windows 7 zip, Thanks for sharing
The latest version of WinRAR (5.01) wast released about 2 days ago.
Before installing FW 00.01.07.00.03 see 'Rigol DG4xxx ppulse and npulse' at: https://www.eevblog.com/forum/testgear/rigol-dg4xxx-ppulse-and-npulse/msg314511/#lastPost