Author Topic: DG4000 - a firmware investigation  (Read 125180 times)

0 Members and 1 Guest are viewing this topic.

Offline tized

  • Contributor
  • Posts: 34
  • Country: il
Re: DG4000 - a firmware investigation
« Reply #125 on: November 25, 2013, 12:24:31 am »
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/dumpfilestar

Quote
./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)


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.
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 246
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #126 on: November 25, 2013, 12:40:34 am »
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.
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline tized

  • Contributor
  • Posts: 34
  • Country: il
Re: DG4000 - a firmware investigation
« Reply #127 on: November 25, 2013, 02:22:08 am »
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.

Yes, I've found it strange that the target of the LDR is 0x2000_4000. Either they found no reason to change the bootloader, or one of the other blocks with the 0x2000_0000 is the bootloader. The first DXE in LDR thought loads into 0xFFA0_8000.
The CRC is standard CRC32, I just used the bzip.crc32() method (I'm coding my parser in Python), the 'V' beside each CRC means it checks OK.

The header format Rigol used in this firmware goes as follows:

Code: [Select]
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

* - Fields I'm guessing about, not sure yet.
 
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 246
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #128 on: November 25, 2013, 02:35:18 am »
so far i agree only the fields per entry which is offset +0x20 according to your table .. e.g.

Code: [Select]
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.....|

07 = i dont see that used in the code
i do see 0x11 = number of records in the header used - and its read in 0x1C chunks x 0x11 times (which relates to your logic) - where the 07 is used, i no clue so far.

do you work form the assembler code or by studying the file ?

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);
« Last Edit: November 25, 2013, 02:41:31 am by cybernet »
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 246
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #129 on: November 25, 2013, 02:45:12 am »
found it +0x20 is a bitmask, bit 0,1,2,3 are probed and that seems to impact the routine that parses the data chunks and writes them to flash. (loc_1FD6B50)
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline tized

  • Contributor
  • Posts: 34
  • Country: il
Re: DG4000 - a firmware investigation
« Reply #130 on: November 25, 2013, 03:44:57 am »
I don't have any disassembler (yet...), I figured it just by looking at file, reading the Blackfin specs. and reading on this forum. Figuring the code is next, thought I would like to do that for the DS/MSO4k firmware, as my MSO4024 should be getting here this week.
 

Offline jboard146

  • Contributor
  • Posts: 36
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #131 on: November 25, 2013, 05:00:18 am »
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 to accept this type of serial #. I only did a find/replace and didn't put any logic in the code to accept both.
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #132 on: November 25, 2013, 05:57:23 am »
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 »
http://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.
 

Offline aurel

  • Contributor
  • Posts: 7
  • Country: fr
Re: DG4000 - a firmware investigation
« Reply #133 on: November 25, 2013, 07:32:44 am »
@cybernet

First a huge thanks for all your work, especially the DS2000 keygen (which my DS2072 enjoyed) and now the DG4000 (I was lurking at a DG4062, this might help convince me even more).

Regarding cengen, as others already reported, it errors out with "invalid <CURRENT_MODEL> len" even with correct parameters.
This is due to a bug in strtoupper() that was also present in your initial DS2000 keygen. The following line has undefined behavior:
Code: [Select]
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:
Code: [Select]
$ gcc --version
gcc (Debian 4.8.2-5) 4.8.2
It is easily fixed with:
Code: [Select]
while ((*p = toupper(*p)))  p++;
I suggest you fix the strtoupper() implementation that you use in various pieces of code.

Anyway, very good job !
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #134 on: November 25, 2013, 08:08:33 pm »
http://www.filedropper.com/dumpfilestar
I 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

Thanks, Anders.  Not sure what was going on the first time, but based on your report, I just gave it another try and it came down fine.   :-+
 

Offline monster

  • Contributor
  • Posts: 5
Re: DG4000 - a firmware investigation
« Reply #135 on: November 28, 2013, 12:26:31 am »
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
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 568
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #136 on: November 28, 2013, 12:33:38 am »
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
Allowing D and E isn't enough, as elCap already reported earlier in this topic having one with a serial number starting with DG4B1:
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!! :-+
 

Offline monster

  • Contributor
  • Posts: 5
Re: DG4000 - a firmware investigation
« Reply #137 on: November 28, 2013, 01:57:09 am »
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 [..]
So why not try 's/DG4D1/DG4B1/g'? It's a no brainer for testing. For this purpose one could also just comment this line:

Code: [Select]
if (strncmp(cur_serial,"DG4D1", strlen("DG4D1"))) { printf("invalid <CURRENT_SERIAL> type\n"); help(); }

as a quick&dirty variant to see if the signal generator would load this file with different serials. I think it's at least worth a try, since it's only a serial number, not a change of hardware or firmware.

But I should add that haven't really fully read and therefor understood the routines in cengen.c yet, so I can't say anything why Cybernet initially put in the limitation to DG4D**** serials. The only reason I could think of for now is a lack of time/interest to test other units. So he released something that he knew was pretty likely working on this specific branch of devices. Anything else would then be the resonsibility of potential DG4$OTHER_LETTERS owners. That's also why I wanted to contribute my findings with my personal DG4E1**** unit.

LG Daniel
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 460
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #138 on: November 28, 2013, 02:43:03 am »
This D,B or E doesn't seem to change the hardware version so it may just be a production time indicator of the same hardware....
Unless someone knows better?
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 246
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #139 on: November 28, 2013, 03:23:56 am »
the serial gets compared to the current one - and the serial gets written (in case of change serial).
i actually used DG4D000DEADBEEF once not thinking if it likes hex at all ;-) but it worked - but i would not completely skip the DS4 thing, could be it dislikes that (bootup process does something with serial num)
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #140 on: December 04, 2013, 03:19:21 am »
DG4000 Arbitrary Function Generator - 121 VAC Power Consumption:

Measurements are considered approximate due to uncertainty of measurement equipment accuracy, although should be very useful as general figure of merit.

Standby  Mode (AC plugged in, OFF)
   W   0.5
   VA    7
   A    0.06
   PF  0.15

Operating Mode (Power ON)
   W     17
   VA   35
   A      0.3
   PF    0.47
« Last Edit: December 04, 2013, 03:28:59 am by ted572 »
 

Offline Avotronics

  • Regular Contributor
  • *
  • Posts: 58
  • Country: gb
    • Rigol Hacks
Re: DG4000 - a firmware investigation
« Reply #141 on: December 04, 2013, 08:17:19 pm »
Anyone got Firmware 00.01.07.00.03 ?
The one in this topic is saying corrupt by winrar.
Why would you buy something ready made when you can make it yourself with half the features for twice the money!
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 568
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #142 on: December 04, 2013, 08:40:28 pm »
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.org

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
« Last Edit: December 04, 2013, 09:05:51 pm by AndersAnd »
 

Offline Avotronics

  • Regular Contributor
  • *
  • Posts: 58
  • Country: gb
    • Rigol Hacks
Re: DG4000 - a firmware investigation
« Reply #143 on: December 04, 2013, 09:02:38 pm »
corrupt by winrar.
I got same error, you need a newer winzip.exe program .

Newer!!  :wtf:
I have the latest winrar, I'm always suspicious if winrar can't open it.
Why would you buy something ready made when you can make it yourself with half the features for twice the money!
 

Offline Avotronics

  • Regular Contributor
  • *
  • Posts: 58
  • Country: gb
    • Rigol Hacks
Re: DG4000 - a firmware investigation
« Reply #144 on: December 04, 2013, 09:07:27 pm »
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.org

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

Cheers, got that okay.
Why would you buy something ready made when you can make it yourself with half the features for twice the money!
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #145 on: December 04, 2013, 10:17:24 pm »
Before installing FW 00.01.07.00.03 see 'Rigol DG4xxx ppulse and npulse' at:  http://www.eevblog.com/forum/testgear/rigol-dg4xxx-ppulse-and-npulse/msg314511/#lastPost

The latest version of WinRAR (5.01) was released about 2 days ago, but I do not know if it will work any better. Or use WinZip to unpack the newer FW file if you decide to install it.

By the way FW 00.01.07.00.03 also updates the FPGA.
 
« Last Edit: December 04, 2013, 11:00:32 pm by ted572 »
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 568
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #146 on: December 04, 2013, 10:26:43 pm »
The latest version of WinRAR (5.01) wast released about 2 days ago.
The uploaded Zip-archive won't unzip with the latest WinRAR 5.01 either.
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 568
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #147 on: December 04, 2013, 10:30:25 pm »
Before installing FW 00.01.07.00.03 see 'Rigol DG4xxx ppulse and npulse' at:  http://www.eevblog.com/forum/testgear/rigol-dg4xxx-ppulse-and-npulse/msg314511/#lastPost
But is this bug only related in FW 00.01.07.00.03?
Isn't the same bug in older firmwares too?
 

Offline Avotronics

  • Regular Contributor
  • *
  • Posts: 58
  • Country: gb
    • Rigol Hacks
Re: DG4000 - a firmware investigation
« Reply #148 on: December 04, 2013, 10:38:47 pm »
I've repackaged the firmwares into fresh zips with winrar 5.01 as I had trouble with one of the other firmwares too.
Not sure what (whoever) is using to zip them originally but something isn't right.

http://rigol.avotronics.co.uk/dg4000-series/
Why would you buy something ready made when you can make it yourself with half the features for twice the money!
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 324
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #149 on: December 05, 2013, 12:15:42 am »
I'm looking into determining what is involved in calibrating the DG4000 to produce a constant (flat) sine wave output level up to 200 MHz.  Although my DG4000 is essentially flat up to about 120 MHz (-1 dB), I would like it ti be flat up through 200 MHz +/- 1 dB or better.

I have provided a listing of all of the Calibration Steps for the DG4000 in the attachment 'DG4000 Calibration Menu Items.doc' (preliminary version).  Hopefully the task can be accomplished primarily by making adjustments to the upper steps in Item 3., High Freq Flat/HFLATth.

I will be working on developing a calibration procedure to accomplish this task.
« Last Edit: December 09, 2013, 08:07:34 am by ted572 »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf