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

0 Members and 1 Guest are viewing this topic.

Offline Mahoo

  • Newbie
  • Posts: 1
Re: DG4000 - a firmware investigation
« Reply #300 on: September 12, 2015, 03:00:28 pm »
Rigol has released the official dg4202 model 200hz function generator.
http://www.rigol.com/prodserv/127/

Now hopefully there will be some more action on this thread now we know that there is potential to hack the dg4000 for 200hz again and someone will work out how to bypass bootloader.
 

Offline Gunb

  • Regular Contributor
  • *
  • Posts: 221
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #301 on: September 21, 2015, 09:31:52 am »
Hi,

short question: how to identify the bootloader version? Which of the listed numbers identifies the bootloader version installed?

Thanks!
 

Offline rramirez

  • Contributor
  • Posts: 10
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #302 on: October 24, 2015, 05:10:02 pm »
I'm just trying to update my DG4062 from 1.07 to 1.12 (no hacks) - no luck, but no harm either.

I unzipped the file from Rigol US and first copied the .06 Bootloader onto a FAT32 formatted 2GB USB stick. I had no trouble getting the Utility button light to blink and go solid, followed by the Store button light. The instructions say that the Waveform menu lights should blink then go solid and when they are all lit, power-off the DG4000; but that never happens. After the Store button lights solid, the unit just sits there.

Is a 2GB USB stick too large? The DG4062 fully powered on does recognize the stick after it's plugged-in. Any ideas?

Russ
Russ
 

Offline devpeeps

  • Newbie
  • Posts: 3
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #303 on: December 11, 2015, 02:22:05 am »
just ordered one of these bad boys so looking forward to playing around with these settings you're talking about
 

Offline m1ke

  • Newbie
  • Posts: 1
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #304 on: December 21, 2015, 04:04:11 pm »
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
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.

-Clayton



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

Offline dr.diesel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: us
  • Cramming the magic smoke back in...
Re: DG4000 - a firmware investigation
« Reply #305 on: December 21, 2015, 04:16:52 pm »
Hi  I can't get this to compile.....keeps giving errors..... can someone please help

Uh, perhaps posting the error(s) might help?  No way for us to simply guess.

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 450
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #306 on: December 21, 2015, 04:47:56 pm »
Hi, this is the error

Did you type "gcc main.c -m32 -o cengen" (without the quotes) to compile your "main.c" file into executable "cengen" ?

It looks like you entered a long string starting with "<DG4062> <..." on the command line, which doesn't make sense.  The shell gives you the error that it doesn't understand the syntax beginning with '<'

 

Offline malekia

  • Contributor
  • Posts: 17
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #307 on: May 07, 2016, 04:25:22 pm »
I'm going to buy a DG4062 or possibly DG4102. Should I assume that:

A) I will NOT be able to apply a hack

B) I WILL be able to apply a hack

C) There's a 50/50 percent chance that I will be able to apply a hack
 

Offline TurboTom

  • Super Contributor
  • ***
  • Posts: 1389
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #308 on: May 08, 2016, 09:55:09 am »
Malekia -
I guess you won't be able to apply the bandwidth hack. I've recently got a DG4102 (manufactured week44, 2015) with the latest firmware already installed and it wouldn't accept the "cengen" bandwidth hack.

Yet i would reconsider to maybe get a different brand / model - the DG4000 currently is quite buggy. Some bugs that are really annoying are its glitches when changing parameters and the rotary encoder that seems to be out-of-phase with the detents (and that's not the result of a faulty encoder but a firmware flaw), making an accurate incremental input impossible.

If I knew about these problems before, this probably would have affected my decision to get this generator.

Cheers,
Thomas
 

Offline Altemir

  • Contributor
  • Posts: 47
  • Country: ru
Re: DG4000 - a firmware investigation
« Reply #309 on: July 13, 2016, 08:14:14 am »
Hi, All.
As rramirez and other I can't update my DG4162. Blinking for bootloader and new FW is too as rramirez's post.
My versions:
SW 00.01.07
FPGA 00.01.08
HW 01.01
KB 04.01

What I and other guys doing wrong?

Offline H.O

  • Frequent Contributor
  • **
  • Posts: 813
  • Country: se
Re: DG4000 - a firmware investigation
« Reply #310 on: July 13, 2016, 01:43:20 pm »
Use another USB stick. I used the same one as I use to update my DS4000 scope but the DG4000 didn't accept it. Since it worked on the DS4000 and the DG4000 did recognise it under normal operation I was certain I was doing something wrong and contacted Rigol support. They insisted it was the USB stick and they where correct.
 

Offline Altemir

  • Contributor
  • Posts: 47
  • Country: ru
Re: DG4000 - a firmware investigation
« Reply #311 on: July 14, 2016, 08:20:07 am »
Thanks. I have used 8 USB flash drives. I'll keep looking :(

Offline megafix

  • Newbie
  • Posts: 7
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #312 on: August 09, 2016, 01:05:00 pm »
Hope this helps! Piranha(DSP)Update_00.01.09.zip

Can anybody supply firmware levels 00.01.09 or 00.01.10 or 00.01.11 for the DG4000 Series? Currently I've only got 00.01.08 and 00.01.12.

Starting with 00.01.09 the new boot loader 00.06 is mandatory. The update instructions mention "Do not update the DG4000(Bootloader)Update file twice or the unit will fail to start up." I haven't tried yet but this seems to be is a nice showstopper.

« Last Edit: August 09, 2016, 01:09:03 pm by megafix »
 

Offline megafix

  • Newbie
  • Posts: 7
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #313 on: August 24, 2016, 11:29:03 am »
Hi Peter,
with 00.01.08.00.02 you could as well extract the available SCPI commands from the first block (out of 17) of the .gel update file.

Starting with 00.01.09.00.01 they added some weak scrambling to the .gel file that requires an updated boot loader and prevents extracting the SCPI commands by simply reading the strings.

How did you dump the 32MB SDRAM (IS42S16160D-7TLI)? I assume through JTAG?


« Last Edit: August 24, 2016, 11:33:34 am by megafix »
 

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #314 on: March 13, 2017, 02:12:32 pm »
OK Guys, old thread but I eventually got around to doing this.  I have a DG4062 that's currently at 200 MHz with the following versions:
SW 00.01.07
FPGA 00.01.08
HW 01.03
KB 05.01

It works fine but, when I try to run the manual calibration, I get messages that tell me that some values are out of range and I'm unable to complete the Cal.  A while back, it was suggested that I drop back down to vn 01.06, run the Cal, and then go back up to 01.08 but, having read through this thread, I'd be happy to drop down to 160 MHz and run the latest firmware.

 I looked for the 01.06 FW but I can't find it anywhere. Any suggestions on the best way to proceed would be appreciated.
If at first you don't succeed, get a bigger hammer
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6202
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #315 on: March 13, 2017, 02:38:43 pm »
I looked for the 01.06 FW but I can't find it anywhere.

Maybe one of these FW is what you were looking for: http://s.go.ro/blmbni71

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #316 on: March 13, 2017, 03:20:53 pm »
Thanks, I got those files.  So is the plan to:

1. Downgrade to 00.01.06
2. Run the manual calibration
3. Upgrade to 00.01.08

I understand that going to 00.01.09 will wipe the 200 MHz out and I will be stuck with the 60 MHz version.

[EDIT] I tried the upgrade but it didn't seem to take.  First I put the 00.01.06 GEL file on the USB drive and then pressed [help] as I powered up, it seemed to start taking stuff from the drive but, after 15 minutes, only 1 extra light was on so I gave up, it booted but the version was still the same - how long does it take to upgrade and what light status indicates it's finished?
« Last Edit: March 13, 2017, 11:05:36 pm by Gandalf_Sr »
If at first you don't succeed, get a bigger hammer
 

Offline Andrusca

  • Contributor
  • Posts: 23
  • Country: ar
Re: DG4000 - a firmware investigation
« Reply #317 on: May 24, 2017, 02:31:08 pm »
Hello Cybernet and friends,
Hope you can give me some advice about how to bring back to life my DG4062!

I have a DG4062 that I modded to DG4162 (with firmware 01.08) with the .CEN file because initially I had Firmware bootloader version 04. That worked like charm until I recently decided to finally upgrade firmware to the current last version (01.12). The reason for that was I have to control the generator using Labview via Ethernet and I was having an avoidable error when uploading an arbitrary waveform after an instrument reset and also having random Ethernet disconnection-connection events which prevent me from operating the instrument remotely in a comfortable way.  The firmware release notes explain that some SCPI and LXI issues were fixed since 01.08 so I thought it was the right time to do a firmware upgrade to try to solve my problems.

First, I power up the instrument with a thumb drive containing the bootloader .GEL file (ver 06). Al light end up on and then instruments self-reset and self-powered up again. I then power down the instruments but I foolishly   :palm: forget to replace the bootloder .GEL  with the firmware .GEL before I power up the instrument again. When I power up the instrument, some lights started to blink in a strange pattern and after 20 minutes of no activity progress I sadly had to power it off. I then replaced the .GEL file in the thumb drive and powered up the DG4K but the upgrade process again is stuck with only the "Ramp" button flashing over and over forever. Of course, DG4K is not also booting normally so it is bricked   :palm: :palm: :palm:.

I am now realizing that the FPGA firmware of my DG4K is corrupted and I think that the only way to make it function again is to reflash the FPGA with a fresh memory dump. It could be any version of DG4062 previous to 01.09, so I can make the DG4162 upgrade and also change the serial number in the source code to make it coincide with mine. I don't know if all of  that is possible and also if it is going to solve the problem.
So I would really appreciate your help and advice about which would be the most appropriate way to proceed.

Many thanks
Andrés
   
 
 

Offline nrxnrx

  • Supporter
  • ****
  • Posts: 68
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #318 on: May 24, 2017, 03:37:06 pm »
Since the bootloader is likely ok, you can try the procedure here:

https://www.eevblog.com/forum/testgear/dg4062-fw-update-non-respomsive-issue/msg945488/#msg945488

If that doesn't work, try pressing Help 3 times at boot (instead of just once), since that works with other rigol products.
 

Offline Andrusca

  • Contributor
  • Posts: 23
  • Country: ar
Re: DG4000 - a firmware investigation
« Reply #319 on: May 25, 2017, 12:00:04 am »
Thanks nrxnrx very much!
Following your advice, I have solved the problem in the following way:

1) First, I noticed that every time I put the stick with the firmware .GEL, it seemed that the firmware update process always started ok but (perhaps because I had previously used the bootloader .GEL twice) it invariable ended stuck with the first light blinking (Ramp). I was always using an old brandless 64MB drive.
2)  I full formatted another stick drive, a 2GB Kingstone DataTraveller II. Then I copied the firmware .GEL file.
3) Surprisingly, this thumb drive was not recognized by the instrument as it only lit up Mod, Utility and Store buttons. This is just what describes Rigol in its DG4000 Firmware Upgrade Procedure. pdf file. Notice that this drive was and is recognized under the Store menu by the DG4K.
4) I full formatted my original 64MB thumb drive and copied the .GEL file again.
5) Yet more surprisingly, the update process then advanced further the Ramp button and ended successfully! :phew:
6) I suspect that having used the "incompatible" thumb drive may reset the previously perturbed update sequence and allowed me to start a fresh new one  :-//.

Now I have the instrument working, upgraded to version 01.12 and keeping the DG4162 model!!   :clap: :clap:

I hope my painful experience can help someone in the future. :-+
 
I have one last question: Now with firmware 01.12, would I be able to do the factory reset calibration to get a flat output beyond 60MHz (the bandwidth of my original DG4062)?

Many thanks,
Andrés
 
The following users thanked this post: kado, nrxnrx

Offline tkarlmann

  • Newbie
  • Posts: 4
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #320 on: June 08, 2017, 10:21:00 pm »
I'm new to all this, and I'm seeing 14 pages of notes to this thread.  I also noted that the early recommendation of the Amontec JTAGkey seems to be no longer possible, as the company is no longer in business.
https://startingelectronics.org/articles/embedded-tools/amontec-info/ See link at left.

I'm starting virtually from scratch, and will need all the assistance I can get, although I've been an EE for 30+ years.  I now have a DS1052E, which also needs to be modded, and I am planning on outfitting a home lab.  Is such a procedure available?  Thanks.  I would like to start with the DG4062, and upgrade it when possible.  For now, I'd like to do these mods.  Can I make it look like the DG4202?  Can I calibrate it to the limits of the DG4202? 

Also, I will be buying new equipment with whatever firmware is current.  I will get: DS1054Z, DS2072A, DG4062, DM3068, and DP832, with a strong look at Rigol's new DL3031A.

All help Appreciated!
« Last Edit: June 08, 2017, 10:32:25 pm by tkarlmann »
 

Offline thlee

  • Contributor
  • Posts: 10
  • Country: hk
Re: DG4000 - a firmware investigation
« Reply #321 on: February 11, 2018, 07:38:04 am »
I bought rigol DG4062 with the serial number DG4Exxxxxxxxx. The software version is 00.01.12 with that new boot loader.  I want to hack my signal generator to DG4162. Is it possible to hack?

I read the previous messages from the forum. May I downgrade the firmware version to 00.01.07 or below, then to change the model number to DG4162? After that, the re-calibration is performed before I upgrade it to the lastest firmware. Are these correct procedures to hack DG4062? I do not fully understand how to perform the downgrading procedures(including boot loader) .  Could anyone give me advice?
 

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #322 on: March 01, 2018, 03:17:05 pm »
Trying to run the online compile on post #104 but first I had to fill in Project>Compile Options (and run options) and. after compiling, there's no file to download.  Can anyone help?
If at first you don't succeed, get a bigger hammer
 

Offline TurboTom

  • Super Contributor
  • ***
  • Posts: 1389
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #323 on: May 12, 2018, 10:07:54 pm »
Apparently, there's new firmware available for the DG4000 series on http://www.rigol.com/File/ProductSoftWare/20180509/DG4000(DSP)update.rar (01.14.00.01 vs. 01.12.00.02). Has anybody been successful installing this file on his DG4000? I didn't succees as yet, and I don't really believe that all of my thumb drives are incopatible (tested about five of my older ones that run well with an operating DG4000 as a storage device. Just for information, my DG4102 hasn't been tampered with (too new model, the patch isn't working...   :( ).

Cheers,
Thomas
 

Offline TurboTom

  • Super Contributor
  • ***
  • Posts: 1389
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #324 on: May 13, 2018, 11:09:06 am »
Thanks Peter,

I finally managed to dig out a really ancient 512MB thumb drive, and -- surprise, surprise -- with that I was finally able to update the firmware. I tested with many different thumb drives from 4 to 32GB that all were detected and usable during normal operation of the generator, but they all failed at updating the firmware.

Unfortunately, it appears that none of the bugs / annoyances that bugger me most with this generator had been addressed. In pulse mode, the nasty 4µs runt pulse of half selected amplitude is still there when changing the pulse width. The encoder response (even/constant/predictable number of increments per detent) hasn't been improved at all. And Rigol didn't bother to have a go at the menu structure to select built-in arbitrary waveforms.

So my recommendation to all those out there shopping for a middle-range AWG, don't even spend a thought on this one, it's still crap and probably wouldn't receive any substantial improvements anymore. I'ld be happy to be proven wrong, though.

Cheers,
Thomas
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf