EEVblog Electronics Community Forum

Products => Test Equipment => Topic started by: cybernet on July 30, 2013, 09:15:44 pm

Title: DG4000 - a firmware investigation
Post by: cybernet on July 30, 2013, 09:15:44 pm
started dumping memory via JTAG on the DG4000 - no probs at all exact same layout as the DS2000's JTAG - aux 3,3V can be stolen from the header next to it if needed for jtag adapter.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on August 06, 2013, 07:14:56 pm
JTAG Dump of a DG4062 - http://www.megafileupload.com/en/file/439251/dg4000-memdump-tar-gz.html (http://www.megafileupload.com/en/file/439251/dg4000-memdump-tar-gz.html)
Title: Re: DG4000 - a firmware investigation
Post by: synapsis on August 06, 2013, 08:50:53 pm
 :-+

My now that I'm finished working on my truck (10 days in Arizona summer), maybe I can finally play with the DG4000.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on August 17, 2013, 11:55:22 pm
unless this is already public knowledge while looking for a way to change the model type, i stumbled over the secure code which is "2010" - this will enable the Test/Cal Submenu on the DG4062/FW 00.01.04
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on August 18, 2013, 12:30:38 am
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)

Title: Re: DG4000 - a firmware investigation
Post by: Corporate666 on August 18, 2013, 12:59:59 am
I'm getting excited!  :scared: :-/O
Title: Re: DG4000 - a firmware investigation
Post by: jasonbrent on August 18, 2013, 01:17:59 am
cybernet; thank you. Just in general, thank you. I appreciate you sharing the benefits of your curiosity.

-jbl
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on August 18, 2013, 01:26:56 am
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)

thx
Title: Re: DG4000 - a firmware investigation
Post by: KedasProbe on August 18, 2013, 08:54:23 am
No didn't know that, thanks! good to know in case it's needed. :)
It works on my DG4102. (I have the same version 00.01.06.00.02)

The only extra thing I know so far (from this forum) was this extra version number info by pressing the first  third and fifth side button in the version screen.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on August 27, 2013, 04:24:12 pm
anyone with a 200Mhz DG4062 ?

this is has been done with jtag hackery, because im too lazy to reverse yet another piece of their cryptobs.
the way it works is that u place a file <something>.CEN which needs to contain a special header, and then some crypted bits and pieces, which will then update the model type.
the message says it updated model type & serial - but i dont see that happening atm it only gets passed the new model type - by forging the right jump and tweaking the arguments of the sub (e.g. string to new model type) a bit .. you can enabled whatever u like - and yes it sticks - i went for a DG4202 ;-) ... also tried a DG4162 - and there are more

you need to have a jtag adapter to do this, and u need to open the device

calibration is obviously off above 60Mhz (vpp, freq is fine) - time to play with the cal menu.

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

did a fw upgrade to 0.6 afterwards, model type sticks  :-+
Title: Re: DG4000 - a firmware investigation
Post by: KedasProbe on August 27, 2013, 05:16:33 pm
Were you also able to measure if the rise/fall time changed after you changed your 60MHz to 160/200MHz?
Title: Re: DG4000 - a firmware investigation
Post by: synapsis on August 27, 2013, 06:00:59 pm
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.)
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on August 27, 2013, 06:01:29 pm
Were you also able to measure if the rise/fall time changed after you changed your 60MHz to 160/200MHz?

only got my DS2062 erm 2202 ;-) - sine wave looks good, but amplitude drops after 60mhz, i played with the call thingy, and probably need some true rms voltmeter to correct it.
the way it works that u go over the items one by one, and input the measured values, then save the results ... "LOAD" is the one thats for the output regulation.

for me its not super important because im more after quick arb and rect than sine stuff ..
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on August 27, 2013, 06:02:16 pm
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.)

true, u can do that - and u can add calibrations, and it seems u can even replace the builtin arb tables ;-)
Title: Re: DG4000 - a firmware investigation
Post by: synapsis on August 27, 2013, 06:25:01 pm
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.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on August 27, 2013, 07:30:20 pm
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
Title: Re: DG4000 - a firmware investigation
Post by: JuanPC on August 28, 2013, 01:43:20 am
Im not a Rigol fan, but coudnt help notice that the FW is 9.7MB?

the Instek GDS-3352 is 18MB.

Bananas vs. Apples jajajaja  :-DD
Title: Re: DG4000 - a firmware investigation
Post by: jsykes on August 28, 2013, 01:55:09 am
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  ?
 
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on August 28, 2013, 02:02:21 am
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  ?

my DG4202

sine: 200M
square: 50M
ramp: 5M
pulse: 50M
harmonic: 100M
arb: 50M

vs DG4162 (acc. batronix homepage):

sine: 160M
square: 50M
pulse: 40M
ramp: 4M
harmonic: 80M
arb: 40M

so its an improvment id say  >:D

the model set routine copies a ton of values to non volatile memory, that determines the limits. manual tweaking probably doable to increase it even further, but i lack
the equipment to judge whats then outputted in terms of quality  :-//
Title: Re: DG4000 - a firmware investigation
Post by: Rigby on August 28, 2013, 02:19:24 pm
Gee whiz, that's amazing.  nicely done.
Title: Re: DG4000 - a firmware investigation
Post by: Uup on August 29, 2013, 07:36:16 am
Nice work Cybernet!   :-+

Attached is the latest firmware (00.01.07.00.03)
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on August 29, 2013, 09:51:47 am
Nice work Cybernet!   :-+

Attached is the latest firmware (00.01.07.00.03)

thx (yet another update, wow) - if someone is willing to look into the algo and how to reverse it let me know via PM. my holidays are over so got to do some real work the next weeks ;/
Title: Re: DG4000 - a firmware investigation
Post by: KedasProbe on August 29, 2013, 04:05:20 pm
Nice work Cybernet!   :-+

Attached is the latest firmware (00.01.07.00.03)
This file gives an error when trying to extract? (only empty folders)
edit: it does work with 7zip, not with winRAR or Windows 7 zip, Thanks for sharing
Title: Hacking Rigol 4000
Post by: echen1024 on September 02, 2013, 02:34:59 am
So, I have decided to purchase the Rigol DG4062, and would like to know if it is hackable up to the 4102/4162.

Thanks.
Title: Re: Hacking Rigol 4000
Post by: BravoV on September 02, 2013, 02:48:55 am
I guess it will be much better you join the huge thread Sniffing the Rigol's internal I2C bus (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/), be prepared to crack open your scope, dump the firmware and post it there too, hopefully it will get "fixed" sooner rather than posting another new thread solely just for you.

Just a suggestion.  :-//

Title: Re: Hacking Rigol 4000
Post by: synapsis on September 02, 2013, 02:54:22 am
The other thread: https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/ (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/)
Title: Re: DG4000 - a firmware investigation
Post by: echen1024 on September 02, 2013, 03:22:09 am
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.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on September 02, 2013, 12:45:17 pm
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.

the steps will vary by the type of JTAG adapter u have - i recommend amontec jtag key tiny - cheap and does the job.
when u have the DG and you are ready to hook it up let me know and i will post the steps here.
also if someone wants to reverse the hash that they use let me know, and i will extract the assembler with what i've reversed so far.
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on September 02, 2013, 10:14:32 pm
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?
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on September 02, 2013, 10:24:11 pm
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.
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on September 02, 2013, 10:47:00 pm
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.

Thanks!  I didn't see that list before.  I checked the UrJTAG documentation (http://urjtag.org/book/_system_requirements.html#_required_software_for_running_urjtag) page and unfortunately the uLink2 is not listed...may be it will be one day...

To avoid hassles, I've just bought the Amontec JTAGkey-Tiny; the shipping is more than the device which is just nuts, but it seems the best way to go!  I'll report back when I've got it.  The DG4062 is standing-by :D
Title: Re: DG4000 - a firmware investigation
Post by: Rufus on September 02, 2013, 11:54:54 pm
To avoid hassles, I've just bought the Amontec JTAGkey-Tiny; the shipping is more than the device which is just nuts,

Their delivery charges to anywhere outside Switzerland are nuts.
Title: Re: DG4000 - a firmware investigation
Post by: Carrington on September 03, 2013, 12:05:12 am
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)
Title: Re: DG4000 - a firmware investigation
Post by: tinhead on September 03, 2013, 12:16:42 am
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


Title: Re: DG4000 - a firmware investigation
Post by: Sparky on September 03, 2013, 12:23:54 am
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)

Might work --- says compatible with jtagkey.  It is more expensive than the Amontec, but including shipping might be cheaper.


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)

Geezzz, hope they've improved shipping since then!  For the $80USD it cost (incl. shipping) I expect it by the end of this week!
Title: Re: DG4000 - a firmware investigation
Post by: synapsis on September 03, 2013, 02:00:21 am
I have the Bus Blaster v3. Unless they've made improvements in speed, it's *very* slow.
Title: Re: DG4000 - a firmware investigation
Post by: echen1024 on September 03, 2013, 02:50:36 am
I might just buy an eBay cheapie. Shipping for this thing is RIDICULOUS.  :bullshit:
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on September 03, 2013, 12:54:57 pm
I might just buy an eBay cheapie. Shipping for this thing is RIDICULOUS.  :bullshit:

its swiss after all ;-)
Title: Re: DG4000 - a firmware investigation
Post by: arvidj on September 05, 2013, 11:43:59 pm
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)
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on September 06, 2013, 12:07:37 am
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!   :--
Title: Re: DG4000 - a firmware investigation
Post by: arvidj on September 06, 2013, 12:28:29 am
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 just ordered one. When it arrives ... two to three weeks ... the first step will be see if the UrJTAG software recognizes it.
Title: Re: DG4000 - a firmware investigation
Post by: bingo600 on September 08, 2013, 07:53:53 pm
I have the Bus Blaster v3. Unless they've made improvements in speed, it's *very* slow.

Afaik a BusBlaster v3 is a FT2232H and a CPLD , how can they make that "slow ?"
I'd say the BusPirate is slow , but if the FT2232H driver is ok it doesn't seem likely that the BB is slow(er) than any other FT2232H based jtags.

Have a look here
http://dangerousprototypes.com/forum/viewtopic.php?f=37&t=4771 (http://dangerousprototypes.com/forum/viewtopic.php?f=37&t=4771)

/Bingo
Title: Re: DG4000 - a firmware investigation
Post by: fluxcapacitor on September 08, 2013, 09:42:53 pm
The bus pirate 3.6 might work with OpenOCD

http://openocd.sourceforge.net/doc/html/Debug-Adapter-Configuration.html#Debug-Adapter-Configuration (http://openocd.sourceforge.net/doc/html/Debug-Adapter-Configuration.html#Debug-Adapter-Configuration)
Title: Re: DG4000 - a firmware investigation
Post by: synapsis on September 08, 2013, 10:46:52 pm
Oh, I'm sorry... I have a Bus PIRATE.   :palm:

I haven't used it in so long I forgot what it was. The pirate is PIC24/FTDI based.
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on September 28, 2013, 12:50:53 am
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!   :--

Update!  Amontec delivered!  I've been away 2 weeks, and during that time the JTAGkey-Tiny arrived.  :phew:  For curious folks, here is the timeline:
Ordered: Sept 2nd (with "priority" shipping, which is supposed to be 2-3 day delivery)
Shipped: Sept 9th
Received: Sept 12 - Sept 25th (not sure exactly when it arrived as I was away)

Total cost was 61.80 euro = ~81 USD.

"Priority" shipping is obviously not worth it --- the item did not ship until a week after my order was placed!  As for shipping, I was charged 32.80 euro = $44.35 USD for shipping alone, whereas the actual shipping cost (on the postage label) was 11.80 CHF = ~13 USD.  Only a padded envelope was used for packaging...surely that does not cost $31 USD. 

The shipping is an obvious rip-off...but at least I got my JTAGkey. 

Now the fun can begin!  cybernet can you provide some next steps?  I've got the drivers for the JTAGkey-Tiny, and OpenOCD and UrJTAG all installed.  Read to go!

Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on September 28, 2013, 09:21:49 am
Sparky wrote:
cybernet can you provide some next steps?


Yes, make this public, please. I have also a DG4062 and want to pimp it up. I hope this

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)

jtag will work.

Thanks a lot.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on September 28, 2013, 05:49:43 pm
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.

Title: Re: DG4000 - a firmware investigation
Post by: Carrington on September 28, 2013, 06:30:27 pm
Download the bf-linux toolkit.
This?

http://blackfin.uclinux.org/doku.php?id=toolchain:installing (http://blackfin.uclinux.org/doku.php?id=toolchain:installing)
http://sourceforge.net/projects/adi-toolchain/files/ (http://sourceforge.net/projects/adi-toolchain/files/)

Thanks!
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on September 28, 2013, 06:33:31 pm
yes  ;)
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on October 01, 2013, 04:29:24 pm
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.

Thanks for the pointers to get started cybernet!  I searched for an adapter to convert the Amontec 20-pin Tiny to Rigol 14-pin JTAG socket but did not find anything suitable, so I've got some jumper wires to connect things as per your schematic in post 1.  Do I need to include the pull-ups you have in the schematic?  (I'm surprised the pull-ups are not on the PCB, but may be they are built-in to Rigol's JTAG tool.)

I have CentOS installed as my linux distribution, and have downloaded the blackfin linux toolkit so will install that next.

I'll post back when I'm up and running :)
Title: Re: DG4000 - a firmware investigation
Post by: Carrington on October 01, 2013, 06:33:03 pm
Sparky, maybe this will be useful:
http://www.topjtag.com/flash-programmer/ (http://www.topjtag.com/flash-programmer/)
Title: Re: DG4000 - a firmware investigation
Post by: Carrington on October 02, 2013, 12:44:48 am
White and bottled.  ;D

Top JTAG:
Programs flash memories connected to any JTAG-compliant device by manipulating the device's pins using boundary-scan technology. TopJTAG Flash Programmer can work with any parallel NOR flash memory compatible with AMD or Intel standard or extended command sets. Both CFI (Common Flash Interface) and non-CFI memories are supported.

S29GL128P90 Datasheet:
Support for CFI (Common Flash Interface).
http://www.mouser.com/ds/2/380/S29GL-P_00-220237.pdf (http://www.mouser.com/ds/2/380/S29GL-P_00-220237.pdf)
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on October 07, 2013, 06:41:07 pm
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 :)
Title: Re: DG4000 - a firmware investigation, DS4000 variant
Post by: cosmos on October 07, 2013, 11:38:00 pm
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.

The various serial decode option settings of the DS4000 can all be set by entering a code, but the BW hack is still not clear as far as I know.
So far I think there are two ways forward that looks promising.
1. HW straps (two resistors, where one is not populated) on the board for "HD Modify version" (not the "HD PCB version" bits)
2. option keys similar to the DS2000, except at least one user has reported unsuccessfully trying many of the bits apart from the ones we know activate the serial decode options.

1.
I have the 011 pattern on my DS4014 and the resistors are 10k to GND or a supply.
0 side is grounded both to metal frame and to pin 2 on the closest programming connector and to pin 13 on the one closer to the BF.
1 side is connected to pin 7 on the closest programming connector but not to any pins on the BF connector.
Very tempting to use micro clips and wire in a 1k here.
...
Well it was so tempting that I had to try it.
I did these patterns without getting any change to the major scope version in utility-system-system info:  010, 001, 111 and the original 011 of course.
I also did not see any changes in rise time but that is not conclusive due to uncertainty with the source I used.

Looking (afterwards) at the extended HW version (edge trigger mode  F7 + F6 + F7 + Utility. then utility-system-system info ) it says 0.1.2.3.
This matches nicely with the straps  for "HD PCB version" being 01 and 10, and the "HD Modify version" being 011.
I can verify this at a later time, did not think about the extended version screen until after put it partly together again.

This means that point 2 gets more interesting.

2. This is the part that sounds similar to the DG4000 work done in this tread ... what would be a good thing to investigate?
Sniffing the I2C for BW setting commands?  (assuming for now that it is the same variable BW buffer as in DS2000)
possibly verifying by sending a higher BW setting on I2C?
extracting the BF image and search for hints of keys for BW upgrades?
search BF image for the I2C code setting the BW and back trace variables used?

I newer used the BF so I am on thin ice here when it comes to interfacing it.
Do we have a DS4000 image to look at already or do we need to get one?
I know someone that has recently worked on BF designs so I can borrow a programming pod from him if needed.

Title: Re: DG4000 - a firmware investigation
Post by: Carrington on October 16, 2013, 01:42:40 pm
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?
Title: Re: DG4000 - a firmware investigation, DS4000 variant
Post by: tized on October 16, 2013, 07:38:30 pm
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.


I'm thinking of getting a DS4024, so I got interested in that to.

From what I read on the Rigol i2c thread (yes, I read the whole thing...) you need to get a JTAG adapter, or a BF programing pod (which is JTAG) and dump the memories. The dump then needs to be de-compiled using a tool like 'IDA pro' to try and find how the BW state is determined.

I'm reading some of the BF data sheets (ADSP-BF526) to find more information on the chip.
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on October 16, 2013, 09:50:41 pm
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?

Time limited on my part --- will hopefully get to it soon...
Title: Re: DG4000 - a firmware investigation
Post by: AndersAnd on November 07, 2013, 03:35:54 am
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.
It says:
Quote
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":
http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables (http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables)
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 07, 2013, 09:34:59 pm
if some one wants to tinker with it too - thats the main routine of the license file verification.
atm i would believe they use some kind of HMAC with "YZDHZSGCX" being the secret key - i just tried a few common ones, but no luck so far.
it will be down to analyzing this bit of code and the 2 "randomly named crypt" functions which i will post later in time when i have some clue what they are doing.

the input arguments are somewhat speculative as i have only roughly done the top level file handling function. if anyone has a serious idea let me know.
i would be suprised if they rolled their own HMAC algo ;)
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 16, 2013, 12:09:50 am

Free DG4062, DG4102, DG4162, DG4202 and a serial# of your choice ...

http://pastebin.com/ipkJCxPM (http://pastebin.com/ipkJCxPM)


Code: [Select]
**     ____  ______________  ___   __
**    / __ \/_  __/ ____/  |/  /  / /
**   / /_/ / / / / /_  / /|_/ /  / /
**  / _, _/ / / / __/ / /  / /  /_/ 
** /_/ |_| /_/ /_/   /_/  /_/  (_)   
**
** 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 ;-)
**
Title: Re: DG4000 - a firmware investigation
Post by: BravoV on November 16, 2013, 12:57:42 am
Damn ... another great job cybernet !  :clap:


.....  ;)  ;)  ;) .... time to update local copy .....  ;)  ;)  ;) ....
Title: Re: DG4000 - a firmware investigation
Post by: Rory on November 16, 2013, 01:12:58 am
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!)
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 16, 2013, 01:43:45 am
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 doubt there is a native 4162 unless u mean the sticker on the front. thats whats rigol uses to determine the model & serial.
calibration can be done if needed with the cal menu. i dont have the knowledge and need to do that, i just needed the square wave limit raised, and that looks good on my scope when i make it a DS2202 ;)
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on November 16, 2013, 04:47:09 am
Amazing work cybernet!  :-+  I was able to compile and read in the .CEN file no hassles whatsoever.  I did the upgrade to DG4202 on firmware 00.01.06

This came around faster than I could get my JTAGKeyTiny hooked in the back of the arb.  At least I have it ready for the next one! :D

Mega thanks!!  :-+

>> Edit: I updated to firmware 00.01.07 after applying the patch and it works fine.
Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on November 16, 2013, 05:44:43 am
Hello Cybernet,

as result of your phantastic work (many, many thanks) I now have a DSA815-TG with all options, a DS2072 (DS2202) with all options and now the chance to pimp up my DG4062 also.
I'm not a programmer and I'm to stupid to compile the file 'cengen.txt'. I renamed it to 'cengen.c'  and tried to compile it with 'MinGW' in Win XP, but no chance for me.  :-((
So I need help. Please can anybody compile it for me? Thank you for help.

Greetings
Rigol-Friend


Excuse my terrible english.


Title: Re: DG4000 - a firmware investigation
Post by: Rory on November 16, 2013, 06:09:34 am
Cengen.c compiles with GCC under Linux (I use Wheezy running in a Virtualbox VM under Windows 7) and creates the .cen file with no problem. Cybernet's instructions in the source are clear and it was easy to do.
Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on November 16, 2013, 06:16:31 am
I have no Linux  :-(
Title: Re: DG4000 - a firmware investigation
Post by: Rory on November 16, 2013, 06:44:44 am
I have no Linux  :-(
Not a valid excuse, if you have an internet connection...

You could download the cygwin installer and install cygwin under Windows, add the gcc, gdb and make packages under 'devel' in the cygwin installer. Then run the cygwin terminal and follow the instructions in cybernet's c file. I just did it, took only a few minutes to install. Compiled and ran exactly as it does in Wheezy.

BTW, I am not a Linux maven, I just did a couple of searches ... cygwin ... gcc under cygwin... and it didn't take a lot of time to find the downloads.  You could save yourself some problems by installing a virtual machine like virtualbox and set a VM up as a linux box under Debian, Ubuntu or one of the turnkey linux distributions then running it when cybernet does his magic. He makes it easy, I think the guy's a genius. 
Title: Re: DG4000 - a firmware investigation
Post by: max-bit on November 16, 2013, 07:19:31 am
Good no...fantastic Job :)
and why buy DG4162 ? |O
Title: Re: DG4000 - a firmware investigation
Post by: TMM on November 16, 2013, 08:03:42 am
awesome work :-+
(http://farm3.staticflickr.com/2884/10881791194_a42e48aa48.jpg)
Title: Re: DG4000 - a firmware investigation
Post by: Harvs on November 16, 2013, 08:48:10 am
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?
Title: Re: DG4000 - a firmware investigation
Post by: TMM on November 16, 2013, 08:57:40 am
you are running it like:
Code: [Select]
./cengen DG4062 DG4162 DG4D123456789correct?

Worked fine first time for me. Ubuntu 11.1 live CD on virtualbox.
Title: Re: DG4000 - a firmware investigation
Post by: Harvs on November 16, 2013, 08:59:58 am
Yep I need to do some more digging.

I changed the printf statement to print the strlen, for some reason it things its 5
Title: Re: DG4000 - a firmware investigation
Post by: Teneyes on November 16, 2013, 09:12:50 am
Fan-Frickin-tastic , again CyberNet , 

I think that is a bottle of Champagne in your picture.
We owe you a Case.

 :-+  :-+
Title: Re: DG4000 - a firmware investigation
Post by: Harvs on November 16, 2013, 09:17:38 am
I'm not quite sure why it's doing it, yet for me it was dropping the D off the front of each of the args.  I just added an extra D i.e.
./cengen DDG4062 DDG4202 DD....

And it worked.  I now have a DG4202 :)

Thanks again Cybernet!!!
Title: Re: DG4000 - a firmware investigation
Post by: Harvs on November 16, 2013, 09:50:21 am
A sweep from 1 to 200MHz, Hack DG4202 to DS2202.  Using a short coax and 50ohm term.

The falling edge of CH2 is a 100MHz.
Title: Re: DG4000 - a firmware investigation
Post by: TMM on November 16, 2013, 10:06:51 am
Looks like the analog bandwidth is 160Mhz. Still worth modding to DG4202 for the 5Mhz Ramp though  :-+
Title: Re: DG4000 - a firmware investigation
Post by: Rory on November 16, 2013, 10:41:09 pm
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?

I have something similar when I compile it using gcc under cygwin both 32 and 64 bit versions.  I added some debug code and it appears that the first character of the argv[] parameters is being truncated by strtoupper() . I got a workaround by adding a dummy character at the beginning of each parameter:   

./cengen xDG4062 xDG4202 xDG4D1000000001

then it passes the error checking and generates the license.CEN file

*edited - strtoupper is truncating, not when the parm is passed via argv.

*edited again - tried an alternative strtoupper() from cplusplus.com forum and works fine. /* */ commented out original function and inserted this:
Code: [Select]
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;
}


Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 16, 2013, 11:15:27 pm
FW 07 also tested okay
Title: Re: DG4000 - a firmware investigation
Post by: Mark_O on November 16, 2013, 11:19:18 pm
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.
Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on November 16, 2013, 11:21:04 pm
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
Title: Re: DG4000 - a firmware investigation
Post by: cosmos on November 16, 2013, 11:22:13 pm
Great work cybernet.

This hack sounds like it could be applied to the DS4000 too.
Is it enough to search the GEL file for similar code to confirm it uses the same method? any specific string to look for?
I tried searching the DS4000 GEL for  "YZDHZSGCX" and segments of it but came up empty.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 16, 2013, 11:27:34 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 ;)

Title: Re: DG4000 - a firmware investigation
Post by: Rory on November 16, 2013, 11:41:14 pm
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

I had same problem Rigol-Friend.  Look at my earlier message above for the change to strtoupper() function. If you just remove the error checking code as you did, the .cen file will not be correct. (missing the D's....)

Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on November 17, 2013, 12:13:09 am
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
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 17, 2013, 12:14:19 am
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

np, that was no champagne, that was just a 'radler' ;)
Title: Re: DG4000 - a firmware investigation
Post by: sprocket on November 17, 2013, 12:28:30 am
Damit I'm getting tempted to get a DG4062, just so I can hack it.. A signal gen like that is actually rather over kill for my needs. I usually just need PWM signals when I'm messing around with SMPS's.
Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on November 17, 2013, 12:30:23 am
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
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 17, 2013, 12:47:00 am
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

more mountains than germany ...  :P
Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on November 17, 2013, 12:57:43 am
What do you think? Can we write in german also?

Mountains? Here, where I live, we have no mountains  :-DD
Title: Re: DG4000 - a firmware investigation
Post by: Harvs on November 17, 2013, 01:25:21 am
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.
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.

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

Yes as stated, a DS2202.

I posted this as more of an encouragement for someone on here to post a sweep taken with much higher performance equipment.
Title: Re: DG4000 - a firmware investigation
Post by: elCap on November 17, 2013, 03:16:32 am
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!! :-+
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 17, 2013, 03:18:18 am
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 ....
Title: Re: DG4000 - a firmware investigation
Post by: elCap on November 17, 2013, 03:32:43 am
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.
Title: Re: DG4000 - a firmware investigation
Post by: TMM on November 17, 2013, 03:49:54 am
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.
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.
Spec for the DG4162 states <-0.8dB @ 160MHz. Spec at 100MHz and 60MHz is identical to the lower models so you can bet money that the hardware is no different.
Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on November 17, 2013, 09:45:31 am
A hint for the german speaking users: Since some weeks Rigol offers the user manual now in german language also. :-)

http://www.batronix.com/pdf/Rigol/UserGuide/DG4000_UserGuide_DE.pdf (http://www.batronix.com/pdf/Rigol/UserGuide/DG4000_UserGuide_DE.pdf)
Title: Re: DG4000 - a firmware investigation
Post by: AndyC_772 on November 17, 2013, 10:36:01 am
If you're interested in the hardware capabilities of the DG4xxx series above their rated frequency response check out this thread:

https://www.eevblog.com/forum/testgear/250-mhz-out-of-a-rigol-dg4102-a-100-mhz-waveform-generator/ (https://www.eevblog.com/forum/testgear/250-mhz-out-of-a-rigol-dg4102-a-100-mhz-waveform-generator/)

I took a bunch of measurements using an Arb waveform which consists of 10 cycles of a sine wave, which quite clearly show the true response of the hardware and the extent to which high frequency roll-off is being corrected for by software calibration. The plots were all taken using a 500 MHz Tektronix scope, so they should be pretty flat across the range of interest.
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on November 17, 2013, 08:41:44 pm
First:  Thank you very much cybernet for all the fine work you have done for us. I'm sure we all appreciate it so much!
          You certainly have made me very happy with my souped up Rigol equipment.

Question for the forum about 'DG4000 cengen':

If you use the 'cengen'  to go from 'DG4062' to 'DG4202', (with, or without changing the S/N) can you then later go back to 'DG4062' (original) using 'cengen' if you find a bug, flaw, or worst yet, have to send your unit back for warranty repair?

BTW I prefer leaving the S/N as is.  Could this cause any potential future issues?

I would like to try this myself, but I'm not a Linux user and I have not been able to figure out how to generate the key as of yet. Cybernet's instructions look clear if you have some basic knowledge of the Linux OS, but I don't, and that's my problem! If there were some step-by-stbep instructions available, I would jump on it. In the mean time I'll continue to try to figure it out.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 17, 2013, 10:08:07 pm
try it and let us know ;)
Title: Re: DG4000 - a firmware investigation
Post by: elCap on November 17, 2013, 11:07:58 pm
I tried to go back from DG4202 to DG4102, no problem. I kept the SN, only changed the model.
Title: Re: DG4000 - a firmware investigation
Post by: Carrington 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:
Title: Re: DG4000 - a firmware investigation
Post by: synapsis on November 18, 2013, 01:00:53 am
cybernet strikes again!

Upgraded my unit in about 4 minutes.  :-+
Title: Re: DG4000 - a firmware investigation
Post by: ted572 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
Title: Re: DG4000 - a firmware investigation
Post by: AndersAnd 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 (http://riglol.3owl.com)
Title: Re: DG4000 - a firmware investigation
Post by: bandgap 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 (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);
}
Title: Re: DG4000 - a firmware investigation
Post by: hammy on November 20, 2013, 07:56:16 am
Cool! Good work cybernet (and all others)!
So, which Rigol devices left?  ;) The dg1032z/dg1062z?
Title: Re: DG4000 - a firmware investigation
Post by: ted572 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
Title: Re: DG4000 - a firmware investigation
Post by: bandgap 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 (http://www.compileonline.com/compile_c_online.php)

Thanks! I've corrected my post.

-Clayton
Title: Re: DG4000 - a firmware investigation
Post by: ted572 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.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet 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
Title: Re: DG4000 - a firmware investigation
Post by: ted572 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

Title: Re: DG4000 - a firmware investigation
Post by: ted572 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.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet 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 ;)
Title: Re: DG4000 - a firmware investigation
Post by: cybernet 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 ....
Title: Re: DG4000 - a firmware investigation
Post by: Uup 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:
Title: Re: DG4000 - a firmware investigation
Post by: cybernet 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.
Title: Re: DG4000 - a firmware investigation
Post by: KedasProbe 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)
Title: Re: DG4000 - a firmware investigation
Post by: ted572 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?
Title: Re: DG4000 - a firmware investigation
Post by: cybernet 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.
Title: Re: DG4000 - a firmware investigation
Post by: ted572 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.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet 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 (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)
Title: Re: DG4000 - a firmware investigation
Post by: Rigby 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 (http://www.filedropper.com/dumpfilestar)


Wow...  Nicely done.
Title: Re: DG4000 - a firmware investigation
Post by: Mark_O on November 24, 2013, 04:36:36 am

http://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?
Title: Re: DG4000 - a firmware investigation
Post by: AndersAnd on November 24, 2013, 08:15:47 am
http://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?
Just checked, works fine for me. Filezize: 9.740 kB
Title: Re: DG4000 - a firmware investigation
Post by: AndersAnd 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/ (https://www.eevblog.com/forum/testgear/rigol-dg4xxx-ppulse-and-npulse/)
Title: Re: DG4000 - a firmware investigation
Post by: tized on November 24, 2013, 01:24:31 pm
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)


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.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 24, 2013, 01:40:34 pm
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.
Title: Re: DG4000 - a firmware investigation
Post by: tized on November 24, 2013, 03:22:08 pm
Funny thing, I've just done the same for the DS2000 firmware and this is what I got:

Code: [Select]
Device: DS2202
Version: 00.01.00.00.03

| No. |  Size (B)  |  Location  |   Target   |      CRC       | Type | Dev. B_A  |
|-----|------------|------------|------------|----------------|------|-----------|
|   1 | 0x00378f9c | 0x00000220 | 0x20040000 | 0x27e9427e (V) |  0   | 0x00_0x01 |
|   2 | 0x0017cca8 | 0x003791bc | 0x20000000 | 0x5a3ac3c3 (V) |  6   | 0x00_0x05 |
|   3 | 0x00010f60 | 0x004f5e64 | 0x20000000 | 0x52c1a46b (V) |  2   | 0x00_0x0a |
|   4 | 0x000321aa | 0x00506dc4 | 0x20020000 | 0x6c49f38a (V) |  2   | 0x00_0x0b |
|   5 | 0x0000245a | 0x00538f6e | 0x200d6000 | 0xcd2a7325 (V) |  2   | 0x00_0x0c |
|   6 | 0x00007fb4 | 0x0053b3c8 | 0x200c8000 | 0x4cac7870 (V) |  4   | 0x00_0x0e |
|   7 | 0x000663f4 | 0x0054337c | 0x200f0000 | 0x454d5a80 (V) |  4   | 0x00_0x0f |
|   8 | 0x00001d54 | 0x005a9770 | 0x20120000 | 0xbcb8589e (V) |  2   | 0x00_0x10 |
|   9 | 0x0006dc62 | 0x005ab4c4 | 0x20000000 | 0x885a8c98 (V) |  4   | 0x00_0x11 |
|  10 | 0x000032d8 | 0x00619126 | 0x20040000 | 0xb7481d18 (V) |  3   | 0x00_0x13 |
|  11 | 0x00000b64 | 0x0061c3fe | 0x20000000 | 0xd2b695f5 (V) |  5   | 0x00_0x14 |
|  12 | 0x0003c598 | 0x0061cf62 | 0x20000c00 | 0x3f1c1bcc (V) |  5   | 0x00_0x15 |
|  13 | 0x00000118 | 0x006594fa | 0x201e4c00 | 0x1af2df9d (V) |  5   | 0x00_0x15 |
|  14 | 0x00009010 | 0x00659612 | 0x2003d400 | 0x550735a2 (V) |  5   | 0x00_0x15 |
|  15 | 0x00001661 | 0x00662622 | 0x201fd800 | 0x5161cee1 (V) |  3   | 0x00_0x15 |
|  16 | 0x000bb808 | 0x00663c83 | 0x20045000 | 0x4b530b40 (V) |  3   | 0x00_0x15 |
|  17 | 0x00046ef0 | 0x0071f48b | 0x20100000 | 0x52c4edfb (V) |  7   | 0x00_0x15 |
|  18 | 0x00000000 | 0x0076637b | 0x20122800 | 0x00000000 (V) |  2   | 0x00_0x32 |
|-----|------------|------------|------------|----------------|------|-----------|

The 'Type' and 'Device' fields are not verified, just my guess. The first block is the LDR and the second is for the FPGAs.
All the 'Type' 2 blocks seem to be more application code.


nize stuff, im also looking into the DS2000 atm - but you are a step ahead as it seems.
for the DG the bootloader stream is in 0x2000 0000 - the application is in 0x2000 4000 - looking at your GEL listing, i would assume its the same with the DS2k.
the bootloaders gets overwritten during boot (0xffa0 0000 segment) and in the 0x0-0x01fff ffff range so best to dump it while it sits in the bootloader ...
did u already find/implement the CRC check ? looks different then the DG one.

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

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

Code: [Select]
16 Bytes - MSB first - ASCII - Device name
16 Bytes - MSB first - ASCII - Version number
 4 Bytes - LSB first - UInt  - Fields per entry (Each field is 32b UInt, LSB first)
 4 Bytes - LSB first - UInt  - Number of entries

List of block descriptor entries, each entry with the following fields:

SIZE     - Number of bytes in block
LOCATION - Offset to the block in the .GEL file
CRC      - Standard CRC32
TYPE*    - Some kind of type code 
TARGET   - Target address
CODE_A*  - Looks like device code
CODE_B*  - Always 0

* - Fields I'm guessing about, not sure yet.
 
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 24, 2013, 03:35:18 pm
so far i agree only the fields per entry which is offset +0x20 according to your table .. e.g.

Code: [Select]
00000000  44 53 32 32 30 32 00 00  00 00 00 00 00 00 00 00  |DS2202..........|
00000010  30 30 2e 30 30 2e 30 31  2e 30 30 2e 30 35 00 00  |00.00.01.00.05..|
00000020  [color=orange]07 00 00 00[/color] [color=red]11 00 00 00[/color]  b4 3d 31 00 04 02 00 00  |.........=1.....|

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

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

loc_1FD6B0A:
R0 = [P5]; // P5 = ptr to file handle
P1 = [FP -0x8]; // P1 = ptr to file data buffer (containing first 0x28 bytes)
R2 = [P1 + 0x24]; 
R2 *= R7;  // R7 =0x1C
CALL FILE_fread_sub_1FF0982;
[FP -0x4] = R0;
CC = (R0 == -0x1);
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 24, 2013, 03:45:12 pm
found it +0x20 is a bitmask, bit 0,1,2,3 are probed and that seems to impact the routine that parses the data chunks and writes them to flash. (loc_1FD6B50)
Title: Re: DG4000 - a firmware investigation
Post by: tized on November 24, 2013, 04:44:57 pm
I don't have any disassembler (yet...), I figured it just by looking at file, reading the Blackfin specs. and reading on this forum. Figuring the code is next, thought I would like to do that for the DS/MSO4k firmware, as my MSO4024 should be getting here this week.
Title: Re: DG4000 - a firmware investigation
Post by: jboard146 on November 24, 2013, 06:00:18 pm
I've got a "new" DG4062 and it has a serial # with an "E" not a "D" in the 4th char. I had to modify the src to accept this type of serial #. I only did a find/replace and didn't put any logic in the code to accept both.
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on November 24, 2013, 06:57:23 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?
I installed FW update 00.01.07.00.03 with some hesitation due to it having a couple serious bugs, but I decided that it would be worth it to find out if it had a FPGA update embedded in it or not. It did, now I have Software Ver. 00.01.07.00.03, as well as FPGA Ver. 00.01.08.03. So now I'm happy to have my unit up to date.  I'll just wait for Rigol to release the next version of software to correct the flaws in 07.

Reference the following for info on Software 07 bugs:
Re: Rigol DG4xxx ppulse and npulse
« Reply #5 on: October 22, 2013, 09:25:30 PM »
https://www.eevblog.com/forum/testgear/rigol-dg4xxx-ppulse-and-npulse/ (https://www.eevblog.com/forum/testgear/rigol-dg4xxx-ppulse-and-npulse/)
Rigol confirmed it is a bug.
This update also fully resolved the problem I was having with the DG4000 Screen Saver.  Where as before it would be flaky about 20% of the time, although it did still blanked the screen.
Title: Re: DG4000 - a firmware investigation
Post by: aurel on November 24, 2013, 08:32:44 pm
@cybernet

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

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

Anyway, very good job !
Title: Re: DG4000 - a firmware investigation
Post by: Mark_O on November 25, 2013, 09:08:33 am
http://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?
Just checked, works fine for me. Filezize: 9.740 kB

Thanks, Anders.  Not sure what was going on the first time, but based on your report, I just gave it another try and it came down fine.   :-+
Title: Re: DG4000 - a firmware investigation
Post by: monster on November 27, 2013, 01:26:31 pm
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
Title: Re: DG4000 - a firmware investigation
Post by: AndersAnd on November 27, 2013, 01:33:38 pm
I've got a "new" DG4062 and it has a serial # with an "E" not a "D" in the 4th char. I had to modify the src [..]
So I was too slow ... just did more or less the same thing and came back here to post it also works with the 'E'-type serials. I believe it might be ok to allow both variants in the original source by Cybernet. Until then a 's/DG4D1/DG4E1/g' will do the job as well.

LG Daniel
Allowing D and E isn't enough, as elCap already reported earlier in this topic having one with a serial number starting with DG4B1:
I'm unlucky  :'(...  I have a DG4102 with a serial number starting with DG4B1. cybernet's program requires DG4D1..
Guess I have to take the JTAG route.. Anyway, thanks for your work!! :-+
Title: Re: DG4000 - a firmware investigation
Post by: monster on November 27, 2013, 02:57:09 pm
I've got a "new" DG4062 and it has a serial # with an "E" not a "D" in the 4th char. I had to modify the src [..]
So I was too slow ... just did more or less the same thing and came back here to post it also works with the 'E'-type serials. I believe it might be ok to allow both variants in the original source by Cybernet. Until then a 's/DG4D1/DG4E1/g' will do the job as well.
Allowing D and E isn't enough, as elCap already reported earlier in this topic having one with a serial number starting with DG4B1 [..]
So why not try 's/DG4D1/DG4B1/g'? It's a no brainer for testing. For this purpose one could also just comment this line:

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

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

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

LG Daniel
Title: Re: DG4000 - a firmware investigation
Post by: KedasProbe on November 27, 2013, 03:43:03 pm
This D,B or E doesn't seem to change the hardware version so it may just be a production time indicator of the same hardware....
Unless someone knows better?
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 27, 2013, 04:23:56 pm
the serial gets compared to the current one - and the serial gets written (in case of change serial).
i actually used DG4D000DEADBEEF once not thinking if it likes hex at all ;-) but it worked - but i would not completely skip the DS4 thing, could be it dislikes that (bootup process does something with serial num)
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 03, 2013, 04:19:21 pm
DG4000 Arbitrary Function Generator - 121 VAC Power Consumption:

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

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

Operating Mode (Power ON)
   W     17
   VA   35
   A      0.3
   PF    0.47
Title: Re: DG4000 - a firmware investigation
Post by: Avotronics on December 04, 2013, 09:17:19 am
Anyone got Firmware 00.01.07.00.03 ?
The one in this topic is saying corrupt by winrar.
Title: Re: DG4000 - a firmware investigation
Post by: AndersAnd on December 04, 2013, 09:40:28 am
Anyone got Firmware 00.01.07.00.03 ?
The one in this topic is saying corrupt by winrar.
Try to extract the zip-archive online here, it looks like this works: http://b1.org/online (http://b1.org/online)

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!   :-+

Attached is the latest firmware (00.01.07.00.03)
This file gives an error when trying to extract? (only empty folders)
edit: it does work with 7zip, not with winRAR or Windows 7 zip, Thanks for sharing
Title: Re: DG4000 - a firmware investigation
Post by: Avotronics on December 04, 2013, 10:02:38 am
corrupt by winrar.
I got same error, you need a newer winzip.exe program .

Newer!!  :wtf:
I have the latest winrar, I'm always suspicious if winrar can't open it.
Title: Re: DG4000 - a firmware investigation
Post by: Avotronics on December 04, 2013, 10:07:27 am
Anyone got Firmware 00.01.07.00.03 ?
The one in this topic is saying corrupt by winrar.
Try to extract the zip-archive online here, it looks like this works: http://b1.org/online (http://b1.org/online)

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!   :-+

Attached is the latest firmware (00.01.07.00.03)
This file gives an error when trying to extract? (only empty folders)
edit: it does work with 7zip, not with winRAR or Windows 7 zip, Thanks for sharing

Cheers, got that okay.
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 04, 2013, 11:17:24 am
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)

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

By the way FW 00.01.07.00.03 also updates the FPGA.
 
Title: Re: DG4000 - a firmware investigation
Post by: AndersAnd on December 04, 2013, 11:26:43 am
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.
Title: Re: DG4000 - a firmware investigation
Post by: AndersAnd on December 04, 2013, 11:30:25 am
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?
Isn't the same bug in older firmwares too?
Title: Re: DG4000 - a firmware investigation
Post by: Avotronics on December 04, 2013, 11:38:47 am
I've repackaged the firmwares into fresh zips with winrar 5.01 as I had trouble with one of the other firmwares too.
Not sure what (whoever) is using to zip them originally but something isn't right.

http://rigol.avotronics.co.uk/dg4000-series/ (http://rigol.avotronics.co.uk/dg4000-series/)
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 04, 2013, 01:15:42 pm
I'm looking into determining what is involved in calibrating the DG4000 to produce a constant (flat) sine wave output level up to 200 MHz.  Although my DG4000 is essentially flat up to about 120 MHz (-1 dB), I would like it ti be flat up through 200 MHz +/- 1 dB or better.

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

I will be working on developing a calibration procedure to accomplish this task.
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 06, 2013, 05:47:35 pm
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. Hi

Repeat for the remaining channel (only if you find it necessary, but I don't think that it will be).
 
   Cheers, Ted
Title: Re: DG4000 - a firmware investigation
Post by: Rufus on December 06, 2013, 06:30:55 pm
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?
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 06, 2013, 07:40:11 pm
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?

Measure Value :  Shows the current value (although apparently it may not be fully active) and outputs its frequency and level for you to measure.
Input Value:     :  Allows you can enter your new measurement value (from the Measure Value step above).

I don't how this fixes the issue with frequency response, just that it brings it all back to life, by Restoring the Original Calibration.  Running the Factory Restore by itself won't do it.   

Don't bother to measure or change anything.  Its not required or necessary.
Just follow the steps I provided to activate the current values that were somehow unactivated from the GEL patch.
If you have already changed some values, then I would exit and restore the Factory Defaults and then repeat the procedure I provided.  But, of course that's your option.
I'm of course starting to wonder if perhaps the same thing should possibly be done for AV, LFLAT, but certainly nothing else. Although I'm not going to go there at this time unless we spot a potential issue.

And by the way my frequency response up to 200 MHz looks to be +/- 0.5 dB or better so far.

Note:  Do the guys here with DG4000 FW 00.01.07.00.03 and the 'ppulse and npulse' issues have this patch installed, if so, could they be getting another artifact that could be related?  I don't know, but they may want to consider the possibility.

     Ted 
Title: Re: DG4000 - a firmware investigation
Post by: Rufus on December 06, 2013, 07:47:35 pm
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.
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 06, 2013, 07:58:08 pm
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.
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.
Title: Re: DG4000 - a firmware investigation
Post by: KedasProbe on December 07, 2013, 11:27:56 am
Interesting, you have a DG4062 but the stored call settings (but not 'activated') gives you a flat responds even higher than 160MHz.

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.
Title: Re: DG4000 - a firmware investigation
Post by: Teneyes on December 07, 2013, 11:35:45 am
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


DG4000 Calibration Restoration:
I think the  steps:
   "Measure Value",
   "Input Value",
   "Rotate select next cal Point"
 can be stepped thru the 62 points and then save only once to save time.
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 07, 2013, 02:56:53 pm
Interesting, you have a DG4062 but the stored call settings (but not 'activated') gives you a flat responds even higher than 160MHz.

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.
No, I do Not think this is the case.
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 07, 2013, 03:01:04 pm
DG4000 Calibration Restoration:
Re. Sniffing the Rigol's internal I2C bus, Reply #1771

I now believe that the Restoration of the DG4000 calibration should be done for AC, LFLAT, and HFLAT to correct some other potential glitches.  Nothing is being changed, or has to be connected to the DG4000, so the process goes fast.  Just bring up and save all the default values for each step, starting with 1, or 1-1 (A/R).
You can also do this for 'Inner Imped' and 'Offset', although I haven't seen a case or benefit for it yet.

I just wouldn't do this for Freq Accuracy, or Counter, unless you see a need for it, and then you should complete this cal. process as prompted.

The calibration restoration is effective for both channels, it isn't necessary to repeat each cal. routine for the other channel.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on December 07, 2013, 04:07:04 pm
if somebody wants to fiddle with it - DG4000 supports 2 file types.

.CDF  - "RIGOL:DG4:CALIBRATION DATA FLASH FILE"
.CDV - "RIGOL:DG4:CALIBRATION DATA VOLATILE FILE"

my, guess its that what they use at the factory. i dont see any flash routines called for the CDV files (the parser is the same)
here is what i know:

file content:

RIGOL:DG4:CALIBRATION DATA VOLATILE FILE<X*0xb14><X*0x654><0x4230>[ <X*0xb14><X*0x654> ]
if X = 1 then the bytes in [ ] are expected too.

cant see where X is coming from atm - but maybe somebody figures out a relation of the sizes to the cal items. i wasnt successfull in that.


Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on December 07, 2013, 06:24:34 pm
Hello to all,

I got arround the same plot on DSA815 like PeDre (before calibrating) as I sweeped up to 200 Mhz.

Sorry, but I don't understand the calibration procedure. I'm not an expert  :(  and my english is poor also.

For example: I find ID1  HFLAT-1-1 (Meas Val) 11.8650 dBm. Ok, I can enter a new value now, but which value?
And what meens HFLAT-x-x ? Is it corresponding with a frequency or frequency-range?

Thank you for help
Rigol-Friend

Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on December 07, 2013, 06:50:52 pm
@Pedre

Thank you for your fast answer, I will try it after dinner.   :D

Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on December 07, 2013, 09:21:49 pm
Very good, PeDre, it works fine, thank you.

I have an output difference between 10 Khz and 200 Mhz of maximum arround 0.5dB. I measured this with DSA815 and Rohde&Schwarz URV35 with URY Z2 Detector. I adjusted the frequencies by hand.

But not so in sweep-function. Adjusted 0dBm of DG4202 produces arround 5dBm until 100Mhz and higher the output falls down till 0dBm at 200Mhz.

Rigol-Friend
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 08, 2013, 03:54:04 am
DG4062 to DG4202 Internal Calibration Info provided at the following:
Sniffing the Rigol's internal I2C bus,  Post #1785,  https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg344008/#msg344008 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg344008/#msg344008)
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 09, 2013, 04:22:21 pm
Does anyone else observe this? (FW=1.04)
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  ?
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?

It would also be nice to know what this looks like on an original (as received) DS4162.  Maybe someone can comment that has one of them.

Thanks, Ted
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 09, 2013, 04:44:54 pm
DG4000 Calibration Restoration:
The calibration restoration is effective for both channels, it isn't necessary to repeat each cal. routine for the other channel.
I am not sure of "effective for both channels" is true ??
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
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.
Title: Re: DG4000 - a firmware investigation
Post by: Teneyes on December 20, 2013, 07:58:02 am
Here are 2 Animated displays  of an auto freq. sweep of a sine wave on DG4000
  1) from 10-160MHz
  2) from 10-161MHz

DSO recording was used to capture 160 frames at 75msec during the sweep
every 10th frame is shown:
       on 1) very little variation of Vp-p
       on 2) Vp-p  starts high and ends at correct value

Again does anyone see this variation on their Rigol  DG4000??
Cannot say this is a Bug ;D
Title: Re: DG4000 - a firmware investigation
Post by: KedasProbe on December 20, 2013, 10:56:01 am
Is 10-159MHz also OK?
(in theory you can't enter >160Mhz so...)
Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on December 20, 2013, 02:05:09 pm
Yes this "bug" is known. See https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg343895/#msg343895 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg343895/#msg343895)

I think, it's maybe a problem with the hardware. Rigol offers the "right" 4162 with maximum frequency limited of 160 Mhz.
I think that has a reason.

Title: Re: DG4000 - a firmware investigation
Post by: whotopia on December 30, 2013, 01:11:44 pm
Hi all,

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. Unfortunately the Rigol site's beyondmeasure.rigoltech site seem to not be working for the past few days, and thus I can'd download http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-0115/0/-/-/-/-/file.pdf (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-0115/0/-/-/-/-/file.pdf)  (the upgrade instructions).  (yes I've search around this forum and others)   

Thanks!
Steven
Title: Re: DG4000 - a firmware investigation
Post by: Rigol-Friend on December 30, 2013, 04:06:29 pm
Hi whotopia,

I tried it some minutes ago and got this PDF without any problem. For you I attached here.
Title: Re: DG4000 - a firmware investigation
Post by: AndersAnd on December 30, 2013, 04:23:09 pm
Hi whotopia,

I tried it some minutes ago and got this PDF without any problem. For you I attached here.
The website seems to b up an running again. I tried without luck to download it after whotopia's post.
But now I have just tried again and now it works.
Title: Re: DG4000 - a firmware investigation
Post by: whotopia on January 01, 2014, 12:12:58 pm
Thanks everyone for the instructions and help.  Upgrade worked fine, but I did need to go through 4-5 memory sticks before I found one that the Rigol would accept.  Seem like I'm not the 1st person with that problem.
Title: Re: DG4000 - a firmware investigation
Post by: snipor on January 02, 2014, 09:19:51 pm
@Rigol-Friend
Would it be possible that you take a quick look in your Message Box?
Thanks
Title: Re: DG4000 - a firmware investigation
Post by: roket on February 04, 2014, 02:20:44 am
hi, everybody! there is at somebody file CyberNet  http://pastebin.com/ipkJCxPM (http://pastebin.com/ipkJCxPM)   ?
Title: Re: DG4000 - a firmware investigation
Post by: roket on February 04, 2014, 08:38:23 am
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
Title: Re: DG4000 - a firmware investigation
Post by: roket on February 04, 2014, 10:59:26 pm
help!  help!  SOS!  SOS!  |O
Title: Re: DG4000 - a firmware investigation
Post by: Orange on February 05, 2014, 06:18:19 pm
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

Title: Re: DG4000 - a firmware investigation
Post by: roket on February 05, 2014, 07:13:13 pm
thanks a lot, I already received, but it is good that it will be here
Title: Re: DG4000 - a firmware investigation
Post by: dougbert on February 06, 2014, 01:04:45 am
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?

Thanks,
Doug
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on February 06, 2014, 02:11:01 am
BTW, is 00.01.07.00.03 still the newest available firmware?

Appears to be the case.  In fact, it's already later than the "latest" version listed on Rigol's website, which is 00.01.06
http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-000d/t/page/fm/0 (http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-000d/t/page/fm/0)

Edit: actually, the link above is showing old information...dated June 2013...it is not the most recent info I have seen.  Appears to be something wrong with Rigol's "Firmware Request" feature at the moment...
Title: DG4000 button responsiveness
Post by: Sparky on February 06, 2014, 03:01:00 am
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!
Title: Re: DG4000 button responsiveness
Post by: Sparky on February 06, 2014, 07:11:51 am
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?
Title: Re: DG4000 button responsiveness
Post by: Orange on February 06, 2014, 04:31:34 pm
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 :-))
Title: Re: DG4000 button responsiveness
Post by: Sparky on February 06, 2014, 05:09:38 pm
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 :-))

Thanks for checking Orange!  It is good to hear that keyboard remains very responsive on 01.07.  I will see if anyone else has further news.  Probably I will try a re-install of 01.07 after some more use and testing.
Title: Re: DG4000 button responsiveness
Post by: Sparky on February 06, 2014, 10:39:43 pm
I noticed a change in my DG4062's response to button presses after ......
Has anyone experienced anything similar?
@Sparky  No prblem here with 'Keyboard Version 04.01' 
 No stall here, with 2 index fingers tapping any 2 digits .

Thanks Teneyes for your testing and report.  I used the DG4062 again this morning, still okay with respect to button presses, so I decided to upgrade again to 01.07...

And, working good so far!  So, I've no idea why it was acting weird before, but working smooth now --- no missing digits when typing on the keypad!  Will call this "problem solved"!

Thanks Orange and Teneyes!
Title: Re: DG4000 - a firmware investigation
Post by: Ivan7enych on February 25, 2014, 02:16:29 pm
I was trying to compile source code with MS Studio 2010 and generate cen file, but have got invalid file.

After several attempts, I've found working instruction here (using online compiler) -
https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg333919/#msg333919 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg333919/#msg333919)

Byte comparison shows me that windows compiler added \r\n line ending in one place, after that all other bytes appear wrong. So the current source code is for unix only.
Title: Re: DG4000 - a firmware investigation
Post by: Commander_Alpha on March 19, 2014, 04:39:17 pm
Hello Everybody,

a few days ago i received a new firmware for my DG4062. its version 1.08.

I attached the file. so everybody can try it.
ops to big. so here is the dropbox link

https://dl.dropboxusercontent.com/u/39956960/DG4000%28DSP%29Update_00.01.08.00.02.zip

greets
Title: Re: DG4000 - a firmware investigation
Post by: KedasProbe on March 20, 2014, 09:14:59 am
Thanks, it has a version history file:
Google translate
1) added more languages
2) increasing the synchronous output mode

So any idea what changed about the synchronous output, bugfix?

Title: Re: DG4000 - a firmware investigation
Post by: ted572 on April 22, 2014, 08:30:44 pm
Thanks, it has a version history file:
Google translate
1) added more languages
2) increasing the synchronous output mode
So any idea what changed about the synchronous output, bugfix?
After installing the new firmware do you still have 160 MHz and any other option hack you had before?
   Thank you in advance.
Title: Re: DG4000 - a firmware investigation
Post by: KedasProbe on April 23, 2014, 11:05:28 am
I did not hack my 100Mhz version (yet), so I cannot tell you.
Title: Re: DG4000 - a firmware investigation
Post by: Teneyes on April 23, 2014, 07:25:51 pm
a few days ago i received a new firmware for my DG4062. its version 1.08.
I Loaded it , All looks ok
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on April 24, 2014, 11:13:07 am
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)?

I'm asking because I initially had my unit set for 200MHz, but decided to go back to 160MHz to avoid any other unknown glitches other than the level drop off above 160 MHz in the Sine sweep mode (although the CW output was flat up to 200MHz).  I also would like to use the 200MHz mod. for the benefit of the improved Rise and Fall times for the Square and Pulse waveforms, if all else is OK with the 200MHz.

Thank you for your opinion about the use/risks of using 200MHz vs. 160MHz.  Ted572

      PS   Firmware 00.01.08 is working fine for me also.  Thanks for your comments in your Reply 194 above.
Title: Re: DG4000 - a firmware investigation
Post by: EV on April 24, 2014, 11:30:46 am
My generator is set to 160 MHz in factory. It drops about 1 dB from 1 MHz to 160 MHz.
Title: Re: DG4000 - a firmware investigation
Post by: Teneyes on April 24, 2014, 11:59:05 am
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
Just be aware to do "Auto Sweeps" only up to 160,
Manually(pic) set output is mostly flat to 200
Title: Re: DG4000 - a firmware investigation
Post by: hacker27 on July 04, 2014, 01:33:32 pm
I just noticed a problem upgrading to the non-existing DG4202: LXI does not work anymore. If you want to use LXI, stay with the DG4162, this works well.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on July 04, 2014, 01:38:01 pm
LXI works fine, for me.
if u mean the ultra sigma crap tool u have to hack the config files i doesnt know about a non existent model of course
Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr on August 03, 2014, 05:28:42 pm
I've just ordered a DG4062.  I paln to try the upgrade to 4162 or higher.  Questions:

1. Is Clayton's online compile (bottom of P7 of this thread) to generate an upgrade .cen file still valid?
2. If I have vn 3.0 firmware, do I need to downgrade to 2.0 first?
3. Will the 4062 upgrade to 300 MHz? If so, what is the target model number?

Any guidance much appreciated.
Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr on August 04, 2014, 11:51:59 am
@ Gandalf
What are you talking about?    Check rigol. site for FW and models
Are you buying a DSO or a Function gen.  .
Erm... 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?
Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr on August 08, 2014, 12:37:54 am
That was easy, just followed the instructions at the bottom of page 7.

I was concerned that my Ser# started DG4E1xxxxxxxx and that there was a strncmp or something that would block that but all I found in code were comments.

Parameters DG4062 DG4202 DG4E1xxxxxxxxx worked, extracted the cen file, and it was accepted no issues.  I can dial up 200 MHz sine waves but haven't actually scoped em.

How do I get to see the Sw Vn, all I see is 00.01.07

Will look at the cal stuff over the weekend.

 :-+
Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr on August 11, 2014, 05:13:10 pm
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
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on August 27, 2014, 02:10:21 am
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

Gandalf:

Please read all of the below so that you know what to expect:

For a DG4202 the CW RF Output should be flat up to 200MHZ within +/- 0.8dB after the Calibration recovery has been completed.  Note that the Sine Sweep Mode is still limited to a maximum frequency of 160.000,000 MHz for a flat RF Output.  Any Stop frequency above this at all, will screw up the frequency response even below 160MHz.  So if want to go beyond 160.000,00MHz do it in Sine CW mode only.

Still think your DG4202 has a problem:

Check that your DG4202 is Set for (under Utility, Settings) 'Power, Default', Not 'Power, Last'.  Then I suggest going back to FW 00.01.06.  Verify that you still have a DG4202 model installed per the DG's 'Utility', 'System', 'Information' menu.  If not use the appropriate CEN file to change it to one.  Perform the Calibration Recovery routine for Amp-AC*, LFLAT*, and HFLAT.  Then go back up to to FW 00.01.08.    How is it now?

Note: *   Cal for Amp-AC and LFLAT Cal. may not be required, but I do it to prevent other potential glitches.  I had a few people tell me that doing this fixed some issues for them, but I don't have any conclusive evidence.  It's easy to do, but you can always go back and do these two later (if you chose to) after you have determined your unit is now working Ok in manual CW mode to 200MHz.

The above is what I have successfully done and has worked for others, but if there is something unusual with your unit (i.e.  FW/hardware) I'm NOT responsible.  I think you will be OK, but I live far, far away, so don't come looking for me.

If you have questions, but no bitching please (Ha Ha), feel free to contact me via a PM.

       Good luck, Ted572
Title: Re: DG4000 - a firmware investigation
Post by: TooOldForThis on August 27, 2014, 03:27:16 am
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.
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on August 27, 2014, 11:58:29 am
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.

Install FW 00.01.08 and then try this again.  There were some bugs in .07 that were fixed in .08.  Even the installation of FW .07 was a little different than normal.  In fact several reported that they didn't think the installation completed properly.  Although the DG reported that FW .07 was installed (via. Utility, System, Information).  I don't know that the issue you found was fixed, but you certainly do want to go to .08.
Title: Re: DG4000 - a firmware investigation
Post by: TooOldForThis on August 28, 2014, 12:44:29 am
I had updated to 1.08 in July.  It didn't help.

Here are the results using rev 1.08 firmware:
Setup:  Measuring the period of a GPS pulse-per-second output. The DG4062 is running on an external 10MHz Rubidium time source.  Gate Time = 10sec. HF suppression on.

Front panel period measurement = 1.0000000011   (dang, off by 1.1nS  ;) )

At the same time, the SCPI output for  “:counter:measure?” is
9.999989975E-01, 1.000000014E+00, 1.000000047E+01, 1.000029678E-01, 8.999970466E-01
(Frequency, Period, Duty Cycle, Positive Pulse Width, Negative Pulse Width)

The problems are:
    The period value displayed over SCPI is always 13-14nS higher than the value on the display.
    The period and frequency values in the SCPI data are not reciprocals of each other.
 
On the plus side, the Positive Pulse Width and Negative Pulse Width values add up nicely to the Period value in the SCPI data.
When test equipment gives you conflicting data for the same measurement, which data, if any, should you believe?
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on September 13, 2014, 11:13:21 pm
The NEW 2014 Rigol DG4000 Performance Verification Guide is attached:
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on September 13, 2014, 11:16:37 pm
The new Rigol 2014 DG4000 Calibration Guide is attached:
Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr on September 17, 2014, 04:00:26 pm
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?

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.
Title: Re: DG4000 - a firmware investigation
Post by: Orange on September 17, 2014, 04:54:35 pm
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?

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.
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.
Try to get firmware 1.08. This can be loaded without to upgrade the boot loader.
BTW, the patch that is available makes a 200MHz generator. Since your friend's model is already a 160MHz generator loading 1.09 firmware is only a small improvement. It's a different story if you own a 60 or 100MHz model.

I forgot to mention that you need a small size USB stick, 1 or 2 Gbyte. Larger sizes give errors
 
Title: Re: DG4000 - a firmware investigation
Post by: Rory on September 19, 2014, 02:07:47 am
What bugs does the 1.09.00.01 firmware fix?
Title: Re: DG4000 - a firmware investigation
Post by: rhost on September 19, 2014, 02:20:30 am
I forgot to mention that you need a small size USB stick, 1 or 2 Gbyte. Larger sizes give errors

 I used a 32GB Sandisk Cruzer on mine. I have 3 other brands of various sizes and they all didn't work. I think the brand makes more of a difference than the capacity.
Title: Re: DG4000 - a firmware investigation
Post by: MiataMuc on October 01, 2014, 07:54:27 am
Hi all,

just a short question: anyone bought a DG4062 in the last few days and knows what firmware will be delivered?

Thanks,

Flo
Title: Re: DG4000 - a firmware investigation
Post by: rhost on October 01, 2014, 01:05:48 pm
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 bought one within the last month or so and the firmware version was

Software 00.01.08
FPGA 00.01.09
Hardware 01.03
Keyboard 05.01
Title: Re: DG4000 - a firmware investigation
Post by: dave3533 on October 09, 2014, 11:44:45 pm
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 purchased a DG4062 from TEquipment on 10/01/2014 and the system info was:
Firmware: 1.08
FPGA: 1.09
Hardware: 1.03
Keyboard: 5.01

The calibration paperwork from Rigol states it was calibrated in April of 2014.
Title: Re: DG4000 - a firmware investigation
Post by: pedjasns on October 26, 2014, 06:26:47 pm
Just got a new DG4062

SW: 00.01.09
FPGA: 00.01.09
HW: 01.03
Keyboard: 06.01

Can it be hacked now or not?  :-\
Title: Re: DG4000 - a firmware investigation
Post by: MiataMuc on October 29, 2014, 07:18:52 pm
Seems not to be the case with the methods we know.
Maybe someone who knows the internals is willing to help? I can offer any data which is needed; I do have an Olimex JTAG adapter and will provide any data which is requiered..

Florian
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on October 31, 2014, 08:23:47 pm
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.
Title: Re: DG4000 - a firmware investigation
Post by: MiataMuc on November 02, 2014, 03:22:59 pm
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..

Florian
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on November 02, 2014, 04:08:25 pm
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.

Yes, I'm facing the same problem...

Title: Re: DG4000 - a firmware investigation
Post by: Sparky on November 02, 2014, 07:25:09 pm
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! Piranha(DSP)Update_00.01.09.zip (http://wikisend.com/download/411438/Piranha(DSP)Update_00.01.09.zip)
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on November 02, 2014, 07:30:23 pm
Hope this helps!

Thanks Sparky! Now for some serious disassembling  :-/O

Edit: Looks like they encrypted the update GEL file now... Well, the answer must be in the boot loader  :box:
Title: Re: DG4000 - a firmware investigation
Post by: TooOldForThis on November 02, 2014, 09:12:47 pm
Quote
Hope this helps! Piranha(DSP)Update_00.01.09.zip

I applied this update a week ago.  I found that you have to rename the GEL files to DG4000Update.GEL before the boot loader will recognize them on your USB stick. 
I don't know what 1.09 fixes, nothing that I could see.  The counter function is still gives different values on the LCD vs SCPI output for slow frequencies (~1Hz)  and the frequency and period values for a single measurement are not reciprocals of each other. Just kind'a close.
Title: Re: DG4000 - a firmware investigation
Post by: EV on November 03, 2014, 02:49:38 pm
I tried this "Piranha(DSP)Update_00.01.09.zip" update without luck.

When Mod and Utility buttons ware lit I inserted the USB stick with DG4000Update_Bootloader.gel file in it. Something was read for a while and Store button was also lit. Then nothing happened for many minutes and I powered off the generator.

I have now 00.01.08.00.02 FW.
Title: Re: DG4000 - a firmware investigation
Post by: MiataMuc on November 03, 2014, 08:14:58 pm
 PA0PBZ:

I'd really like to help, but I do not have any experience in Diassembling :-(

Florian
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on November 03, 2014, 08:25:54 pm
Actually I made some progress. The GEL file is not really encrypted, they just added 00-FF repeatedly starting at address 0080, so that was a quick fix.
Comparing with 00.01.08 I found that the key is still the same, they deleted the (nonexisting) DG4202 model and they sortof halfway deleted the .GEN file support  :--
I'm not sure how to go from here, I could try to downgrade to version 00.01.08 by lying about the version maybe, or try to find out if there is still support for .GEN files hiding. I'm trying to find a blackfin plugin for my IDA but having a hard time to find a Visual C 6.0 to compile it. Anyone have a spare blackfin plugin for IDA 6.1?

Title: Re: DG4000 - a firmware investigation
Post by: TooOldForThis on November 04, 2014, 12:50:13 am
Quote
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 new application file took at least 10 minutes to load.  For both files, the DG4000 rebooted  itself after it was done loading the new GEL file.  Don't chicken out part way through the load process.     
Title: Re: DG4000 - a firmware investigation
Post by: EV on November 04, 2014, 08:04:07 am
..   
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.

The USB stick is 1 Gb Kingston and it works with the generator.

Here is the system information now:

Software 00.01.08
FPGA 00.01.09
Hardware 01.01
Keyboard 04.01
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on November 04, 2014, 12:46:31 pm

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?

Title: Re: DG4000 - a firmware investigation
Post by: EV on November 04, 2014, 02:06:12 pm
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
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on November 04, 2014, 02:18:26 pm
I did not realise that also the bootloader file had to be renamed.

Don't worry, I only got the idea after reading your post for the third time  ;)
Title: Re: DG4000 - a firmware investigation
Post by: Orange on November 04, 2014, 02:45:02 pm
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
Is the calibration still OK after the 1.09 upgrade?
If the calibration is back to defaults, your amplitude and offsets are way out.


I'm asking because if you upgrade the firmware on a DG1022, your calibration is lost, and loads factory defaults. I had this with my DG1022.

Just be aware that upgrading software on RIGOL generators it might loose your calibration!
Title: Re: DG4000 - a firmware investigation
Post by: EV on November 04, 2014, 02:59:20 pm
Just be aware that upgrading software on RIGOL generators it might loose your calibration!

If the calibration will be lost, I have lost it already two times before this update. This was third FW update for my DG4162. There is only manual calbration which is behind password.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 05, 2014, 01:12:32 am
http://bayfiles.net/file/1lrDi/0Wrw06/bfin_rigol_cybernet.rar (http://bayfiles.net/file/1lrDi/0Wrw06/bfin_rigol_cybernet.rar) (for IDA 6.1)

bfin module is (c) Andreas Schuler, rigol ldr contains some of my mods to also read GEL files right away.
PM me if u need the IDA DB with my initial reversing of the .GEN files.

maybe its worth checking new vs old bootloader to prevent rigol from preventing u to downgrade.
the old BL is fully reversed if somebody has questions about it.

unfortunately not much time for rigol stuff lately, but i see its in good hands ;-)
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on November 06, 2014, 02:46:26 pm
http://bayfiles.net/file/1lrDi/0Wrw06/bfin_rigol_cybernet.rar (http://bayfiles.net/file/1lrDi/0Wrw06/bfin_rigol_cybernet.rar) (for IDA 6.1)

bfin module is (c) Andreas Schuler, rigol ldr contains some of my mods to also read GEL files right away.
PM me if u need the IDA DB with my initial reversing of the .GEN files.

maybe its worth checking new vs old bootloader to prevent rigol from preventing u to downgrade.
the old BL is fully reversed if somebody has questions about it.

unfortunately not much time for rigol stuff lately, but i see its in good hands ;-)

CYBERNET:

Please take a look at your download link [ http://bayfiles.net/file/1lrDi/0Wrw06/bfin_rigol_cybernet.rar ].  When I go to bayfiles via this link and select Download for your file,  a On-Line Game comes up that does some nasty things to my computer if I don't exit out of it.  I use the application EAZ-FIX so I can recover quickly and easily, but other users may not be as lucky.
Sorry if I'm wrong, and this is a false alarm, but I don't think so.  Please let me know if everything looks Ok to you and that I'm wrong.
Thank you, Ted572
 
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on November 06, 2014, 02:49:28 pm
Click the Premium Download button... 8)
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on November 06, 2014, 04:25:45 pm
Click the Premium Download button... 8)

PA0PBZ: Yes 'Premium Download' does download the file, but another incidence of my Internet Browser was opened with an advertisement in it along with the downloaded file.   Therefore my personal opinion is that this isn't necessarily a favorable file download service for us to use.  Without you telling me I wouldn't have known about having to use the [Premium Download] button, as this usually means that it requires membership with the download site with a paid for user fee.

CYBERNET: I very much appreciate your providing these files for us to download, as well as all the assistance that you have provided me personally, and the EEVblog group.

  Thank you both for your dedication to helping us, Ted     
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 06, 2014, 04:27:04 pm
i would expect that ppl who can make use of my shared files are able to download them without infecting their computer with adware - if not, then i suppose it acts as a gatekeeper ;-)
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on November 06, 2014, 04:37:24 pm
i would expect that ppl who can make use of my shared files are able to download them without infecting their computer with adware - if not, then i suppose it acts as a gatekeeper ;-)

Your point is well taken.  As I had disabled my 'Ad Muncher' application to see the worst case effect that others without protection may have.  Thank you
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on November 06, 2014, 06:34:41 pm
Therefore my personal opinion is that this isn't necessarily a favorable file download service for us to use.

Ted,
I totally agree with you, I just hate these sites tricking you into clicking something that you wouldn't if you knew, like this example or the ones with download buttons all over the place giving you a hard time to find the correct one, or those like a maze just telling you that the file is gone after you have been served ads for like 5 minutes.
But then again, there's something about the given horse etc... so if cybernet decided to use that site I'll thankfully download the file and curse silently :)
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on November 06, 2014, 06:38:45 pm
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.

I did PM but:

Quote
pm deactivated, use the search function ...

So not sure if it ever got there.
I'm interested in what you have, because I can always reinvent the wheel if I ever have enough time...
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 06, 2014, 08:36:42 pm
will send once im home again, dont have those on may travel laptop  :)
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on November 06, 2014, 08:46:18 pm
will send once im home again, dont have those on may travel laptop  :)

Thanks! And while you are at it, the IDA rigol loader file you uploaded is a .obj, not a .ldw
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 06, 2014, 10:36:16 pm
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 file
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on November 06, 2014, 10:42:43 pm
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 file
Got it, thanks!
Title: Re: DG4000 - a firmware investigation
Post by: guarneri0 on November 17, 2014, 04:26:51 pm
Hi,

I have read most of the thread and it appears that the latest 4062 is no longer hackable (as apparently it comes with a version of the firmware that can't be hacked yet.)

Is this still true?  Is there perhaps a more complicated route, but still hack 4062 to go up to ~200Mhz?  I was planning to purchase a 4062 and this is a key factor to consider.

Thanks.
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on November 20, 2014, 06:34:57 pm
the old BL is fully reversed if somebody has questions about it.

Hi Cyber,

If you have an IDA file for the old BL I'd be more than happy to have a look. The new FW is a dead end, they removed the part that reads the license file and I'm not feeling like putting that back in. So the best route to take is to convince the new BL to accept older FW, but even disassembled the BF code is hard to read. So if I can understand the old one I could probably make something up to fool the new one.
Title: Re: DG4000 - a firmware investigation
Post by: cybernet on November 20, 2014, 06:39:38 pm
see pm ;) dont want to give rigol ideas
Title: Re: DG4000 - a firmware investigation
Post by: fact on November 24, 2014, 05:03:13 pm
Cyber,

My DG4062 also suffers from a too recent firmware to hack and I'd like to take a peek at your investigations regarding the previous version of the bootloader. Wonder if you could spare me a copy of your work.
Title: Re: DG4000 - a firmware investigation
Post by: fact on November 29, 2014, 09:45:03 am
Any progress yet?
Title: Re: DG4000 - a firmware investigation
Post by: dudarobe on December 05, 2014, 06:46:17 pm
Hi, any one know, that dg4100 with:
Software 00.01.07
Hardware 01.03
It can be hacked?

Thanks, Robert
Title: Re: DG4000 - a firmware investigation
Post by: Teneyes on December 05, 2014, 10:12:54 pm
Hi, any one know, that dg4100 with:
Software 00.01.07.   Hardware 01.03
See  /here (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg382414/#msg382414)
Title: Re: DG4000 - a firmware investigation
Post by: Pasky on December 30, 2014, 04:06:10 pm
Hi, any progress made on this?  Thanks.
Title: Re: DG4000 - a firmware investigation
Post by: Pasky on December 30, 2014, 11:10:42 pm
Well, just ordered a DG4062 from Tequipment today.  Hoping the ones in stock have a 01.08 or lower.  If not, I think 60Mhz will satisfy what I need.
Title: Re: DG4000 - a firmware investigation
Post by: fact on December 31, 2014, 04:48:02 pm
It's been quiet the last couple of weeks. I'm hoping someone is looking into this.
I tried to obtain a copy of previous work of cyber to investigate myself. So far I did not get anything.

I'll just wait until someone comes up with a solution or stuff I can work on myself. In the mean time I'm maxing out at 60MHz.
Title: Re: DG4000 - a firmware investigation
Post by: Pasky on January 02, 2015, 11:54:38 pm
Just got my function generator today.  It had 01.07 on it and just modified it to a DG4202.  Thanks for all your work!

(http://i.imgur.com/XWtbQoBl.jpg) (http://imgur.com/XWtbQoB.jpg)

(http://i.imgur.com/UGIBGscl.jpg) (http://imgur.com/UGIBGsc.jpg)
Title: Re: DG4000 - a firmware investigation
Post by: Pasky on January 03, 2015, 12:07:04 am
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?

EDIT:

Nevermind, didn't adjust the period  :palm:
Title: Re: DG4000 - a firmware investigation
Post by: TooOldForThis on January 03, 2015, 12:38:25 am
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?

Check this service note from Rigol entitled "Why does my scope show a Sine Wave when I expect a Square?" http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-00ca/0/-/-/-/-/file.pdf (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-00ca/0/-/-/-/-/file.pdf)
Title: Re: DG4000 - a firmware investigation
Post by: Pasky on January 03, 2015, 12:41:00 am
Thanks for that!
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on January 03, 2015, 12:45:47 am
New firmware: DG4000 Series v00.01.10.zip (http://wikisend.com/download/482676/DG4000 Series v00.01.10.zip) (uses bootloader v00.00.06)

Edit: The bootloader (00.06) is the same as was released with the 01.09 firmware update.
Title: Re: DG4000 - a firmware investigation
Post by: TooOldForThis on January 03, 2015, 02:38:24 am
I just loaded 1.10.   Lord knows what this version fixed, but it wasn't the counter function.  At low frequencies, a period measurement read from the SCPI interface is still 13nS longer than the same measurement displayed on the LCD.  The SCPI and LCD frequency values don't match either.  Neither the SCPI or LCD frequency values are the reciprocals of either the SCPI period or LCD period values.  They've done a lovely job of maximizing the number of conflicting values reported for a single measurement.

Title: Re: DG4000 - a firmware investigation
Post by: Rory on January 03, 2015, 02:50:58 am
I just loaded 1.10.

Extended bandwidth mod still working?
Title: Re: DG4000 - a firmware investigation
Post by: plasijo on January 03, 2015, 08:57:11 am
Dear all,
may I ask you, where is the generator available for downloading? Unfortunately bayfiles.net is not working.
Thanks.
Title: Re: DG4000 - a firmware investigation
Post by: Chainsaw_ on January 04, 2015, 10:30:50 am
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?
Title: Re: DG4000 - a firmware investigation
Post by: Chainsaw_ on January 04, 2015, 10:32:34 am
where is the generator available for downloading?

Page seven, bottom post, from bandgap.
Title: Re: DG4000 - a firmware investigation
Post by: Teneyes on January 05, 2015, 01:37:55 am
Here is an interesting comparison with $1200 unit  testing  (https://www.youtube.com/watch?v=xqYQqXz7DZA&feature=youtu.be&app=desktop&t=27m20s)
Title: Re: DG4000 - a firmware investigation
Post by: Rory on January 05, 2015, 03:32:33 am
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?

Mine reverted back to DG4062 from DG4202 when 1.10 installed. :(
Title: Re: DG4000 - a firmware investigation
Post by: DrMag on January 06, 2015, 04:02:19 pm
Quote
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?

Quote
Mine reverted back to DG4062 from DG4202 when 1.10 installed.

Rory, was it possible to reenable the added bandwidth after the update?

Can anyone else verify/confirm one of the two conflicting results reported here?
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on January 06, 2015, 05:29:04 pm
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.
Title: Re: DG4000 - a firmware investigation
Post by: Rory on January 06, 2015, 06:41:30 pm
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

It was at 1.08 before the update. Dang, I wish I'd changed it to 4162 before updating the firmware.
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on January 12, 2015, 06:21:19 am
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.

I was using my DG4062 (now DG4162) and decide to check for amplitude flatness up to 150 MHz.  I found it to be quite bad above 60MHz; large +ve and -ve variation in amplitude with frequency.  It is much worse than Teneye's shows here (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg350723/#msg350723) or here (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg431464/#msg431464).  So I thought I hadn't done the "calibration restoration" correct as per ted572's instructions.

I repeated the "Calibration Restoration" for Amplitude, Low Freq Flat and High Freq Flat and Saved the results after completing the Measure Value/Input Value step for each set of points.  When I repeat the frequency sweep there doesn't seem to be any noticeable improvement in amplitude, compared to before restoring the calibration.  If I go back into calibration to inspect values I find the column of measured values ("MeasValue") is empty for all Amplitude, Low Freq. Flat, etc.  It doesn't show the values that were previously restored by the "Measure Value", "Input Value" button presses.  Are other people's experiences the same?  I'm thinking the calibration values are not being saved, and that's why I don't see any effect of the calibration.
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on January 12, 2015, 01:22:54 pm
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.

I was using my DG4062 (now DG4162) and decide to check for amplitude flatness up to 150 MHz.  I found it to be quite bad above 60MHz; large +ve and -ve variation in amplitude with frequency.  It is much worse than Teneye's shows here (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg350723/#msg350723) or here (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg431464/#msg431464).  So I thought I hadn't done the "calibration restoration" correct as per ted572's instructions.

I repeated the "Calibration Restoration" for Amplitude, Low Freq Flat and High Freq Flat and Saved the results after completing the Measure Value/Input Value step for each set of points.  When I repeat the frequency sweep there doesn't seem to be any noticeable improvement in amplitude, compared to before restoring the calibration.  If I go back into calibration to inspect values I find the column of measured values ("MeasValue") is empty for all Amplitude, Low Freq. Flat, etc.  It doesn't show the values that were previously restored by the "Measure Value", "Input Value" button presses.  Are other people's experiences the same?  I'm thinking the calibration values are not being saved, and that's why I don't see any effect of the calibration.

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 CoaxA 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.   
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on January 13, 2015, 06:08:31 am
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 CoaxA 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.   

Thanks ted572 for your comments!  My DG4062 was modified to DG4202 for a while, but the recent DSP v01.10 firmware wouldn't install on my unit (possibly I was still using the bootloader before v01.06 which was released with the previous DSP v01.09 firmware), and so I ended up downgrading to DSP v01.04, then upgrading to DSP v01.06, applied the DG4162 model, and then upgrading again to DSP v01.08.

Anyways, I appreciate your comments and from your notes my oversight was obvious --- I forgot to set the scope input to 50 Ohm impedance.  I repeat the measurements (600mVp-p sine wave, 1MHz to 159Mhz sweep over 10sec) now with 50 Ohm output on the DG4162, and the o'scope (MSO2072A modded to MSO2302A) input set to 50 Ohm internal impedance.  I used RG-58 A/U coax.

The results I obtained this time were much better, although the first was still much different than those published earlier (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg431949/#msg431949) so I repeated the frequency sweep with 3 different coax cables I have (different manufacturers).  I'm surprised to find significant differences with simple RG-58 A/U!  I have attached the screenshots from the o'scope --- you can easily see the 10sec over which the frequency sweep runs.

The last result seems very good.  I have to conclude no problem with the DG4162 calibration, and that lack of 50 ohm termination and coax quality was responsible for erroneous earlier results.  It is good to see things working correctly this time. 

Anyone feel free to leave some comments or post comparisons of frequency sweep from your DG4000 units.

Edit: Some extra info.  My AWG is DG4162 model (updated from DG4062), with following hardware/firmware revisions:
Software Version: 00.01.08.00.02
FPGA Version:     00.01.09.00
Hard Version:     01.01
Keyboard Version: 04.01
Title: Re: DG4000 - a firmware investigation
Post by: Teneyes on January 14, 2015, 06:51:00 am
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
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on January 14, 2015, 07:00:42 am
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

Nice, Teneyes!  The last result looks especially good.  That was a good idea to use trigger out of the DSO to start the sweep on the DG.  I will put a note on my cables, too.

Out of curiosity: Does anyone know which part(s) of the cable (coax itself, BNC connectors, or termination quality) is responsible for non-flatness and roll-off at high frequency.  If its not the coax itself, does that mean someone could "repair" a poor cable by replacing the BNC connectors?
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on January 18, 2015, 07:28:37 am
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

Thanks for the info, Ted!  Very helpful!  I wouldn't mind buying the cable and connectors and assembling myself so I can make custom lengths as needed, and from a quick look on Pasternack it is cheaper to buy the parts.  I note there are clamp/solder BNC connectors, so no costly crimp tool needed.  Would you happen to have a recommendation of a tool for cutting the insulation and braid to the specific lengths as needed for the connectors?  Thank you!
Title: Re: DG4000 - a firmware investigation
Post by: MiataMuc on February 02, 2015, 06:01:04 pm
wild idea (from someone who has never used a jtag-device other than for reading his DS2000 firmware out.. ): would it be possible to put an older (=hack-compatible) Firmware-Version on the DG4000 by jtag?

Flo
Title: Re: DG4000 - a firmware investigation
Post by: rf-loop on February 02, 2015, 07:53:49 pm
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

Cables are different, of course. It can read from cables datasheets.

One question about this interesting thing.

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)?

(this question is because there is not 50ohm source impedance and not 50ohm load impedance
Oscilloscope input is mostly NOT 50 ohm impedance at all. It is more like 50ohm resistance for DC.  There is around 50ohm resistance and then inductive and capasitive reactances series and parralle and because this scope input reflects back something more or less and depending cable lenght it affect more or less with different frequencies..)

Title: Re: DG4000 - a firmware investigation
Post by: Teneyes on February 03, 2015, 06:53:32 am
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 2 of the cables were 3 feet long and 1 was 6 feet long.
After I did the Cable sweep  test,  I did do a timing test  to see how much longer the 6' cable was  in time delay, so I connected the shorter cable on Chan.1 and the longer cable on Chan.2  and feed the Sync output pulse from each of the Gen 2 outputs (50 ohm) . One cable is about 6.4 nS longer. the Gen outputs were 'Frequency Locked'.
 
But as I show in the 2nd Pix the timing  drifts over time ( note clock 3hours, and my stored Ref traces, pink and white)  ,
When I reset the 'Phase Align'  the 2 pulses are aligned at the Gen again. see Pix #3 (5 hours)

That is something to know when locking 2 Channels on the DG4000. Frequency Lock does not Lock the phases also.
 
Title: Re: DG4000 - a firmware investigation
Post by: dpenev on February 03, 2015, 11:18:59 am
Hi Gents,

The slope of my DG4062 square wave is about 10ns, and this is what i see spicified in the documentataion 
On your pictures I see quicker slopes (about 2ns).
Have you done some calibration to get this?

Regards
Dimitar

   
Title: Re: DG4000 - a firmware investigation
Post by: Teneyes on February 03, 2015, 03:45:49 pm
On your pictures I see quicker slopes (about 2ns).
Have you done some calibration to get this?
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 .
Good for you to notice the slope, but did anyone notice the trigger point ;D
Title: Re: DG4000 - a firmware investigation
Post by: dpenev on February 03, 2015, 05:18:18 pm
Hi Teneyes,

Yes you seems to have 1ns shift in the trigger point issue in yoru scope?

Dimitar

Title: Re: DG4000 - a firmware investigation
Post by: rf-loop on February 03, 2015, 06:02:09 pm
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. 

Reason for this my question was just there. 50ohm feed thru in oscilloscope input is not 50ohm impedance.
So, these "waves" in sweep shape level tell that there is somewhere mismatch or scope front end itself is weird. I believe more mismatch. Genrator output... it is not true 50ohm impedance, scope input is not at all 50ohm impedance when there is 50ohm feed thru. Cable... what difference come from cable qualitu itself and whhaat come from testing quality for this named purpose - classifying cables quality. For this work you need other tools or just very strong "believe".
Title: Re: DG4000 - a firmware investigation
Post by: H.O on February 03, 2015, 06:35:53 pm
Hi,
Quote
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").

EDIT: Actually, you can enter any load resistance you want (from 1ohm to 10k) and the DG4000 will scale the displayed amplitude and offset values accordingly. The actual output resistance/impedense is always a fixed 50ohm (nominal). More details to be found on page 10-5 in the manual (http://www.batronix.com/pdf/Rigol/UserGuide/DG4000_UserGuide_EN.pdf).
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on February 13, 2015, 07:40:49 pm
It seems that now there is another reason (https://www.eevblog.com/forum/testgear/rigol-dg4xxx-signal-generator-burst-mode-bug/msg608849/#msg608849) to upgrade to firmware v1.09 :(
Title: Re: DG4000 - a firmware investigation
Post by: ytsejam on February 23, 2015, 09:34:10 am
Hi cybernet,

I own a DG4062 with latest FW 1.10. Just wondering if it is possible to revert the bootloader and firmware version to 1.08 by JTAG with mem dumps by 1.08 owners? Could you please help to shed some lights?
Title: Re: DG4000 - a firmware investigation
Post by: ytsejam on March 07, 2015, 07:16:28 pm
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg623998/#msg623998 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg623998/#msg623998)

The above link shows how to use TopJTAG Flash Programmer to dump the flash on DSA815. (at least a portion)

I used the same method to dump DG4062's flash (with bootloader 00.06), and compared the dumped binary with DG4000 bootloader 00.06 update file.
Found that the content of dump result does contain the bootloader 00.06.

If any owner of DG4062 with previous bootloader (00.05) can give a hand, help to use the same method to dump the flash (1MB file) and share it with me privately.
I can restore that back to my DG4062 to see if bootloader can be downgrade to 00.05 by this method. Then the new DG4000 (with 00.06) owner might get a chance to downgrade the FW to previous version.

Can anyone give a hand? Much appreciated!
Title: Re: DG4000 - a firmware investigation
Post by: fact on March 09, 2015, 04:01:08 pm
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?
Title: Re: DG4000 - a firmware investigation
Post by: ytsejam on March 09, 2015, 06:00:56 pm
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?

Sounds like chickens and eggs.

For new firmware (1.09 and 1.12), though not 100% sure, but I think RIGOL has removed the function for reading the CEN file or at least change the format.
And new bootloader (ver 06) won't accept firmware prior to 1.09.

So we got two choices:

1. Hack the new firmware to find out if there's any new way. This will require JTAG dump the flash and reverse engineering.

2. Overwrite the new bootloader (ver 06) with old one  (ver 05), and that needs JTAG as well.

3. Wait for someone to compile a firmware (home brew) can be loaded by new bootloader, which provides the capability to rewrite the bootloader back to old one or provides a way to update the flash with new model key.


Title: Re: DG4000 - a firmware investigation
Post by: MiataMuc on March 09, 2015, 07:26:04 pm
maybe anoter option:

dump the flash, do manually what the cen-file used to do, and then uplaod the changed flash?
Title: Re: DG4000 - a firmware investigation
Post by: ytsejam on March 10, 2015, 03:26:05 am
maybe anoter option:

dump the flash, do manually what the cen-file used to do, and then uplaod the changed flash?

That should work, but:

1. As I learned from the forum, the CEN file is a key file, if valid, DG4000 will store the key somewhere in the flash, however, I don't know in which form or format, nor the address.

2. JTAG is needed for dumping/uploading the flash. (which means we need to open the back cover)

Title: Re: DG4000 - a firmware investigation
Post by: signals on March 26, 2015, 01:27:28 am
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.

Well, it was fun while it lasted. I should learn to READ THE EEVBLOG FORUM before I go and do something stupid like upgrade the firmware on my hacked DG4062. :palm: Well at least it fixed the problem I was having where it would stop responding to SCPI commands over LXI when in counter mode. Think I'd rather have 200Mhz (or 160Mhz if I would have read the forum first) though.

I guess I'll keep my fingers crossed that someone figures out how to undo the damage I just did. Won't hold my breath though.  |O
Title: Re: DG4000 - a firmware investigation
Post by: lunxg on June 16, 2015, 08:58:43 am
Hi all,

Just got my DG4062 today(16/6/2015) and the software and FPGA version is 00.01.11
Hard version 01.03
Keyboard version 06.02
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on June 17, 2015, 06:12:37 am
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
Title: Re: DG4000 - a firmware investigation
Post by: EV on June 17, 2015, 08:19:56 am
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?
Title: Re: DG4000 - a firmware investigation
Post by: lunxg on June 17, 2015, 08:46:06 am
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

Hi Sparky,

where can I get the "160MHz model patch"? I would like to try in my new arrived one, thanks! :)
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on June 17, 2015, 01:53:22 pm
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.
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on June 17, 2015, 03:39:06 pm
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?

Looks like version 01.12 just came out!  I haven't tried it yet.
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on June 17, 2015, 04:32:17 pm
  The latest DG4000 Firmware 00.01.12.00.02 works fine!
Rigol DG4000 Firmware 00.01.12.00.02 Update Links follow below.
  DG4000 Firmware 00.01.12.00.02:  ->  http://beyondmeasure.rigoltech.com/acton/ct/1579/s-065a-1505/Bct/l-3732/l-3732:e30/ct3_0/1?sid=iDpmeZr9z (http://beyondmeasure.rigoltech.com/acton/ct/1579/s-065a-1505/Bct/l-3732/l-3732:e30/ct3_0/1?sid=iDpmeZr9z)
Note: In Rigol's USA style you may see 00.01.11 when you download it, but when you open it up you will see that is actually 00.01.12.00.02.
  DG4000 Installation of Firmware 00.01.09 and above:  Note: If you currently have Bootloader 00.06 installed, Skip the instructions for installing the Bootloader.
->  http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-032b/1/-/-/-/-/DG4FWUpgrade_Above_01_08.pdf?sid=iDpmeZr9 (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-032b/1/-/-/-/-/DG4FWUpgrade_Above_01_08.pdf?sid=iDpmeZr9)

Edit:  The Link for the Firmware installation instructions stopped working properly.  I revised it, and it is now functional again.
Title: Re: DG4000 - a firmware investigation
Post by: lunxg on June 17, 2015, 04:35:57 pm
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.

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.
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
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on June 17, 2015, 04:48:31 pm
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.
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.
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
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.
Title: Re: DG4000 - a firmware investigation
Post by: lunxg on June 17, 2015, 05:09:26 pm
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.
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.
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
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.
I got it.
So it is a hacked 160MHz with 1.09 -> 1.11 firmware without losing hack, right?
If 200MHz hack with 1.09 -> 1.11 firmware probably losing all the hack
Correct me if it is wrong
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on June 17, 2015, 05:29:25 pm
lunxg:

     Yes, you are correct.   Cheers, Ted572
Title: Re: DG4000 - a firmware investigation
Post by: EV on June 17, 2015, 07:25:50 pm
ted572

Thanks for the links!
Title: Re: DG4000 - a firmware investigation
Post by: lunxg on June 18, 2015, 02:51:55 am
OK... I still get a try to hack my new arrived DG4062 with software and FPGA  00.01.11 but it popup a message "please select a valid file type" when I press the read button with the .CEN file......

What I can do is learn how to operate the machine now, and wait for folks to hack the new version :)
Title: Re: DG4000 - a firmware investigation
Post by: scalargr on June 20, 2015, 02:01:39 pm
hello to all,
I have for some time my F G 4102 without any upgrade (fw  00.01.03),and I want to upgrade it at 160 MHz .
 My 1st attempts have been made with rory’s  instructions Reply #67 on: November 16, 2013, 05:44:44 PM  but It’s too complicated for me( I’m lacking knowledge of linux).
The 2nd was with  bandgap instructions on Reply #104 on: November 20, 2013, 06:40:38 PM ... I made several attempts and combinations as described , but nothing valuable came out.
( something is wrong / I’m wrong???) ???

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.


I don’t want to use 200MHz
Anyway, Could someone post some detailed instructions step by step on that, or could someone make any upgrade for me?????
Thanks.
PS: I managed to h/k my msox2014a successfully .Thanks to the forum and the contributors  ;)
Title: Re: DG4000 - a firmware investigation
Post by: neki on June 28, 2015, 03:24:34 pm

Free DG4062, DG4102, DG4162, DG4202 and a serial# of your choice ...

http://pastebin.com/ipkJCxPM (http://pastebin.com/ipkJCxPM)


This link is not working anymore. Does anybody has the file or new link?
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on July 03, 2015, 10:59:03 pm

Free DG4062, DG4102, DG4162, DG4202 and a serial# of your choice ...

http://pastebin.com/ipkJCxPM (http://pastebin.com/ipkJCxPM)


This link is not working anymore. Does anybody has the file or new link?
Neki:  If you have DG4000 Firmware version 1.09 or higher this won't help you, because the DG4000 will no longer accept the upper frequency extension modification file.  If your Firmware is prior to 1.09,  then perhaps someone here has the application and can help you.  Sorry, I do not have it.
Title: Re: DG4000 - a firmware investigation
Post by: scalargr on July 09, 2015, 10:53:07 am
Hi to all.
Can somebody tell me why it doesnt work on my serial (DG4B141xxxxxx) with FW 00.01.03 ???
Teneyes (thanks again for sending me the cen. files) helped me about that. I tried some different usb sticks, but It's hopeless. :palm:
I get ...<invalid license file> / <Excessive number of errors. Please restart>. |O |O |O

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.

Could some one help me?
Title: Re: DG4000 - a firmware investigation
Post by: Michael@de on July 16, 2015, 06:16:18 pm
Hi folks!

Just bought a used DG4062 and want to upgrade it at 160 MHz .

SN      DG4D....
SW    1.04
FPGA 1.07
HV     1.03
KV     4.01

Could you pls provide a (new) link for the upgrade files?

Michael
Title: Re: DG4000 - a firmware investigation
Post by: TheContractor on September 01, 2015, 02:41:41 pm
Since I purchased my DG4062 after this hack was discovered, mine has the updated bootloader. I was wondering if there's a way to fool it into thinking an older version of firmware is actually a newer version by modifying the version in the byte code. To do this we would need to accomplish two things:


Reverse engineering is not my strong suit but I'm going to dig into this, if anyone has some insight relevant to this please share!
Title: Re: DG4000 - a firmware investigation
Post by: Mahoo on September 12, 2015, 03:00:28 pm
Rigol has released the official dg4202 model 200hz function generator.
http://www.rigol.com/prodserv/127/ (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.
Title: Re: DG4000 - a firmware investigation
Post by: Gunb 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!
Title: Re: DG4000 - a firmware investigation
Post by: rramirez 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
Title: Re: DG4000 - a firmware investigation
Post by: devpeeps 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
Title: Re: DG4000 - a firmware investigation
Post by: m1ke 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 (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
Title: Re: DG4000 - a firmware investigation
Post by: dr.diesel 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.
Title: Re: DG4000 - a firmware investigation
Post by: Sparky 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 '<'

Title: Re: DG4000 - a firmware investigation
Post by: malekia 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
Title: Re: DG4000 - a firmware investigation
Post by: TurboTom 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
Title: Re: DG4000 - a firmware investigation
Post by: Altemir 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?
Title: Re: DG4000 - a firmware investigation
Post by: H.O 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.
Title: Re: DG4000 - a firmware investigation
Post by: Altemir on July 14, 2016, 08:20:07 am
Thanks. I have used 8 USB flash drives. I'll keep looking :(
Title: Re: DG4000 - a firmware investigation
Post by: megafix on August 09, 2016, 01:05:00 pm
Hope this helps! Piranha(DSP)Update_00.01.09.zip (http://wikisend.com/download/411438/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.

Title: Re: DG4000 - a firmware investigation
Post by: ted572 on August 09, 2016, 02:35:24 pm
Hello megafix:

FW ver. .09 and .10 both had the boot loader supplied with them.  I don't know that there was a version .11 (?).

If you don't have the 160 MHz option installed you should install it first with FW ver. .08.  But, DO NOT install the mod. for 200 MHz.  If the 200 MHz mod. is installed now, get it out before proceeding!

    Cheers, Ted

Edit: Added 'Hello megafix'
Title: Re: DG4000 - a firmware investigation
Post by: megafix 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?


Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr 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.
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge 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 (http://s.go.ro/blmbni71)
Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr 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?
Title: Re: DG4000 - a firmware investigation
Post by: Andrusca 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
   
 
Title: Re: DG4000 - a firmware investigation
Post by: nrxnrx 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 (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.
Title: Re: DG4000 - a firmware investigation
Post by: Andrusca 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
Title: Re: DG4000 - a firmware investigation
Post by: tkarlmann 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/ (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!
Title: Re: DG4000 - a firmware investigation
Post by: thlee 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?
Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr 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?
Title: Re: DG4000 - a firmware investigation
Post by: TurboTom 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 (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
Title: Re: DG4000 - a firmware investigation
Post by: TurboTom 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
Title: Re: DG4000 - a firmware investigation
Post by: Netsniper on August 06, 2018, 03:42:18 pm
Hello everybody !

First, I'm sorry for my english... I'm French and the school is so far...

I have two DG4062 (#3 is not mine) and I have working to obtain the last firmware (01.14) AND 200Mhz version.

By luck, I had three DG4000 to play with:

#1 DG4062 with "Keyboard version" (Bootloader) 06.01 and FW00.01.12 ("upgraded" in DG4102 model before upgrade FW00.01.12/Bootloarder 06.01)
#2 DG4062 with "Keyboard version" (Bootloader) 05.01 and FW00.01.06 (leave in DG4062 model)
#3 DG4062 (My father one) with "Keyboard version" (Bootloader) 06.02 and FW00.01.13

I will now explain how I have proceed...

First, I have unsolder the flash memory chipset S29GL128P90TFIR1 from the #1

- I have read the flash with a RT809H
- Write a blank flash chip with the content (I know, no modification at this state  :D)
I have use a S29GL128P11TFI020 (R&S dont have the exact ref. but the speed is not very important, just the time to transfer the content at each startup of the DG to RAMs module. (Difference is not perceptible)
- I have solder a TSOP56 socket in the DG at the flash place.
- Put the newly write flash in the socket, power ON and the DG work as before...no progress but desolder/cleaning/read/write process was valid !

I have start with #1 becaus I was aware about the process and if I make a mistake, I prefer to kill the flash with the bootloader 06.01 and make my second try to the #2 with knowledge of my eventual mistake...

After that, same thing with the #2 with success... Ouf... the big deal was over...


At this state, I had two DG4000 with socket in place of the flash and two .BIN. I can write flash with this .BIN and put inside each one.

When I put the #1 flash in #2, #2 work as #1, same serial, same version at all (Device model, serial, Soft. Vers., FPGA Vers. and Keyboard Version)

*For information, the Hardware Version is not in the flash (normal) it's hard Coded, 5 Zero Ohm resistor are inside and the version is binary coded: For Hard ver. 1.3 resistor are 01.011 (It' near the buzzer)

Ok... I know what you think... "He write the #1 Flash with the #2 .BIN and he can use the licence key file to have DG4202 because he don't have the 06.01 bootloader limit..."

Yes, I can...but it's not sufficient. I don't want to have two DG4202 with old firmware...
For memory, the Goal was two DG4202 with latest firmware (01.14 at this time)

But with socket and the hability to write directly the flash with the content I want, I can make lot of test.
If I brick the DG... just unpluged the flash, program it again with a working content and then test again...
I can make tests without stress...and it's that I did.

Rest of process :

- I have write the #2 flash content (FW 00.01.08 Keyboard Ver. 05.01) to a new flash and plug it inside one DG4000
- Create licence file with Cybernet method. Model DG4062 --> DG4202 without change the serial
- Upgrade Bootloader to 06.01 (Rigol process)
- Upgrade to FW 00.01.12 (DG4202 model is preserved)
- Upgrade to FW 00.01.14 (DG4202 model is preserved)

I don't know why the DG4202 model is preserved when I come from FW 00.01.08 Bootloader 05.01 --> FW 00.01.12 and 00.01.14 Bootloader 06.01...


The case of the #3 : I have unsolder the flash but the socket soldering was a failure...
Finally, I have read the flash content to have the .BIN and I have solder directly a new flash with alreday DG4202 model FW V00.01.12 Bootloader 06.01 and after I have upgrade to FW 00.01.14 (keeping model DG4202 as for #1 and #2)

But the difference for the #3 is the Keyboard Version... When I have start to work with this DG4062, the Keyboard Version was 06.02
For memory, when I put a flash (.BIN) coming from #1 or #2 to #1 or #2 all version except Hardware ver. follow (Device model, serial, Soft. Vers., FPGA Vers. and Keyboard Version)
When I put a flash with an older version of the Keyboard, the Keyboard version is downgraded.


For the #3, the Keyboard Version DON'T change, all the rest change (Device model, serial, Soft. Vers., FPGA Vers.)
My conclusion, in the #3, the Keyboard version is elsewhere... (I have search at the keyboard PCB in #1 and #2 and the LATTICE chipset LCMX0256C don't inform me, no ROM in this version but...)
I don't understand this point.

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
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on August 06, 2018, 06:14:25 pm
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

Hello Netsniper!  Your English is great!  No need to worry about that :)  Great job with the work you have done to revise this project and examine more firmware differences :-+

For firmwares, you are missing a few.  I have posted them all here (https://www.dropbox.com/sh/x08qw2px9czn9c2/AADogjnY6hRI17pB_tGDC1jUa?dl=0), and various versions of "upgrade" instructions I have come across.  I will leave the files here for few days :)

That is interesting puzzle with the keyboard version.  I have an early DG4062 unit and the keyboard has given me troubles in the past...at times it seemed unresponsive and I needed to really push the buttons hard/firm.  If I don't the keypress will not be detected.  I have used a later manufactured one (same model) and it does not have the issue --- keyboard is very responsible and feels "normal".

So, I wonder if there is a real keyboard hardware change...if so it might help explain some difference you are observing...but does not indicate where the keyboard version is stored or wired.

Good luck with the extra firmware versions -- hope it will help you!
Title: Re: DG4000 - a firmware investigation
Post by: bgm370 on October 12, 2018, 08:38:37 pm
I can confirm that installing 1.12/1.14 on an "upgraded" DG4062 running 1.08 preserves the 200Mhz "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.
Title: Re: DG4000 - a firmware investigation
Post by: TheNewLab on October 26, 2018, 06:10:40 am
I have just acquired a DG4062 with the plan of updating it here. I have downloaded everything I can find, and made notes form this thread and others.

Simple question, which I may already know.When compiling on Linux I use the makefile, command from the terminal, there is no application to do this, is there?
Title: Re: DG4000 - a firmware investigation
Post by: gts1991 on December 14, 2018, 07:34:00 pm
Can you release DG4062 versions?
Without opening the housing

Thank you
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on January 26, 2019, 02:19:39 am
I can confirm that installing 1.12/1.14 on an "upgraded" DG4062 running 1.08 preserves the 200Mhz "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.
Is it possible to upgrade directly from firmware v1.08 to v1.14 without a Bootloader upgrade?
If "no", then what version of the Bootloader is needed before upgrading to firmware v1.14 and where to get the Bootloader from ?
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on January 27, 2019, 10:19:35 am
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 ?

P.S.
Thank you for the link to the v1.14 firmware
Title: Re: DG4000 - a firmware investigation
Post by: Vahoo on January 28, 2019, 02:32:40 pm
Hi dear GonzoTheGreat, send  please link  v1.14, thanks! vahagnhak@yahoo.com
Title: Re: DG4000 - a firmware investigation
Post by: Netsniper on January 28, 2019, 03:23:22 pm
Please find the link to the 1.14 FW : https://we.tl/t-68FtwLMVMK
Title: Re: DG4000 - a firmware investigation
Post by: Vahoo on January 28, 2019, 08:00:52 pm
thanks for firmware, also tell please ,

in what chip the serial number of the generator is?

thanks!
Title: Re: DG4000 - a firmware investigation
Post by: TooOldForThis on February 01, 2019, 03:15:25 am
Many years ago my ersatz DG4202 went back to being a boring old DG4062 after I installed FW 1.09.   And it was a boring old DG4062 ever sense.  But tonight I updated it from FW 1.12 to 1.14 and it's suddenly back to being a DG4202.   The extra 140MHz were lying dormant in there all along.   I didn't do anything other than load 1.14.
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on February 01, 2019, 09:48:00 am
It was never clear to me:
1. Is the old calibration (up to 60MHz) preserved after extending the range?
2. Does it require a new calibration for frequencies higher than 60MHz?
Title: Re: DG4000 - a firmware investigation
Post by: kado on February 01, 2019, 11:12:47 am
Hi @ all

can someone please send me FW 1.12 Version via PM or Downloadserver ?
I stuck on FW 1.08 (dont want to lost the 200 Mhz). If i want to go to FW 1.4 i need first go via FW 1.12 is that right?

Thanks to all contributors

Karsten
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on February 01, 2019, 11:56:59 am
I have these (including FW1.12):  http://s.go.ro/blmbni71 (http://s.go.ro/blmbni71)

A couple of questions, please:
1. Is the old calibration (0...60MHz) preserved after extending the range to 200MHz?
2. Does it require a new calibration for frequencies higher than 60MHz?
Title: Re: DG4000 - a firmware investigation
Post by: kado on February 01, 2019, 03:18:08 pm
Thanks to PeDre and RoGeorge for the FW Links !

Karsten
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on February 01, 2019, 05:46:17 pm
You're welcomed.

What about the calibration?
Does anybody have any info about the calibration under, and over 60 MHz, please?
Title: Re: DG4000 - a firmware investigation
Post by: Sparky on February 01, 2019, 06:44:42 pm
What about the calibration?
Does anybody have any info about the calibration under, and over 60 MHz, please?

Have a read at post #149 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg342046/#msg342046) and subsequent posts by ted.  I think you'll find the information you need.
Title: Re: DG4000 - a firmware investigation
Post by: TooOldForThis on February 02, 2019, 12:30:44 am
I just ran a quick test of my DG4062 that still has the original factory cal.   It's flat from 1 to 160Mhz and then gradually loses 2dBm over the last 40MHz. I'm sure if I fiddle with the calibration menus for a while I can make it much, much worse.
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on February 13, 2019, 01:02:33 pm
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 ?
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on February 13, 2019, 04:23:01 pm
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.

2. It doesn't extract the files because I haven't had no need for it.
 But, with the information that I show in the parsing you could do that easily with any hex editor.

3. See previous answer.

4. The ones that have executable code can be looked at in IDA.

5. I can have a look that. But, isn't there any PCB photos that let you identify the ICs involved?
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on February 13, 2019, 05:07:20 pm
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
I already figured out the the checksum for each segment is the CRC16 with Poly==0x8408 and Init==0xFFFF.

Do the GEL files for the DG4000 have an encrypted footer like the GEL files for DS1000Z ?


4. The ones that have executable code can be looked at in IDA.
Isn't the code obfuscated?
Anyway, without ubiquitous executable headers (like ELF, PE, etc...), IDA might have a problem recognizing the code.

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.
Even if there were photos detailed enough to read the markings on the chips, I would expect them to be house numbers.

I have the time and burning desire to patch some bugs and strings in the CPU's code.
FPGA code is beyond my abilities, but the function calls to it are not.

Title: Re: DG4000 - a firmware investigation
Post by: smithnerd on February 13, 2019, 05:25:15 pm

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.
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on February 13, 2019, 05:37:57 pm
For FPGA/DSP/DAC, a nice teardown with lots of info about the inside of DG4000, by mikeselectricstuff

https://www.youtube.com/watch?v=jGXiS4X4Hlw (https://www.youtube.com/watch?v=jGXiS4X4Hlw)

https://www.eevblog.com/forum/testgear/rigol-dg4062-functionarbitary-waveform-generator-teardown/ (https://www.eevblog.com/forum/testgear/rigol-dg4062-functionarbitary-waveform-generator-teardown/)
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on February 13, 2019, 05:54:24 pm
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 :(
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on February 13, 2019, 06:04:56 pm
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.

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.
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on February 13, 2019, 06:20:05 pm
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.
I would like to analyze the code that controls the Burst Mode parameters.  See this bug report (https://www.eevblog.com/forum/testgear/rigol-dg4xxx-signal-generator-burst-mode-bug/msg608764/#msg608764).
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on February 13, 2019, 07:13:54 pm
If you want to reverse engineer the DG4000 in order to "fix bugs" for yourself, that will be highly unlikely, especially that what it is described there as bugs are, in fact, in spec DC offset, or expected behavior from a DDS type of generator.

A DDS is different from an analog generator, it first lay down a waveform in memory, then it samples that waveform.  Waveform frequency is achieved by sampling memory at different increments of addresses, so it can get into apparently weird behavior when slowly changing the frequency of a given waveform, especially for square waves or pulses.

I admit I didn't read the bugs topic very carefully, but they all looked to be expected behavior coming from a DDS architecture.
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on February 13, 2019, 07:29:25 pm
...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.

They are very similar. You can try one of the methods of the plugin. Of course, you must use IDA <7 or adapt the plugin to the v7.

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!
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on February 13, 2019, 07:42:12 pm
I've checked my code. You have the CRC16 parameters wrong.
I was not wrong
Due to the way in which I process the CRC, the bits of the polynomial  are stored in reverse order. This makes the polynomial 0x8408 in my code.

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?
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on November 16, 2019, 09:24:16 am
The attached image is inside the official DG4000Update.GEL .  (I think colors are now correct: 800x480 Format16bppRgb565 )

Can anyone explain me when does it appear in the DG?
Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr on November 16, 2019, 09:30:42 am
Wow, cool picture!  It must be associated with some sort of Easter egg.
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on November 16, 2019, 09:59:09 am
A reversed image search shows that pic listed as wallpaper hosted on many Russian and Chinese websites.   :)
Title: Re: DG4000 - a firmware investigation
Post by: TurboTom on December 04, 2019, 04:54:29 pm
Would the v1.08 F/W possibly re-open the door to the old BW hacking approach with the Cengen tool by @Cybernet? Skimming over the old posts didn't make it completely clear to me if the Cengen Hack was only possible up to F/V 1.06 or if it worked up to 1.08 (which all required bootloader 4.01 / 5.01).  I would actually give it a try on my machine, no risk, no fun, you know...  ;)

P.S. All for the sake of science, of course  :P
Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr on December 06, 2019, 01:21:37 pm
Given how similar the DG4000 UI is to the DG1022Z, I wonder if the 'magic' USB drive with SCPI upgrade approach would work?
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on December 07, 2019, 09:21:52 am
Given how similar the DG4000 UI is to the DG1022Z, I wonder if the 'magic' USB drive with SCPI upgrade approach would work?

In this regard, they are different. Work in progress...
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on December 11, 2019, 09:48:48 pm
I 've finally reversed the new format (since v1.09) of .GEL files for the DG4000.  (This has never been done before and gives hope to those who can't downgrade their FW due to the bootloader v06.xx...)

As a teaser, I show here the parsing of the v00.01.14.00.01 GEL:

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

In the coming days I'll do some tests to (re)create some "custom" GELs. Let's see where this will end...   ;)
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 11, 2019, 10:28:57 pm
Hello tv84:  Re. your previous Post 'Reply #374'.
Where did you find FW  00.01.14.00.01 (GEL File) for the DS40000?  Could you please give us a link for it, because I have not seen it being available anywhere (just 00.01.12.00).  Thank you in advance, and I'm sure other users will also be very interested.    With appreciation, Ted572
PS  I did notice that Rigol installed 00.01.14.00.01 in EEVblog'er swperkhad's unit that he was having a issue with installing FW 00,01.12.00.  I offered to send him a USB drive that would have worked, although he chose to return his unit to Rigol, and is happy now. Congratulations to him.  And it was very nice of of you to assist him as you did.  We are all grateful for what you have done for the EEVblog community.  Thank you!

Edit:   This turned out to be a false alarm on my part, because when I went to the Rigol NA Web Site to see if there was a newer firmware file and only found version 00.01.12.00. Therefore I incorrectly thought that I must need 00.01.14.00.01 to be current. So I asked here for help locating a source of it.  Although when I checked my unit's firmware later I found that I had actually updated it early in 2018 to 00.01.14.00.01.  TurboTom was right on below saving - It's really a shame that Rigol isn't keeping all their web sites' (international ones and also distributor's) download sections consistent.
Title: Re: DG4000 - a firmware investigation
Post by: TurboTom on December 11, 2019, 10:45:31 pm
F/W 01.14 was available for download from Rigol's chinese firmware archive -- before they "updated" their web site. Now, unfortunately a log-in is required to acces the files but with an on-line translator and a lot of patience, it's still possible to access the files, even for individuals not capable of reading mandarin (though I'm not sure if really everything's still available that was before).

It's really a shame that Rigol isn't keeping all their web sites' (international ones and also distributor's) download sections consistent, so regardless where their customers are located and whatever language they speak, they have access to the same soft- and firmware pool.

The way they handle this situation currently is really everything but professional.  :--
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on December 11, 2019, 11:54:00 pm
Where did you find FW  00.01.14.00.01 (GEL File) for the DS4000...

Rename it from .tar to .rar before unpacking.  Version v00.01.14.00.01 2017-12-23 downloaded from rigol.com in 2018.

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

Why do you need it?
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on December 14, 2019, 04:09:41 pm
Hi all,

A few years ago, when Rigol introduced DG4000 FW v1.09 supported on bootloader v06.xx some of the guys (that had experimented the 200MHz BW) lost their BW settings, downgrading to 60 MHz BW.

For those ones that lost their official 100MHz/160MHz BWs, please find attached a handcrafted FW v1.08 GEL file that can be flashed with bootloaders v06.xx.

And, to finish up what member cybernet (kudos to him) started a few years ago, I attach here an  "updated and cleaned" compiled version of his famous license generator "cengen", for Windows machines. I called it v0.2 because it has some corrections/optimizations.

For those interested, I think you know what steps you need to do next.  :popcorn:

PS: As always, flashing involves a certain risk. So, although this has already been tested by a knowledgeable forum member, it's your responsibility.
Title: Re: DG4000 - a firmware investigation
Post by: TurboTom on December 14, 2019, 06:37:12 pm
My DG4102 from Q4/2015 that was supplied with F/W 1.09 (and somehow lost its 200MHz capabilities... 8)) didn't even require a recalibration (obviously) -- a sweep of +3dBm level from 1MHz to 200MHz is accurate within +-0.5dB despite an 80cm RG178 DIY interconnection cable.

A big thanks to @tv84  :-+
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on December 14, 2019, 07:35:04 pm
Perfect! I was just too late buying the DG4062 and got 1.09 with it, so the license file trick didn't work. I studied cybernet's work but this processor just gives me headaches  :-//
Anyway, liberated after all  :-+ So can we now safely update to 1.13/1.14?
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on December 14, 2019, 07:57:18 pm
Anyway, liberated after all  :-+ So can we now safely update to 1.13/1.14?

Yes, after correcting what needs to be corrected you can go directly to v1.14
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on December 14, 2019, 11:03:27 pm
tv84, 1 000 000 THANK YOU!!!

https://www.youtube.com/watch?v=Qw2kDH2HWhI (https://www.youtube.com/watch?v=Qw2kDH2HWhI)

My DG4102 has had from factory a FW version bigger than 1.08, so until today it could never use 'license.CEN' files generate by 'cengen' tool.  The message was Unknown format file.

Now, using your modified firmware to downgrade to FW1.08, then generate a license file to turn DG4102 into DG4202 using your cengen.exe, then upgrade to the latest FW1.14.01 from Rigol, it worked!  :-+

Former DG4102 (max. 100MHz) is now upgraded to a DG4202 (max. 200MHz)!  :scared:

Code: [Select]
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
--------------------------
Title: Re: DG4000 - a firmware investigation
Post by: ted572 on December 14, 2019, 11:13:35 pm
Wow !   I also have 200 MHz.  Thank you tv84.
Title: Re: DG4000 - a firmware investigation
Post by: zitt on December 17, 2019, 12:11:00 am
I bought a DG4062 base model as a Black Friday deal from their clearance/demo section.
It came with v1.12 if I recall.
So tv84's hacked firmware would allow me to reverse flash to a earlier version ... hack the firmware, and then upgrade back to v1.14?

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).
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on December 17, 2019, 09:58:21 am
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.
Title: Re: DG4000 - a firmware investigation
Post by: zitt on December 17, 2019, 11:57:52 pm
Without opening it, no.

Are you aware of any procedure / walk thru on how to do this?
I'm thinking maybe I'll do this when the warranty expires in a couple of months.
I feel like I may have seem some references earlier in the thread; but not 100% sure.

Am I being overly paranoid?
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on December 18, 2019, 07:20:35 am
Yes, you are.  :)

Just load the modified by tv84 firmware 1.08, then load the license file for 200 MHz, then load the latest 1.14.00.01 firmware from Rigol.  To generate the license.CEN file I used the tv84 cengen.exe in a virtual Windows XP machine (because I have Linux).  Ask about any details if in doubt.

Nothing to backup, and nothing bad will happen anyway.  Even if you manage to brick your DG4000, you can still claim the warranty, and even if they'll refused to service it, people here could still guide to un-brick it yourself.

Good luck with the 200 MHz upgrade.
Title: Re: DG4000 - a firmware investigation
Post by: Teneyes on December 19, 2019, 05:39:39 pm
Thanks for the message and great  work.
I,ll  will give it a try after Xmas
Wish you a great holiday and New Year.

Title: Re: DG4000 - a firmware investigation
Post by: zitt on December 19, 2019, 11:57:22 pm
Yes, you are.  :)

Agreed. I took the callenge last night. Couple of issues I had:
1) Tried a 32GB stick. Wouldn't work. Utility button never began flashing. Using an old 1GB stick I had work perfectly.
2) Couldn't figure out how to "read" the license file. I had assumed I needed to find the license entry screen. I later learned all I had to do was "read" the license.cen file from the utitlity menu.
3) V1.14 upgrade was dirt simple using the same process as the back flash.

Now my only goal is to figure out how to calibrate for above 60MHz. Looking over the document; I lack a "calibrated" DVM and Frequency Counter. I'm actually disappointed I can't use my 1GHz OSCOPE. :( Didn't read thru the whole document.
Title: Re: DG4000 - a firmware investigation
Post by: TurboTom on December 20, 2019, 12:50:05 am
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.
Title: Re: DG4000 - a firmware investigation
Post by: thlee on December 21, 2019, 09:32:33 am
Hi tv48, thank you for your information, I have upgraded my DG4062 to DG4202. It is  great work  :-+.
Title: Re: DG4000 - a firmware investigation
Post by: Vahoo on December 28, 2019, 06:32:45 pm
Hi dear tv84. i have DG4062, I want to change the firmware for DG4202, but I can’t,
after update license.gen, the name does not change in the generator.
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on December 28, 2019, 08:17:51 pm
When you generated the license.GEN, what command line did you use on the PC?
Title: Re: DG4000 - a firmware investigation
Post by: mahi on December 29, 2019, 01:31:04 pm
Thank you tv84! Another DG4062 upgraded to 200 MHz :)
Title: Re: DG4000 - a firmware investigation
Post by: Vahoo on December 29, 2019, 04:40:03 pm
Hi dear RoGeorge!

My PC software is winXP, command line is MS-dos, run CMD ..., c:\>cengen.exe

I correctly do?
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on December 29, 2019, 04:59:55 pm
No.  It should be

Code: [Select]
cengen.exe DG4062 DG4202 DG4Exxxxxxxxxx

where you replace 'DG4Exxxxxxxxxx' with the the serial of your generator, the one deleted with red in the attached photo above.  Then, copy on the pen drive the generated license.CEN (check the date and time to see it's the one just created) and read the file with the DG4000 generator.
Title: Re: DG4000 - a firmware investigation
Post by: Vahoo on December 29, 2019, 05:18:49 pm
I and do, I should change the regional languagе?
Title: Re: DG4000 - a firmware investigation
Post by: Vahoo on December 29, 2019, 05:49:54 pm
Dear RoGeorge ,  "read the file with the DG4000 generator" or update generator? (press HELP and torn ON generator,
to insert USB storage ... ) , thanks!
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on December 29, 2019, 06:00:04 pm
No.  Open DG4000 normally.  Do not press Help.  Insert USB with file license.CEN into DG4000.  Read file "license.CEN" (upgrade generator).  Get DG4202.

If you see DG4202, finally upgrade firmware to 1.14.
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on December 29, 2019, 06:12:38 pm
Read file "license.CEN" (upgrade generator).

To clarify "Read file":

 - Press the Store button
 - If the USB drive was recognized you will see C: and D: under Disk
 - Turn the Knob to select D:
 - Press the "File Type" soft button
 - Press the "All File" soft button
 - Press the "Browser" soft button
 - Turn the Knob to select the licence file (only necessary if there are more files on the USB drive)
 - Press the "Read" soft button
 - Enjoy

Title: Re: DG4000 - a firmware investigation
Post by: Vahoo on December 29, 2019, 06:13:22 pm
Thank you very much, I got everything.  :-+  :-+  :-+
Title: Re: DG4000 - a firmware investigation
Post by: zitt on January 01, 2020, 01:22:48 am
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.

No. I haven't done anything more than view the output with my Scope.
IIRC; mine had some signal attenuation above the 60MHz limit; but, I haven't done anything specific to verify. Again; quick check using aglent scope.

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.

I do have a Spectrum Analyzer (CMU200); but was a fleabay purchase so it's calibration isn't assured. The document I have:
"CalibrationProcedure.pdf"
doesn't appear to discuss calibration or measurement by Spectrum Analyzer.

Do you have a link to this "bodge" schematic and/or wiki?
Title: Re: DG4000 - a firmware investigation
Post by: EV on January 01, 2020, 05:41:15 pm
I read this license.gen to my DG4162. It looks to work as earlier but the signal is about 1.4 dBm low at 200 MHz. Between 1 - 160 MHz signal is ok.

Is it possible to correct this by calibration?
Title: Re: DG4000 - a firmware investigation
Post by: stuartmp on February 13, 2020, 01:12:07 am
Hi All,

I would like to update my Bootloader & Firmware, Attached is my current system
information for my DG4062.

I managed to find the necessary files to update it as the
current version is 00.01.07 and it says online that I need minimum
00.01.08 to run the current file but I can't find the instructions to Flash the bootloader or Firmware.

I'm not interested in Hacking my machine I just want to up date it to the latest version.

Could someone please send through some instruction on how to  Flash the bootloader and Firmware.

I have also attached an image of my current system information.


Kind Regards

Stuart
Title: Re: DG4000 - a firmware investigation
Post by: stuartmp on February 13, 2020, 07:26:06 am
Here is my firmware collection. The instructions for updating are included.
Code: [Select]
http://peter.dreisiebner.at/tmp/rigol_dg4000_firmware.7z
Peter

Thanks Peter, Just what I was looking for
Title: Re: DG4000 - a firmware investigation
Post by: stuartmp on February 13, 2020, 09:40:57 am
Hi Peter,

Thanks again for the files.
I have formatted a 2GB usb stick Fat32 and copied the 00.01.08.00.02 update file (DG4000Update.GEL) into the root directory

I have followed the instructions as per the attached pdf but it stops at point 8.
Am I using the correct file or is there a problem with my usb stick?

The utility light does flash a few times but then stops and none of the waveform lights start to flash.
What is my current firmware version it looks like 00.01.07 as per the attached image. Is that correct?
What is FPGA?


Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr on February 13, 2020, 09:43:43 am
I recall that you have to wait quite a while before the new firmware is applied, I was making the mistake of assuming it wasn't working.
Title: Re: DG4000 - a firmware investigation
Post by: stuartmp on February 13, 2020, 10:03:23 am
I waited 7 minutes and not one of the waveform lights had come on.
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on February 13, 2020, 10:15:27 am
I waited 7 minutes and not one of the waveform lights had come on.

Make sure the .GEL file you have in the pen has CRC32: D36150FB

I don't know if most of the LEDs blinking is more intensive in the post-v08 era...

Try formatting the USB disk again and/or use another.
Title: Re: DG4000 - a firmware investigation
Post by: scalargr on March 30, 2020, 07:47:26 pm
Hello folks. I think the upd file is corrupted (00.08.).I downloaded too, and no respond.  You need a clean update, ask some one here on the forum, someone have it, if you need it. I have a soft ver. 00.01.06 thats worked for me.

Important note is the handling of the boot procedures in some  DGs, IT matters how you power up your fg to read the stick!!!
Some tell to <let fg work normal, put usb stick in, let him recognize it, power down, press HELP button and power up,If went ok, you see the ramp button
flashing and after a while its stops and stay lit, and the flash go to other buttons (Waveform) and make the same procedure , and stop at USER button in the same way.>     Thats the normal way. (sandisk cruser mikcro 2.0 gb formated full FAT32).It worked for me.

Next step:Download cengen.exe, put it on root directory (c:\cengen.exe) and let it there.
 Open cmd.exe and type in c:\cengen.exe XXXXXX XXXXXX serial number  and press enter. (Modify it accordingly)
You get a message: SUCCSESS: licence file saved to:licence.CEN, Next, make a search on your computer, you find it as the nearest in time or date,
that's your file.
 Next step, make a copy of it and put it in a folder marking it as valid licence.CEN file. Copy it to your USB stick as licence.CEN.
Put it on your DG in and let it recognize it, Press Store button and select it at D, press Read, and it's popping up a message: invalid licence file.Too many errors.
Press again Store button and you got:Valid licence file or so. Go then to Utility to validate/verify the changes. 8) 8) 8)

Hope it helps ...Thank's to the forum!!! :)

Title: Re: DG4000 - a firmware investigation
Post by: bartver on April 15, 2020, 05:56:42 pm
tnx... got mine with 1.09 and had to wait for it..
Thank you TV84 !!
Bart
Title: Re: DG4000 - a firmware investigation
Post by: sbvr4 on April 26, 2020, 09:16:02 pm
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
Title: Re: DG4000 - a firmware investigation
Post by: TurboTom on April 26, 2020, 10:57:27 pm
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

As per the calibration manual (see attachment) it should be "2010". Not sure if that's still valid for the current F/W Rev.
Title: Re: DG4000 - a firmware investigation
Post by: sbvr4 on April 27, 2020, 12:46:23 pm
@TurboTom
Thank you sir. Ugh. :palm: It was right in front of my face. I looked further back in the cal manual and didn't any specific reference other than referencing the "Secure Code." I assumed it wasn't public at that point. 

Thanks again
Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr on June 10, 2020, 06:07:21 pm
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...

Device Model: DG4202
Serial Number: DG4Exxxxxxxxxx
Software Vn: 00.01.07
FPGA Vn: 00.01.08
Hard Vn: 01.03
KeyBrd Vn: 05.01

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. 

I thought I'd try to downgrade from DG4202 to DG4162 and then apply a software version upgrade. I was able to run the cengen code in the MinGW environment (I couldn't figure out the online generator) and generate a new .GEL file but when I tried to apply that .GEL file to my DG4000, it seemed to make no difference and still reported the above data including DG4202.

Today I bricked it  :-BROKE here's what I did...
- Applied the Rigol bootloader update, it took maybe a minute and rebooted to the standard screen but I did not check system info that it was actually at bootloadler vn06.
- Tried to load official vn 1.12, it didn't take (no LEDs lit under Waveform section) and now it won't boot at all - I get a blank screen
- Tried to reload the 06 bootloader but I'm told that may have been a mistake
- Tried to load the 08 firmware (in case the bootloader was still at 05), nothing

Just to check, when I power up, as soon as the lights flash I press [Help] and then insert the USB drive, the [Utility] LED flashes and so does the USB access LED (on the drive itself) - then it just sits there with [Mod],[Utility], and [Store] LEDs lit.  Am I doing something wrong? I have tried 2 different USB drives and I'm almost certain they are good with the Rigols.

Any ideas?
[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...

Device Model: DG4202
Serial Number: DG4Exxxxxxxxxx
Software Vn: 00.01.12
FPGA Vn: 00.01.11
Hard Vn: 01.03
KeyBrd Vn: 06.01

Bold stuff is what's changed.
Title: Re: DG4000 - a firmware investigation
Post by: PA0PBZ on June 10, 2020, 06:49:32 pm
[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?
Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr on June 10, 2020, 07:22:18 pm
[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?
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.

I'm on version 1.12 which was the highest offered to by by Rigol's website, is 13 or 14 better?

Has anyone here done an automated calibration app for the DG4000?
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on June 10, 2020, 07:42:44 pm
 :clap:

Now update to v1.14 (attached).

Code: [Select]
[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.
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on June 10, 2020, 09:04:58 pm
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. 

Mine was a DG4102, now upgraded to DG4202.  I've used the frequency counter before and after the upgrade, and it worked.  The only thing is on speed "Normal" might miss some counts and ruin the statistics (looks like it would be imprecise).  If this happens, change the statistics speed from Normal to Full.
Counter -> Down Arrow -> Statist Set -> Speed Full

Also, not all the displayed digits are measured, some are fake/computed.  The resolution is of only 7 digits/s, if there are more, those are not measured, the extra resolution is the results of arithmetic calculations.
Title: Re: DG4000 - a firmware investigation
Post by: Gandalf_Sr on June 12, 2020, 04:42:10 pm
Now update to v1.14 (attached).
Thanks, now I see...

Device Model: DG4202
Serial Number: DG4Exxxxxxxxxx
Software Vn: 00.01.14
FPGA Vn: 00.01.11
Hard Vn: 01.03
KeyBrd Vn: 06.01

(Bold stuff has changed)

Used the same USB drive that worked before and all went smoothly.
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on August 04, 2020, 04:16:06 pm
[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!

I wonder what the problem is with the newer pendrives?
Is it the cluster size ?  If "yes" then creating a smaller partition on the pendrive would solve the problem, wouldn't it?

Must the partition be formatted as FAT32 or can it be also FAT16 ?
...and what are the acceptable Partition IDs in the partition table anyway ( 0x0b, 0x0c, 0x06, 0x0e, etc...) ?

Finally, must the filename be uppercase or lowercase and is any length acceptable?
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on August 04, 2020, 04:23:32 pm
FAT, FAT16 or FAT32 should work.

Format it with a linux machine.
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on August 04, 2020, 04:30:38 pm
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...
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on August 04, 2020, 04:38:16 pm
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...

:)

I can't go into such detail as I don't have any pen DG4000-approved.

You need to use a small pen and not worry with those inner works.

Format it fully in linux and then a quick FAT format. I've said time and time again: IMHO sometimes it might be a controller timing thing and not so much the formatting params.
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on August 04, 2020, 04:50:01 pm
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).
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on August 04, 2020, 05:13:09 pm
 :-DD  How do you get all that stuff in Antarctica??
Title: Re: DG4000 - a firmware investigation
Post by: PeDre on August 04, 2020, 05:46:01 pm
Could you post the partition table and Boot Sector/FS Information Sector so I can see what parameters work ?

Here is the information from my 1 GB USB stick I use for the DG4000. Determined with the program 'USB Drive Info' by Uwe Sieber.
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on August 04, 2020, 07:09:16 pm
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).

Try an USB SD card reader with any card inside.
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on August 04, 2020, 11:05:22 pm
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.
The DG4000 just hangs there with the MOD, UTILITY and STORE buttons lit up steadily (there was a brief burst of activity indicated by the pendrive's LED when I inserted it, though).
Title: Re: DG4000 - a firmware investigation
Post by: PeDre on August 05, 2020, 05:41:27 am
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.
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on August 05, 2020, 09:04:36 am
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.
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on August 05, 2020, 09:05:49 am
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.
Title: Re: DG4000 - a firmware investigation
Post by: PeDre on August 05, 2020, 09:06:28 am
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.

I have a Saleae Logic and just tested the new Alpha Software v2.3.4. The DG4000 uses USB Full-Speed. A test with plugging in the USB stick and recording worked. The export of the raw data as CSV works. In the program I can display the USB protocol.
I will try to record the data.
Title: Re: DG4000 - a firmware investigation
Post by: PeDre on August 05, 2020, 10:31:43 am
I have now used another USB stick with 2 GB for the update. The screenshot of the 010 editor is attached. So the update works when the stick is directly plugged in.

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?
The cable works without problems if the USB stick is used during normal operation of the DG4000.

With a USB power meter (Ruideng AT34 USB 3.0 tester) I measure 4.91 volts. The update also works with this adapter.
I will build a new short adapter, maybe it will work with it.
Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on August 05, 2020, 12:14:42 pm
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?
The cable works without problems if the USB stick is used during normal operation of the DG4000.
It could indicate intolerance of the boot-loader's code to propagation delays occurring in a longer cable.  How long was it?
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on August 05, 2020, 12:49:53 pm
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.

I've just found my logs with the steps to upgrade, same thread in page 16, see the "code" section.  My USB pen drive was formatted FAT32:
https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg2829452/#msg2829452 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg2829452/#msg2829452)
Title: Re: DG4000 - a firmware investigation
Post by: PeDre on August 05, 2020, 01:26:33 pm
It could indicate intolerance of the boot-loader's code to propagation delays occurring in a longer cable.  How long was it?

The cable is 1.3 m long.

But I cannot record any communication with the USB stick during the update at the moment. The USB stick is not accessed at all, only a short pulse appears on the data line D+. But the update is completely executed and takes about 7 minutes.
The new short adapter with 10 cm length works. During normal operation I can record the communication with the adapter.
At the moment I am standing before a mystery.

Edit: Maybe the update works via USB High-Speed? I'll check it with the oscilloscope.

Edit 2: The update is performed via USB High-Speed. I can't record this.

Title: Re: DG4000 - a firmware investigation
Post by: GonzoTheGreat on August 05, 2020, 04:04:01 pm
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.
Title: Re: DG4000 - a firmware investigation
Post by: PeDre on August 05, 2020, 04:52:01 pm
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.
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on August 05, 2020, 05:56:26 pm
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.

 :D That adds credit to my theory that this is a timing problem. The programming/interrupts doesn't know how to handle with certain controllers responses. It definitely seems that there is no flux control (delays, timeouts, etc) being maintained.

So, basically, it's a matter of luck.
Title: Re: DG4000 - a firmware investigation
Post by: noreply on August 06, 2020, 07:38:22 pm
Not sure if this is going to be at all helpful, but I thought I should chime-in with regard to USB stuff.

I use (had no problems so far with a number of instruments) a Sandisk Ultra microSDHC UGS-I 32GB card

I put this 'card' into a usb adaptor - and the device 'looks like' a USB drive to the instrument.

I can then change the microSDHC cards - each different card with associated firmware / files / hacks - in the adaptor for each different instrument.

The cards are kept in a little 'box' dedicated for the storage of these devices - and they are cheap to buy <$10 and convenient to store.

Hope the above info is helpful.

The bonus element in the above is that if you want to 'retire' the microSDHC card from your USB applications - you can simply put it into a camera / smartphone and simply format - now you have a totally new use.

Title: Re: DG4000 - a firmware investigation
Post by: PeDre on August 07, 2020, 07:00:20 am
I have tested different cards with my SD card adapter. All cards worked!
The adapter was bought at "Conrad", "Renkforce" is the house brand.

The cards were formatted in the adapter with the "SD Card Formatter 5.0.1" from www.sdcard.org (http://www.sdcard.org). Only the option "Quick format" was used.

The cards up to 1 GB were formatted with FAT16 and 16 kB cluster size.
The cards with 2 GB were formatted with FAT16 and 32 kB cluster size.
The cards with 16 and 32 GB were formatted with FAT32 and 32 kB cluster size.

Important!
During testing I noticed that you have to press the help button very fast, otherwise the update will not work. And the DG4000 gets stuck with the three illuminated buttons.
I could check this several times with working cards.

Edit:
Information about the SD-Card adapter:

Device ID: USB\VID_048D&PID_1336\00000000000006
Hardware IDs: USB\VID_048D&PID_1336&REV_0100 USB\VID_048D&PID_1336

Device Descriptor:
bcdUSB:  0x0200
bDeviceClass:  0x00
bDeviceSubClass:  0x00
bDeviceProtocol:  0x00
bMaxPacketSize0:  0x40 (64)
idVendor:  0x048D (Integrated Technology Express)
idProduct:  0x1336
bcdDevice:  0x0100
iManufacturer:  0x01
0x0409: "Generic   "
iProduct:  0x02
0x0409: "Mass Storage Device"
iSerialNumber:  0x03
0x0409: "00000000000006"
bNumConfigurations:  0x01
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on August 07, 2020, 07:29:19 am
Peter,

We have to take into account that your controller IC (which is in the reader) is always the same. So, in size/format investigation terms, is not totally clarifying.

During testing I noticed that you have to press the help button very fast, otherwise the update will not work.

This is one of the best conclusions from your test! We press a button to trigger an event. Why is it that the pressing speed is relevant to the triggering of the event?

In my opinion 2 reasons: bad programming in the trigger answering function or a problem with the event sequence timings of the processes triggered by the pressing.

Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on August 07, 2020, 07:49:09 am
I kept the 'Help' button continuously pressed, from the powered off state until 'Utility' starts to flash, like I wrote in my update log.

Code: [Select]
-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
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on August 07, 2020, 07:58:17 am
I kept the 'Help' button continuously pressed, from the powered off state until 'Utility' starts to flash, like I wrote in my update log.

Do you have consistent behavior with that technique?

I hadn't notice your procedure. Based on the trigger speed reported by Peter, I think your method is a good option to try to replicate.  :-+
Title: Re: DG4000 - a firmware investigation
Post by: PeDre on August 07, 2020, 08:06:54 am
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.

Edit:
System Info:
Device Model: DG4162
Serial Number: DG4D135100282
Software Version: 00.01.14.00.01
FPGA Version: 00.01.11.00
Hard Version: 01.01
Keyboard Version: 06.01
Enc FPGA Version: 05
Title: Re: DG4000 - a firmware investigation
Post by: tv84 on August 07, 2020, 08:53:45 am
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.

 :-DD    :palm:
Title: Re: DG4000 - a firmware investigation
Post by: RoGeorge on August 07, 2020, 09:32:35 am
Do you have consistent behavior with that technique?

That's how I did when you taught me how to upgrade from DG4102 to DG4202, or at least that's what I wrote down:
https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg2829452/#msg2829452 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg2829452/#msg2829452)
 :-//

The generator says now it's a DG4202, and it can generate sine signals up to 200 MHz.  Since then, I didn't make any other firmware upgrade.  I'll try to remember to test at the next upgrade, and write back here if that behavior still happens.

The USB pen drive was an ADATA model UV100/4GB, formatted FAT32.

Might be hardware version related, IDK, my DG4102 was bought in Oct 2015, from Batronix.