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

0 Members and 1 Guest are viewing this topic.

Offline Carrington

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: es
Re: DG4000 - a firmware investigation
« Reply #100 on: November 17, 2013, 11:53:08 pm »
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 ;)
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 ;)
Congratulations Cybernet.  :-+
A custom firmware would be great and a titanic task.  :phew:
My English can be pretty bad, so suggestions are welcome. ;)
Space Weather.
Lightning & Thunderstorms in Real Time.
 

Offline synapsis

  • Regular Contributor
  • *
  • Posts: 140
  • Country: us
    • Blackcow
Re: DG4000 - a firmware investigation
« Reply #101 on: November 18, 2013, 01:00:53 am »
cybernet strikes again!

Upgraded my unit in about 4 minutes.  :-+
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #102 on: November 18, 2013, 10:39:54 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
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 572
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #103 on: November 19, 2013, 01:51: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
The best would be if studio25 could integrate it in his web app RigLOL http://riglol.3owl.com
 

Offline bandgap

  • Contributor
  • Posts: 47
  • Country: us
  • .: no electrons here :.
    • Bandgap.net
Re: DG4000 - a firmware investigation
« Reply #104 on: November 20, 2013, 07:40:38 am »
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);
}
« Last Edit: November 21, 2013, 09:33:36 am by bandgap »
 
The following users thanked this post: twdotnet

Offline hammy

  • Supporter
  • ****
  • Posts: 465
  • Country: 00
Re: DG4000 - a firmware investigation
« Reply #105 on: November 20, 2013, 07:56:16 am »
Cool! Good work cybernet (and all others)!
So, which Rigol devices left?  ;) The dg1032z/dg1062z?
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #106 on: November 21, 2013, 05:00:46 am »
Re.  bandgap, : DG4000 - a firmware investigation
                       : Reply #104 on: Yesterday at 06:40:38 PM »

Thank you Clayton. This was easy to use and it worked very well. I'm sure that you have made a lot of Windows users happy!

     Thanks again, Ted
 

Offline bandgap

  • Contributor
  • Posts: 47
  • Country: us
  • .: no electrons here :.
    • Bandgap.net
Re: DG4000 - a firmware investigation
« Reply #107 on: November 21, 2013, 09:40:47 am »
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

Thanks! I've corrected my post.

-Clayton
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #108 on: November 21, 2013, 10:54:43 am »
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.
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #109 on: November 21, 2013, 11:53:32 am »
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.

@screensaver - no issues for me - tried with FW 03, 06 and 07 - i doubt the mod interferes with the screensaver in any way.
@flatness - you will probably have to do a manual cal -> pw is 2010 - im no expert on that matter, but a Vrms meter should be sufficient, it seems to output different sines at different offsets/frequencies and expects you to correct the values shown in the tables - some of the tables are actually called "flatness" - so i would assume thats what can be used to tune it up to 160MHZ if not 200MHZ
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #110 on: November 21, 2013, 12:44:01 pm »
 cybernet     Re: DG4000 - a firmware investigation
                   « Reply #110 on: Today at 10:53:32 PM »
                    Quote from: ted572 on Today at 09:54:43 PM

    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
----------------------------------------------------------
@screensaver - no issues for me - tried with FW 03, 06 and 07 - i doubt the mod interferes with the screensaver in any way.
@flatness - you will probably have to do a manual cal -> pw is 2010 - im no expert on that matter, but a Vrms meter should be sufficient, it seems to output different sines at different offsets/frequencies and expects you to correct the values shown in the tables - some of the tables are actually called "flatness" - so i would assume thats what can be used to tune it up to 160MHZ if not 200MHZ.
----------------------------------------------------------

 cybernet:

I installed the DG4162 patch CEN and the freq. response is the same at 100MHz, 120MHz, and 160MHz as above with the DG4202 configuration.  Thank you for the information on the Calibration with the PW.  I will be looking into Cal. next.  And BTW I'm not worried about the Screen Saver and agree that it is a separate issue not related to Turbocharging.

Thanks again for your assistance and all you have done for us all.  It is truly awesome !         Cheers, Ted

 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #111 on: November 21, 2013, 01:39:21 pm »
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.
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #112 on: November 21, 2013, 01:49:52 pm »
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.

not that i know of, and i doubt rigol will share it for that purpose ;-)
but the way i understood it is u just check the tables, it will do a measurement internally - you do one externaly, fix the value - and thats it.
there is also the "factory" button which seens to reset it - i fu**ed around out of curiosity with the tables, then it was off badly, and i just reset it back to normal.
the parnoid ones could always write down the old values ... no fear ;)
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #113 on: November 21, 2013, 01:51:41 pm »
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 ....
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline Uup

  • Regular Contributor
  • *
  • Posts: 82
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #114 on: November 21, 2013, 02:08:22 pm »
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:
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #115 on: November 21, 2013, 02:13:26 pm »
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:

when u are very bored, maybe u could share that values with us ... (i know its a lot of work ...) - but i would be willing to test them on my DG4062 and see if it improves flatness/specs .. if so i'd look into file format for calibration files.
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #116 on: November 21, 2013, 02:18:26 pm »
Thanks for your work cybernet. (I'm not planning to use it unless I really need more than 100Mhz)
If upgraded from 60Mhz does it also need recalibration for frequencies up to 60Mhz?
Did someone do several measurements before and after? (for below 60Mhz)
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #117 on: November 23, 2013, 06:47:49 pm »
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?
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #118 on: November 23, 2013, 06:56:58 pm »
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.
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #119 on: November 24, 2013, 02:06:49 am »
Subject: Getting a newer FPGA version for DG4000.

I have a new DG4000 that I just received a week ago, but I have been seeing posts from people with older units that have more current software/firmware.

This is my 'System Info':  Device Model - DG4062,  Serial Number - DG4D152xxxxxx,  Software (I believe we generally refer to this as Firmware (?) ) - 00.01.06.00.02,  FPGA* - 00.01.07.09,  Hard - 01.03,  Keyboard - 05.01,  and Enc FPGA – 06

My concern is with the FPGA* version, which for me is 00.01.07.09, because I see that some other owners have version 00.01.08.xx. Is there anyway for me to upgrade to the FPGA version 00.01.08.xx?  Is the FPGA Firmware every included, or is it even possible to be provided along with a newer Software/Firmware version from Rigol?


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.

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.

Thank for getting back to me, as it was what you said that helped me decide to go ahead and install the current 07 GEL knowing it has issues. By the way Rigol says that the current version is 06, and this must be because they don't want more owners to upgrade into a flawed version that they are working on to correct. This of course is my interpretation of why they say 06 is the current version.

Thanks 'cybernet'

Reference below for info on Software 07 bugs:

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.
« Last Edit: November 24, 2013, 02:11:06 am by ted572 »
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #120 on: November 24, 2013, 02:28:14 am »
just reversed the crc on the firmware files for the DG4000 ;-)
its actually a packaging format, that contains multiple segments which get loaded into the flash then (the loader addresses are still a bit off) anyhow i attach a link to the splitted files.
the big 2MB file is the main code - u can load it into LDRViewer and it dismantle it without a hitch, other stuff are help system files, etc ..
so theoretically it should now be possible to modify code, stuff it back together, crc it - and flash it ;-)

http://www.filedropper.com/dumpfilestar

Quote
./gelfile ./DG4000Update.GEL
hdr_buf: RIGOL:DG4:UPDATE FILE ALL
fwr: CRC:7A57 ADDR:20040000 LEN:00228EF0 00000004 00000004
    -> dumped dump_20040000.bin (2264816 bytes)
fwr: CRC:8CE7 ADDR:20300000 LEN:000C3DF6 00000008 00000008
    -> dumped dump_20300000.bin (802294 bytes)
fwr: CRC:8C44 ADDR:20400000 LEN:00001661 00000008 00000008
    -> dumped dump_20400000.bin (5729 bytes)
fwr: CRC:0611 ADDR:20440000 LEN:00000252 00000010 00000010
    -> dumped dump_20440000.bin (594 bytes)
fwr: CRC:8845 ADDR:20440400 LEN:00002855 00000010 00000010
    -> dumped dump_20440400.bin (10325 bytes)
fwr: CRC:D973 ADDR:20443400 LEN:00000252 00000010 00000010
    -> dumped dump_20443400.bin (594 bytes)
fwr: CRC:BDC8 ADDR:20443800 LEN:000019FE 00000010 00000010
    -> dumped dump_20443800.bin (6654 bytes)
fwr: CRC:8570 ADDR:20460000 LEN:00000206 00000010 00000010
    -> dumped dump_20460000.bin (518 bytes)
fwr: CRC:3CB3 ADDR:20460400 LEN:0000F081 00000010 00000010
    -> dumped dump_20460400.bin (61569 bytes)
fwr: CRC:D5A9 ADDR:2046FC00 LEN:00000206 00000010 00000010
    -> dumped dump_2046fc00.bin (518 bytes)
fwr: CRC:0259 ADDR:20470000 LEN:000091B6 00000010 00000010
    -> dumped dump_20470000.bin (37302 bytes)
fwr: CRC:219D ADDR:205B0000 LEN:00169DE8 00000020 00000020
    -> dumped dump_205b0000.bin (1482216 bytes)
fwr: CRC:A299 ADDR:207B0000 LEN:0003D6C4 00000040 00000040
    -> dumped dump_207b0000.bin (251588 bytes)
fwr: CRC:63BD ADDR:20830000 LEN:0004BB9C 00000040 00000040
    -> dumped dump_20830000.bin (310172 bytes)
fwr: CRC:0000 ADDR:209B0000 LEN:00480000 00000080 00000080
    -> dumped dump_209b0000.bin (2097152 bytes)
    -> dumped dump_20bb0000.bin (2097152 bytes)
    -> dumped dump_20db0000.bin (524288 bytes)
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: DG4000 - a firmware investigation
« Reply #121 on: November 24, 2013, 03:49:34 am »
just reversed the crc on the firmware files for the DG4000 ;-)
its actually a packaging format, that contains multiple segments which get loaded into the flash then (the loader addresses are still a bit off) anyhow i attach a link to the splitted files.
the big 2MB file is the main code - u can load it into LDRViewer and it dismantle it without a hitch, other stuff are help system files, etc ..
so theoretically it should now be possible to modify code, stuff it back together, crc it - and flash it ;-)

http://www.filedropper.com/dumpfilestar


Wow...  Nicely done.
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #122 on: November 24, 2013, 04:36:36 am »

http://www.filedropper.com/dumpfilestar


I may be doing something wrong, but I believe it says the linked file is 0 kB?
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 572
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #123 on: November 24, 2013, 08:15:47 am »
http://www.filedropper.com/dumpfilestar
I may be doing something wrong, but I believe it says the linked file is 0 kB?
Just checked, works fine for me. Filezize: 9.740 kB
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 572
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #124 on: November 24, 2013, 08:18:19 am »
Reference below for info on Software 07 bugs:

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.
Link to that topic: https://www.eevblog.com/forum/testgear/rigol-dg4xxx-ppulse-and-npulse/
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf