Here are links to DG4062 firmware (.GEL files), in case it is helpful to this effort :)
00.01.04.00.02 (http://ul.to/e37bkxqu) (date: 6/13/2012)
00.01.06.00.02 (http://ul.to/6oyygxer) (date: 5/9/2013)
ROM:CB1924 aDg4052_0: ascii "DG4052",0
ROM:CB192C aDg4062_5: ascii "DG4062",0
ROM:CB1934 aDg4072_1: ascii "DG4072",0
ROM:CB193C aDg4102_0: ascii "DG4102",0
ROM:CB1944 aDg4162_0: ascii "DG4162",0
ROM:CB194C aDg4072e_0: ascii "DG4072E",0
ROM:CB1954 aDg4202_0: ascii "DG4202",0
ROM:CB195C aDg4072a_0: ascii "DG4072A",0
ROM:CB1964 aDg4102a_0: ascii "DG4102A",0
ROM:CB196C aDg4162a_0: ascii "DG4162A",0
ROM:CB1974 aDg4202a_0: ascii "DG4202A",0
ROM:CB197C aDg4102e_0: ascii "DG4102E",0
Were you also able to measure if the rise/fall time changed after you changed your 60MHz to 160/200MHz?
If it takes the information from a file you provide, it sounds like it could be possible to update the model through a hidden menu with a crypto-signed file on a USB stick. (I don't know, I haven't looked through the firmware.)
Once I get time to play with my DG4000, I can put it on my HP 5335A 200Mhz counter (with Rubidium reference) to check rise/fall/amplitude.
Once I get time to play with my DG4000, I can put it on my HP 5335A 200Mhz counter (with Rubidium reference) to check rise/fall/amplitude.
PM3082 (CRO) and DS2 show slightly below 5ns risetime/falltime for a 50mhz square wave
Will your "DG4202" go a bit higher in frequency limit than the 4162 in the square (50MHz), ramp (4MHz), pulse 40MHz) and harmonic (80MHz) modes ?
Nice work Cybernet! :-+
Attached is the latest firmware (00.01.07.00.03)
Nice work Cybernet! :-+This file gives an error when trying to extract? (only empty folders)
Attached is the latest firmware (00.01.07.00.03)
So could you PM me the exact steps you took to do this, including the data. I'm looking to buy a DG4062 with some surplus birthday money.
Hmm, I have a Keil uLink 2 JTAG handy; it only works with Keil uVision IDE as far as I know. Is it possible to do whatever needs to be done using Keil tools?
Hmm, I have a Keil uLink 2 JTAG handy; it only works with Keil uVision IDE as far as I know. Is it possible to do whatever needs to be done using Keil tools?
should work according to this list
http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=Cables (http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=Cables)
the gnu blackfin toolkit uses urjtag as basis for its gdb proxy.
To avoid hassles, I've just bought the Amontec JTAGkey-Tiny; the shipping is more than the device which is just nuts,
I'll report back when I've got it.
Why not this other? http://www.seeedstudio.com/depot/bus-blaster-v4-p-1416.html (http://www.seeedstudio.com/depot/bus-blaster-v4-p-1416.html)
I'll report back when I've got it.
good luck! as i ordered my second jtag key (2) i had to make some presure over good known german forum to get any response from them. That was 2011, but it looks like others have still similar issues
https://forum.sparkfun.com/viewtopic.php?f=18&t=27090 (https://forum.sparkfun.com/viewtopic.php?f=18&t=27090)
I might just buy an eBay cheapie. Shipping for this thing is RIDICULOUS. :bullshit:
I might just buy an eBay cheapie. Shipping for this thing is RIDICULOUS. :bullshit:
I might just buy an eBay cheapie. Shipping for this thing is RIDICULOUS. :bullshit:
An eBay cheapie ... I wonder if something like this would work? http://www.ebay.com/itm/Ulink-2-USB-JTAG-Emulator-ARM9-Cortex-Keil-Ulink-II-GH2-White-Adapter-Debug-S9-/251317410028?pt=LH_DefaultDomain_0&hash=item3a83af58ec (http://www.ebay.com/itm/Ulink-2-USB-JTAG-Emulator-ARM9-Cortex-Keil-Ulink-II-GH2-White-Adapter-Debug-S9-/251317410028?pt=LH_DefaultDomain_0&hash=item3a83af58ec)
I might just buy an eBay cheapie. Shipping for this thing is RIDICULOUS. :bullshit:
An eBay cheapie ... I wonder if something like this would work? http://www.ebay.com/itm/Ulink-2-USB-JTAG-Emulator-ARM9-Cortex-Keil-Ulink-II-GH2-White-Adapter-Debug-S9-/251317410028?pt=LH_DefaultDomain_0&hash=item3a83af58ec (http://www.ebay.com/itm/Ulink-2-USB-JTAG-Emulator-ARM9-Cortex-Keil-Ulink-II-GH2-White-Adapter-Debug-S9-/251317410028?pt=LH_DefaultDomain_0&hash=item3a83af58ec)
I doubt it'll work --- it's a fraud Keil uLink2, so it's "designed" to replicate the uLink2, which is not listed as compatible with UrJTAG. But, if you want to give it a shot....
Amontec have stolen my money...no tracking number from my order with them yet...and they don't reply to my email! :--
I have the Bus Blaster v3. Unless they've made improvements in speed, it's *very* slow.
Geezzz, hope they've improved shipping since then! For the $80USD it cost (incl. shipping) I expect it by the end of this week!
Amontec have stolen my money...no tracking number from my order with them yet...and they don't reply to my email! :--
Download the bf-linux toolkit.This?
i will writeup a howto shorty, but atm im rather busy, so expect it coming week.
in the meantime see if u get jtag to fly - and ida pro the bf plugin - forget openocd, download the bf-linux toolkit.
to test jtag run
./bfin-gdbproxy --debug bfin --frequency=6000000
if it finds the BF, then u are good to go.
Sparky, maybe this will be useful:
http://www.topjtag.com/flash-programmer/ (http://www.topjtag.com/flash-programmer/)
Well, it's good to know more tools I can use with the Amontec JTAG, but for now I'm following our local expert cybernet's advice --- it's my first experience with JTAG so I'm kinda tip-toeing around!
Continuing on with the matter...before I've hooked the JTAG up, I've done a little reading of the usual ADI JTAG interface, and also cybernet's earlier info about it (posted here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg241335/#msg241335)).
I attached a snippet of schematic from ADSP-BF526 ezboard manual, which shows JTAG with similar pinout as cybernet's schematic (in post 1 of this thread). Also see the Analog EE Note-68 which includes a bunch of example JTAG configurations, and from which it can be seen the conflicting pin 1 = GND for the usual ADI JTAG which cybernet cautions about in his post linked above.
My next task should be to hook things up :)
I realize this is not a DS4000 BW tread but I hope it can be viewed as close enough to investigating the DG4000 that I can ask some DS4000 things too.
Well, it's good to know more tools I can use with the Amontec JTAG, but for now I'm following our local expert cybernet's advice --- it's my first experience with JTAG so I'm kinda tip-toeing around!
Continuing on with the matter...before I've hooked the JTAG up, I've done a little reading of the usual ADI JTAG interface, and also cybernet's earlier info about it (posted here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg241335/#msg241335)).
I attached a snippet of schematic from ADSP-BF526 ezboard manual, which shows JTAG with similar pinout as cybernet's schematic (in post 1 of this thread). Also see the Analog EE Note-68 which includes a bunch of example JTAG configurations, and from which it can be seen the conflicting pin 1 = GND for the usual ADI JTAG which cybernet cautions about in his post linked above.
My next task should be to hook things up :)
Any progress on this?
It says:Hmm, I have a Keil uLink 2 JTAG handy; it only works with Keil uVision IDE as far as I know. Is it possible to do whatever needs to be done using Keil tools?
should work according to this list
http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=Cables (http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=Cables)
the gnu blackfin toolkit uses urjtag as basis for its gdb proxy.
Appearance of a cable in the list here doesn't mean that it's supported yet by UrJTAG. For a list of supported cables, please have a look at the actual Documentation (http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=Documentation)Keil is not on this list named "Supported JTAG adapters/cables":
** ____ ______________ ___ __
** / __ \/_ __/ ____/ |/ / / /
** / /_/ / / / / /_ / /|_/ / / /
** / _, _/ / / / __/ / / / / /_/
** /_/ |_| /_/ /_/ /_/ /_/ (_)
**
** this tool generates a new model type (DG4XXX) & serial (DG4D1XXXXXXXX) string,
** calculates a MAC and creates a .CEN file.
**
** what to do with the file ?
**
** put it on an USB stick, plug stick into DG4000, goto "Store", browse USB Stick,
** change "File Type" to "All File", navigate to your .CEN file, press "Read".
**
** You should get a Popup telling you that you successfully changed your model type and serial
**
** if *not* you:
** used a wrong current model type
** used a wrong current serial
** used an invalid new model type
** used an invalid new serial
**
**
** firmware tested:
** 00.01.06
** 00.01.03
**
**
** no warranties, if it explodes, your problem ;-)
**
So, once you install this, how does it compare to the native DG4164? Calibration? (I've been one of those holding out until this hack appears... Thanks Cybernet!)
I have no Linux :-(Not a valid excuse, if you have an internet connection...
./cengen DG4062 DG4162 DG4D123456789
correct?Amazing job Cybernet... 8)
Anywho, I've compiled it fine on Ubuntu 13.10 under Vbox, but when run I always get an error "Invalid <CURRENT_MODEL> len"
I thought this was a bit odd, as there's only so many ways you can get DG4062 wrong. So I copied and pasted the example command, and I get the same error. So obviously there's something wrong with the setup.
My guess is it's going to be something to do with local terminal options or the like? Can any linux guru's shed light on that one for me?
char *strtoupper(char *str){
int i = 0;
char *p = (char*) malloc((strlen(str) + 1) * sizeof(char)); // EDIT: + 1 important!
for(; str[i]; ++i){
if((str[i] >= 'a') && (str[i] <= 'z'))
p[i] = str[i] + 'A' - 'a';
else
p[i] = str[i];
}
p[i] = '\0';
return p;
}
Looks like the analog bandwidth is 160Mhz. Still worth modding to DG4202 for the 5Mhz Ramp though :-+
At first I have to say 'THANK YOU so much' to RORY
, because he helped me with "CygWin"
and so it was possible for me to compile "cengen.c" in Win XP.
But after this I got the next problem:
I started "cengen.exe" with correct parameters, I got every time an error
message like attachment. Then -for a test- I deleted in "cengem.c" these
6 if-lines [first line begins "if (strlen(cur_model)!=6)..."]
and after that I got the "license.cen" with 751 bytes without errors.
But as the DG4062 has read it, it answered: "invalid license file" :-((
After no sleep last night, now I gave it up very tired. I think, I'm to old (72 Y.)
for those adventures with no knowledge from Linux.
Maybe it's a problem with the firmware?
My DG4062 shows:
Softvers. 00.01.04
FPGA Vers. 00.01.07
Hardw.vers. 01.01
Keyb.vers. 04.01
Is there any chance? Thank you and forgive my terible english.
Rigol-Friend
CYBERNET and the other friends:
Jesus Christ, Cybernet, the cen-file you sent to me worked 100%. Now my generator (DG4062) produces frequencies up to 200 mhz, WOW.
THANK YOU, THANK YOU, THANK YOU THANK YOU, THANK YOU, THANK YOU THANK YOU, THANK YOU, THANK YOU.
For me as radioamateur this is more than interessting.
If you like, I want to invite you for a bottle of Champain, or more :-))
Phantastig,
Rigol-Friend
That's fine Cybernet :-))
I think you are a German. The word 'Radler' only Germans are using. And remember the bottle of beer at your picture, isn't it ??
Anyway, I think you are more than genius, yes I think so !!
Good night,
Rigol-Friend
Yes, I wouldn't go as far as drawing any conclusions yet. We need someone with a scope with significantly higher bandwidth to test this one.Looks like the analog bandwidth is 160Mhz. Still worth modding to DG4202 for the 5Mhz Ramp though :-+
TMM, that conclusion assumes the measuring device (scope) is itself perfectly flat to 200 MHz. Thus the falloff is completely due to the generator. That's unlikely to be the case.
Also, Harvs wrote:
> Using a short coax and 50ohm term. <
and an external 50-ohm terminator does not eliminate the internal capacitance on the front end. I'm assuming he's using one of the DS2000-series scopes.
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'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!! :-+
change the strcmp in the code ....
We can assume the DS2202 does a bit better than 200MHz so it is a little less than 3dB (70.7% p-p) down at 200MHz. From that you can conclude that the bandwidth of the function gen falls between 100MHz and 200MHz. You wouldn't expect a function gen to be less than 6dB down at 200MHz if it's bandwidth was 60MHz.Looks like the analog bandwidth is 160Mhz. Still worth modding to DG4202 for the 5Mhz Ramp though :-+
TMM, that conclusion assumes the measuring device (scope) is itself perfectly flat to 200 MHz. Thus the falloff is completely due to the generator. That's unlikely to be the case.
the DS4k software is based on the DS2k software - there is no CEN support that i would have spotted on my way through this piece of s...oftware ;)Congratulations Cybernet. :-+
but there are still some bits to be discovered in that software ... internal filesystem (and how to access it), some SCPI commands that seem "unreachable", bootloader update, and custom firmware - running linux would be fun ;)
Re. DG4000 cengen: There are several of us non Unix/Linux users here on the forum that would very much appreciate a Windows or Web application to generate the required CEN file. If someone could put one together it would be very much appreciatedThe best would be if studio25 could integrate it in his web app RigLOL http://riglol.3owl.com (http://riglol.3owl.com)
Re. DG4000 cengen: There are several of us non Unix/Linux users here on the forum that would very much appreciate a Windows or Web application to generate the required CEN file. If someone could put one together it would be very much appreciated
/*
** rigol DG4000 cengen / cybernet
**
** BUILD WITH:
** gcc cengen.c -m32 -o cengen
**
** RUN WITH:
**
** ./cengen <CURRENT_MODEL> <NEW_MODEL> <CURRENT_SERIAL> [<NEW_SERIAL>]
**
** <?_MODEL> = DG4062, DG4102, DG4162, DG4202(*)
** <?_SERIAL> = DG4D1XXXXXXXX
**
** if <NEW_SERIAL> is omitted the serial will not be modified
** (*) DG4202 is not an official model, but 200Mhz seems to work fine
**
**
** =================================================================================
** more info: https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/
** =================================================================================
**
** ____ ______________ ___ __
** / __ \/_ __/ ____/ |/ / / /
** / /_/ / / / / /_ / /|_/ / / /
** / _, _/ / / / __/ / / / / /_/
** /_/ |_| /_/ /_/ /_/ /_/ (_)
**
** this tool generates a new model type (DG4XXX) & serial (DG4D1XXXXXXXX) string,
** calculates a MAC and creates a .CEN file.
**
** what to do with the file ?
**
** put it on an USB stick, plug stick into DG4000, goto "Store", browse USB Stick,
** change "File Type" to "All File", navigate to your .CEN file, press "Read".
**
** You should get a Popup telling you that you successfully changed your model type and serial
**
** if *not* you:
** used a wrong current model type
** used a wrong current serial
** used an invalid new model type
** used an invalid new serial
**
**
** firmware tested:
** 00.01.06
** 00.01.03
**
**
** no warranties, if it explodes, your problem ;-)
**
*/
#include<stdio.h>
#include<stdlib.h>
#include<stdint.h>
#include<string.h>
#include<ctype.h>
#define VERSION "0.1"
char header[]="RIGOL:DG4:FIRM LICENSE FILE";
char iv[]="1000000110000001";
char static_cccc[4];
char static_zero[8];
// endianess shit
union helper {
unsigned char c[8];
unsigned int l[2];
uint64_t u;
};
// shifty
void do_cbc(char a, char b, char c, char d, char e, char f, uint16_t word1, char *buffer)
{
uint16_t bit1,bit2,bit3,bit4,u,x,y,z;
char out;
int la;
if (buffer==0) return;
u=(1<<a)-1;
z=0;
x=0;
while (a > z)
{
x=x|(1<<z);
z++;
}
y=word1&x;
if (e==0)
{
la=0;
while (u > la)
{
*(int*)(buffer+la*2)=(int)y;
if (b==0) bit1=0;
else
{
bit1=(y>>(b-1))&1;
}
if (c==0) bit2=0;
else
{
bit2=(y>>(c-1))&1;
}
if (d==0) bit3=0;
else
{
bit3=(y>>(d-1))&1;
}
if (f==0) bit4=0;
else
{
bit4=(y>>(f-1))&1;
}
out=bit1^bit2;
out=out^bit3;
out=out^bit4;
y=y*2;
y=y&x;
y=y|out;
la++;
}
}
else
{
printf("not implemented - deemed useless code ...\n");
exit(-1);
}
}
/*
** convert string to uppercase chars
*/
char * strtoupper(char *str)
{
int i = 0;
for(i = 0; str[i]; i++)
{
str[i] = toupper(str[i]);
}
return str;
}
void ascii(void)
{
printf("\n");
printf(" ________ ____ ____ ____ ____\n");
printf(" / ___/ _ \\/ __ \\/ __ `/ _ \\/ __ \\\n");
printf("/ /__/ __/ / / / /_/ / __/ / / /\n");
printf("\\___/\\___/_/ /_/\\__, /\\___/_/ /_/\n");
printf(" V%s /____/ cybernet 2013\n\n", VERSION);
}
void help(void)
{
printf("\n ./cengen <CURRENT_MODEL> <NEW_MODEL> <CURRENT_SERIAL> [<NEW_SERIAL>]\n\n");
printf(" <?_MODEL> = DG4062, DG4102, DG4162, DG4202(*)\n");
printf(" <?_SERIAL> = DG4D1XXXXXXXX\n\n");
printf(" example: ./cengen DG4062 DG4202 DG4D150400123\n");
printf(" (upgrades DG4062 to DG4202, keeps serial number)\n\n");
printf(" if <NEW_SERIAL> is omitted the serial will not be modified\n");
printf(" (*) DG4202 is not an official model, but 200Mhz seems to work fine\n\n");
exit(-1);
}
char buffer_shift(int la, uint16_t *word1, char *buf)
{
int w;
int y;
int li=0;
char x=0;
while (li > la)
{
w=*word1;
y=*(buf+li);
if (y!=li)
{
*word1=w+1;
li=0;
x=1;
}
li++;
}
return(x);
}
// dump license file
void write_file(char *nms, char *buf, uint16_t buf_len)
{
char len[8];
FILE *fd=NULL;
fd=fopen("license.CEN", "w");
if (fd==NULL)
{
printf("unable to open file 'license.CEN' for writing\n");
exit(-1);
}
memset(static_cccc, 0xcc, 4);
memset(static_zero, 0x0, 8);
memset(len,0,8);
//bzero(len,8);
len[0]=(buf_len)&0xFF;
len[1]=((buf_len)>>8)&0xFF;
fwrite(header,1,strlen(header),fd);
fwrite(len,1,4,fd);
fwrite(static_zero,1,4,fd);
fwrite(static_cccc,1,2,fd);
fwrite(iv,1,strlen(iv)+1,fd);
fwrite(nms,1,strlen(nms),fd);
fwrite(buf,1,buf_len*2,fd);
fclose(fd);
}
int main(int argc, char *argv[])
{
char secret[]="YZDHZSGCX";
char new_model[8];
char new_serial[14];
char *new_model_serial;
char cur_model[8];
char cur_serial[14];
char *cur_model_serial;
char *buffer20;
char *buffer_a2;
char *buffer_a4;
int la;
char hbuf[3];
char chr;
int duplets,bits;
int r1,d1,r2,d2;
unsigned int data1,data2;
uint16_t word1;
unsigned char lasthex;
union helper uni1;
int key_len;
int prime=13;
int len_mts;
int lc,lb,ld;
int y;
uint16_t w;
ascii();
if (argc>=4)
{
strcpy(cur_serial, strtoupper(argv[3]));
strcpy(new_model, strtoupper(argv[2]));
strcpy(cur_model, strtoupper(argv[1]));
if (strlen(cur_model)!=6) { printf("invalid <CURRENT_MODEL> len\n"); help(); }
if (strlen(new_model)!=6) { printf("invalid <NEW_MODEL> len\n"); help(); }
if (strlen(cur_serial)!=13) { printf("invalid <CURRENT_SERIAL> len\n"); help(); }
if (strncmp(cur_model,"DG4", strlen("DG4"))) { printf("invalid <CURRENT_MODEL> type\n"); help(); }
if (strncmp(new_model,"DG4", strlen("DG4"))) { printf("invalid <NEW_MODEL> type\n"); help(); }
if (strncmp(cur_serial,"DG4", strlen("DG4"))) { printf("invalid <CURRENT_SERIAL> type\n"); help(); }
if (argc==5)
{
strcpy(new_serial, strtoupper(argv[4]));
if (strlen(new_serial)!=13) { printf("invalid <NEW_SERIAL> len\n"); help(); }
if (strncmp(new_serial,"DG4", strlen("DG4"))) { printf("invalid <NEW_SERIAL> type\n"); help(); }
strcpy(new_serial, strtoupper(argv[4]));
}
else strcpy(new_serial, strtoupper(argv[3]));
}
else help();
cur_model_serial=(char*)calloc(1, strlen(cur_model)+strlen(cur_serial)+1);
new_model_serial=(char*)calloc(1, strlen(new_model)+strlen(new_serial)+1);
strcpy(new_model_serial, new_model);
strcat(new_model_serial, new_serial);
strcpy(cur_model_serial, cur_model);
strcat(cur_model_serial, cur_serial);
printf("\nCurrent settings:\n");
printf("\tModel:\t\t%s\n",cur_model);
printf("\tSerial#:\t%s\n",cur_serial);
printf("\nNew settings:\n");
printf("\tModel:\t\t%s\n",new_model);
printf("\tSerial#:\t%s\n\n",new_serial);
buffer20=(char*)calloc(1,20);
buffer_a2=(char*)calloc(4,8192);
buffer_a4=(char*)calloc(4,8192);
memset(buffer_a4,0xAA,8192);
key_len=strlen(secret);
la=0;
duplets=0;
y=0;
hbuf[2]=0;
while(la < strlen(iv))
{
hbuf[0]=iv[la];
hbuf[1]=iv[la+1];
uni1.c[duplets]=strtol(hbuf,NULL,0x10);
duplets++;
la=la+2;
}
data1=uni1.l[0];
data2=uni1.l[1];
bits=duplets<<3;
r1=bits%prime;
d1=bits/prime;
if (r1 != 0) d1++;
lasthex=uni1.c[duplets-1];
d2=64/prime;
r2=64%prime;
la=0;
while (d1>la)
{
if (d2>0)
{
word1=data1&0x1fff;
uni1.u=uni1.u>>prime;
data1=uni1.l[0];
data2=uni1.l[1];
d2--;
}
else
{
word1=(int)(((int)data1)|(lasthex<<r2))&0xffff;
}
buffer_shift(la,&word1,buffer20);
*(int*)(buffer20+la*2)=(int)word1;
do_cbc(0xd, 0x1, 0x3, 0x4, 0x0, 0xd, word1, buffer_a2);
len_mts=strlen(new_model_serial);
ld=lb=lc=0;
while (len_mts > lc)
{
chr=cur_model_serial[lc];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
if (lb > (key_len-1)) lb=0;
chr=secret[lb];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
chr=secret[lb]^cur_model_serial[lc];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
if (ld > (len_mts-1)) ld=0;
chr=new_model_serial[ld];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
lc++;
lb++;
ld++;
}
la++;
}
w=*(uint16_t*)(buffer_a4)&0xffff;
w=w&0xfffc;
*(uint16_t*)(buffer_a4)=(uint16_t)w;
*(uint16_t*)(buffer_a4)=2|(uint16_t)w;
w=*(uint16_t*)(buffer_a4+0x14)&0xffff;
*(uint16_t*)(buffer_a4+0x14)=2|(uint16_t)w&0xfff8;
write_file(new_model_serial, buffer_a4, y);
printf("license file dumped into: 'license.CEN' - have fun !\n\n");
exit(0);
}
There's a dot at the end of your link before the [/url] bracket, so clicking the link doesn't work correctly.
Here's the correct link: http://www.compileonline.com/compile_c_online.php (http://www.compileonline.com/compile_c_online.php)
I Upgraded my DG4062 to a DG4202 (200 MHz), but . . .
Issue 1. What I’m seeing is that the sine wave output is flat to 100MHz within +/- ~ 0.4 dB to 100MHz, but about -1 dB @ 120MHz, ~ -2.5 dB @ 160MHz, and ~ -4.5dB @ 200MHz. The Square Wave Rise Time is about 4.1 ns, so I’m happy about that, as I believe that the extrapolated spec would be 5ns for the DG4202. But the Sine Wave level drop above 100MHz seems way out of the ordinary with the Flatness spec for the DG4162 being +/- 0.8 up to 160 MHz. Test configuration: I have the DG4000 output impedance set for 50 Ohms, used output levels of 0 and -15dBm (with the same results), and the output measurements were made with a Spectrum Analyzer and a HP RF Power Meter.
Issue 2. I also have an issue with DG4000 Screen Saver after several minutes of no activity (not making any changes on the front panel). The DS4000 comes up with a dark screen and a Rigol logo that changes position on the screen every 5 seconds, or comes up with Rigol in a single fixed position, or comes up with a blank screen. I didn’t notice this behavior before. Hopefully this issue is simply in the version 00.01.06.00.02 of software/firmware and others with/without this upgrade patch are experiencing this also (?).
System Info: Device Model - DG4062/DG4202, Serial Number - DG4D152xxxxxx, Software - 00.01.06.00.02, FPGA - 00.01.07.09, Hard - 01.03, Keyboard - 05.01, and Enc FPGA – 06.
I was able to successfully recovery the original DG4062 configuration by using the ‘cegen’ Keygen in reverse (DG4202 to DG4062).
The Screen Saver operation is the same. And by the way it kicks in after 15 minutes of no front panel activity. Out of 8 tests the Rigol Logo froze twice. So does this mean it is due to a firmware bug and was there before using ‘cengen’? Probably. . . Has this issue been reported by anyone else?
Please, any thoughts or comments would be appreciated.
cybernet, or anyone else:
Do you know where I can get a DG4000 calibration procedure, or at least a description of the meanings for the various calibration points?
Any clues about the calibration would be helpful and appreciated. I have the resources to accomplish it after I find some details/clues about it.
The PW you provided cybernet did allow me access to the Manual Cal. pages. Thank you.
and on the heels of that - there is a calibration file format that can be loaded like the CEN files, which is probably what rigol uses to do an inital calibration. so if somebody WOULD get sane values for a 160/200MHZ upgraded one, i might look into the file format to make that available easily to the rest. (depends on time on my end) - would save some measurement and type in sessions ....
and on the heels of that - there is a calibration file format that can be loaded like the CEN files, which is probably what rigol uses to do an inital calibration. so if somebody WOULD get sane values for a 160/200MHZ upgraded one, i might look into the file format to make that available easily to the rest. (depends on time on my end) - would save some measurement and type in sessions ....
I have a DG4162, so its calibration values should be sane to at least 160MHz. I haven't compiled your code yet but thank you all the same for sharing your brilliant reverse engineering work. :clap:
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?
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?
there is some fpga firmware in the GEL file, but could be for display or keyboard FPGA - and there is a dedicated file format header for FPGA only upgrades (might used in factory), but nobody has such a file.
./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)
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 (http://www.filedropper.com/dumpfilestar)
http://www.filedropper.com/dumpfilestar (http://www.filedropper.com/dumpfilestar)
Just checked, works fine for me. Filezize: 9.740 kBhttp://www.filedropper.com/dumpfilestar (http://www.filedropper.com/dumpfilestar)I may be doing something wrong, but I believe it says the linked file is 0 kB?
Reference below for info on Software 07 bugs:Link to that topic: https://www.eevblog.com/forum/testgear/rigol-dg4xxx-ppulse-and-npulse/ (https://www.eevblog.com/forum/testgear/rigol-dg4xxx-ppulse-and-npulse/)
Re: Rigol DG4xxx ppulse and npulse
« Reply #5 on: October 22, 2013, 09:25:30 PM »
Quote
Yes, Rigol just confirmed it is a bug, I'll post here when they come up with the fix.
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 (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)
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); |
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.Subject: Getting a newer FPGA version for DG4000.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.
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?
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/ (https://www.eevblog.com/forum/testgear/rigol-dg4xxx-ppulse-and-npulse/)
Rigol confirmed it is a bug.
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++;
Just checked, works fine for me. Filezize: 9.740 kBhttp://www.filedropper.com/dumpfilestar (http://www.filedropper.com/dumpfilestar)I may be doing something wrong, but I believe it says the linked file is 0 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 [..]
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'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!! :-+
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: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'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.
if (strncmp(cur_serial,"DG4D1", strlen("DG4D1"))) { printf("invalid <CURRENT_SERIAL> type\n"); help(); }
Anyone got Firmware 00.01.07.00.03 ?Try to extract the zip-archive online here, it looks like this works: http://b1.org/online (http://b1.org/online)
The one in this topic is saying corrupt by winrar.
Nice work Cybernet! :-+This file gives an error when trying to extract? (only empty folders)
Attached is the latest firmware (00.01.07.00.03)
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 ?Try to extract the zip-archive online here, it looks like this works: http://b1.org/online (http://b1.org/online)
The one in this topic is saying corrupt by winrar.
Edit: I have unzipped it online here, where you can download the .GEL file: http://wobzip.org/file/aWTQIIIQ (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 (http://b1.org)Nice work Cybernet! :-+This file gives an error when trying to extract? (only empty folders)
Attached is the latest firmware (00.01.07.00.03)
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.The uploaded Zip-archive won't unzip with the latest WinRAR 5.01 either.
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 (https://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?
Then for Cal. select HFLAT, Call Point (start at HFLAT 1-1), Measure Value, Input Value, press Save and wait for it to complete (about 3 seconds), select Cal Point for the next step. Repeat for all 60 steps. Then your done and you didn't have to connect anything up to your DG4000, except for AC power. Hi
Then for Cal. select HFLAT, Call Point (start at HFLAT 1-1), Measure Value, Input Value, press Save and wait for it to complete (about 3 seconds), select Cal Point for the next step. Repeat for all 60 steps. Then your done and you didn't have to connect anything up to your DG4000, except for AC power. Hi
That isn't making any sense to me. What does "Measure Value, Input Value" mean?
If you can calibrate without connecting anything but mains why can't the thing self calibrate with one button?
I don't know why this fixes the issue with frequency response, just that it brings it all back to life. The Factory Restore by itself won't do it either.
Yes, we are Restoring the Original Calibration. And you are correct, the description was incorrect, but then this is a new revelation of what is going on in the DG4000.I don't know why this fixes the issue with frequency response, just that it brings it all back to life. The Factory Restore by itself won't do it either.
Calling it calibration is what made it confusing since you are not calibrating, just going through some motions which appears to re-instate an existing calibration.
DG4000 Calibration Restoration:
So to calibrate (or rather restore the previous calibration of) your DG4000:
Press - Utility, Test/Cal, Secure Code, (put in PW) 2010, Enter, Secure OFF, (the result should be) Secure ON, Access gained.
Then for Cal. select HFLAT, Call Point (start at HFLAT 1-1), Measure Value, Input Value, press Save and wait for it to complete (about 3 seconds), select Cal Point for the next step. Repeat for all 60 steps. Then your done and you didn't have to make measurements or level changes. You didn't even have to hook anything up to your DG4000 except for AC power. Hi
Interesting, you have a DG4062 but the stored call settings (but not 'activated') gives you a flat responds even higher than 160MHz.No, I do Not think this is the case.
So it looks like reducing the unit to 60MHz is done after the full factory calibration of the PCB
or there is some nice self calibration feature build in that is used during this procedure.
Does anyone else observe this? (FW=1.04)Can you try to do the Calibration Restoration for everything else except for 'Freq. Accuracy' and 'Counter' to see if that fixes the Sweep Freq Response?
When doing a sweep (6 sec ) from 100 ->160 MHz that the output is mostly Flat
about 1 Vpp , see Pix 1
But when the sweep is set to 100 ->161 MHz
the out jumps to 1.42 Vpp (@100MHz) and the sweep looks like Pix 2
Note At the end of the sweep the output is at 1 Vpp (60sec end Hold)
see Pix 3
Is this a FW issue, a limit, a bug, or a Calibration error ?
I have had others tell me that sometimes they have a glitch, fault, or otherwise strange behavior with the DG4000, and they reset or Power OFF/ON and the issue goes away. Have you observed anything like this? Anyway what you reported above could possibly this kind of thing. No one else has said anything about having do do a Cal. for both channels. Although of course it is possible, I think somewhat unlikely.DG4000 Calibration Restoration:I am not sure of "effective for both channels" is true ??
The calibration restoration is effective for both channels, it isn't necessary to repeat each cal. routine for the other channel.
In pics I show a glitch on chan 2 out (6sec sweep 1->160MHz) at about 24 MHz
there was no clitch on Chan 1
I restored ALL of Chan 2 HFLAT and the glitch was corrected
Hi whotopia,The website seems to b up an running again. I tried without luck to download it after whotopia's post.
I tried it some minutes ago and got this PDF without any problem. For you I attached here.
I meant file tool generates - ;DG4000 cengen; from cybernet for DG4062? http://pastebin.com/ipkJCxPM (http://pastebin.com/ipkJCxPM)
doesn't work unfortunately my mail roket333@rambler.ru
Silly question, but could someone please post instructions on how to upgrade firmware on DG4000? I got a DG4062 for Xmas, ran the cengen output and would now like to upgrade to latest firmware.
BTW, is 00.01.07.00.03 still the newest available firmware?
Hi everyone,
I noticed a change in my DG4062's response to button presses after applying the "cengen" upgrade to DG4202. I thought perhaps it's just me, but I tried a retail DG4102 and it was more responsive, like my DG4062 used to be. I just used my DG4062 again and I'm convinced there is a reduction in responsiveness to button presses. Some times button presses are not even registered and I have to push the button twice or three times --- this never happened in the past, and nor did it happen on the DG4102 I used a couple of days ago.
I wonder if this is something to do with the cengen mod, or could it be related to a 01.07 firmware update I did around the same time?
For most of the time I've had the DG4062, I was running firmware 01.06 and never had any troubles with buttons. I've only been running 01.07 since applying the cengen mod.
Has anyone experienced anything similar?
Cheers!
Hi everyone,
I noticed a change in my DG4062's response to button presses after applying the "cengen" upgrade to DG4202. I thought perhaps it's just me, but I tried a retail DG4102 and it was more responsive, like my DG4062 used to be. I just used my DG4062 again and I'm convinced there is a reduction in responsiveness to button presses. Some times button presses are not even registered and I have to push the button twice or three times --- this never happened in the past, and nor did it happen on the DG4102 I used a couple of days ago.
I wonder if this is something to do with the cengen mod, or could it be related to a 01.07 firmware update I did around the same time?
For most of the time I've had the DG4062, I was running firmware 01.06 and never had any troubles with buttons. I've only been running 01.07 since applying the cengen mod.
Has anyone experienced anything similar?
Cheers!
Answering my own question: I decided to downgrade from 01.07 to 01.06 to see if indeed it was the firmware upgrade that caused it. To my delight the responsive keys are back with 01.06 installed! The higher max frequencies that come with the cengen (DG4202 model) change have remained.
So, at least in my instance, the 01.07 firmware had the effect of introducing a slower response time to detecting and processing key presses. It seems weird that it could be true, but certainly the usability has improved back to what it was originally.
>> I am still be interesting to hear anyone else's experience related to button press responsiveness. As a test, on 01.06, I can enter the sequence "121212121212" (say for frequency setting) quickly, one button after the other using a single finger and the key pad, it shows as you'd expect on the display "121212121212". However on 01.07, it'll miss some keys and I'll get "121221212112122" where there are missing '1' and '2' where a key press wasn't detected/processed.
Anyone on 01.07 or 01.06 care to try it?
Hi Sparky
I have an upgraded DG4102, running 1.07 FW and I cannot reproduce your findings, keyboard is responsive (sometimes a bit to overly responsive :-))
I noticed a change in my DG4062's response to button presses after ......@Sparky No prblem here with 'Keyboard Version 04.01'
Has anyone experienced anything similar?
No stall here, with 2 index fingers tapping any 2 digits .
Thanks, it has a version history file:After installing the new firmware do you still have 160 MHz and any other option hack you had before?
Google translate
1) added more languages
2) increasing the synchronous output mode
So any idea what changed about the synchronous output, bugfix?
a few days ago i received a new firmware for my DG4062. its version 1.08.I Loaded it , All looks ok
Teneyes: Apparently you have your DG4000 set for 200MHz. Questions: 1. When you use a automatic Sine sweep up to 200MHz is the output now flat, or does it drop off 4.5 - 5dB at 200 MHz from the output at 160MHz, as was our observation several months ago (whereas a manual CW sweep resulted in essentially a flat output level)? 2. Have you found any other glitches that were the result of having the DG4000 configured for 200MHz (instead of 160MHZ)?a few days ago i received a new firmware for my DG4062. its version 1.08.I Loaded it , All looks ok
2. Have you found any other glitches that were the result of having the DG4000 configured for 200MHz (instead of 160MHZ)?I haven't done much with the DG4000
@ GandalfErm... just having a senior moment, I'm talking about an AWG, the DG4062 but I am mixing my refs to firmware versions up with the DS2072 that I just ordered too. But I guess the question is, does it matter what firmware version mine is (when it gets here) if I'm thinking of upgrading the AWG?
What are you talking about? Check rigol. site for FW and models
Are you buying a DSO or a Function gen. .
I tried Ted's open, no change, save CAL technique (on HFLAT only) but it does not seem to have worked; at some point, the values that self-populated for the steps took a jump from 16's to -2's. I get significant drop in output level (Vpp) when going up to 100 MHz and more at 200 MHz. I guess I'll have to do a real CAL :-BROKE
One thing I found is that when using a DG4062 (FW rev 1.07) to measure ~1 second periods, the value displayed on the LCD and the value sent over the USB interface don't match. The value that comes back from ":counter:measure?" is always ~13.5nS higher than the value on the display.
For example, LCD value = 1.000,000,001,1 while the USB value = 1.000000014E+00
This problem doesn't happen at higher frequencies.
I reported this to a Rigol app eng. The last I heard from him was "I have reproduced the issue. We are investigating. I'll let you know what I find." That was six months ago.
A friend has a DG4162 that's sw vn 00.01.04, he contacted Rigol who've sent him firmware vn 00.01.09.00.01 along with a new vn 00.06 bootloader which he's been told to apply before the firware. He contacted me because the instructions from Rigol on how to apply the update don't seem to work. Any ideas?Most likely the 1.09 firmware can only be loaded with that new boot loader. The new boot loader prevents you then from loading an older version of the firmware.
I wonder why there's a new bootloader? It's possible that they are trying to close down the loopholes. I'm thinking that he should try the firmware update without the bootloader first.
I forgot to mention that you need a small size USB stick, 1 or 2 Gbyte. Larger sizes give errors
Hi all,
just a short question: anyone bought a DG4062 in the last few days and knows what firmware will be delivered?
Thanks,
Flo
Hi all,
just a short question: anyone bought a DG4062 in the last few days and knows what firmware will be delivered?
Thanks,
Flo
I could just ask them for the software, but they want to know the serial, and might find out that they delivered my DG4062 with the latest firmware.
Just got my DG4062, unfortunately SW: 00.01.09. Does anyone have the 00.01.09 update GEL file?
Maybe all they changed is the key, so I'd like to have a look at the update.
I could just ask them for the software, but they want to know the serial, and might find out that they delivered my DG4062 with the latest firmware. Anyone with an older firmware might be able to help you..
Hope this helps!
Hope this helps! Piranha(DSP)Update_00.01.09.zip
I tried this "Piranha(DSP)Update_00.01.09.zip" update without luck.EV,
..
You have to rename the file to "DG4000Update.GEL" The bootloader only looks for "DG4000Update.GEL" on the USB stick.
The new bootloader loaded in a few minutes.
...
The problem is that I can not load the new bootloader. I tried it again and waited 15 minutes but no luck. Only Mod, Utility and Store buttons are lit. Nothing else happens.
Did you rename the DG4000Update_Bootloader.GEL to DG4000Update.GEL?
I did not realise that also the bootloader file had to be renamed.
Is the calibration still OK after the 1.09 upgrade?Did you rename the DG4000Update_Bootloader.GEL to DG4000Update.GEL?
Thanks PA0PBZ!
I did not realise that also the bootloader file had to be renamed. |O
The system information is now:
Software 00.01.09
FPGA 00.01.09
Hardware 01.01
Keyboard 06.01
Just be aware that upgrading software on RIGOL generators it might loose your calibration!
Therefore my personal opinion is that this isn't necessarily a favorable file download service for us to use.
PM me if u need the IDA DB with my initial reversing of the .GEN files.
...
the old BL is fully reversed if somebody has questions about it.
pm deactivated, use the search function ...
will send once im home again, dont have those on may travel laptop :)
http://bayfiles.net/file/1lwMQ/FCREFF/bfin_rigol_cybernet_updated.rar (http://bayfiles.net/file/1lwMQ/FCREFF/bfin_rigol_cybernet_updated.rar) - this with right .ldr fileGot it, thanks!
the old BL is fully reversed if somebody has questions about it.
Hi, any one know, that dg4100 with:See /here (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg382414/#msg382414)
Software 00.01.07. Hardware 01.03
Quick question, I re-calibrated the generator using the measure value/input value and saving on the calibration points. I noticed the Square wave at 50Mhz looks almost like a Sine wave and hardly resembles a square wave. Is this normal or is my calibration off?
I just loaded 1.10.
I just loaded 1.10.Extended bandwidth mod still working?
where is the generator available for downloading?
I just loaded 1.10.Extended bandwidth mod still working?
Retained its new-found DG4162 identity fine, yes. Chassis label is DG4102 and mod done on 1.07; do you want me to sweep it to be sure?
Retained its new-found DG4162 identity fine, yes. Chassis label is DG4102 and mod done on 1.07; do you want me to sweep it to be sure?
Mine reverted back to DG4062 from DG4202 when 1.10 installed.
It looks like Chainsaw changed from 1.07 to 1.10 and Rory changed from 1.09 to 1.10, that could be the difference
Not to worry , the Man is working on it , see sniffing
DG4000 Calibration Restoration:
I just finished calibrating my DG4000 for Channel 1 and 2, and the frequency response is flat up to 200 MHz and well within better than +/- 0.8 dB.
So what is calibration? I have concluded that it is removing the un-calibration that you end up with after you install the firmware patch to extend the frequency!
So to calibrate (or rather restore the previous calibration of) your DG4000: Press - Utility, Test/Cal, Secure Code, (put in PW) 2010, Enter, Secure OFF, (the result should be) Secure ON, Access gained.
Then for Cal. select HFLAT, Call Point (start at HFLAT 1-1), Measure Value, Input Value, press Save and wait for it to complete (about 3 seconds), select Cal Point for the next step. Repeat for all 60 steps. Then your done and you didn't have to connect anything up to your DG4000, except for AC power.
We shouldn't have to do anything with the Calibration for a DG4162. This is only required for the DG4202 (200MHz hack). There are also a couple of other small glitches we can run into with the DG4202 modification. Which is why I now suggest staying away from the DG4202 hack. And you can also loose your hack and end up back with a DG4062 by installing a recent Firmware release update. And then end up SOL for going back to even a DG4162 (the preferred model).
How I would measure the DG4162 output level frequency response: I would set the DG4162 for 50 Ohm output impedance (preferred for these higher frequencies for a flat output into your 50 Ohm Input device). If I used an O'Scope then I would Terminate its input with 50 Ohms (either internally, or with a 50 Ohm Feed Through Termination). The measurement should be into a 50 Ohm measurement device using 50 Ohm Coax. A RF Power Meter, Spectrum Analyzer, etc. is preferred over a O'Scope for better output level measurement accuracy. Although many hobbyist may not have this type of equipment, and therefore an O'Scope may be the their only choice, and should be fine if it has at least a 200MHz BW.
Edit: If a 50 Ohm Feed Through Termination for the O'Scope isn't available, a BNC Tee Adapter (one Male port and two Female ports) with a BNC 50 Ohm Termination on one of the BNC Tee's Female ports can be used. If a 50 Ohm Termination isn't available, a 50 Ohm resistor can be soldered to one of its Female ports (with very short leads). If a BNC Tee Adapter isn't available, I believe that they can generally be found at a Radio Shack store.
Anyone feel free to leave some comments or post comparisons of frequency sweep from your DG4000 units.Here are sweeps on 3 different coax cables
Anyone feel free to leave some comments or post comparisons of frequency sweep from your DG4000 units.Here are sweeps on 3 different coax cables
The sweeps are linear from 10-160Mhz over 60sec.
I have to note which cable is best
Note: DSO was in single sweep with DSO trigger out connect to DG sweep trigger input
Sparky: I generally avoid using RG-58. I use RG-223 in its place for a flexible coax cable for my test cables. Other cables that make good test cable, although aren't as flexible, are RG-141, 400, etc. with PTFE (teflon).
I'm kind of surprised that your RG-58 is as poor as it is, but that could be due to it having been flexed a lot over the years, having been kinked, pinched, BNC terminations being flaky, etc. To inspect the BNC (etc) connectors you would have to disassemble them from the cable ends are redress the cable by cutting an inch or so and reterminating the connections. Do NOT just stick them back together without having fresh and clean connections. An important thing to keep in mind with coax is not to over flex it too much, and to never bend a kink in it, or pinch/crush it. If you kink it and then straighten out 'even a flexible coax cable', the site of the kink will show up with a Time Domain Reflectometer test as a purtibation/discontinuity in the coax.
I suggest getting some new RG-223 and BNC connectors to use with it if you have any doubt about your coax test cables. We should be cautious buying coax from a Hamfest flee market in the parking lot. Does it look fresh, clean, and undamaged? Then hey, it may be Ok (?). And if people have any doubt on how to properly dress the cable for a proper connector termination, they should look it up and follow the recommended process. Some hobbyist have a hard time assembling coax cables/connectors simply because they have never been taught or studied the proper methods. Regards, Ted
Anyone feel free to leave some comments or post comparisons of frequency sweep from your DG4000 units.Here are sweeps on 3 different coax cables
The sweeps are linear from 10-160Mhz over 60sec.
I have to note which cable is best
Note: DSO was in single sweep with DSO trigger out connected to DG sweep trigger input
Did you use exactly same cable lenght (and not only physical lenght but with around same travel time lenght because it matter. And images looks like there is signal travel time differencies between cables - and impedance mismatches)?@rf-loop, Yes the DG4000 generator was set to 50ohm output and there was a 50 ohm feed-thru termination on the DS2000.
On your pictures I see quicker slopes (about 2ns).If you are referring to the step changes I just posted, please NOTE that I stated the traces are of the Sync outputs, fast switching pulse, but Fixed at 1.6 V .
Have you done some calibration to get this?
Did you use exactly same cable lenght (and not only physical lenght but with around same travel time lenght because it matter. And images looks like there is signal travel time differencies between cables - and impedance mismatches)?@rf-loop, Yes the DG4000 generator was set to 50ohm output and there was a 50 ohm feed-thru termination on the DS2000.
Yes the DG4000 generator was set to 50ohm output and there was a 50 ohm feed-thru termination on the DS2000.Just a note, may not have relevance to the current topic but anyway: On the DG4000 you can't, as far as I know, change the actual output impedence, it's always a nominal 50 ohms. What you do when you enable the "50 ohm output impedance" is telling the generator that the external load connected TO the generator is 50ohm, it then changes the displayed amplitude etc with this taken into consideration. (Cutting it in half compared to the "High Z setting").
Instead of J-Tagging the bootloader and/or firmware, would it be possible to just put the parameters for extending the frequency range in the correct spot in memory?
maybe anoter option:
dump the flash, do manually what the cen-file used to do, and then uplaod the changed flash?
Re. DG4000 and the Hack for Rigol's 'unreleased' DG4202 (200MHZ) version:
As of DG4000 Firmware version 00.01.09.00 the DG4000 AWG is no longer compatible with the DG4202 (200MHz), a model version that had never been released by Rigol for the DG4000.
Therefore if you upgrade to FW i00.01.09.00 or 00.01.10.00 you will loose your previously Hacked in DG4202 (200MHz), and your unit will in general be set back to DG4062 (60MHz). And currently there is no way back. It's gone!
If on the other hand you installed a valid Hack, such as DG4162 (160MHz), or less, prior to installing FW 00.0.09, then your unit will retain DG4162 (160MHz), etc, after you upgrade the FW to 00.01.09.00 and/or 00.01.10.00.
A new firmware has been released for DG4000 series last month. It is v00.01.11.00.00 (and contains bootloader 00.06, which is the same as 01.10 DSP firmware).Here is listed that the latest firmware is 00.01.12:
Hi folks,
A new firmware has been released for DG4000 series last month. It is v00.01.11.00.00 (and contains bootloader 00.06, which is the same as 01.10 DSP firmware).
I have installed it on my DG4062 with "160MHz model patch" and all is well :) The boot time seems a little longer than previous, and --- if I'm recalling things correctly --- the LED indication at boot is a little different (the waveform button LEDs seem to light up in sequence, though quickly). I'm not sure what is new, fixed or broken in this release so...upgrade at your own risk :)
Cheers,
Sparky
A new firmware has been released for DG4000 series last month. It is v00.01.11.00.00 (and contains bootloader 00.06, which is the same as 01.10 DSP firmware).Here is listed that the latest firmware is 00.01.12:
http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm)
Has someone installed it? Have you any link to load these firmwares?
Re: Where can I get the "160MHz model patch"? I would like to try in my new arrived one, thanks!
Regretfully I don't think you will be able to install the 160MHz BW software modification on units with the newer firmware. See -> https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg581608/#msg581608 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg581608/#msg581608) (Reply #270). But please don't be discouraged, as this is still an awesome Function / Arbitrary Waveform Generator. And (possibly) someone may figure out how to perform this software fix in the future.
I got it.Sparky had 160MHz installed prior to Firmware 00.01.09. If you have firmware 00.01.09 or later it is too late for you to get 160MHz. Please read my DG4000 Post #270 again.Re: Where can I get the "160MHz model patch"? I would like to try in my new arrived one, thanks!Since I saw Sparky still can install the upgrade with v00.01.11.00.00 firmware. I think the new unit still have a chance to get a try.
Regretfully I don't think you will be able to install the 160MHz BW software modification on units with the newer firmware. See -> https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg581608/#msg581608 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg581608/#msg581608) (Reply #270). But please don't be discouraged, as this is still an awesome Function / Arbitrary Waveform Generator. And (possibly) someone may figure out how to perform this software fix in the future.
But I am not sure what happens if it is failed to upgrade 160MHz.(maybe brick my DG4062?)
I read through the post and found the cengen.c but unfortunately I only have WIN PC. The online compiler seems doesn't work (can compile and execute but show no directly to save the .cen file)
I have to make more time to study on it ;D
Free DG4062, DG4102, DG4162, DG4202 and a serial# of your choice ...
http://pastebin.com/ipkJCxPM (http://pastebin.com/ipkJCxPM)
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!! :-+
change the strcmp in the code ....
Thanks!! It worked perfect! :)
By the way, I have version 01.02. I will upgrade to 01.07 now.
Re. DG4000 cengen: There are several of us non Unix/Linux users here on the forum that would very much appreciate a Windows or Web application to generate the required CEN file. If someone could put one together it would be very much appreciated
---
original post removed
---
I'm editing this post to remove the link to my windows binary. Apparently it is putting extra bytes in the license file. I tried several different compilers and even tried cross-compiling for windows from my linux box. Every windows binary I make puts extra bytes into the license file. I don't have enough time to see exactly why, so I offer here an alternative solution if you only have access to windows.
1) Go to http://www.compileonline.com/compile_c_online.php (http://www.compileonline.com/compile_c_online.php)
2) Replace the code in the left box with the code below.
3) Put your command line arguments in the text box at the bottom (in the form <current model> <new model> <current serial>)
4) Press "Compile and Execute" in the top left
5) Press "Download Files" in the top right (assuming everything executed properly)
6) The result tar.gz file will have the proper license.CEN file contained within it.
-ClaytonCode: [Select]/*
** rigol DG4000 cengen / cybernet
**
** BUILD WITH:
** gcc cengen.c -m32 -o cengen
**
** RUN WITH:
**
** ./cengen <CURRENT_MODEL> <NEW_MODEL> <CURRENT_SERIAL> [<NEW_SERIAL>]
**
** <?_MODEL> = DG4062, DG4102, DG4162, DG4202(*)
** <?_SERIAL> = DG4D1XXXXXXXX
**
** if <NEW_SERIAL> is omitted the serial will not be modified
** (*) DG4202 is not an official model, but 200Mhz seems to work fine
**
**
** =================================================================================
** more info: https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/
** =================================================================================
**
** ____ ______________ ___ __
** / __ \/_ __/ ____/ |/ / / /
** / /_/ / / / / /_ / /|_/ / / /
** / _, _/ / / / __/ / / / / /_/
** /_/ |_| /_/ /_/ /_/ /_/ (_)
**
** this tool generates a new model type (DG4XXX) & serial (DG4D1XXXXXXXX) string,
** calculates a MAC and creates a .CEN file.
**
** what to do with the file ?
**
** put it on an USB stick, plug stick into DG4000, goto "Store", browse USB Stick,
** change "File Type" to "All File", navigate to your .CEN file, press "Read".
**
** You should get a Popup telling you that you successfully changed your model type and serial
**
** if *not* you:
** used a wrong current model type
** used a wrong current serial
** used an invalid new model type
** used an invalid new serial
**
**
** firmware tested:
** 00.01.06
** 00.01.03
**
**
** no warranties, if it explodes, your problem ;-)
**
*/
#include<stdio.h>
#include<stdlib.h>
#include<stdint.h>
#include<string.h>
#include<ctype.h>
#define VERSION "0.1"
char header[]="RIGOL:DG4:FIRM LICENSE FILE";
char iv[]="1000000110000001";
char static_cccc[4];
char static_zero[8];
// endianess shit
union helper {
unsigned char c[8];
unsigned int l[2];
uint64_t u;
};
// shifty
void do_cbc(char a, char b, char c, char d, char e, char f, uint16_t word1, char *buffer)
{
uint16_t bit1,bit2,bit3,bit4,u,x,y,z;
char out;
int la;
if (buffer==0) return;
u=(1<<a)-1;
z=0;
x=0;
while (a > z)
{
x=x|(1<<z);
z++;
}
y=word1&x;
if (e==0)
{
la=0;
while (u > la)
{
*(int*)(buffer+la*2)=(int)y;
if (b==0) bit1=0;
else
{
bit1=(y>>(b-1))&1;
}
if (c==0) bit2=0;
else
{
bit2=(y>>(c-1))&1;
}
if (d==0) bit3=0;
else
{
bit3=(y>>(d-1))&1;
}
if (f==0) bit4=0;
else
{
bit4=(y>>(f-1))&1;
}
out=bit1^bit2;
out=out^bit3;
out=out^bit4;
y=y*2;
y=y&x;
y=y|out;
la++;
}
}
else
{
printf("not implemented - deemed useless code ...\n");
exit(-1);
}
}
/*
** convert string to uppercase chars
*/
char * strtoupper(char *str)
{
int i = 0;
for(i = 0; str[i]; i++)
{
str[i] = toupper(str[i]);
}
return str;
}
void ascii(void)
{
printf("\n");
printf(" ________ ____ ____ ____ ____\n");
printf(" / ___/ _ \\/ __ \\/ __ `/ _ \\/ __ \\\n");
printf("/ /__/ __/ / / / /_/ / __/ / / /\n");
printf("\\___/\\___/_/ /_/\\__, /\\___/_/ /_/\n");
printf(" V%s /____/ cybernet 2013\n\n", VERSION);
}
void help(void)
{
printf("\n ./cengen <CURRENT_MODEL> <NEW_MODEL> <CURRENT_SERIAL> [<NEW_SERIAL>]\n\n");
printf(" <?_MODEL> = DG4062, DG4102, DG4162, DG4202(*)\n");
printf(" <?_SERIAL> = DG4D1XXXXXXXX\n\n");
printf(" example: ./cengen DG4062 DG4202 DG4D150400123\n");
printf(" (upgrades DG4062 to DG4202, keeps serial number)\n\n");
printf(" if <NEW_SERIAL> is omitted the serial will not be modified\n");
printf(" (*) DG4202 is not an official model, but 200Mhz seems to work fine\n\n");
exit(-1);
}
char buffer_shift(int la, uint16_t *word1, char *buf)
{
int w;
int y;
int li=0;
char x=0;
while (li > la)
{
w=*word1;
y=*(buf+li);
if (y!=li)
{
*word1=w+1;
li=0;
x=1;
}
li++;
}
return(x);
}
// dump license file
void write_file(char *nms, char *buf, uint16_t buf_len)
{
char len[8];
FILE *fd=NULL;
fd=fopen("license.CEN", "w");
if (fd==NULL)
{
printf("unable to open file 'license.CEN' for writing\n");
exit(-1);
}
memset(static_cccc, 0xcc, 4);
memset(static_zero, 0x0, 8);
memset(len,0,8);
//bzero(len,8);
len[0]=(buf_len)&0xFF;
len[1]=((buf_len)>>8)&0xFF;
fwrite(header,1,strlen(header),fd);
fwrite(len,1,4,fd);
fwrite(static_zero,1,4,fd);
fwrite(static_cccc,1,2,fd);
fwrite(iv,1,strlen(iv)+1,fd);
fwrite(nms,1,strlen(nms),fd);
fwrite(buf,1,buf_len*2,fd);
fclose(fd);
}
int main(int argc, char *argv[])
{
char secret[]="YZDHZSGCX";
char new_model[8];
char new_serial[14];
char *new_model_serial;
char cur_model[8];
char cur_serial[14];
char *cur_model_serial;
char *buffer20;
char *buffer_a2;
char *buffer_a4;
int la;
char hbuf[3];
char chr;
int duplets,bits;
int r1,d1,r2,d2;
unsigned int data1,data2;
uint16_t word1;
unsigned char lasthex;
union helper uni1;
int key_len;
int prime=13;
int len_mts;
int lc,lb,ld;
int y;
uint16_t w;
ascii();
if (argc>=4)
{
strcpy(cur_serial, strtoupper(argv[3]));
strcpy(new_model, strtoupper(argv[2]));
strcpy(cur_model, strtoupper(argv[1]));
if (strlen(cur_model)!=6) { printf("invalid <CURRENT_MODEL> len\n"); help(); }
if (strlen(new_model)!=6) { printf("invalid <NEW_MODEL> len\n"); help(); }
if (strlen(cur_serial)!=13) { printf("invalid <CURRENT_SERIAL> len\n"); help(); }
if (strncmp(cur_model,"DG4", strlen("DG4"))) { printf("invalid <CURRENT_MODEL> type\n"); help(); }
if (strncmp(new_model,"DG4", strlen("DG4"))) { printf("invalid <NEW_MODEL> type\n"); help(); }
if (strncmp(cur_serial,"DG4", strlen("DG4"))) { printf("invalid <CURRENT_SERIAL> type\n"); help(); }
if (argc==5)
{
strcpy(new_serial, strtoupper(argv[4]));
if (strlen(new_serial)!=13) { printf("invalid <NEW_SERIAL> len\n"); help(); }
if (strncmp(new_serial,"DG4", strlen("DG4"))) { printf("invalid <NEW_SERIAL> type\n"); help(); }
strcpy(new_serial, strtoupper(argv[4]));
}
else strcpy(new_serial, strtoupper(argv[3]));
}
else help();
cur_model_serial=(char*)calloc(1, strlen(cur_model)+strlen(cur_serial)+1);
new_model_serial=(char*)calloc(1, strlen(new_model)+strlen(new_serial)+1);
strcpy(new_model_serial, new_model);
strcat(new_model_serial, new_serial);
strcpy(cur_model_serial, cur_model);
strcat(cur_model_serial, cur_serial);
printf("\nCurrent settings:\n");
printf("\tModel:\t\t%s\n",cur_model);
printf("\tSerial#:\t%s\n",cur_serial);
printf("\nNew settings:\n");
printf("\tModel:\t\t%s\n",new_model);
printf("\tSerial#:\t%s\n\n",new_serial);
buffer20=(char*)calloc(1,20);
buffer_a2=(char*)calloc(4,8192);
buffer_a4=(char*)calloc(4,8192);
memset(buffer_a4,0xAA,8192);
key_len=strlen(secret);
la=0;
duplets=0;
y=0;
hbuf[2]=0;
while(la < strlen(iv))
{
hbuf[0]=iv[la];
hbuf[1]=iv[la+1];
uni1.c[duplets]=strtol(hbuf,NULL,0x10);
duplets++;
la=la+2;
}
data1=uni1.l[0];
data2=uni1.l[1];
bits=duplets<<3;
r1=bits%prime;
d1=bits/prime;
if (r1 != 0) d1++;
lasthex=uni1.c[duplets-1];
d2=64/prime;
r2=64%prime;
la=0;
while (d1>la)
{
if (d2>0)
{
word1=data1&0x1fff;
uni1.u=uni1.u>>prime;
data1=uni1.l[0];
data2=uni1.l[1];
d2--;
}
else
{
word1=(int)(((int)data1)|(lasthex<<r2))&0xffff;
}
buffer_shift(la,&word1,buffer20);
*(int*)(buffer20+la*2)=(int)word1;
do_cbc(0xd, 0x1, 0x3, 0x4, 0x0, 0xd, word1, buffer_a2);
len_mts=strlen(new_model_serial);
ld=lb=lc=0;
while (len_mts > lc)
{
chr=cur_model_serial[lc];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
if (lb > (key_len-1)) lb=0;
chr=secret[lb];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
chr=secret[lb]^cur_model_serial[lc];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
if (ld > (len_mts-1)) ld=0;
chr=new_model_serial[ld];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
lc++;
lb++;
ld++;
}
la++;
}
w=*(uint16_t*)(buffer_a4)&0xffff;
w=w&0xfffc;
*(uint16_t*)(buffer_a4)=(uint16_t)w;
*(uint16_t*)(buffer_a4)=2|(uint16_t)w;
w=*(uint16_t*)(buffer_a4+0x14)&0xffff;
*(uint16_t*)(buffer_a4+0x14)=2|(uint16_t)w&0xfff8;
write_file(new_model_serial, buffer_a4, y);
printf("license file dumped into: 'license.CEN' - have fun !\n\n");
exit(0);
}
Hi I can't get this to compile.....keeps giving errors..... can someone please help
Hi, this is the error
Hope this helps! Piranha(DSP)Update_00.01.09.zip (http://wikisend.com/download/411438/Piranha(DSP)Update_00.01.09.zip)
I looked for the 01.06 FW but I can't find it anywhere.
Hello everybody !
First, I'm sorry for my english... I'm French and the school is so far...
<snip>
At this time I have following FW (Rigol update files) :
- 00.01.04.00.02
- 00.01.06.00.02
- 00.01.07.00.03
- 00.01.08.00.02
- 00.01.12.00.02
- 00.01.14.00.01
In the #3, the firmware was 00.13.00.XX but I don't have original files from Rigol. If somebody have some other Firmware, I'm interested (All versions I don't have already).
Here, I don't have explain all steps of my work, it's to long for one message, if somebody is intersted, I will continu to explain other action.
First Goal : Have two DG4062 upgraded in DG4202 with last FW and be able to search without risk --> Achieved
Next Goal : Flash from file or from JTAG (I don't know how to flash the flash memory from JTAG port (or other present at the mother board), If someone can explain to me, I will be happy)
Next Next Goal : Understand where is the Keyboard version in the #3, extract and flash if possible in #1 and #2
I hope to restart this old subject >:D
I can confirm that installing 1.12/1.14 on an "upgraded" DG4062 running 1.08 preserves the 200Mhz "upgrade".Is it possible to upgrade directly from firmware v1.08 to v1.14 without a Bootloader upgrade?
Just to be safe I desoldered and cloned the flash chip first. Then I went from 1.05 to 1.08, new bootloader next, then 1.12 and 1.14.
No problems whatsoever.
With the newer versions it is no longer possible to change the model.But does the v1.12 or v1.14 downgrade the current model (DG4202 v1.08 in my case) like the v1.09 does ?
What about the calibration?
Does anybody have any info about the calibration under, and over 60 MHz, please?
My contribution to your cause is attached (parsing of all the DG4000 GELs that I have).
Don't know if looking at the various segments in each GEL allows you to identify the different parts.Code: [Select]F:\zscan\original\RIGOL\DG4000_GEL\DG4000 FPGA 00.01.08\DG4000Update.GEL / CRC32: E5BFBD9A
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - C000 C773 20300000 000C3DF6 00000008 00000008 [00000054-000C3E49] CRC OK
F:\zscan\original\RIGOL\DG4000_GEL\DG4000(Bootloader)Update_00.06\DG4000Update.GEL / CRC32: D8960038
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - D053 D2BD 20000000 00029710 3B4E0002 B1000002 [00000054-00029763] CRC OK
F:\zscan\original\RIGOL\DG4000_GEL\DG4000(DSP)Update_00.01.08.00.02\DG4000Update.GEL / CRC32: D36150FB
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - 4000 1017 20040000 0024AD90 00000004 00000004 [00000054-0024ADE3] CRC OK
0024ADE4 - 4000 913A 20300000 000C3DF6 00000008 00000008 [0024ADF8-0030EBED] CRC OK
0030EBEE - 4000 7697 20400000 0000165C 00000008 00000008 [0030EC02-0031025D] CRC OK
0031025E - 4000 2644 20440000 00000254 00000010 00000010 [00310272-003104C5] CRC OK
003104C6 - 4000 9DE4 20440400 0000286B 00000010 00000010 [003104DA-00312D44] CRC OK
00312D45 - 4000 636F 20443400 00000254 00000010 00000010 [00312D59-00312FAC] CRC OK
00312FAD - 4000 E553 20443800 00001A11 00000010 00000010 [00312FC1-003149D1] CRC OK
003149D2 - 4000 D12E 20460000 0000021A 00000010 00000010 [003149E6-00314BFF] CRC OK
00314C00 - 4000 C36B 20460400 0000F7F3 00000010 00000010 [00314C14-00324406] CRC OK
00324407 - 4000 4AF6 2046FC00 0000021A 00000010 00000010 [0032441B-00324634] CRC OK
00324635 - 4000 84CF 20470000 000095D7 00000010 00000010 [00324649-0032DC1F] CRC OK
0032DC20 - 4000 219D 205B0000 00169DE8 00000020 00000020 [0032DC34-00497A1B] CRC OK
00497A1C - 4000 A299 207B0000 0003D6C4 00000040 00000040 [00497A30-004D50F3] CRC OK
004D50F4 - 4000 FBF1 20830000 0004BBEC 00000040 00000040 [004D5108-00520CF3] CRC OK
00520CF4 - 0000 0000 208B0000 0000CF0C 00000040 00000040 [00520D08-0052DC13]
0052DC14 - 0000 0000 208F0000 0000644C 00000040 00000040 [0052DC28-00534073]
00534074 - 8000 0000 209B0000 00480000 00000080 00000080 [00534088-009B4087]
F:\zscan\original\RIGOL\DG4000_GEL\DG4000(Dsp)Update_00.01.12.00.02\DG4000Update.GEL / CRC32: 2A0D0C3C
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - 48EF 4F98 20040000 0025ABAC 25970004 FE000004 [00000054-0025ABFF] CRC OK
0025AC00 - 4053 790A 20300000 000C3DF6 73000008 00000008 [0025AC14-0031EA09] CRC OK
0031EA0A - 403F 8C44 20400000 00001661 F2000008 00000008 [0031EA1E-0032007E] CRC OK
0032007F - 4016 34ED 20440000 0000027E 8D000010 00000010 [00320093-00320310] CRC OK
00320311 - 4043 CA34 20440400 00002C18 03000010 00000010 [00320325-00322F3C] CRC OK
00322F3D - 405C 632B 20443400 0000027E 22000010 00000010 [00322F51-003231CE] CRC OK
003231CF - 4060 51F6 20443800 00001C36 93000010 00000010 [003231E3-00324E18] CRC OK
00324E19 - 4033 A7BA 20460000 00000232 FC000010 00000010 [00324E2D-0032505E] CRC OK
0032505F - 40F0 D041 20460400 0000FFCF 62000010 00000010 [00325073-00335041] CRC OK
00335042 - 403A C82A 20470400 00000232 1C000010 00000010 [00335056-00335287] CRC OK
00335288 - 404C 83E8 20470800 00009C1C D7000010 00000010 [0033529C-0033EEB7] CRC OK
0033EEB8 - 4017 219D 205B0000 00169DE8 FA000020 00000020 [0033EECC-004A8CB3] CRC OK
004A8CB4 - 40B6 A299 207B0000 0003D6C4 3B000040 00000040 [004A8CC8-004E638B] CRC OK
004E638C - 403E FBF1 20830000 0004BBEC 18000040 00000040 [004E63A0-00531F8B] CRC OK
00531F8C - 0000 0000 208B0000 0000DE90 00000040 00000040 [00531FA0-0053FE2F]
0053FE30 - 0000 0000 208F0000 00006C5A 00000040 00000040 [0053FE44-00546A9D]
00546A9E - 8000 0000 209B0000 00480000 00000080 00000080 [00546AB2-009C6AB1]
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.04.00.02\DG4000Update.GEL / CRC32: 902CF808
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - 4000 C90D 20040000 00228CF0 00000004 00000004 [00000054-00228D43] CRC OK
00228D44 - 4000 AF46 20300000 000C3DF6 00000008 00000008 [00228D58-002ECB4D] CRC OK
002ECB4E - 4000 8C44 20400000 00001661 00000008 00000008 [002ECB62-002EE1C2] CRC OK
002EE1C3 - 4000 8ED1 20440000 00000252 00000010 00000010 [002EE1D7-002EE428] CRC OK
002EE429 - 4000 5256 20440400 00002859 00000010 00000010 [002EE43D-002F0C95] CRC OK
002F0C96 - 4000 DCD6 20443400 00000252 00000010 00000010 [002F0CAA-002F0EFB] CRC OK
002F0EFC - 4000 042D 20443800 00001A00 00000010 00000010 [002F0F10-002F290F] CRC OK
002F2910 - 4000 EB6F 20460000 00000208 00000010 00000010 [002F2924-002F2B2B] CRC OK
002F2B2C - 4000 E168 20460400 0000F0CD 00000010 00000010 [002F2B40-00301C0C] CRC OK
00301C0D - 4000 3945 2046FC00 00000208 00000010 00000010 [00301C21-00301E28] CRC OK
00301E29 - 4000 9307 20470000 000091BC 00000010 00000010 [00301E3D-0030AFF8] CRC OK
0030AFF9 - 4000 219D 205B0000 00169DE8 00000020 00000020 [0030B00D-00474DF4] CRC OK
00474DF5 - 4000 A299 207B0000 0003D6C4 00000040 00000040 [00474E09-004B24CC] CRC OK
004B24CD - 4000 63BD 20830000 0004BB9C 00000040 00000040 [004B24E1-004FE07C] CRC OK
004FE07D - 8000 0000 209B0000 00480000 00000080 00000080 [004FE091-0097E090]
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.04.00.02\Piranha(DSP)Update_00.01.04.00.02\DG4000Update.GEL / CRC32: 902CF808
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - 4000 C90D 20040000 00228CF0 00000004 00000004 [00000054-00228D43] CRC OK
00228D44 - 4000 AF46 20300000 000C3DF6 00000008 00000008 [00228D58-002ECB4D] CRC OK
002ECB4E - 4000 8C44 20400000 00001661 00000008 00000008 [002ECB62-002EE1C2] CRC OK
002EE1C3 - 4000 8ED1 20440000 00000252 00000010 00000010 [002EE1D7-002EE428] CRC OK
002EE429 - 4000 5256 20440400 00002859 00000010 00000010 [002EE43D-002F0C95] CRC OK
002F0C96 - 4000 DCD6 20443400 00000252 00000010 00000010 [002F0CAA-002F0EFB] CRC OK
002F0EFC - 4000 042D 20443800 00001A00 00000010 00000010 [002F0F10-002F290F] CRC OK
002F2910 - 4000 EB6F 20460000 00000208 00000010 00000010 [002F2924-002F2B2B] CRC OK
002F2B2C - 4000 E168 20460400 0000F0CD 00000010 00000010 [002F2B40-00301C0C] CRC OK
00301C0D - 4000 3945 2046FC00 00000208 00000010 00000010 [00301C21-00301E28] CRC OK
00301E29 - 4000 9307 20470000 000091BC 00000010 00000010 [00301E3D-0030AFF8] CRC OK
0030AFF9 - 4000 219D 205B0000 00169DE8 00000020 00000020 [0030B00D-00474DF4] CRC OK
00474DF5 - 4000 A299 207B0000 0003D6C4 00000040 00000040 [00474E09-004B24CC] CRC OK
004B24CD - 4000 63BD 20830000 0004BB9C 00000040 00000040 [004B24E1-004FE07C] CRC OK
004FE07D - 8000 0000 209B0000 00480000 00000080 00000080 [004FE091-0097E090]
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.05.00.04\DG4000Update.GEL / CRC32: D1689375
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - 4000 3C14 20040000 0022CF98 00000004 00000004 [00000054-0022CFEB] CRC OK
0022CFEC - 4000 09F9 20300000 000C3CE2 00000008 00000008 [0022D000-002F0CE1] CRC OK
002F0CE2 - 4000 8C44 20400000 00001661 00000008 00000008 [002F0CF6-002F2356] CRC OK
002F2357 - 4000 8ED1 20440000 00000252 00000010 00000010 [002F236B-002F25BC] CRC OK
002F25BD - 4000 5256 20440400 00002859 00000010 00000010 [002F25D1-002F4E29] CRC OK
002F4E2A - 4000 DCD6 20443400 00000252 00000010 00000010 [002F4E3E-002F508F] CRC OK
002F5090 - 4000 042D 20443800 00001A00 00000010 00000010 [002F50A4-002F6AA3] CRC OK
002F6AA4 - 4000 184D 20460000 0000020A 00000010 00000010 [002F6AB8-002F6CC1] CRC OK
002F6CC2 - 4000 B518 20460400 0000F126 00000010 00000010 [002F6CD6-00305DFB] CRC OK
00305DFC - 4000 7121 2046FC00 0000020A 00000010 00000010 [00305E10-00306019] CRC OK
0030601A - 4000 367E 20470000 000091E4 00000010 00000010 [0030602E-0030F211] CRC OK
0030F212 - 4000 219D 205B0000 00169DE8 00000020 00000020 [0030F226-0047900D] CRC OK
0047900E - 4000 A299 207B0000 0003D6C4 00000040 00000040 [00479022-004B66E5] CRC OK
004B66E6 - 4000 63BD 20830000 0004BB9C 00000040 00000040 [004B66FA-00502295] CRC OK
00502296 - 8000 0000 209B0000 00480000 00000080 00000080 [005022AA-009822A9]
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.06.00.02\DG4000Update.GEL / CRC32: EB7EF2D7
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - 4000 8725 20040000 00202608 00000004 00000004 [00000054-0020265B] CRC OK
0020265C - 4000 9052 20300000 000C3DF6 00000008 00000008 [00202670-002C6465] CRC OK
002C6466 - 4000 7697 20400000 0000165C 00000008 00000008 [002C647A-002C7AD5] CRC OK
002C7AD6 - 4000 8ED1 20440000 00000252 00000010 00000010 [002C7AEA-002C7D3B] CRC OK
002C7D3C - 4000 5256 20440400 00002859 00000010 00000010 [002C7D50-002CA5A8] CRC OK
002CA5A9 - 4000 DCD6 20443400 00000252 00000010 00000010 [002CA5BD-002CA80E] CRC OK
002CA80F - 4000 042D 20443800 00001A00 00000010 00000010 [002CA823-002CC222] CRC OK
002CC223 - 4000 5F4B 20460000 0000020C 00000010 00000010 [002CC237-002CC442] CRC OK
002CC443 - 4000 7D3C 20460400 0000F144 00000010 00000010 [002CC457-002DB59A] CRC OK
002DB59B - 4000 774F 2046FC00 0000020C 00000010 00000010 [002DB5AF-002DB7BA] CRC OK
002DB7BB - 4000 6E3C 20470000 000091F7 00000010 00000010 [002DB7CF-002E49C5] CRC OK
002E49C6 - 4000 219D 205B0000 00169DE8 00000020 00000020 [002E49DA-0044E7C1] CRC OK
0044E7C2 - 4000 A299 207B0000 0003D6C4 00000040 00000040 [0044E7D6-0048BE99] CRC OK
0048BE9A - 4000 FBF1 20830000 0004BBEC 00000040 00000040 [0048BEAE-004D7A99] CRC OK
004D7A9A - 8000 0000 209B0000 00480000 00000080 00000080 [004D7AAE-00957AAD]
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.07.00.03\DG4000Update.GEL / CRC32: 9AEA33D0
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - 4000 3A3C 20040000 0021C000 00000004 00000004 [00000054-0021C053] CRC OK
0021C054 - 4000 C773 20300000 000C3DF6 00000008 00000008 [0021C068-002DFE5D] CRC OK
002DFE5E - 4000 7697 20400000 0000165C 00000008 00000008 [002DFE72-002E14CD] CRC OK
002E14CE - 4000 8ED1 20440000 00000252 00000010 00000010 [002E14E2-002E1733] CRC OK
002E1734 - 4000 5256 20440400 00002859 00000010 00000010 [002E1748-002E3FA0] CRC OK
002E3FA1 - 4000 DCD6 20443400 00000252 00000010 00000010 [002E3FB5-002E4206] CRC OK
002E4207 - 4000 042D 20443800 00001A00 00000010 00000010 [002E421B-002E5C1A] CRC OK
002E5C1B - 4000 5F4B 20460000 0000020C 00000010 00000010 [002E5C2F-002E5E3A] CRC OK
002E5E3B - 4000 7D3C 20460400 0000F144 00000010 00000010 [002E5E4F-002F4F92] CRC OK
002F4F93 - 4000 774F 2046FC00 0000020C 00000010 00000010 [002F4FA7-002F51B2] CRC OK
002F51B3 - 4000 6E3C 20470000 000091F7 00000010 00000010 [002F51C7-002FE3BD] CRC OK
002FE3BE - 4000 219D 205B0000 00169DE8 00000020 00000020 [002FE3D2-004681B9] CRC OK
004681BA - 4000 A299 207B0000 0003D6C4 00000040 00000040 [004681CE-004A5891] CRC OK
004A5892 - 4000 FBF1 20830000 0004BBEC 00000040 00000040 [004A58A6-004F1491] CRC OK
004F1492 - 8000 0000 209B0000 00480000 00000080 00000080 [004F14A6-009714A5]
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.07.00.03\DG4000(DSP)update\Piranha(DSP)Update_00.01.07.00.03\DG4000Update.GEL / CRC32: 9AEA33D0
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - 4000 3A3C 20040000 0021C000 00000004 00000004 [00000054-0021C053] CRC OK
0021C054 - 4000 C773 20300000 000C3DF6 00000008 00000008 [0021C068-002DFE5D] CRC OK
002DFE5E - 4000 7697 20400000 0000165C 00000008 00000008 [002DFE72-002E14CD] CRC OK
002E14CE - 4000 8ED1 20440000 00000252 00000010 00000010 [002E14E2-002E1733] CRC OK
002E1734 - 4000 5256 20440400 00002859 00000010 00000010 [002E1748-002E3FA0] CRC OK
002E3FA1 - 4000 DCD6 20443400 00000252 00000010 00000010 [002E3FB5-002E4206] CRC OK
002E4207 - 4000 042D 20443800 00001A00 00000010 00000010 [002E421B-002E5C1A] CRC OK
002E5C1B - 4000 5F4B 20460000 0000020C 00000010 00000010 [002E5C2F-002E5E3A] CRC OK
002E5E3B - 4000 7D3C 20460400 0000F144 00000010 00000010 [002E5E4F-002F4F92] CRC OK
002F4F93 - 4000 774F 2046FC00 0000020C 00000010 00000010 [002F4FA7-002F51B2] CRC OK
002F51B3 - 4000 6E3C 20470000 000091F7 00000010 00000010 [002F51C7-002FE3BD] CRC OK
002FE3BE - 4000 219D 205B0000 00169DE8 00000020 00000020 [002FE3D2-004681B9] CRC OK
004681BA - 4000 A299 207B0000 0003D6C4 00000040 00000040 [004681CE-004A5891] CRC OK
004A5892 - 4000 FBF1 20830000 0004BBEC 00000040 00000040 [004A58A6-004F1491] CRC OK
004F1492 - 8000 0000 209B0000 00480000 00000080 00000080 [004F14A6-009714A5]
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.09\DG4000Update_Bootloader.GEL / CRC32: D8960038
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - D053 D2BD 20000000 00029710 3B4E0002 B1000002 [00000054-00029763] CRC OK
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.09\DG4000Update_DSP.GEL / CRC32: DDA03A46
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - 4834 17B4 20040000 00247D04 D6BF0004 8A000004 [00000054-00247D57] CRC OK
00247D58 - 40B4 913A 20300000 000C3DF6 8B000008 00000008 [00247D6C-0030BB61] CRC OK
0030BB62 - 402B 7697 20400000 0000165C 87000008 00000008 [0030BB76-0030D1D1] CRC OK
0030D1D2 - 40DD AB61 20440000 0000025C BF000010 00000010 [0030D1E6-0030D441] CRC OK
0030D442 - 40D0 ECA7 20440400 000028F9 AC000010 00000010 [0030D456-0030FD4E] CRC OK
0030FD4F - 4078 168A 20443400 0000025C 85000010 00000010 [0030FD63-0030FFBE] CRC OK
0030FFBF - 40B9 5A4F 20443800 00001A6A B3000010 00000010 [0030FFD3-00311A3C] CRC OK
00311A3D - 407E D12E 20460000 0000021A A5000010 00000010 [00311A51-00311C6A] CRC OK
00311C6B - 408D C36B 20460400 0000F7F3 ED000010 00000010 [00311C7F-00321471] CRC OK
00321472 - 40DF 4AF6 2046FC00 0000021A FD000010 00000010 [00321486-0032169F] CRC OK
003216A0 - 4041 84CF 20470000 000095D7 77000010 00000010 [003216B4-0032AC8A] CRC OK
0032AC8B - 4017 219D 205B0000 00169DE8 FA000020 00000020 [0032AC9F-00494A86] CRC OK
00494A87 - 40B6 A299 207B0000 0003D6C4 3B000040 00000040 [00494A9B-004D215E] CRC OK
004D215F - 403E FBF1 20830000 0004BBEC 18000040 00000040 [004D2173-0051DD5E] CRC OK
0051DD5F - 0000 0000 208B0000 0000CF0C 00000040 00000040 [0051DD73-0052AC7E]
0052AC7F - 0000 0000 208F0000 0000644C 00000040 00000040 [0052AC93-005310DE]
005310DF - 8000 0000 209B0000 00480000 00000080 00000080 [005310F3-009B10F2]
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.10.00.00\DG4000(Bootloader)Update_00.06\DG4000Update.GEL / CRC32: D8960038
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - D053 D2BD 20000000 00029710 3B4E0002 B1000002 [00000054-00029763] CRC OK
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.10.00.00\DG4000(Dsp)Update_00.01.10.00.00\DG4000Update.GEL / CRC32: B617C0B0
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - 485D FEAF 20040000 0024CD2C EE6A0004 EB000004 [00000054-0024CD7F] CRC OK
0024CD80 - 40B8 6F4D 20300000 000C3F0A 8C000008 00000008 [0024CD94-00310C9D] CRC OK
00310C9E - 403F 8C44 20400000 00001661 F2000008 00000008 [00310CB2-00312312] CRC OK
00312313 - 40B9 D9CB 20440000 00000270 71000010 00000010 [00312327-00312596] CRC OK
00312597 - 4053 FBDF 20440400 00002AEC 4F000010 00000010 [003125AB-00315096] CRC OK
00315097 - 40EA D4AB 20443400 00000270 75000010 00000010 [003150AB-0031531A] CRC OK
0031531B - 4053 E5B5 20443800 00001B88 8A000010 00000010 [0031532F-00316EB6] CRC OK
00316EB7 - 40DD 21CE 20460000 0000022C EE000010 00000010 [00316ECB-003170F6] CRC OK
003170F7 - 406E 4072 20460400 0000FDC4 47000010 00000010 [0031710B-00326ECE] CRC OK
00326ECF - 406A 0F08 20470400 0000022C D4000010 00000010 [00326EE3-0032710E] CRC OK
0032710F - 404A C5D3 20470800 000098FD 1C000010 00000010 [00327123-00330A1F] CRC OK
00330A20 - 4017 219D 205B0000 00169DE8 FA000020 00000020 [00330A34-0049A81B] CRC OK
0049A81C - 40B6 A299 207B0000 0003D6C4 3B000040 00000040 [0049A830-004D7EF3] CRC OK
004D7EF4 - 403E FBF1 20830000 0004BBEC 18000040 00000040 [004D7F08-00523AF3] CRC OK
00523AF4 - 0000 0000 208B0000 0000DA98 00000040 00000040 [00523B08-0053159F]
005315A0 - 0000 0000 208F0000 00006A9E 00000040 00000040 [005315B4-00538051]
00538052 - 8000 0000 209B0000 00480000 00000080 00000080 [00538066-009B8065]
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.11.00.00\DG4000(Bootloader)Update_00.06\DG4000Update.GEL / CRC32: D8960038
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - D053 D2BD 20000000 00029710 3B4E0002 B1000002 [00000054-00029763] CRC OK
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.11.00.00\DG4000(Dsp)Update_00.01.11.00.00\DG4000Update.GEL / CRC32: 4C561044
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - 4867 C712 20040000 0024AE08 9B5D0004 CB000004 [00000054-0024AE5B] CRC OK
0024AE5C - 4053 790A 20300000 000C3DF6 73000008 00000008 [0024AE70-0030EC65] CRC OK
0030EC66 - 403F 8C44 20400000 00001661 F2000008 00000008 [0030EC7A-003102DA] CRC OK
003102DB - 40B9 D9CB 20440000 00000270 71000010 00000010 [003102EF-0031055E] CRC OK
0031055F - 4053 FBDF 20440400 00002AEC 4F000010 00000010 [00310573-0031305E] CRC OK
0031305F - 40EA D4AB 20443400 00000270 75000010 00000010 [00313073-003132E2] CRC OK
003132E3 - 4053 E5B5 20443800 00001B88 8A000010 00000010 [003132F7-00314E7E] CRC OK
00314E7F - 40DD 21CE 20460000 0000022C EE000010 00000010 [00314E93-003150BE] CRC OK
003150BF - 406E 4072 20460400 0000FDC4 47000010 00000010 [003150D3-00324E96] CRC OK
00324E97 - 4026 2D33 20470400 0000022C A5000010 00000010 [00324EAB-003250D6] CRC OK
003250D7 - 40AE F3AF 20470800 000098FB A2000010 00000010 [003250EB-0032E9E5] CRC OK
0032E9E6 - 4017 219D 205B0000 00169DE8 FA000020 00000020 [0032E9FA-004987E1] CRC OK
004987E2 - 40B6 A299 207B0000 0003D6C4 3B000040 00000040 [004987F6-004D5EB9] CRC OK
004D5EBA - 403E FBF1 20830000 0004BBEC 18000040 00000040 [004D5ECE-00521AB9] CRC OK
00521ABA - 0000 0000 208B0000 0000DE90 00000040 00000040 [00521ACE-0052F95D]
0052F95E - 0000 0000 208F0000 00006C5A 00000040 00000040 [0052F972-005365CB]
005365CC - 8000 0000 209B0000 00480000 00000080 00000080 [005365E0-009B65DF]
F:\zscan\original\RIGOL\DG4000_GEL\Piranha(DSP)Update_00.01.14.00.01\DG4000(DSP)update 01.14.00.01\DG4000(DSP)update\DG4000Update.GEL / CRC32: BDFA4DD0
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Offset Flag CRC LoadAdd Size
00000040 - 4832 59D8 20040000 0026210C 2E240004 1A000004 [00000054-0026215F] CRC OK
00262160 - 4053 790A 20300000 000C3DF6 73000008 00000008 [00262174-00325F69] CRC OK
00325F6A - 403F 8C44 20400000 00001661 F2000008 00000008 [00325F7E-003275DE] CRC OK
003275DF - 4016 34ED 20440000 0000027E 8D000010 00000010 [003275F3-00327870] CRC OK
00327871 - 4043 CA34 20440400 00002C18 03000010 00000010 [00327885-0032A49C] CRC OK
0032A49D - 405C 632B 20443400 0000027E 22000010 00000010 [0032A4B1-0032A72E] CRC OK
0032A72F - 4060 51F6 20443800 00001C36 93000010 00000010 [0032A743-0032C378] CRC OK
0032C379 - 4033 A7BA 20460000 00000232 FC000010 00000010 [0032C38D-0032C5BE] CRC OK
0032C5BF - 40F0 D041 20460400 0000FFCF 62000010 00000010 [0032C5D3-0033C5A1] CRC OK
0033C5A2 - 403A C82A 20470400 00000232 1C000010 00000010 [0033C5B6-0033C7E7] CRC OK
0033C7E8 - 404C 83E8 20470800 00009C1C D7000010 00000010 [0033C7FC-00346417] CRC OK
00346418 - 4017 219D 205B0000 00169DE8 FA000020 00000020 [0034642C-004B0213] CRC OK
004B0214 - 40B6 A299 207B0000 0003D6C4 3B000040 00000040 [004B0228-004ED8EB] CRC OK
004ED8EC - 403E FBF1 20830000 0004BBEC 18000040 00000040 [004ED900-005394EB] CRC OK
005394EC - 0000 0000 208B0000 000126F4 00000040 00000040 [00539500-0054BBF3]
0054BBF4 - 0000 0000 208F0000 00008F2C 00000040 00000040 [0054BC08-00554B33]
00554B34 - 8000 0000 209B0000 00480000 00000080 00000080 [00554B48-009D4B47]
How did you parse these segments of the GEL file ?
Is there a tool for that?
Can this tool extract these segments as separate files ?
Can this tool calculate the checksum (CRC) of an altered segment and update the GEL file with it ?
Is it possible to disassemble the code in these segments with IDA ?
P.S.
What CPU does the DG4000 firmware run on ?
What FPGA does the DG4000 firmware run on ?
1. With a special parser that I developed.Would you send me the source code for it? I'd like to improve it.
But, with the information that I show in the parsing you could do that easily with any hex editor.Of course
4. The ones that have executable code can be looked at in IDA.Isn't the code obfuscated?
5. I can have a look that. But, isn't there any PCB photos that let you identify the ICs involved?Not that, I know of.
What CPU does the DG4000 firmware run on ?
The firmware has '(DSP)' in the filename rather than '(ARM)', which probably means it will be an Analog Devices Blackfin part, like the DS2000 uses.Shit!
The firmware has '(DSP)' in the filename rather than '(ARM)', which probably means it will be an Analog Devices Blackfin part, like the DS2000 uses.Shit!
IDA 7 does not support this Analog Devices BlackFin ADSP-BF526 processor and a 3rd party BlackFin plugin is 8 years old :(
The 3rd party plugin should help, despite it's age....but how? alas the ADSP-BF526 did not even exist then. Anyway the IDA v7 is not even compatible with this plugin because the API changed between v6 and v7.
If you have any particular block you are sure you would like to analyse, I can dump it for you in a way you don't need to rely on the plugin.I would not even know the block at this stage of investigation.
...but how? alas the ADSP-BF526 did not even exist then. Anyway the IDA v7 is not even compatible with this plugin because the API changed between v6 and v7.
...
I would not even know the block at this stage of investigation.
I've checked my code. You have the CRC16 parameters wrong.I was not wrong
Based on what RoGeorde said and your level of knowledge about the BF, I think this is beyond your capabilities. It's beyond mine for sure!Yes, it is beyond now, but I have built and learned undocumented CPU architectures before... and the BlackFin is documented, isn't it?
Given how similar the DG4000 UI is to the DG1022Z, I wonder if the 'magic' USB drive with SCPI upgrade approach would work?
00000000 - File Type: RIGOL:DG4:UPDATE FILE ALL
Deobfuscating...
Header_LDR_block / CRC2 Validation OK
Header_LDR_block / CRC3 Validation OK
FW Signature: 0x51 OK
Offset Flags CRC1 CRC2 CRC3 LoadAdd Size LED1 LED2
00000040 - 01001000(48) 59D8 322E 241A 20040000 0026210C 0004 000004 [00000054-0026215F] 256 Bytes + .LDR block CRC3 OK CRC2 OK CRC1 OK
00262160 - 01000000(40) 790A 5373 0000 20300000 000C3DF6 0008 000008 [00262174-00325F69] FPGA bitstream CRC2 OK CRC1 OK
00325F6A - 01000000(40) 8C44 3FF2 0000 20400000 00001661 0008 000008 [00325F7E-003275DE] Definitions (???) CRC2 OK CRC1 OK
003275DF - 01000000(40) 34ED 168D 0000 20440000 0000027E 0010 000010 [003275F3-00327870] Strings Indexes CRC2 OK CRC1 OK
00327871 - 01000000(40) CA34 4303 0000 20440400 00002C18 0010 000010 [00327885-0032A49C] Strings CRC2 OK CRC1 OK
0032A49D - 01000000(40) 632B 5C22 0000 20443400 0000027E 0010 000010 [0032A4B1-0032A72E] Strings Indexes CRC2 OK CRC1 OK
0032A72F - 01000000(40) 51F6 6093 0000 20443800 00001C36 0010 000010 [0032A743-0032C378] Strings CRC2 OK CRC1 OK
0032C379 - 01000000(40) A7BA 33FC 0000 20460000 00000232 0010 000010 [0032C38D-0032C5BE] Strings Indexes CRC2 OK CRC1 OK
0032C5BF - 01000000(40) D041 F062 0000 20460400 0000FFCF 0010 000010 [0032C5D3-0033C5A1] Strings CRC2 OK CRC1 OK
0033C5A2 - 01000000(40) C82A 3A1C 0000 20470400 00000232 0010 000010 [0033C5B6-0033C7E7] Strings Indexes CRC2 OK CRC1 OK
0033C7E8 - 01000000(40) 83E8 4CD7 0000 20470800 00009C1C 0010 000010 [0033C7FC-00346417] Strings CRC2 OK CRC1 OK
00346418 - 01000000(40) 219D 17FA 0000 205B0000 00169DE8 0020 000020 [0034642C-004B0213] Graphics, Images CRC2 OK CRC1 OK
004B0214 - 01000000(40) A299 B63B 0000 207B0000 0003D6C4 0040 000040 [004B0228-004ED8EB] Data (0x00) CRC2 OK CRC1 OK
004ED8EC - 01000000(40) FBF1 3E18 0000 20830000 0004BBEC 0040 000040 [004ED900-005394EB] Data (0x00) CRC2 OK CRC1 OK
005394EC - 00000000(00) 0000 0000 0000 208B0000 000126F4 0040 000040 [00539500-0054BBF3] Data (0x48) CRC: 7E9A
0054BBF4 - 00000000(00) 0000 0000 0000 208F0000 00008F2C 0040 000040 [0054BC08-00554B33] Data (0x48) CRC: F392
00554B34 - 10000000(80) 0000 0000 0000 209B0000 00480000 0080 000080 [00554B48-009D4B47] CPLD (???) CRC: BD1E
│││││
││││└─ 256-bytes header block (before app)
│││└── 64-bytes footer block (after bootloader)
││└─── FRAM(?) write select (default: 0 -> FLASH write select)
│└──── CRC validation required
└───── Last block
Where did you find FW 00.01.14.00.01 (GEL File) for the DS4000...
[Model Supported] DG4062,DG4102,DG4162,DG4202
[Latest Revision Date] 2017-12-23
[Updated Contents]
v00.01.14.00.01 2017-12-23
- Solve the abnormal output of part of the machine CH1 at normal temperature or low temperature
- Solve the keyboard board encoder causing crashes.
[Previous Versions and Updated Contents]
v00.01.13.00.00 2015-11-05
- Added Traditional Chinese in the Menu.
- The EdgeTime is too slow when the 5MHz square wave is modified to sweep frequency,
- Output can not be changed in real time when editing any wave point.
Anyway, liberated after all :-+ So can we now safely update to 1.13/1.14?
Reminder of the main steps to do the upgrade
==================================
1. Upgrade normally to latest FW1.14.01 from Rigol
2. Downgrade to modified by TV84 FW1.08
3. Use cengen.exe in Windows to generate a license file for DG4202
4. Read the CEN file with DG4102 FW1.08 modified
5. Upgrade to latest unmodified FW1.14.01 from Rigol
DG 4102 should now be seen as DG4202 and the max allowed sinus frequency should be 200MHz.
-------------------------
-The USB drive should be formatted FAT32
-DG4000Update.GEL should be copied alone on the clean formatted USB drive
-To update FW
- insert USB with desired GEL file
- power down the DG4102
- keep the 'Help' button pressed while pressing the 'Power ON' button
- release the 'Help' button when 'Utility' button starts to flash
- from there, leave the unit running, the buttons will start to blink one by one, starting with 'Ramp'
- after about 10 minutes, the DG4000 will restart itself, firmware update is now done
-To see FW version press 'Utility' -> 'System' -> 'System Info'
-To see detailed version press 'Utility' -> 'System' -> 'System Info' -> 'G1' ->'G3' -> 'G5'
where G1...G5 are the grey buttons on the right of the screen
--------------------------
Is there something I can do now to back up my machine before the flashing without opening the machine? There is still a 90day warranty on this clearance unit (I think).
Without opening it, no.
Yes, you are. :)
cengen.exe DG4062 DG4202 DG4Exxxxxxxxxx
Read file "license.CEN" (upgrade generator).
zitt -
did you check the level accuracy of your DG4000 after the "liberation"? I found mine to be spot on up to 200MHz (DS4102 from Q4/2015). Maybe yours also doesn't need to be calibrated at all.
P.s. If you haven't got a spectrum analyzer or a calibrated level meter, you may DIY a detector type level tester with a 50R terminator resistor (preferably 2*100R 1% 805 in parallel), a small signal, low capacitance schottky diode, a 10n smoothing capacitor and maybe a 10k load resistor, coupled to a multimeter. All this has to be assembled just a the back of a BNC connector to keep the impedance low. This "bodge" should give you a good idea of your generator's level accuracy.
Here is my firmware collection. The instructions for updating are included.Code: [Select]http://peter.dreisiebner.at/tmp/rigol_dg4000_firmware.7z
Peter
I waited 7 minutes and not one of the waveform lights had come on.
Hi All,
Does anyone know if the secure calibration passsword has been found? If so, would anyone mind sharing? I looked through the thread and didn't see anything.
Thank you
[EDIT] It's fixed, I used a different (older) USB drive, that is the problem 99.9999999999999999999% of the time with these updates in my experience. So the original drives must have allowed the bootloader to update but then, the same drive, wouldn't do the firmware update! It kept the Model at DG4202...
I've tried the counter and it seems 'better' 1) it hasn't crashed yet 2) it actually counts. I looked at some 'square' waves which were like slightly squared sine waves by the time I got up to 25 MHz, at 50 MHz they were sine waves. I'll come up with pictures if you want.[EDIT] It's fixed, I used a different (older) USB drive, that is the problem 99.9999999999999999999% of the time with these updates in my experience. So the original drives must have allowed the bootloader to update but then, the same drive, wouldn't do the firmware update! It kept the Model at DG4202...
I keep one USB drive apart for the DG4000 with a label "DG4000 UPGRADE" on it. I think I tried close to 10 different sticks before I found one that worked.
So... how is you counter now? And your square wave?
[Model Supported] DG4062,DG4102,DG4162,DG4202
[Latest Revision Date] 2017-12-23
[Updated Contents]
v00.01.14.00.01 2017-12-23
- Solve the abnormal output of part of the machine CH1 at normal temperature or low temperature
- Solve the keyboard board encoder causing crashes.
[Previous Versions and Updated Contents]
v00.01.13.00.00 2015-11-05
- Added Traditional Chinese in the Menu.
- The EdgeTime is too slow when the 5MHz square wave is modified to sweep frequency,
- Output can not be changed in real time when editing any wave point.
I have a DG4062 that I 'upgraded' to a DG4202 back in Aug 2014 and made no changes since, it reports the following under system info...
...
Anyway, I tried to use the frequency counter (32,768 Hz signal) yesterday and it was useless, locked up even. That made me revisit this thread.
Now update to v1.14 (attached).Thanks, now I see...
[EDIT] It's fixed, I used a different (older) USB drive, that is the problem 99.9999999999999999999% of the time with these updates in my experience. So the original drives must have allowed the bootloader to update but then, the same drive, wouldn't do the firmware update!Buying a small pendrive nowadays borders a miracle!
Just tried Linux - it did not work.
Could you post the partition table and Boot Sector/FS Information Sector so I can see what parameters work ?
Maybe the pendrive must support CHS addressing and the FAT partition must start on cylinder 1, ...or on head 0 and sector 1, etc...
You need to use a small pen and not worry with those inner works.I need to worry about these details because, the smallest pendrive I have is 8GB.
You need to use a small pen and not worry with those inner works.I need to worry about these details because, the smallest pendrive I have is 8GB.
I tried local computer stores - nothing
I tried local toy stores - nothing
I tried local novelty stores - nothing
I even asked my neighbors - nothing (although when I offered to trade a new 64GB pendrive for an old small used one, they suspected it was some kind of scam).
Here is the information from my 1 GB USB stick I use for the DG4000.OK, I adjusted the partition table and the FAT16 parameter block to be as close to yours as possible (see the attachment), Windows can mount and write to this pendrive, chkdsk reports no errors, but it does not work with the DG4000.
You could record the USB protocol during the update from the USB stick. Once from a good and once from a bad USB stick. I'd have the option to do that. But searching the log is gonna be tedious.Yup, that would be the next step in the analysis of the problem, but I don't have a USB capture device ...nor a DG400 "approved" pendrive for comparison.
Try an USB SD card reader with any card inside.I did, without success ...but not with the clone of the "approved" FAT16 file system like before.
I now wanted to record the data with a self-made USB cable. But this does not work, the DG4000 gets stuck with the three illuminated buttons. Could this indicate a voltage problem?It could indicate intolerance of the boot-loader's code to propagation delays occurring in a longer cable. How long was it?
The cable works without problems if the USB stick is used during normal operation of the DG4000.
Try an USB SD card reader with any card inside.I did, without success ...but not with the clone of the "approved" FAT16 file system like before.
The MOD button is lit up steadily and the UTILITY button flashes slowly ...forever.
Why are you using FAT16 format? I remember mine it was formatted FAT32.Because our resident expert "tv84" has written here (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg3173408/#msg3173408) that it is OK to use FAT16 and "PeDre" has posted his file system structure here (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg3173540/#msg3173540), which contained FAT16. I just cloned it.
I have tested several other USB sticks with 4 and 8 GB, but none works with the update. Even an external power supply for the USB stick does not help.
During testing I noticed that you have to press the help button very fast, otherwise the update will not work.
-DG4000Update.GEL should be copied alone on the clean formatted USB drive (mine was FAT32)
-To update FW
- insert USB with desired GEL file
- power down the DG4102
- keep the 'Help' button pressed while pressing the 'Power ON' button
- release the 'Help' button when 'Utility' button starts to flash
- from there, leave the unit running, the buttons will start to blink one by one, starting with 'Ramp'
- after about 10 minutes, the DG4000 will restart itself, firmware update is now done
-To see FW version press 'Utility' -> 'System' -> 'System Info'
-To see detailed version press 'Utility' -> 'System' -> 'System Info' -> 'G1' ->'G3' -> 'G5'
where G1...G5 are the grey buttons on the right of the screen
I kept the 'Help' button continuously pressed, from the powered off state until 'Utility' starts to flash, like I wrote in my update log.
If I hold down the help button when I turn on the DG4000, it will boot normally without starting the update.
I can only press the Help button after powering up for the update.
Do you have consistent behavior with that technique?
Does the same Agilent voltmeter shows the generated voltage (after calibration) as correct (constant) when tested at various fixed frequencies? If not, then the calibration procedure went wrong.
If yes, then it's either the voltmeter or the spectrum analyzer.
How do you calibration? Need Powermeter?
Warm DG4000 up for at least 30 minutes. Press Utility Test/Cal
Secure Code, use the knob and direction keys to enter the correct password, press
Secure and the calibration safety protection turns off.
I just got an accurate 10MHz source (Leo Bodnar, Mini) and I thought about calibrating the freq of my DG4102 (not hacked, yet, FW1.07 HW1.01)
In the manual they mention:QuoteWarm DG4000 up for at least 30 minutes. Press Utility Test/Cal
Secure Code, use the knob and direction keys to enter the correct password, press
Secure and the calibration safety protection turns off.
Do we know what this secure code is? (I didn't find it in this thread?)
The internal frequency is only off by 1.2Hz too low though.
Generally speaking, we do not recommend the upgrade of the DG4000 firmware with series before 00.01.08.002 or the keyboard version before 05.01.
After upgrading the DG4000 using the bootloader program, the calibration data will be cleared, and the unit needs to be recalibrated. This cannot be completed on the customer side, as bootloaders are usually not directly developed for the customer's use.
However, if customers emphasize on upgrading the firmware, the unit will have to be returned for replacing the DG4000 mainboard. This will imply a charge of the service.