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

0 Members and 1 Guest are viewing this topic.

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
DG4000 - a firmware investigation
« 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.
« Last Edit: July 30, 2013, 09:39:12 pm by cybernet »
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #1 on: August 06, 2013, 07:14:56 pm »
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline synapsis

  • Regular Contributor
  • *
  • Posts: 140
  • Country: us
    • Blackcow
Re: DG4000 - a firmware investigation
« Reply #2 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.
 

Offline cybernetTopic starter

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

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #4 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 (date: 6/13/2012)

00.01.06.00.02 (date: 5/9/2013)

 

Offline Corporate666

  • Supporter
  • ****
  • Posts: 2008
  • Country: us
  • Remember, you are unique, just like everybody else
Re: DG4000 - a firmware investigation
« Reply #5 on: August 18, 2013, 12:59:59 am »
I'm getting excited!  :scared: :-/O
It's not always the most popular person who gets the job done.
 

Offline jasonbrent

  • Regular Contributor
  • *
  • Posts: 176
Re: DG4000 - a firmware investigation
« Reply #6 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
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #7 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 (date: 6/13/2012)

00.01.06.00.02 (date: 5/9/2013)

thx
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #8 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.
« Last Edit: August 18, 2013, 10:02:22 am by KedasProbe »
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #9 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  :-+
« Last Edit: August 27, 2013, 08:36:47 pm by cybernet »
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #10 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?
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline synapsis

  • Regular Contributor
  • *
  • Posts: 140
  • Country: us
    • Blackcow
Re: DG4000 - a firmware investigation
« Reply #11 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.)
 

Offline cybernetTopic starter

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

Offline cybernetTopic starter

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

Offline synapsis

  • Regular Contributor
  • *
  • Posts: 140
  • Country: us
    • Blackcow
Re: DG4000 - a firmware investigation
« Reply #14 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.
 

Offline cybernetTopic starter

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

JuanPC

  • Guest
Re: DG4000 - a firmware investigation
« Reply #16 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
 

Offline jsykes

  • Contributor
  • Posts: 31
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #17 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  ?
 
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #18 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  :-//
« Last Edit: August 28, 2013, 02:45:05 pm by cybernet »
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: DG4000 - a firmware investigation
« Reply #19 on: August 28, 2013, 02:19:24 pm »
Gee whiz, that's amazing.  nicely done.
 

Offline Uup

  • Regular Contributor
  • *
  • Posts: 82
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #20 on: August 29, 2013, 07:36:16 am »
Nice work Cybernet!   :-+

Attached is the latest firmware (00.01.07.00.03)
 

Offline cybernetTopic starter

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

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #22 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
« Last Edit: August 29, 2013, 06:11:58 pm by KedasProbe »
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline echen1024

  • Super Contributor
  • ***
  • Posts: 1660
  • Country: us
  • 15 yo Future EE
Hacking Rigol 4000
« Reply #23 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.
I'm not saying we should kill all stupid people. I'm just saying that we should remove all product safety labels and let natural selection do its work.

https://www.youtube.com/user/echen1024
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7547
  • Country: 00
  • +++ ATH1
Re: Hacking Rigol 4000
« Reply #24 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, 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.  :-//


Offline synapsis

  • Regular Contributor
  • *
  • Posts: 140
  • Country: us
    • Blackcow
Re: Hacking Rigol 4000
« Reply #25 on: September 02, 2013, 02:54:22 am »
 

Offline echen1024

  • Super Contributor
  • ***
  • Posts: 1660
  • Country: us
  • 15 yo Future EE
Re: DG4000 - a firmware investigation
« Reply #26 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.
I'm not saying we should kill all stupid people. I'm just saying that we should remove all product safety labels and let natural selection do its work.

https://www.youtube.com/user/echen1024
 

Offline cybernetTopic starter

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

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #28 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?
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #29 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

the gnu blackfin toolkit uses urjtag as basis for its gdb proxy.
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #30 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

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

Offline Rufus

  • Super Contributor
  • ***
  • Posts: 2095
Re: DG4000 - a firmware investigation
« Reply #31 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.
 

Offline Carrington

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: es
Re: DG4000 - a firmware investigation
« Reply #32 on: September 03, 2013, 12:05:12 am »
My English can be pretty bad, so suggestions are welcome. ;)
Space Weather.
Lightning & Thunderstorms in Real Time.
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1918
  • Country: 00
    • If you like my hacks, send me a donation
Re: DG4000 - a firmware investigation
« Reply #33 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


I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #34 on: September 03, 2013, 12:23:54 am »
Why not this other? 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

Geezzz, hope they've improved shipping since then!  For the $80USD it cost (incl. shipping) I expect it by the end of this week!
 

Offline synapsis

  • Regular Contributor
  • *
  • Posts: 140
  • Country: us
    • Blackcow
Re: DG4000 - a firmware investigation
« Reply #35 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.
 

Offline echen1024

  • Super Contributor
  • ***
  • Posts: 1660
  • Country: us
  • 15 yo Future EE
Re: DG4000 - a firmware investigation
« Reply #36 on: September 03, 2013, 02:50:36 am »
I might just buy an eBay cheapie. Shipping for this thing is RIDICULOUS.  :bullshit:
I'm not saying we should kill all stupid people. I'm just saying that we should remove all product safety labels and let natural selection do its work.

https://www.youtube.com/user/echen1024
 

Offline cybernetTopic starter

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

Offline arvidj

  • Contributor
  • Posts: 32
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #38 on: September 05, 2013, 11:43:59 pm »
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #39 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

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

Offline arvidj

  • Contributor
  • Posts: 32
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #40 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

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.
 

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1976
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #41 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

/Bingo
« Last Edit: September 08, 2013, 07:59:29 pm by bingo600 »
 

Offline fluxcapacitor

  • Frequent Contributor
  • **
  • Posts: 345
  • Country: gb
Re: DG4000 - a firmware investigation
« Reply #42 on: September 08, 2013, 09:42:53 pm »
 

Offline synapsis

  • Regular Contributor
  • *
  • Posts: 140
  • Country: us
    • Blackcow
Re: DG4000 - a firmware investigation
« Reply #43 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.
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #44 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!

« Last Edit: September 28, 2013, 12:55:41 am by Sparky »
 

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #45 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

jtag will work.

Thanks a lot.
My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #46 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.

___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline Carrington

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: es
My English can be pretty bad, so suggestions are welcome. ;)
Space Weather.
Lightning & Thunderstorms in Real Time.
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #48 on: September 28, 2013, 06:33:31 pm »
yes  ;)
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #49 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 :)
 

Offline Carrington

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: es
Re: DG4000 - a firmware investigation
« Reply #50 on: October 01, 2013, 06:33:03 pm »
Sparky, maybe this will be useful:
http://www.topjtag.com/flash-programmer/
My English can be pretty bad, so suggestions are welcome. ;)
Space Weather.
Lightning & Thunderstorms in Real Time.
 

Offline Carrington

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: es
Re: DG4000 - a firmware investigation
« Reply #51 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
« Last Edit: October 02, 2013, 12:46:29 am by Carrington »
My English can be pretty bad, so suggestions are welcome. ;)
Space Weather.
Lightning & Thunderstorms in Real Time.
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #52 on: October 07, 2013, 06:41:07 pm »
Sparky, maybe this will be useful:
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). 

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 :)
« Last Edit: October 07, 2013, 06:43:27 pm by Sparky »
 

Offline cosmos

  • Regular Contributor
  • *
  • Posts: 110
  • Country: 00
Re: DG4000 - a firmware investigation, DS4000 variant
« Reply #53 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.

 

Offline Carrington

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: es
Re: DG4000 - a firmware investigation
« Reply #54 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). 

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?
My English can be pretty bad, so suggestions are welcome. ;)
Space Weather.
Lightning & Thunderstorms in Real Time.
 

Offline tized

  • Contributor
  • Posts: 35
  • Country: il
Re: DG4000 - a firmware investigation, DS4000 variant
« Reply #55 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.
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #56 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). 

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

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 572
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #57 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

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
Keil is not on this list named "Supported JTAG adapters/cables":
http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables
« Last Edit: November 07, 2013, 03:40:11 am by AndersAnd »
 

Offline cybernetTopic starter

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

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #59 on: November 16, 2013, 12:09:50 am »

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

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 ;-)
**
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7547
  • Country: 00
  • +++ ATH1
Re: DG4000 - a firmware investigation
« Reply #60 on: November 16, 2013, 12:57:42 am »
Damn ... another great job cybernet !  :clap:


.....  ;)  ;)  ;) .... time to update local copy .....  ;)  ;)  ;) ....

Offline Rory

  • Frequent Contributor
  • **
  • Posts: 410
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #61 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!)
 

Offline cybernetTopic starter

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

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #63 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.
« Last Edit: November 16, 2013, 11:18:05 pm by Sparky »
 

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #64 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.


My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Offline Rory

  • Frequent Contributor
  • **
  • Posts: 410
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #65 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.
 

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #66 on: November 16, 2013, 06:16:31 am »
I have no Linux  :-(
My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Offline Rory

  • Frequent Contributor
  • **
  • Posts: 410
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #67 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. 
 

Offline max-bit

  • Frequent Contributor
  • **
  • Posts: 668
  • Country: pl
Re: DG4000 - a firmware investigation
« Reply #68 on: November 16, 2013, 07:19:31 am »
Good no...fantastic Job :)
and why buy DG4162 ? |O
 

Offline TMM

  • Frequent Contributor
  • **
  • Posts: 471
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #69 on: November 16, 2013, 08:03:42 am »
awesome work :-+
 

Offline Harvs

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #70 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?
 

Offline TMM

  • Frequent Contributor
  • **
  • Posts: 471
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #71 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.
 

Offline Harvs

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #72 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
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #73 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.

 :-+  :-+
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline Harvs

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #74 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!!!
 

Offline Harvs

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #75 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.
 

Offline TMM

  • Frequent Contributor
  • **
  • Posts: 471
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #76 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  :-+
 

Offline Rory

  • Frequent Contributor
  • **
  • Posts: 410
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #77 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;
}


« Last Edit: November 16, 2013, 11:22:41 pm by Rory »
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #78 on: November 16, 2013, 11:15:27 pm »
FW 07 also tested okay
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #79 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.
 

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #80 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
My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Offline cosmos

  • Regular Contributor
  • *
  • Posts: 110
  • Country: 00
Re: DG4000 - a firmware investigation
« Reply #81 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.
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #82 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 ;)

« Last Edit: November 16, 2013, 11:30:33 pm by cybernet »
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline Rory

  • Frequent Contributor
  • **
  • Posts: 410
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #83 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....)

 

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #84 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
My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Offline cybernetTopic starter

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

Offline sprocket

  • Regular Contributor
  • *
  • Posts: 52
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #86 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.
 

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #87 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
« Last Edit: November 17, 2013, 12:32:50 am by Rigol-Friend »
My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Offline cybernetTopic starter

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

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #89 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
My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Offline Harvs

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #90 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.
 

Offline elCap

  • Regular Contributor
  • *
  • Posts: 109
  • Country: jp
Re: DG4000 - a firmware investigation
« Reply #91 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!! :-+
 

Offline cybernetTopic starter

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

Offline elCap

  • Regular Contributor
  • *
  • Posts: 109
  • Country: jp
Re: DG4000 - a firmware investigation
« Reply #93 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.
« Last Edit: November 17, 2013, 03:34:24 am by elCap »
 

Offline TMM

  • Frequent Contributor
  • **
  • Posts: 471
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #94 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.
« Last Edit: November 17, 2013, 03:55:33 am by TMM »
 

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #95 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
My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Online AndyC_772

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: DG4000 - a firmware investigation
« Reply #96 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/

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.

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #97 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.
« Last Edit: November 18, 2013, 10:41:33 pm by ted572 »
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #98 on: November 17, 2013, 10:08:07 pm »
try it and let us know ;)
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline elCap

  • Regular Contributor
  • *
  • Posts: 109
  • Country: jp
Re: DG4000 - a firmware investigation
« Reply #99 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.
 

Offline Carrington

  • Super Contributor
  • ***
  • Posts: 1202
  • Country: es
Re: DG4000 - a firmware investigation
« Reply #100 on: November 17, 2013, 11:53:08 pm »
the DS4k software is based on the DS2k software - there is no CEN support that i would have spotted on my way through this piece of s...oftware ;)
but there are still some bits to be discovered in that software ... internal filesystem (and how to access it), some SCPI commands that seem "unreachable", bootloader update, and custom firmware - running linux would be fun ;)
Congratulations Cybernet.  :-+
A custom firmware would be great and a titanic task.  :phew:
My English can be pretty bad, so suggestions are welcome. ;)
Space Weather.
Lightning & Thunderstorms in Real Time.
 

Offline synapsis

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

Upgraded my unit in about 4 minutes.  :-+
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #102 on: November 18, 2013, 10:39:54 pm »
Re. DG4000 cengen:  There are several of us non Unix/Linux users here on the forum that would very much appreciate a Windows or Web application to generate the required CEN file.  If someone could put one together it would be very much appreciated
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 572
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #103 on: November 19, 2013, 01:51:11 pm »
Re. DG4000 cengen:  There are several of us non Unix/Linux users here on the forum that would very much appreciate a Windows or Web application to generate the required CEN file.  If someone could put one together it would be very much appreciated
The best would be if studio25 could integrate it in his web app RigLOL http://riglol.3owl.com
 

Offline bandgap

  • Contributor
  • Posts: 47
  • Country: us
  • .: no electrons here :.
    • Bandgap.net
Re: DG4000 - a firmware investigation
« Reply #104 on: November 20, 2013, 07:40:38 am »
Re. DG4000 cengen:  There are several of us non Unix/Linux users here on the forum that would very much appreciate a Windows or Web application to generate the required CEN file.  If someone could put one together it would be very much appreciated


---
original post removed
---

I'm editing this post to remove the link to my windows binary. Apparently it is putting extra bytes in the license file. I tried several different compilers and even tried cross-compiling for windows from my linux box. Every windows binary I make puts extra bytes into the license file. I don't have enough time to see exactly why, so I offer here an alternative solution if you only have access to windows.

1) Go to http://www.compileonline.com/compile_c_online.php
2) Replace the code in the left box with the code below.
3) Put your command line arguments in the text box at the bottom (in the form <current model> <new model> <current serial>)
4) Press "Compile and Execute" in the top left
5) Press "Download Files" in the top right (assuming everything executed properly)
6) The result tar.gz file will have the proper license.CEN file contained within it.

-Clayton



Code: [Select]
/*
** rigol DG4000 cengen / cybernet
**
** BUILD WITH:
**    gcc cengen.c -m32 -o cengen
**
** RUN WITH:
**
**    ./cengen <CURRENT_MODEL> <NEW_MODEL> <CURRENT_SERIAL> [<NEW_SERIAL>]
**
**     <?_MODEL> = DG4062, DG4102, DG4162, DG4202(*)
**     <?_SERIAL> = DG4D1XXXXXXXX
**
**    if <NEW_SERIAL> is omitted the serial will not be modified
**    (*) DG4202 is not an official model, but 200Mhz seems to work fine
**
**
** =================================================================================
** more info: https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/
** =================================================================================
**
**     ____  ______________  ___   __
**    / __ \/_  __/ ____/  |/  /  / /
**   / /_/ / / / / /_  / /|_/ /  / /
**  / _, _/ / / / __/ / /  / /  /_/
** /_/ |_| /_/ /_/   /_/  /_/  (_)
**
** this tool generates a new model type (DG4XXX) & serial (DG4D1XXXXXXXX) string,
** calculates a MAC and creates a .CEN file.
**
** what to do with the file ?
**
** put it on an USB stick, plug stick into DG4000, goto "Store", browse USB Stick,
** change "File Type" to "All File", navigate to your .CEN file, press "Read".
**
** You should get a Popup telling you that you successfully changed your model type and serial
**
** if *not* you:
**         used a wrong current model type
** used a wrong current serial
** used an invalid new model type
** used an invalid new serial
**
**
** firmware tested:
**     00.01.06
**     00.01.03
**
**
** no warranties, if it explodes, your problem ;-)
**
*/
#include<stdio.h>
#include<stdlib.h>
#include<stdint.h>
#include<string.h>
#include<ctype.h>

#define VERSION "0.1"

char     header[]="RIGOL:DG4:FIRM LICENSE FILE";
char     iv[]="1000000110000001";
char     static_cccc[4];
char static_zero[8];

// endianess shit
union helper {
 unsigned char c[8];
 unsigned int  l[2];
 uint64_t      u;
};

// shifty
void do_cbc(char a, char b, char c, char d, char e, char f, uint16_t word1, char *buffer)
{
 uint16_t bit1,bit2,bit3,bit4,u,x,y,z;
 char out;
 int la;

 if (buffer==0) return;
 u=(1<<a)-1;
 z=0;
 x=0;
 while (a > z)
 {
   x=x|(1<<z);
   z++;
 }
 y=word1&x;
 if (e==0)
 {
    la=0;
    while (u > la)
    {
*(int*)(buffer+la*2)=(int)y;
if (b==0) bit1=0;
else
{
      bit1=(y>>(b-1))&1;
}
if (c==0) bit2=0;
else
{
      bit2=(y>>(c-1))&1;
}
if (d==0) bit3=0;
else
        {
              bit3=(y>>(d-1))&1;
        }
        if (f==0) bit4=0;
else
        {
              bit4=(y>>(f-1))&1;
        }
        out=bit1^bit2;
out=out^bit3;
out=out^bit4;
y=y*2;
y=y&x;
y=y|out;
la++;
    }
 }
 else
 {
   printf("not implemented - deemed useless code ...\n");
   exit(-1);
 }
}

/*
** convert string to uppercase chars
*/
char * strtoupper(char *str)
{
  int i = 0;

   for(i = 0; str[i]; i++)
   {
      str[i] = toupper(str[i]);
   }
   return  str;
}

void ascii(void)
{
printf("\n");
printf("  ________  ____  ____ ____  ____\n");
printf(" / ___/ _ \\/ __ \\/ __ `/ _ \\/ __ \\\n");
printf("/ /__/  __/ / / / /_/ /  __/ / / /\n");
printf("\\___/\\___/_/ /_/\\__, /\\___/_/ /_/\n");
printf(" V%s          /____/  cybernet 2013\n\n", VERSION);
}

void help(void)
{
printf("\n ./cengen <CURRENT_MODEL> <NEW_MODEL> <CURRENT_SERIAL> [<NEW_SERIAL>]\n\n");
printf("    <?_MODEL> = DG4062, DG4102, DG4162, DG4202(*)\n");
printf("    <?_SERIAL> = DG4D1XXXXXXXX\n\n");
printf("  example: ./cengen DG4062 DG4202 DG4D150400123\n");
printf("  (upgrades DG4062 to DG4202, keeps serial number)\n\n");
printf("  if <NEW_SERIAL> is omitted the serial will not be modified\n");
printf("  (*) DG4202 is not an official model, but 200Mhz seems to work fine\n\n");
exit(-1);
}

char buffer_shift(int la, uint16_t *word1, char *buf)
{
int w;
int y;
int li=0;
char x=0;

while (li > la)
{
  w=*word1;
  y=*(buf+li);
  if (y!=li)
  {
    *word1=w+1;
    li=0;
    x=1;
  }
  li++;
}
return(x);
}

// dump license file
void write_file(char *nms, char *buf, uint16_t buf_len)
{
 char len[8];
 FILE *fd=NULL;

 fd=fopen("license.CEN", "w");
 if (fd==NULL)
 {
   printf("unable to open file 'license.CEN' for writing\n");
   exit(-1);
 }
 memset(static_cccc, 0xcc, 4);
 memset(static_zero, 0x0, 8);
 memset(len,0,8);
 //bzero(len,8);
 len[0]=(buf_len)&0xFF;
 len[1]=((buf_len)>>8)&0xFF;
 fwrite(header,1,strlen(header),fd);
 fwrite(len,1,4,fd);
 fwrite(static_zero,1,4,fd);
 fwrite(static_cccc,1,2,fd);
 fwrite(iv,1,strlen(iv)+1,fd);
 fwrite(nms,1,strlen(nms),fd);
 fwrite(buf,1,buf_len*2,fd);
 fclose(fd);
}

int main(int argc, char *argv[])
{
 char  secret[]="YZDHZSGCX";
 char  new_model[8];
 char  new_serial[14];
 char  *new_model_serial;
 char  cur_model[8];
 char  cur_serial[14];
 char  *cur_model_serial;
 char  *buffer20;
 char  *buffer_a2;
 char  *buffer_a4;
 int la;
 char  hbuf[3];
 char  chr;
 int   duplets,bits;
 int   r1,d1,r2,d2;
 unsigned int data1,data2;
 uint16_t word1;
 unsigned char lasthex;
 union helper uni1;
 int   key_len;
 int   prime=13;
 int   len_mts;
 int lc,lb,ld;
 int   y;
 uint16_t   w;


 ascii();
 if (argc>=4)
 {
   strcpy(cur_serial, strtoupper(argv[3]));
   strcpy(new_model, strtoupper(argv[2]));
   strcpy(cur_model, strtoupper(argv[1]));

   if (strlen(cur_model)!=6) { printf("invalid <CURRENT_MODEL> len\n"); help(); }
   if (strlen(new_model)!=6) { printf("invalid <NEW_MODEL> len\n"); help(); }
   if (strlen(cur_serial)!=13) { printf("invalid <CURRENT_SERIAL> len\n"); help();  }
   if (strncmp(cur_model,"DG4", strlen("DG4"))) { printf("invalid <CURRENT_MODEL> type\n"); help(); }
   if (strncmp(new_model,"DG4", strlen("DG4"))) { printf("invalid <NEW_MODEL> type\n"); help(); }
   if (strncmp(cur_serial,"DG4", strlen("DG4"))) { printf("invalid <CURRENT_SERIAL> type\n"); help(); }
   if (argc==5)
   {
     strcpy(new_serial, strtoupper(argv[4]));
     if (strlen(new_serial)!=13) { printf("invalid <NEW_SERIAL> len\n"); help(); }
     if (strncmp(new_serial,"DG4", strlen("DG4"))) { printf("invalid <NEW_SERIAL> type\n"); help(); }
     strcpy(new_serial, strtoupper(argv[4]));
   }
   else strcpy(new_serial, strtoupper(argv[3]));
 }
 else help();

 cur_model_serial=(char*)calloc(1, strlen(cur_model)+strlen(cur_serial)+1);
 new_model_serial=(char*)calloc(1, strlen(new_model)+strlen(new_serial)+1);
 strcpy(new_model_serial, new_model);
 strcat(new_model_serial, new_serial);
 strcpy(cur_model_serial, cur_model);
 strcat(cur_model_serial, cur_serial);
 printf("\nCurrent settings:\n");
 printf("\tModel:\t\t%s\n",cur_model);
 printf("\tSerial#:\t%s\n",cur_serial);
 printf("\nNew settings:\n");
 printf("\tModel:\t\t%s\n",new_model);
 printf("\tSerial#:\t%s\n\n",new_serial);
 buffer20=(char*)calloc(1,20);
 buffer_a2=(char*)calloc(4,8192);
 buffer_a4=(char*)calloc(4,8192);
 memset(buffer_a4,0xAA,8192);
 key_len=strlen(secret);
 la=0;
 duplets=0;
 y=0;
 hbuf[2]=0;
 while(la < strlen(iv))
 {
   hbuf[0]=iv[la];
   hbuf[1]=iv[la+1];
   uni1.c[duplets]=strtol(hbuf,NULL,0x10);
   duplets++;
   la=la+2;
 }
 data1=uni1.l[0];
 data2=uni1.l[1];
 bits=duplets<<3;
 r1=bits%prime;
 d1=bits/prime;
 if (r1 != 0) d1++;
 lasthex=uni1.c[duplets-1];
 d2=64/prime;
 r2=64%prime;
 la=0;
 while (d1>la)
 {
    if (d2>0)
    {
word1=data1&0x1fff;
       uni1.u=uni1.u>>prime;
data1=uni1.l[0];
       data2=uni1.l[1];
d2--;
    }
    else
    {
word1=(int)(((int)data1)|(lasthex<<r2))&0xffff;
    }
    buffer_shift(la,&word1,buffer20);
    *(int*)(buffer20+la*2)=(int)word1;
    do_cbc(0xd, 0x1, 0x3, 0x4, 0x0, 0xd, word1, buffer_a2);
    len_mts=strlen(new_model_serial);
    ld=lb=lc=0;
    while (len_mts > lc)
    {
chr=cur_model_serial[lc];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
       *(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
if (lb > (key_len-1)) lb=0;

       chr=secret[lb];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
chr=secret[lb]^cur_model_serial[lc];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
       *(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
       y++;
       if (ld > (len_mts-1)) ld=0;

chr=new_model_serial[ld];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
       y++;

lc++;
lb++;
ld++;
    }
    la++;
 }
 w=*(uint16_t*)(buffer_a4)&0xffff;
 w=w&0xfffc;
 *(uint16_t*)(buffer_a4)=(uint16_t)w;
 *(uint16_t*)(buffer_a4)=2|(uint16_t)w;
 w=*(uint16_t*)(buffer_a4+0x14)&0xffff;
 *(uint16_t*)(buffer_a4+0x14)=2|(uint16_t)w&0xfff8;
 write_file(new_model_serial, buffer_a4, y);
 printf("license file dumped into: 'license.CEN' - have fun !\n\n");
 exit(0);
}
« Last Edit: November 21, 2013, 09:33:36 am by bandgap »
 
The following users thanked this post: twdotnet

Offline hammy

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

Offline ted572

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

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

     Thanks again, Ted
 

Offline bandgap

  • Contributor
  • Posts: 47
  • Country: us
  • .: no electrons here :.
    • Bandgap.net
Re: DG4000 - a firmware investigation
« Reply #107 on: November 21, 2013, 09:40:47 am »
There's a dot at the end of your link before the [/url] bracket, so clicking the link doesn't work correctly.
Here's the correct link: http://www.compileonline.com/compile_c_online.php

Thanks! I've corrected my post.

-Clayton
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #108 on: November 21, 2013, 10:54:43 am »
I Upgraded my DG4062 to a DG4202 (200 MHz), but . . . 

Issue 1.  What I’m seeing is that the sine wave output is flat to 100MHz within +/- ~ 0.4 dB to 100MHz, but about -1 dB @ 120MHz, ~ -2.5 dB @ 160MHz, and ~ -4.5dB @ 200MHz. The Square Wave Rise Time is about 4.1 ns, so I’m happy about that, as I believe that the extrapolated spec would be 5ns for the DG4202. But the Sine Wave level drop above 100MHz seems way out of the ordinary with the Flatness spec for the DG4162 being +/- 0.8 up to 160 MHz.   Test configuration: I have the DG4000 output impedance set for 50 Ohms, used output levels of 0 and -15dBm (with the same results), and the output measurements were made with a Spectrum Analyzer and a HP RF Power Meter.

Issue 2.  I also have an issue with DG4000 Screen Saver after several minutes of no activity (not making any changes on the front panel). The DS4000 comes up with a dark screen and a Rigol logo that changes position on the screen every 5 seconds, or comes up with Rigol in a single fixed position, or comes up with a blank screen. I didn’t notice this behavior before. Hopefully this issue is simply in the version 00.01.06.00.02 of software/firmware and others with/without this upgrade patch are experiencing this also (?).

System Info:  Device Model - DG4062/DG4202, Serial Number - DG4D152xxxxxx, Software - 00.01.06.00.02, FPGA - 00.01.07.09, Hard - 01.03, Keyboard - 05.01, and Enc FPGA – 06.

I was able to successfully recovery the original DG4062 configuration by using the ‘cegen’ Keygen in reverse (DG4202 to DG4062).

The Screen Saver operation is the same. And by the way it kicks in after 15 minutes of no front panel activity. Out of 8 tests the Rigol Logo froze twice. So does this mean it is due to a firmware bug and was there before using ‘cengen’?  Probably. . .  Has this issue been reported by anyone else?

Please, any thoughts or comments would be appreciated.
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #109 on: November 21, 2013, 11:53:32 am »
I Upgraded my DG4062 to a DG4202 (200 MHz), but . . . 

Issue 1.  What I’m seeing is that the sine wave output is flat to 100MHz within +/- ~ 0.4 dB to 100MHz, but about -1 dB @ 120MHz, ~ -2.5 dB @ 160MHz, and ~ -4.5dB @ 200MHz. The Square Wave Rise Time is about 4.1 ns, so I’m happy about that, as I believe that the extrapolated spec would be 5ns for the DG4202. But the Sine Wave level drop above 100MHz seems way out of the ordinary with the Flatness spec for the DG4162 being +/- 0.8 up to 160 MHz.   Test configuration: I have the DG4000 output impedance set for 50 Ohms, used output levels of 0 and -15dBm (with the same results), and the output measurements were made with a Spectrum Analyzer and a HP RF Power Meter.

Issue 2.  I also have an issue with DG4000 Screen Saver after several minutes of no activity (not making any changes on the front panel). The DS4000 comes up with a dark screen and a Rigol logo that changes position on the screen every 5 seconds, or comes up with Rigol in a single fixed position, or comes up with a blank screen. I didn’t notice this behavior before. Hopefully this issue is simply in the version 00.01.06.00.02 of software/firmware and others with/without this upgrade patch are experiencing this also (?).

System Info:  Device Model - DG4062/DG4202, Serial Number - DG4D152xxxxxx, Software - 00.01.06.00.02, FPGA - 00.01.07.09, Hard - 01.03, Keyboard - 05.01, and Enc FPGA – 06.

I was able to successfully recovery the original DG4062 configuration by using the ‘cegen’ Keygen in reverse (DG4202 to DG4062).

The Screen Saver operation is the same. And by the way it kicks in after 15 minutes of no front panel activity. Out of 8 tests the Rigol Logo froze twice. So does this mean it is due to a firmware bug and was there before using ‘cengen’?  Probably. . .  Has this issue been reported by anyone else?

Please, any thoughts or comments would be appreciated.

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

Offline ted572

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

    I Upgraded my DG4062 to a DG4202 (200 MHz), but . . .

    Issue 1.  What I’m seeing is that the sine wave output is flat to 100MHz within +/- ~ 0.4 dB to 100MHz, but about -1 dB @ 120MHz, ~ -2.5 dB @ 160MHz, and ~ -4.5dB @ 200MHz. The Square Wave Rise Time is about 4.1 ns, so I’m happy about that
----------------------------------------------------------
@screensaver - no issues for me - tried with FW 03, 06 and 07 - i doubt the mod interferes with the screensaver in any way.
@flatness - you will probably have to do a manual cal -> pw is 2010 - im no expert on that matter, but a Vrms meter should be sufficient, it seems to output different sines at different offsets/frequencies and expects you to correct the values shown in the tables - some of the tables are actually called "flatness" - so i would assume thats what can be used to tune it up to 160MHZ if not 200MHZ.
----------------------------------------------------------

 cybernet:

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

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

 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #111 on: November 21, 2013, 01:39:21 pm »
cybernet, or anyone else:

Do you know where I can get a DG4000 calibration procedure, or at least a description of the meanings for the various calibration points?
Any clues about the calibration would be helpful and appreciated. I have the resources to accomplish it after I find some details/clues about it.

The PW you provided cybernet did allow me access to the Manual Cal. pages. Thank you.
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #112 on: November 21, 2013, 01:49:52 pm »
cybernet, or anyone else:

Do you know where I can get a DG4000 calibration procedure, or at least a description of the meanings for the various calibration points?
Any clues about the calibration would be helpful and appreciated. I have the resources to accomplish it after I find some details/clues about it.

The PW you provided cybernet did allow me access to the Manual Cal. pages. Thank you.

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

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #113 on: November 21, 2013, 01:51:41 pm »
and on the heels of that - there is a calibration file format that can be loaded like the CEN files, which is probably what rigol uses to do an inital calibration. so if somebody WOULD get sane values for a 160/200MHZ upgraded one, i might look into the file format to make that available easily to the rest. (depends on time on my end) - would save some measurement and type in sessions ....
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline Uup

  • Regular Contributor
  • *
  • Posts: 82
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #114 on: November 21, 2013, 02:08:22 pm »
and on the heels of that - there is a calibration file format that can be loaded like the CEN files, which is probably what rigol uses to do an inital calibration. so if somebody WOULD get sane values for a 160/200MHZ upgraded one, i might look into the file format to make that available easily to the rest. (depends on time on my end) - would save some measurement and type in sessions ....

I have a DG4162, so its calibration values should be sane to at least 160MHz. I haven't compiled your code yet but thank you all the same for sharing your brilliant reverse engineering work.  :clap:
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #115 on: November 21, 2013, 02:13:26 pm »
and on the heels of that - there is a calibration file format that can be loaded like the CEN files, which is probably what rigol uses to do an inital calibration. so if somebody WOULD get sane values for a 160/200MHZ upgraded one, i might look into the file format to make that available easily to the rest. (depends on time on my end) - would save some measurement and type in sessions ....

I have a DG4162, so its calibration values should be sane to at least 160MHz. I haven't compiled your code yet but thank you all the same for sharing your brilliant reverse engineering work.  :clap:

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

Offline KedasProbe

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

Offline ted572

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

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

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

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

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #118 on: November 23, 2013, 06:56:58 pm »
Subject: Getting a newer FPGA version for DG4000.

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

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

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

there is some fpga firmware in the GEL file, but could be for display or keyboard FPGA - and there is a dedicated file format header for FPGA only upgrades (might used in factory), but nobody has such a file.
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline ted572

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

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

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

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


there is some fpga firmware in the GEL file, but could be for display or keyboard FPGA - and there is a dedicated file format header for FPGA only upgrades (might used in factory), but nobody has such a file.

I installed FW update 00.01.07.00.03 with some hesitation due to it having a couple serious bugs, but I decided that it would be worth it to find out if it had a FPGA update embedded in it or not. It did, now I have Software Ver. 00.01.07.00.03, as well as FPGA Ver. 00.01.08.03. So now I'm happy to have my unit up to date.  I'll just wait for Rigol to release the next version of software to correct the flaws in 07.

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

Thanks 'cybernet'

Reference below for info on Software 07 bugs:

Re: Rigol DG4xxx ppulse and npulse
« Reply #5 on: October 22, 2013, 09:25:30 PM »

    Quote

Yes, Rigol just confirmed it is a bug, I'll post here when they come up with the fix.
« Last Edit: November 24, 2013, 02:11:06 am by ted572 »
 

Offline cybernetTopic starter

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

http://www.filedropper.com/dumpfilestar

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

Offline Rigby

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

http://www.filedropper.com/dumpfilestar


Wow...  Nicely done.
 

Offline Mark_O

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

http://www.filedropper.com/dumpfilestar


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

Offline AndersAnd

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

Offline AndersAnd

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

Re: Rigol DG4xxx ppulse and npulse
« Reply #5 on: October 22, 2013, 09:25:30 PM »

    Quote

Yes, Rigol just confirmed it is a bug, I'll post here when they come up with the fix.
Link to that topic: https://www.eevblog.com/forum/testgear/rigol-dg4xxx-ppulse-and-npulse/
 

Offline tized

  • Contributor
  • Posts: 35
  • Country: il
Re: DG4000 - a firmware investigation
« Reply #125 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

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


Funny thing, I've just done the same for the DS2000 firmware and this is what I got:

Code: [Select]
Device: DS2202
Version: 00.01.00.00.03

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

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

Offline cybernetTopic starter

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

Offline tized

  • Contributor
  • Posts: 35
  • Country: il
Re: DG4000 - a firmware investigation
« Reply #127 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.
 
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #128 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);
« Last Edit: November 24, 2013, 03:41:31 pm by cybernet »
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline cybernetTopic starter

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

Offline tized

  • Contributor
  • Posts: 35
  • Country: il
Re: DG4000 - a firmware investigation
« Reply #130 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.
 

Offline jboard146

  • Contributor
  • Posts: 38
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #131 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.
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #132 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/
Rigol confirmed it is a bug.
This update also fully resolved the problem I was having with the DG4000 Screen Saver.  Where as before it would be flaky about 20% of the time, although it did still blanked the screen.
 

Offline aurel

  • Contributor
  • Posts: 16
  • Country: fr
Re: DG4000 - a firmware investigation
« Reply #133 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 !
 

Offline Mark_O

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

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

Offline monster

  • Newbie
  • Posts: 5
Re: DG4000 - a firmware investigation
« Reply #135 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
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 572
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #136 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!! :-+
 

Offline monster

  • Newbie
  • Posts: 5
Re: DG4000 - a firmware investigation
« Reply #137 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
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #138 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?
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline cybernetTopic starter

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

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #140 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
« Last Edit: December 03, 2013, 04:28:59 pm by ted572 »
 

Offline Avotronics

  • Regular Contributor
  • *
  • Posts: 58
  • Country: gb
    • Rigol Hacks
Re: DG4000 - a firmware investigation
« Reply #141 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.
Why would you buy something ready made when you can make it yourself with half the features for twice the money!
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 572
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #142 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

Edit: I have unzipped it online here, where you can download the .GEL file: http://wobzip.org/file/aWTQIIIQ
The file will only be kept by Wobzip for 3 days.
"Download as zip" doesn't work for this file, but you can zip it in WinRAR once downloaded.

Otherwise you can install 7zip, this seems to work with this archive. But if you don't want to install another zip archiver, try the online tool first.

B1 also have an installable zip archiver: http://b1.org

Nice work Cybernet!   :-+

Attached is the latest firmware (00.01.07.00.03)
This file gives an error when trying to extract? (only empty folders)
edit: it does work with 7zip, not with winRAR or Windows 7 zip, Thanks for sharing
« Last Edit: December 04, 2013, 10:05:51 am by AndersAnd »
 

Offline Avotronics

  • Regular Contributor
  • *
  • Posts: 58
  • Country: gb
    • Rigol Hacks
Re: DG4000 - a firmware investigation
« Reply #143 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.
Why would you buy something ready made when you can make it yourself with half the features for twice the money!
 

Offline Avotronics

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

Edit: I have unzipped it online here, where you can download the .GEL file: http://wobzip.org/file/aWTQIIIQ
The file will only be kept by Wobzip for 3 days.
"Download as zip" doesn't work for this file, but you can zip it in WinRAR once downloaded.

Otherwise you can install 7zip, this seems to work with this archive. But if you don't want to install another zip archiver, try the online tool first.

B1 also have an installable zip archiver: http://b1.org

Nice work Cybernet!   :-+

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

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

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #145 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

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

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

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 572
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #146 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.
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 572
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #147 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
But is this bug only related in FW 00.01.07.00.03?
Isn't the same bug in older firmwares too?
 

Offline Avotronics

  • Regular Contributor
  • *
  • Posts: 58
  • Country: gb
    • Rigol Hacks
Re: DG4000 - a firmware investigation
« Reply #148 on: December 04, 2013, 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/
Why would you buy something ready made when you can make it yourself with half the features for twice the money!
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #149 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.
« Last Edit: December 08, 2013, 09:07:34 pm by ted572 »
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #150 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
« Last Edit: December 07, 2013, 05:23:09 pm by ted572 »
 

Offline Rufus

  • Super Contributor
  • ***
  • Posts: 2095
Re: DG4000 - a firmware investigation
« Reply #151 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?
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #152 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 
« Last Edit: December 06, 2013, 07:51:39 pm by ted572 »
 

Offline Rufus

  • Super Contributor
  • ***
  • Posts: 2095
Re: DG4000 - a firmware investigation
« Reply #153 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.
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #154 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.
« Last Edit: December 06, 2013, 08:05:23 pm by ted572 »
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #155 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.
« Last Edit: December 07, 2013, 11:39:15 am by KedasProbe »
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #156 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.
« Last Edit: January 07, 2014, 07:50:34 pm by Teneyes »
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #157 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.
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #158 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.
« Last Edit: December 08, 2013, 09:10:49 pm by ted572 »
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #159 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.


___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #160 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

My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #161 on: December 07, 2013, 06:50:52 pm »
@Pedre

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

My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #162 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
« Last Edit: December 08, 2013, 05:09:09 am by Rigol-Friend »
My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #163 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
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #164 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
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #165 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.
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #166 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
« Last Edit: December 20, 2013, 08:12:22 am by Teneyes »
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #167 on: December 20, 2013, 10:56:01 am »
Is 10-159MHz also OK?
(in theory you can't enter >160Mhz so...)
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #168 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

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.

My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Offline whotopia

  • Contributor
  • Posts: 12
  • Country: ch
Re: DG4000 - a firmware investigation
« Reply #169 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  (the upgrade instructions).  (yes I've search around this forum and others)   

Thanks!
Steven
 

Offline Rigol-Friend

  • Contributor
  • Posts: 35
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #170 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.
My english is VERY poor, sorry. I learned in school, about more than 55 years ago.

But I'am a happy owner of Rigol DSA815-TG with all options + DS2302 (was DS2072) + DG4202 (was DG4062)
Mega thanks to the developers of the key-generator ! Especially to CYBERNET with his brilliant brain !
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 572
  • Country: dk
Re: DG4000 - a firmware investigation
« Reply #171 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.
 

Offline whotopia

  • Contributor
  • Posts: 12
  • Country: ch
Re: DG4000 - a firmware investigation
« Reply #172 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.
 

Offline snipor

  • Newbie
  • Posts: 2
Re: DG4000 - a firmware investigation
« Reply #173 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
« Last Edit: January 02, 2014, 09:21:38 pm by snipor »
 

Offline roket

  • Contributor
  • Posts: 14
  • Country: ru
Re: DG4000 - a firmware investigation
« Reply #174 on: February 04, 2014, 02:20:44 am »
hi, everybody! there is at somebody file CyberNet  http://pastebin.com/ipkJCxPM   ?
 

Offline roket

  • Contributor
  • Posts: 14
  • Country: ru
Re: DG4000 - a firmware investigation
« Reply #175 on: February 04, 2014, 08:38:23 am »
I meant file tool generates - ;DG4000 cengen; from cybernet for DG4062? http://pastebin.com/ipkJCxPM
doesn't work unfortunately  my mail roket333@rambler.ru
 

Offline roket

  • Contributor
  • Posts: 14
  • Country: ru
Re: DG4000 - a firmware investigation
« Reply #176 on: February 04, 2014, 10:59:26 pm »
help!  help!  SOS!  SOS!  |O
 

Offline Orange

  • Frequent Contributor
  • **
  • Posts: 346
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #177 on: February 05, 2014, 06:18:19 pm »
I meant file tool generates - ;DG4000 cengen; from cybernet for DG4062? http://pastebin.com/ipkJCxPM
doesn't work unfortunately  my mail roket333@rambler.ru

 

Offline roket

  • Contributor
  • Posts: 14
  • Country: ru
Re: DG4000 - a firmware investigation
« Reply #178 on: February 05, 2014, 07:13:13 pm »
thanks a lot, I already received, but it is good that it will be here
 

Offline dougbert

  • Newbie
  • Posts: 8
Re: DG4000 - a firmware investigation
« Reply #179 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
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #180 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

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...
« Last Edit: February 06, 2014, 02:21:50 am by Sparky »
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
DG4000 button responsiveness
« Reply #181 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!
« Last Edit: February 06, 2014, 03:03:46 am by Sparky »
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 button responsiveness
« Reply #182 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?
 

Offline Orange

  • Frequent Contributor
  • **
  • Posts: 346
  • Country: nl
Re: DG4000 button responsiveness
« Reply #183 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 :-))
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 button responsiveness
« Reply #184 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.
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 button responsiveness
« Reply #185 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!
 

Offline Ivan7enych

  • Regular Contributor
  • *
  • Posts: 158
  • Country: ru
    • My astronomy projects
Re: DG4000 - a firmware investigation
« Reply #186 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

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.
« Last Edit: February 25, 2014, 02:27:04 pm by Ivan7enych »
 

Offline Commander_Alpha

  • Newbie
  • Posts: 1
Re: DG4000 - a firmware investigation
« Reply #187 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
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #188 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?

Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #189 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.
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #190 on: April 23, 2014, 11:05:28 am »
I did not hack my 100Mhz version (yet), so I cannot tell you.
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #191 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
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #192 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.
« Last Edit: April 24, 2014, 12:05:45 pm by ted572 »
 

Offline EV

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: fi
  • Aficionado
Re: DG4000 - a firmware investigation
« Reply #193 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.
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #194 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
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline hacker27

  • Newbie
  • Posts: 1
Re: DG4000 - a firmware investigation
« Reply #195 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.
 

Offline cybernetTopic starter

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

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #197 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.
If at first you don't succeed, get a bigger hammer
 

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #198 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?
If at first you don't succeed, get a bigger hammer
 

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #199 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.

 :-+
If at first you don't succeed, get a bigger hammer
 

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #200 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
If at first you don't succeed, get a bigger hammer
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #201 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
 

Offline TooOldForThis

  • Regular Contributor
  • *
  • Posts: 57
  • Country: us
  • H: 42.576MHz/Tesla
Re: DG4000 - a firmware investigation
« Reply #202 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.
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #203 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.
 

Offline TooOldForThis

  • Regular Contributor
  • *
  • Posts: 57
  • Country: us
  • H: 42.576MHz/Tesla
Re: DG4000 - a firmware investigation
« Reply #204 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?
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #205 on: September 13, 2014, 11:13:21 pm »
The NEW 2014 Rigol DG4000 Performance Verification Guide is attached:
 

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: DG4000 - a firmware investigation
« Reply #206 on: September 13, 2014, 11:16:37 pm »
The new Rigol 2014 DG4000 Calibration Guide is attached:
 

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #207 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.
If at first you don't succeed, get a bigger hammer
 

Offline Orange

  • Frequent Contributor
  • **
  • Posts: 346
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #208 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
 
« Last Edit: September 17, 2014, 04:59:10 pm by Orange »
 

Offline Rory

  • Frequent Contributor
  • **
  • Posts: 410
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #209 on: September 19, 2014, 02:07:47 am »
What bugs does the 1.09.00.01 firmware fix?
 

Offline rhost

  • Newbie
  • Posts: 9
Re: DG4000 - a firmware investigation
« Reply #210 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.
 

Offline MiataMuc

  • Regular Contributor
  • *
  • Posts: 52
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #211 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
 

Offline rhost

  • Newbie
  • Posts: 9
Re: DG4000 - a firmware investigation
« Reply #212 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
 

Offline dave3533

  • Contributor
  • Posts: 22
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #213 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.
 

Offline pedjasns

  • Newbie
  • Posts: 3
Re: DG4000 - a firmware investigation
« Reply #214 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?  :-\
 

Offline MiataMuc

  • Regular Contributor
  • *
  • Posts: 52
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #215 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
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #216 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.
Keyboard error: Press F1 to continue.
 

Offline MiataMuc

  • Regular Contributor
  • *
  • Posts: 52
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #217 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
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #218 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...

Keyboard error: Press F1 to continue.
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #219 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
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #220 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:
« Last Edit: November 02, 2014, 07:35:55 pm by PA0PBZ »
Keyboard error: Press F1 to continue.
 

Offline TooOldForThis

  • Regular Contributor
  • *
  • Posts: 57
  • Country: us
  • H: 42.576MHz/Tesla
Re: DG4000 - a firmware investigation
« Reply #221 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.
 

Offline EV

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: fi
  • Aficionado
Re: DG4000 - a firmware investigation
« Reply #222 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.
 

Offline MiataMuc

  • Regular Contributor
  • *
  • Posts: 52
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #223 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
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #224 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?

Keyboard error: Press F1 to continue.
 

Offline TooOldForThis

  • Regular Contributor
  • *
  • Posts: 57
  • Country: us
  • H: 42.576MHz/Tesla
Re: DG4000 - a firmware investigation
« Reply #225 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.     
 

Offline EV

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: fi
  • Aficionado
Re: DG4000 - a firmware investigation
« Reply #226 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
« Last Edit: November 04, 2014, 08:50:57 am by EV »
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #227 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?

Keyboard error: Press F1 to continue.
 

Offline EV

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: fi
  • Aficionado
Re: DG4000 - a firmware investigation
« Reply #228 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
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #229 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  ;)
Keyboard error: Press F1 to continue.
 

Offline Orange

  • Frequent Contributor
  • **
  • Posts: 346
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #230 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!
 

Offline EV

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: fi
  • Aficionado
Re: DG4000 - a firmware investigation
« Reply #231 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.
 

Offline cybernetTopic starter

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

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #233 on: November 06, 2014, 02:49:28 pm »
Click the Premium Download button... 8)
Keyboard error: Press F1 to continue.
 

Offline cybernetTopic starter

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

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #235 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 :)
Keyboard error: Press F1 to continue.
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #236 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...
Keyboard error: Press F1 to continue.
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #237 on: November 06, 2014, 08:36:42 pm »
will send once im home again, dont have those on may travel laptop  :)
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #238 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
Keyboard error: Press F1 to continue.
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #239 on: November 06, 2014, 10:36:16 pm »
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Keyboard error: Press F1 to continue.
 

Offline guarneri0

  • Contributor
  • Posts: 12
Re: DG4000 - a firmware investigation
« Reply #241 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.
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #242 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.
Keyboard error: Press F1 to continue.
 

Offline cybernetTopic starter

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: DG4000 - a firmware investigation
« Reply #243 on: November 20, 2014, 06:39:38 pm »
see pm ;) dont want to give rigol ideas
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline fact

  • Contributor
  • Posts: 35
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #244 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.
 

Offline fact

  • Contributor
  • Posts: 35
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #245 on: November 29, 2014, 09:45:03 am »
Any progress yet?
 

Offline dudarobe

  • Newbie
  • Posts: 3
Re: DG4000 - a firmware investigation
« Reply #246 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
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #247 on: December 05, 2014, 10:12:54 pm »
Hi, any one know, that dg4100 with:
Software 00.01.07.   Hardware 01.03
See  /here
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline Pasky

  • Regular Contributor
  • *
  • Posts: 149
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #248 on: December 30, 2014, 04:06:10 pm »
Hi, any progress made on this?  Thanks.
 

Offline Pasky

  • Regular Contributor
  • *
  • Posts: 149
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #249 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.
 

Offline fact

  • Contributor
  • Posts: 35
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #250 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.
 

Offline Pasky

  • Regular Contributor
  • *
  • Posts: 149
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #251 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!



« Last Edit: January 03, 2015, 06:16:08 am by Pasky »
 

Offline Pasky

  • Regular Contributor
  • *
  • Posts: 149
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #252 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:
« Last Edit: January 03, 2015, 12:36:54 am by Pasky »
 

Offline TooOldForThis

  • Regular Contributor
  • *
  • Posts: 57
  • Country: us
  • H: 42.576MHz/Tesla
Re: DG4000 - a firmware investigation
« Reply #253 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
 

Offline Pasky

  • Regular Contributor
  • *
  • Posts: 149
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #254 on: January 03, 2015, 12:41:00 am »
Thanks for that!
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #255 on: January 03, 2015, 12:45:47 am »
New firmware: 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.
« Last Edit: January 03, 2015, 07:06:17 pm by Sparky »
 

Offline TooOldForThis

  • Regular Contributor
  • *
  • Posts: 57
  • Country: us
  • H: 42.576MHz/Tesla
Re: DG4000 - a firmware investigation
« Reply #256 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.

 

Offline Rory

  • Frequent Contributor
  • **
  • Posts: 410
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #257 on: January 03, 2015, 02:50:58 am »
I just loaded 1.10.

Extended bandwidth mod still working?
 

Offline plasijo

  • Newbie
  • Posts: 3
Re: DG4000 - a firmware investigation
« Reply #258 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.
 

Offline Chainsaw_

  • Supporter
  • ****
  • Posts: 8
  • Country: gb
Re: DG4000 - a firmware investigation
« Reply #259 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?
 

Offline Chainsaw_

  • Supporter
  • ****
  • Posts: 8
  • Country: gb
Re: DG4000 - a firmware investigation
« Reply #260 on: January 04, 2015, 10:32:34 am »
where is the generator available for downloading?

Page seven, bottom post, from bandgap.
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #261 on: January 05, 2015, 01:37:55 am »
Here is an interesting comparison with $1200 unit testing
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline Rory

  • Frequent Contributor
  • **
  • Posts: 410
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #262 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. :(
 

Offline DrMag

  • Regular Contributor
  • *
  • Posts: 61
Re: DG4000 - a firmware investigation
« Reply #263 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?
 

Offline Rory

  • Frequent Contributor
  • **
  • Posts: 410
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #264 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.
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #265 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 or here.  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.
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #266 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 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
« Last Edit: January 13, 2015, 06:17:14 am by Sparky »
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #267 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
« Last Edit: January 14, 2015, 03:42:10 pm by Teneyes »
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #268 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?
« Last Edit: January 15, 2015, 07:58:16 am by Sparky »
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #269 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!
 

Offline MiataMuc

  • Regular Contributor
  • *
  • Posts: 52
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #270 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
 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 4061
  • Country: fi
  • Born in Finland with DLL21 in hand
Re: DG4000 - a firmware investigation
« Reply #271 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..)

« Last Edit: February 02, 2015, 07:57:11 pm by rf-loop »
I drive a LEC (low el. consumption) BEV car. Smoke exhaust pipes - go to museum. In Finland quite all electric power is made using nuclear, wind, solar and water.

Wises must compel the mad barbarians to stop their crimes against humanity. Where have the wises gone?
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #272 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.
 
« Last Edit: February 03, 2015, 05:56:46 pm by Teneyes »
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline dpenev

  • Regular Contributor
  • *
  • Posts: 183
Re: DG4000 - a firmware investigation
« Reply #273 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

   
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #274 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
« Last Edit: February 03, 2015, 05:53:57 pm by Teneyes »
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline dpenev

  • Regular Contributor
  • *
  • Posts: 183
Re: DG4000 - a firmware investigation
« Reply #275 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

 

Offline rf-loop

  • Super Contributor
  • ***
  • Posts: 4061
  • Country: fi
  • Born in Finland with DLL21 in hand
Re: DG4000 - a firmware investigation
« Reply #276 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".
I drive a LEC (low el. consumption) BEV car. Smoke exhaust pipes - go to museum. In Finland quite all electric power is made using nuclear, wind, solar and water.

Wises must compel the mad barbarians to stop their crimes against humanity. Where have the wises gone?
 

Online H.O

  • Frequent Contributor
  • **
  • Posts: 807
  • Country: se
Re: DG4000 - a firmware investigation
« Reply #277 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.
« Last Edit: February 04, 2015, 07:12:12 am by H.O »
 

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #278 on: February 13, 2015, 07:40:49 pm »
It seems that now there is another reason to upgrade to firmware v1.09 :(
« Last Edit: February 15, 2015, 10:03:38 pm by GonzoTheGreat »
 

Offline ytsejam

  • Contributor
  • Posts: 17
Re: DG4000 - a firmware investigation
« Reply #279 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?
 

Offline ytsejam

  • Contributor
  • Posts: 17
Re: DG4000 - a firmware investigation
« Reply #280 on: March 07, 2015, 07:16:28 pm »
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!
 

Offline fact

  • Contributor
  • Posts: 35
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #281 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?
 

Offline ytsejam

  • Contributor
  • Posts: 17
Re: DG4000 - a firmware investigation
« Reply #282 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.


 

Offline MiataMuc

  • Regular Contributor
  • *
  • Posts: 52
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #283 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?
 

Offline ytsejam

  • Contributor
  • Posts: 17
Re: DG4000 - a firmware investigation
« Reply #284 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)

 

Offline signals

  • Contributor
  • Posts: 17
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #285 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
 

Offline lunxg

  • Contributor
  • Posts: 13
Re: DG4000 - a firmware investigation
« Reply #286 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
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #287 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
« Last Edit: June 17, 2015, 06:15:23 am by Sparky »
 

Offline EV

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: fi
  • Aficionado
Re: DG4000 - a firmware investigation
« Reply #288 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

Has someone installed it? Have you any link to load these firmwares?
« Last Edit: June 17, 2015, 08:26:43 am by EV »
 

Offline lunxg

  • Contributor
  • Posts: 13
Re: DG4000 - a firmware investigation
« Reply #289 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! :)
 

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #290 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

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.
 

Offline lunxg

  • Contributor
  • Posts: 13
Re: DG4000 - a firmware investigation
« Reply #291 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   (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
 

Offline lunxg

  • Contributor
  • Posts: 13
Re: DG4000 - a firmware investigation
« Reply #292 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   (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
 

Offline EV

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: fi
  • Aficionado
Re: DG4000 - a firmware investigation
« Reply #293 on: June 17, 2015, 07:25:50 pm »
ted572

Thanks for the links!
 

Offline lunxg

  • Contributor
  • Posts: 13
Re: DG4000 - a firmware investigation
« Reply #294 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 :)
 

Offline scalargr

  • Newbie
  • Posts: 3
Re: DG4000 - a firmware investigation
« Reply #295 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
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  ;)
 

Offline neki

  • Newbie
  • Posts: 3
Re: DG4000 - a firmware investigation
« Reply #296 on: June 28, 2015, 03:24:34 pm »

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

http://pastebin.com/ipkJCxPM


This link is not working anymore. Does anybody has the file or new link?
 

Offline scalargr

  • Newbie
  • Posts: 3
Re: DG4000 - a firmware investigation
« Reply #297 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?
« Last Edit: July 09, 2015, 11:05:26 am by scalargr »
 

Offline Michael@de

  • Newbie
  • Posts: 2
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #298 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
« Last Edit: July 16, 2015, 06:19:07 pm by Michael@de »
 

Offline TheContractor

  • Newbie
  • Posts: 5
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #299 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:

  • Find the address that the version number is stored at
  • Figure out which CRC algorithm is used on the firmware upload file and update the CRC

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!
 

Offline Mahoo

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

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

Offline Gunb

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

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

Thanks!
 

Offline rramirez

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

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

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

Russ
Russ
 

Offline devpeeps

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

Offline m1ke

  • Newbie
  • Posts: 1
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #304 on: December 21, 2015, 04:04:11 pm »
Re. DG4000 cengen:  There are several of us non Unix/Linux users here on the forum that would very much appreciate a Windows or Web application to generate the required CEN file.  If someone could put one together it would be very much appreciated


---
original post removed
---

I'm editing this post to remove the link to my windows binary. Apparently it is putting extra bytes in the license file. I tried several different compilers and even tried cross-compiling for windows from my linux box. Every windows binary I make puts extra bytes into the license file. I don't have enough time to see exactly why, so I offer here an alternative solution if you only have access to windows.

1) Go to http://www.compileonline.com/compile_c_online.php
2) Replace the code in the left box with the code below.
3) Put your command line arguments in the text box at the bottom (in the form <current model> <new model> <current serial>)
4) Press "Compile and Execute" in the top left
5) Press "Download Files" in the top right (assuming everything executed properly)
6) The result tar.gz file will have the proper license.CEN file contained within it.

-Clayton



Code: [Select]
/*
** rigol DG4000 cengen / cybernet
**
** BUILD WITH:
**    gcc cengen.c -m32 -o cengen
**
** RUN WITH:
**
**    ./cengen <CURRENT_MODEL> <NEW_MODEL> <CURRENT_SERIAL> [<NEW_SERIAL>]
**
**     <?_MODEL> = DG4062, DG4102, DG4162, DG4202(*)
**     <?_SERIAL> = DG4D1XXXXXXXX
**
**    if <NEW_SERIAL> is omitted the serial will not be modified
**    (*) DG4202 is not an official model, but 200Mhz seems to work fine
**
**
** =================================================================================
** more info: https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/
** =================================================================================
**
**     ____  ______________  ___   __
**    / __ \/_  __/ ____/  |/  /  / /
**   / /_/ / / / / /_  / /|_/ /  / /
**  / _, _/ / / / __/ / /  / /  /_/
** /_/ |_| /_/ /_/   /_/  /_/  (_)
**
** this tool generates a new model type (DG4XXX) & serial (DG4D1XXXXXXXX) string,
** calculates a MAC and creates a .CEN file.
**
** what to do with the file ?
**
** put it on an USB stick, plug stick into DG4000, goto "Store", browse USB Stick,
** change "File Type" to "All File", navigate to your .CEN file, press "Read".
**
** You should get a Popup telling you that you successfully changed your model type and serial
**
** if *not* you:
**         used a wrong current model type
** used a wrong current serial
** used an invalid new model type
** used an invalid new serial
**
**
** firmware tested:
**     00.01.06
**     00.01.03
**
**
** no warranties, if it explodes, your problem ;-)
**
*/
#include<stdio.h>
#include<stdlib.h>
#include<stdint.h>
#include<string.h>
#include<ctype.h>

#define VERSION "0.1"

char     header[]="RIGOL:DG4:FIRM LICENSE FILE";
char     iv[]="1000000110000001";
char     static_cccc[4];
char static_zero[8];

// endianess shit
union helper {
 unsigned char c[8];
 unsigned int  l[2];
 uint64_t      u;
};

// shifty
void do_cbc(char a, char b, char c, char d, char e, char f, uint16_t word1, char *buffer)
{
 uint16_t bit1,bit2,bit3,bit4,u,x,y,z;
 char out;
 int la;

 if (buffer==0) return;
 u=(1<<a)-1;
 z=0;
 x=0;
 while (a > z)
 {
   x=x|(1<<z);
   z++;
 }
 y=word1&x;
 if (e==0)
 {
    la=0;
    while (u > la)
    {
*(int*)(buffer+la*2)=(int)y;
if (b==0) bit1=0;
else
{
      bit1=(y>>(b-1))&1;
}
if (c==0) bit2=0;
else
{
      bit2=(y>>(c-1))&1;
}
if (d==0) bit3=0;
else
        {
              bit3=(y>>(d-1))&1;
        }
        if (f==0) bit4=0;
else
        {
              bit4=(y>>(f-1))&1;
        }
        out=bit1^bit2;
out=out^bit3;
out=out^bit4;
y=y*2;
y=y&x;
y=y|out;
la++;
    }
 }
 else
 {
   printf("not implemented - deemed useless code ...\n");
   exit(-1);
 }
}

/*
** convert string to uppercase chars
*/
char * strtoupper(char *str)
{
  int i = 0;

   for(i = 0; str[i]; i++)
   {
      str[i] = toupper(str[i]);
   }
   return  str;
}

void ascii(void)
{
printf("\n");
printf("  ________  ____  ____ ____  ____\n");
printf(" / ___/ _ \\/ __ \\/ __ `/ _ \\/ __ \\\n");
printf("/ /__/  __/ / / / /_/ /  __/ / / /\n");
printf("\\___/\\___/_/ /_/\\__, /\\___/_/ /_/\n");
printf(" V%s          /____/  cybernet 2013\n\n", VERSION);
}

void help(void)
{
printf("\n ./cengen <CURRENT_MODEL> <NEW_MODEL> <CURRENT_SERIAL> [<NEW_SERIAL>]\n\n");
printf("    <?_MODEL> = DG4062, DG4102, DG4162, DG4202(*)\n");
printf("    <?_SERIAL> = DG4D1XXXXXXXX\n\n");
printf("  example: ./cengen DG4062 DG4202 DG4D150400123\n");
printf("  (upgrades DG4062 to DG4202, keeps serial number)\n\n");
printf("  if <NEW_SERIAL> is omitted the serial will not be modified\n");
printf("  (*) DG4202 is not an official model, but 200Mhz seems to work fine\n\n");
exit(-1);
}

char buffer_shift(int la, uint16_t *word1, char *buf)
{
int w;
int y;
int li=0;
char x=0;

while (li > la)
{
  w=*word1;
  y=*(buf+li);
  if (y!=li)
  {
    *word1=w+1;
    li=0;
    x=1;
  }
  li++;
}
return(x);
}

// dump license file
void write_file(char *nms, char *buf, uint16_t buf_len)
{
 char len[8];
 FILE *fd=NULL;

 fd=fopen("license.CEN", "w");
 if (fd==NULL)
 {
   printf("unable to open file 'license.CEN' for writing\n");
   exit(-1);
 }
 memset(static_cccc, 0xcc, 4);
 memset(static_zero, 0x0, 8);
 memset(len,0,8);
 //bzero(len,8);
 len[0]=(buf_len)&0xFF;
 len[1]=((buf_len)>>8)&0xFF;
 fwrite(header,1,strlen(header),fd);
 fwrite(len,1,4,fd);
 fwrite(static_zero,1,4,fd);
 fwrite(static_cccc,1,2,fd);
 fwrite(iv,1,strlen(iv)+1,fd);
 fwrite(nms,1,strlen(nms),fd);
 fwrite(buf,1,buf_len*2,fd);
 fclose(fd);
}

int main(int argc, char *argv[])
{
 char  secret[]="YZDHZSGCX";
 char  new_model[8];
 char  new_serial[14];
 char  *new_model_serial;
 char  cur_model[8];
 char  cur_serial[14];
 char  *cur_model_serial;
 char  *buffer20;
 char  *buffer_a2;
 char  *buffer_a4;
 int la;
 char  hbuf[3];
 char  chr;
 int   duplets,bits;
 int   r1,d1,r2,d2;
 unsigned int data1,data2;
 uint16_t word1;
 unsigned char lasthex;
 union helper uni1;
 int   key_len;
 int   prime=13;
 int   len_mts;
 int lc,lb,ld;
 int   y;
 uint16_t   w;


 ascii();
 if (argc>=4)
 {
   strcpy(cur_serial, strtoupper(argv[3]));
   strcpy(new_model, strtoupper(argv[2]));
   strcpy(cur_model, strtoupper(argv[1]));

   if (strlen(cur_model)!=6) { printf("invalid <CURRENT_MODEL> len\n"); help(); }
   if (strlen(new_model)!=6) { printf("invalid <NEW_MODEL> len\n"); help(); }
   if (strlen(cur_serial)!=13) { printf("invalid <CURRENT_SERIAL> len\n"); help();  }
   if (strncmp(cur_model,"DG4", strlen("DG4"))) { printf("invalid <CURRENT_MODEL> type\n"); help(); }
   if (strncmp(new_model,"DG4", strlen("DG4"))) { printf("invalid <NEW_MODEL> type\n"); help(); }
   if (strncmp(cur_serial,"DG4", strlen("DG4"))) { printf("invalid <CURRENT_SERIAL> type\n"); help(); }
   if (argc==5)
   {
     strcpy(new_serial, strtoupper(argv[4]));
     if (strlen(new_serial)!=13) { printf("invalid <NEW_SERIAL> len\n"); help(); }
     if (strncmp(new_serial,"DG4", strlen("DG4"))) { printf("invalid <NEW_SERIAL> type\n"); help(); }
     strcpy(new_serial, strtoupper(argv[4]));
   }
   else strcpy(new_serial, strtoupper(argv[3]));
 }
 else help();

 cur_model_serial=(char*)calloc(1, strlen(cur_model)+strlen(cur_serial)+1);
 new_model_serial=(char*)calloc(1, strlen(new_model)+strlen(new_serial)+1);
 strcpy(new_model_serial, new_model);
 strcat(new_model_serial, new_serial);
 strcpy(cur_model_serial, cur_model);
 strcat(cur_model_serial, cur_serial);
 printf("\nCurrent settings:\n");
 printf("\tModel:\t\t%s\n",cur_model);
 printf("\tSerial#:\t%s\n",cur_serial);
 printf("\nNew settings:\n");
 printf("\tModel:\t\t%s\n",new_model);
 printf("\tSerial#:\t%s\n\n",new_serial);
 buffer20=(char*)calloc(1,20);
 buffer_a2=(char*)calloc(4,8192);
 buffer_a4=(char*)calloc(4,8192);
 memset(buffer_a4,0xAA,8192);
 key_len=strlen(secret);
 la=0;
 duplets=0;
 y=0;
 hbuf[2]=0;
 while(la < strlen(iv))
 {
   hbuf[0]=iv[la];
   hbuf[1]=iv[la+1];
   uni1.c[duplets]=strtol(hbuf,NULL,0x10);
   duplets++;
   la=la+2;
 }
 data1=uni1.l[0];
 data2=uni1.l[1];
 bits=duplets<<3;
 r1=bits%prime;
 d1=bits/prime;
 if (r1 != 0) d1++;
 lasthex=uni1.c[duplets-1];
 d2=64/prime;
 r2=64%prime;
 la=0;
 while (d1>la)
 {
    if (d2>0)
    {
word1=data1&0x1fff;
       uni1.u=uni1.u>>prime;
data1=uni1.l[0];
       data2=uni1.l[1];
d2--;
    }
    else
    {
word1=(int)(((int)data1)|(lasthex<<r2))&0xffff;
    }
    buffer_shift(la,&word1,buffer20);
    *(int*)(buffer20+la*2)=(int)word1;
    do_cbc(0xd, 0x1, 0x3, 0x4, 0x0, 0xd, word1, buffer_a2);
    len_mts=strlen(new_model_serial);
    ld=lb=lc=0;
    while (len_mts > lc)
    {
chr=cur_model_serial[lc];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
       *(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
if (lb > (key_len-1)) lb=0;

       chr=secret[lb];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
y++;
chr=secret[lb]^cur_model_serial[lc];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
       *(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
       y++;
       if (ld > (len_mts-1)) ld=0;

chr=new_model_serial[ld];
w=*(uint16_t*)(buffer_a2+chr*2)&0xffff;
*(uint16_t*)(buffer_a4+y*2)=(uint16_t)w;
       y++;

lc++;
lb++;
ld++;
    }
    la++;
 }
 w=*(uint16_t*)(buffer_a4)&0xffff;
 w=w&0xfffc;
 *(uint16_t*)(buffer_a4)=(uint16_t)w;
 *(uint16_t*)(buffer_a4)=2|(uint16_t)w;
 w=*(uint16_t*)(buffer_a4+0x14)&0xffff;
 *(uint16_t*)(buffer_a4+0x14)=2|(uint16_t)w&0xfff8;
 write_file(new_model_serial, buffer_a4, y);
 printf("license file dumped into: 'license.CEN' - have fun !\n\n");
 exit(0);
}

Hi  I can't get this to compile.....keeps giving errors..... can someone please help
 

Offline dr.diesel

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

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

Offline Sparky

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

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

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

 

Offline malekia

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

A) I will NOT be able to apply a hack

B) I WILL be able to apply a hack

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

Offline TurboTom

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

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

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

Cheers,
Thomas
 

Offline Altemir

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

What I and other guys doing wrong?

Online H.O

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

Offline Altemir

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

Offline megafix

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

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

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

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

Offline megafix

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

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

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


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

Offline Gandalf_Sr

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

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

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

Offline RoGeorge

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

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

Offline Gandalf_Sr

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

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

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

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

Offline Andrusca

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

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

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

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

Many thanks
Andrés
   
 
 

Offline nrxnrx

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

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

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

Offline Andrusca

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

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

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

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

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

Offline tkarlmann

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

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

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

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

Offline thlee

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

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

Offline Gandalf_Sr

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

Offline TurboTom

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

Cheers,
Thomas
 

Offline TurboTom

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

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

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

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

Cheers,
Thomas
 

Offline Netsniper

  • Newbie
  • Posts: 3
Re: DG4000 - a firmware investigation
« Reply #325 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
« Last Edit: August 08, 2018, 09:54:05 am by Netsniper »
 
The following users thanked this post: thm_w, GonzoTheGreat

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #326 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, 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!
« Last Edit: August 06, 2018, 07:48:59 pm by Sparky »
 

Offline bgm370

  • Contributor
  • Posts: 14
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #327 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.
 

Offline TheNewLab

  • Frequent Contributor
  • **
  • Posts: 290
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #328 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?
 

Offline gts1991

  • Newbie
  • Posts: 2
Re: DG4000 - a firmware investigation
« Reply #329 on: December 14, 2018, 07:34:00 pm »
Can you release DG4062 versions?
Without opening the housing

Thank you
 

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #330 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 ?
 

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #331 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
 

Offline Vahoo

  • Newbie
  • Posts: 8
  • Country: am
Re: DG4000 - a firmware investigation
« Reply #332 on: January 28, 2019, 02:32:40 pm »
Hi dear GonzoTheGreat, send  please link  v1.14, thanks! vahagnhak@yahoo.com
« Last Edit: January 28, 2019, 02:34:28 pm by Vahoo »
 

Offline Netsniper

  • Newbie
  • Posts: 3
Re: DG4000 - a firmware investigation
« Reply #333 on: January 28, 2019, 03:23:22 pm »
Please find the link to the 1.14 FW : https://we.tl/t-68FtwLMVMK
 

Offline Vahoo

  • Newbie
  • Posts: 8
  • Country: am
Re: DG4000 - a firmware investigation
« Reply #334 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!
 

Offline TooOldForThis

  • Regular Contributor
  • *
  • Posts: 57
  • Country: us
  • H: 42.576MHz/Tesla
Re: DG4000 - a firmware investigation
« Reply #335 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.
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #336 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?

Offline kado

  • Regular Contributor
  • *
  • Posts: 51
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #337 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
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #338 on: February 01, 2019, 11:56:59 am »
I have these (including FW1.12):  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?
 
The following users thanked this post: kado

Offline kado

  • Regular Contributor
  • *
  • Posts: 51
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #339 on: February 01, 2019, 03:18:08 pm »
Thanks to PeDre and RoGeorge for the FW Links !

Karsten
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #340 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?

Offline Sparky

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #341 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 and subsequent posts by ted.  I think you'll find the information you need.
 
The following users thanked this post: RoGeorge

Offline TooOldForThis

  • Regular Contributor
  • *
  • Posts: 57
  • Country: us
  • H: 42.576MHz/Tesla
Re: DG4000 - a firmware investigation
« Reply #342 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.
 
The following users thanked this post: RoGeorge

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #343 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 ?
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #344 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?
 

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #345 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.

« Last Edit: February 13, 2019, 05:35:26 pm by GonzoTheGreat »
 

Offline smithnerd

  • Regular Contributor
  • *
  • Posts: 120
  • Country: gb
Re: DG4000 - a firmware investigation
« Reply #346 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.
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #347 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.eevblog.com/forum/testgear/rigol-dg4062-functionarbitary-waveform-generator-teardown/

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #348 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 :(
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #349 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.
 

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #350 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.
« Last Edit: February 13, 2019, 07:10:42 pm by GonzoTheGreat »
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #351 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.

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #352 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!
 

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #353 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?
« Last Edit: February 13, 2019, 07:45:12 pm by GonzoTheGreat »
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #354 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?
« Last Edit: November 16, 2019, 09:32:48 am by tv84 »
 

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #355 on: November 16, 2019, 09:30:42 am »
Wow, cool picture!  It must be associated with some sort of Easter egg.
If at first you don't succeed, get a bigger hammer
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #356 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.   :)

Offline TurboTom

  • Super Contributor
  • ***
  • Posts: 1388
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #357 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
« Last Edit: December 04, 2019, 04:56:30 pm by TurboTom »
 

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #358 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?
If at first you don't succeed, get a bigger hammer
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #359 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...
 
The following users thanked this post: Gandalf_Sr

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #360 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...   ;)
« Last Edit: December 14, 2019, 06:03:53 pm by tv84 »
 

Offline TurboTom

  • Super Contributor
  • ***
  • Posts: 1388
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #361 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.  :--
 
The following users thanked this post: ted572

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #362 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?
 
The following users thanked this post: mahi

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #363 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.
 
The following users thanked this post: PA0PBZ, ted572, ralphrmartin, MiataMuc, TurboTom, ytsejam, RoGeorge, mahi, eplpwr, nive, Mark Krass

Offline TurboTom

  • Super Contributor
  • ***
  • Posts: 1388
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #364 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  :-+
« Last Edit: December 14, 2019, 09:14:00 pm by TurboTom »
 
The following users thanked this post: ted572, RoGeorge

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #365 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?
Keyboard error: Press F1 to continue.
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #366 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
 
The following users thanked this post: ted572, RoGeorge

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #367 on: December 14, 2019, 11:03:27 pm »
tv84, 1 000 000 THANK YOU!!!



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
--------------------------
« Last Edit: December 15, 2019, 12:09:12 am by RoGeorge »
 
The following users thanked this post: ted572, ytsejam

Offline zitt

  • Regular Contributor
  • *
  • Posts: 113
  • Country: us
    • Pinball-Mods.com
Re: DG4000 - a firmware investigation
« Reply #368 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).
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #369 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.
 

Offline zitt

  • Regular Contributor
  • *
  • Posts: 113
  • Country: us
    • Pinball-Mods.com
Re: DG4000 - a firmware investigation
« Reply #370 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?
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #371 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.

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: DG4000 - a firmware investigation
« Reply #372 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.

IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 
The following users thanked this post: egonotto

Offline zitt

  • Regular Contributor
  • *
  • Posts: 113
  • Country: us
    • Pinball-Mods.com
Re: DG4000 - a firmware investigation
« Reply #373 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.
 

Offline TurboTom

  • Super Contributor
  • ***
  • Posts: 1388
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #374 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.
« Last Edit: December 21, 2019, 12:10:17 pm by TurboTom »
 

Offline thlee

  • Contributor
  • Posts: 10
  • Country: hk
Re: DG4000 - a firmware investigation
« Reply #375 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  :-+.
 

Offline Vahoo

  • Newbie
  • Posts: 8
  • Country: am
Re: DG4000 - a firmware investigation
« Reply #376 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.
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #377 on: December 28, 2019, 08:17:51 pm »
When you generated the license.GEN, what command line did you use on the PC?

Offline mahi

  • Regular Contributor
  • *
  • Posts: 85
  • Country: 00
Re: DG4000 - a firmware investigation
« Reply #378 on: December 29, 2019, 01:31:04 pm »
Thank you tv84! Another DG4062 upgraded to 200 MHz :)

Offline Vahoo

  • Newbie
  • Posts: 8
  • Country: am
Re: DG4000 - a firmware investigation
« Reply #379 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?
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #380 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.
 
The following users thanked this post: EV

Offline Vahoo

  • Newbie
  • Posts: 8
  • Country: am
Re: DG4000 - a firmware investigation
« Reply #381 on: December 29, 2019, 05:18:49 pm »
I and do, I should change the regional languagе?
 

Offline Vahoo

  • Newbie
  • Posts: 8
  • Country: am
Re: DG4000 - a firmware investigation
« Reply #382 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!
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #383 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.

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #384 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

Keyboard error: Press F1 to continue.
 
The following users thanked this post: EV, Mark Krass

Offline Vahoo

  • Newbie
  • Posts: 8
  • Country: am
Re: DG4000 - a firmware investigation
« Reply #385 on: December 29, 2019, 06:13:22 pm »
Thank you very much, I got everything.  :-+  :-+  :-+
 

Offline zitt

  • Regular Contributor
  • *
  • Posts: 113
  • Country: us
    • Pinball-Mods.com
Re: DG4000 - a firmware investigation
« Reply #386 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?
« Last Edit: January 01, 2020, 01:24:24 am by zitt »
 

Offline EV

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: fi
  • Aficionado
Re: DG4000 - a firmware investigation
« Reply #387 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?
 

Offline stuartmp

  • Contributor
  • Posts: 27
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #388 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
 

Offline stuartmp

  • Contributor
  • Posts: 27
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #389 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
 

Offline stuartmp

  • Contributor
  • Posts: 27
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #390 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?


 

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #391 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.
If at first you don't succeed, get a bigger hammer
 

Offline stuartmp

  • Contributor
  • Posts: 27
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #392 on: February 13, 2020, 10:03:23 am »
I waited 7 minutes and not one of the waveform lights had come on.
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #393 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.
 

Offline scalargr

  • Newbie
  • Posts: 3
Re: DG4000 - a firmware investigation
« Reply #394 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!!! :)

« Last Edit: March 31, 2020, 07:55:05 am by scalargr »
 
The following users thanked this post: MiataMuc

Offline bartver

  • Contributor
  • Posts: 24
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #395 on: April 15, 2020, 05:56:42 pm »
tnx... got mine with 1.09 and had to wait for it..
Thank you TV84 !!
Bart
 

Offline sbvr4

  • Contributor
  • Posts: 28
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #396 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
 

Offline TurboTom

  • Super Contributor
  • ***
  • Posts: 1388
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #397 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.
 
The following users thanked this post: sbvr4

Offline sbvr4

  • Contributor
  • Posts: 28
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #398 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
 

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #399 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.
« Last Edit: June 10, 2020, 06:43:36 pm by Gandalf_Sr »
If at first you don't succeed, get a bigger hammer
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #400 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?
Keyboard error: Press F1 to continue.
 

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #401 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?
If at first you don't succeed, get a bigger hammer
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #402 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.
« Last Edit: June 10, 2020, 07:53:23 pm by tv84 »
 
The following users thanked this post: Gandalf_Sr, GonzoTheGreat

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #403 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.
 
The following users thanked this post: Gandalf_Sr

Offline Gandalf_Sr

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #404 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.
If at first you don't succeed, get a bigger hammer
 
The following users thanked this post: PA0PBZ

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #405 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?
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #406 on: August 04, 2020, 04:23:32 pm »
FAT, FAT16 or FAT32 should work.

Format it with a linux machine.
 

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #407 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...
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #408 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.
 

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #409 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).
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #410 on: August 04, 2020, 05:13:09 pm »
 :-DD  How do you get all that stuff in Antarctica??
 
The following users thanked this post: PA0PBZ, 4cx10000

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #411 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.

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #412 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).
« Last Edit: August 05, 2020, 08:34:39 am by GonzoTheGreat »
 

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #413 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.
 

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #414 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.
 

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #415 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?
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #416 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

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: DG4000 - a firmware investigation
« Reply #417 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 that it is OK to use FAT16 and "PeDre" has posted his file system structure here, which contained FAT16.  I just cloned it.
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #418 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.
 

Offline noreply

  • Frequent Contributor
  • **
  • Posts: 276
  • Country: gb
Re: DG4000 - a firmware investigation
« Reply #419 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.

 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #420 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.

 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #421 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

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #422 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.  :-+
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #423 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:
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #424 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
 :-//

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.


Offline Wim13

  • Regular Contributor
  • *
  • Posts: 241
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #425 on: October 25, 2020, 10:23:48 am »
I upgraded my DG4102 from fw 1.08 to fw 1.14, but the upgrade was different from the attached upgrade document.

I had, fw 1.08 and bootloader 0.4,
(for new readers, the bootloader version is on the system info page, under keyboard version !?!?)

First i had to find a working USB stick i have several, a 256Mb did not work a 2 GB older type did work with FAT32.

I tried to change fw first without loading a new bootloader, to see waht happens,(nothing)
sometimes it did nothing and utility and store button stay on.
and sometimes all kind of buttons began to flikker, nice, but nothing worse happens.
Later i discovered that it had to do someting with the setting save last powerOn.

So i updated the bootloader, the file is only 166Kb, it took several minutes of flikkering utility button,
then suddenly the waveform buttons went on, and in a second later the unit rebooted by it self, but ..
no changes in the system info menu ??

So i turned the unit off and on again,...black screen !??, nothing, rebooted again
still nothing, then i noticed that the mod, utility and store button were on again.....

Loooks it was waiting for something, and could not load fw 1.08 with the new bootloader !!
Then i put the USB stick with the fw 1.14 in the unit and watched wath would happen.

The utitlity button began to flikker for lots of minutes...not much activity on the stick..
and then suddenly the ramp button light up, and the flikkering of utility stoped.

Well, slowly all waveform buttons lights went on....and finally it rebooted by it self,
and a happy end, all worked oke.

So the attached file is not correct, in my case, between loading bootloader and fw.









 

 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: gb
    • Me
Re: DG4000 - a firmware investigation
« Reply #426 on: October 26, 2020, 11:58:35 am »
Thank you for everyone's efforts on this thread, especially TV84. Having now gone through the steps here on my DG4062, and performed calibration as explained, on doing a sweep from 1MHz to 200MHz, I'm getting output which jumps up and down by about 5dB from 1MHz to about 30 MHz, is then flat ± 0.5dB to about 100MHz, then falls of pretty much linearly to about 4dB down at 200MHz.
Worse, for some combinations of voltage and frequency (e.g. 10MHz 200mV, 400mV) I get no output at all.

Have I missed something? Any suggestions for how to fix at least the issues up to 30MHz?
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: gb
    • Me
Re: DG4000 - a firmware investigation
« Reply #427 on: October 26, 2020, 01:28:31 pm »
Here's a plot of the output versus frequency
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #428 on: October 26, 2020, 04:51:05 pm »
This is the output of my liberated DG4062, I did not touch the calibration.
1dB down at about 160MHz and almost 3dB at 200MHz.
Keyboard error: Press F1 to continue.
 
The following users thanked this post: ralphrmartin

Offline TurboTom

  • Super Contributor
  • ***
  • Posts: 1388
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #429 on: October 26, 2020, 07:15:53 pm »
I guess I got lucky with mine... It started live as a DG4102.  >:D

 

Offline bgm370

  • Contributor
  • Posts: 14
  • Country: us
Re: DG4000 - a firmware investigation
« Reply #430 on: October 26, 2020, 07:35:23 pm »
I had the same calibration problem with my 4062 “enhanced” to a 4202 a while ago. Both 1.12 and 1.14 were not calibrating properly. I downgraded to 1.08 (it might have been an even earlier fw version) and it calibrated just fine. Then I upgraded it back to 1.14 and the proper calibration was preserved.
 
The following users thanked this post: ralphrmartin, nive

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: gb
    • Me
Re: DG4000 - a firmware investigation
« Reply #431 on: October 26, 2020, 09:04:59 pm »
BGM, your suggestion certainly helped, although there's still something not quite right.
I now get a more-or-less flattish trace out to 100 MHz, and while I dont get so many weird jumps up and down now below 30MHz, I still get one jump down of about 0.8dB at 12 MHz or so.
There is then a linear-ish ramp down from about 100MHz to 200MHz, dropping a further 5dB.

I'm not too worried about the latter - perhaps the device just has some default values for this frequency range which wouldn't have needed factory calibration anyway.

However, the step at 12 MHz is rather more puzzling as I would have thought that would have been calibrated out.

On the other hand, the device is 7 or 8 years old now, so perhaps it has just drifted away from the original calibration.

PA0PBZ, I see if you look carefully, your plot also seems to show a bit of a drop at around 12MHz.

Perhaps I'll try to run through the full calibration procedure - but for both channels that seems to involve taking perhaps 300 power and voltage readings, and typing them in, which will be no fun when the DG's keyboard suffers from key bounce.

Thanks again for all the help.
« Last Edit: October 26, 2020, 09:06:46 pm by ralphrmartin »
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: gb
    • Me
Re: DG4000 - a firmware investigation
« Reply #432 on: October 27, 2020, 03:45:32 pm »
Well, having gone back to 4.08, done the calibration with defaults, and got a not too bad trace, and come back to 4.12, I then spent a morning doing a proper calibration (with multimeter and spectrum analyzer). The net result is back to like that shown in my original sweep: several serious jumps of a few dB up to about 12MHz, flat-ish out to about 100MHz, and then a linear-ish slope losing 4dB by 200MHz. Where it's flat and linear are probably flatter and more linear than before - but the large artefacts, and slope, still exist.

I suspect the slope might be due to different circuitry in the (newer?) higher frequency models.

However, if I do a sweep not from 1Mhz to 200MHz, but from 1MHz to 12MHz, all the jumps go away. So, they are not a calibration issue, but some sort of artefact produced by the sweep function,. Different ranges of sweeps make jumps in different places. Ugly.
« Last Edit: October 27, 2020, 03:49:00 pm by ralphrmartin »
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #433 on: October 27, 2020, 03:56:10 pm »
Let's call it a 30-100MHz model...
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: gb
    • Me
Re: DG4000 - a firmware investigation
« Reply #434 on: October 27, 2020, 04:37:48 pm »
Haha. Gained 40Mhz, lost 30Mhz, for an overall win by 10Mhz!  :-DD

But even stranger - if I set everything back to the factory calibration - all of the jumps disappear....
This sounds to me awfully like there's a "differencing two big numbers to get a small number" kind of problem somewhere in there.

So I now have a 0 MHz to 110MHz model ...  ;D
So apart from wasting a morning on a useless calibration,  I'm definitely winning!
And as long as I only want a narrow band at even higher frequencies, that's good too, as long as I check the exact output level separately.


 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #435 on: October 27, 2020, 04:51:33 pm »
I see no reason why it should jump like that.  Maybe the calibration instruments are not calibrated, or maybe the measuring setup has something wrong in it, maybe a cable is faulty, IDK, but my unlocked DG4102 doesn't show any amplitude jumps in the first 30MHz or so (also never touched its calibration - I suspect the altered calibration might be the most probable cause for seeing jumps).

Does the amplitudes and frequencies of the jumps preserve when a narrower frequency sweep is performed?

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: gb
    • Me
Re: DG4000 - a firmware investigation
« Reply #436 on: October 27, 2020, 05:37:21 pm »
It's the voltage settings (not RF power settings) which caused the jumps, and that was done with a 6.5 digit Agilent meter I've no reason to suspect to be out of spec. BNC coax lead to a BNC-banana plug splitter. Same coax lead to BNC-to-N adapter for spectrum analyzer. No problems with these leads etc in other work.

I've tried calibrating twice now, and both times ended up with jumps, once before going back to firmware 08 and redoing things there, and once after coming back to the latest fw.

Note that my machine doesn't show any jumps if you reset to the factory calibration.

Maybe the calibration procedure itself has some issues. It would be interesting to know if anyone has successfully recalibrated their DG4000 with the procedure given, with the current fw.
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #437 on: October 27, 2020, 05:51:39 pm »
Does the same Agilent voltmeter shows the generated voltage (after calibration) as correct (constant) when tested at various fixed frequencies?  If not, then the calibration procedure went wrong.  If yes, then it's either the voltmeter or the spectrum analyzer.

Voltage jumps of 3 or 6 dB should be easy to spot on any instrument.  Does the jumps show on other instruments, too, e.g. an oscilloscope or some other less precise voltmeter?
 
The following users thanked this post: ralphrmartin

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • Country: gb
    • Me
Re: DG4000 - a firmware investigation
« Reply #438 on: October 27, 2020, 06:43:01 pm »
Thanks for your comment, RoGeorge.

Does the same Agilent voltmeter shows the generated voltage (after calibration) as correct (constant) when tested at various fixed frequencies? If not, then the calibration procedure went wrong.

True (as long as I use frequencies within the meter's AC range), but that doesn't tell us where it went wrong:
- voltmeter not working correctly (e.g. giving inconsistent readings at different frequencies)
- I misapplied the calibration procedure (failed to write some values, entered incorrect values by mistyping for example)
- there's a bug in the user calibration procedure code e.g. it
-- tries to measure voltages at frequencies outside the DMMs capabilities
-- does something wrong with the entered values (stores them in the wrong place, wrong format, etc)

If yes, then it's either the voltmeter or the spectrum analyzer.

Not necessarily. The software in the DG4000 in general, and the sweep function in particular, may make some assumptions about the calibration. It is certainly doing something strange when sweeping, as the jumps may or may not be present depending on exactly what frequency range you sweep. Intuitively, miscalibration should always lead to the same voltage at the same frequency, just the wrong voltage, and that is not happens. The voltage you get at a particular frequency depends on the frequency range of the sweep.

Unfortunately, because of the jumps, I reset it to the factory calibration (which doesn't have them), so I have now way of telling which of these possibilities it is, without wasting another 1/2 day to redo the calibration. Note that lack of jumps observed with the factory calibration indicates that the jumps are real in my calibration (you said to see if they exist using a different instrument).

Furthermore, the factory calibration does give readings on the voltmeter (using the same leads) from 1kHz to 100kHz (in steps of 1kHz) which are within 0.2% or better of the stated output of the DG4000, so I have no reason to think the voltmeter is playing up.

Perhaps the software makes some assumptions about the entered calibration values, and if the calibration values entered are too far from the expected ones, it breaks these assumptions
« Last Edit: October 27, 2020, 06:49:30 pm by ralphrmartin »
 

Offline ZETOR1

  • Newbie
  • Posts: 1
  • Country: pl
Re: DG4000 - a firmware investigation
« Reply #439 on: January 04, 2021, 04:35:44 pm »
Hello. I have dg4062 software version: 00.01.01. I want to update to 00.01.06. Where I can find 01.01.06. or 00.01.07?
 

Offline nive

  • Newbie
  • Posts: 9
  • Country: nl
  • if nothing goes right, go left :-)
Re: DG4000 - a firmware investigation
« Reply #440 on: April 23, 2021, 06:20:10 pm »
does someone sees this strange little peak on about 79.719 khz in a Sinus sweep from 1 hz til 100 hz kHz (0 dBM output) signal?
« Last Edit: April 25, 2021, 11:19:45 am by nive »
 

Offline nive

  • Newbie
  • Posts: 9
  • Country: nl
  • if nothing goes right, go left :-)
Re: DG4000 - a firmware investigation
« Reply #441 on: April 25, 2021, 01:05:00 pm »
i found out that it was a spurious signal inside my Siglent SA.  :palm:
 

Offline nive

  • Newbie
  • Posts: 9
  • Country: nl
  • if nothing goes right, go left :-)
Re: DG4000 - a firmware investigation
« Reply #442 on: April 25, 2021, 07:03:58 pm »
I confirm that the calibration on firmware 00.01.14 not works when you has updated your frequency with a license key in firmware 00.01.08.

Work around for me was going back to firmware 00.01.08 (with licence key installed), then applying a calibration for LFLAT en HFLAT. After saving this calibration and updating again to firmware 00.01.14 the DG4202 is flat within a 0,5 dBm.
 
The following users thanked this post: 4cx10000, RoGeorge

Offline Yeson

  • Newbie
  • Posts: 6
  • Country: cn
Re: DG4000 - a firmware investigation
« Reply #443 on: July 23, 2022, 09:15:30 am »
I hack the DG4062 to DG4202.The Amplitude is lower more than -4dbm from 60Mhz to 200Mhz. I havn't a power meter to do the calibration.  I record the factory default value. Can I edit some calpiont value of High Freq Flat to make the Amp more flatter.
 

Offline Yeson

  • Newbie
  • Posts: 6
  • Country: cn
Re: DG4000 - a firmware investigation
« Reply #444 on: July 27, 2022, 03:31:03 am »
How do you calibration? Need Powermeter?
 

Offline TurboTom

  • Super Contributor
  • ***
  • Posts: 1388
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #445 on: July 27, 2022, 08:23:37 am »
How do you calibration? Need Powermeter?

Rigol clearly specifies in their calibration guide (attched) the required instruments. For high frequency flatness, a power meter is required, and I don't see much chance for a replacement if you need the amplitude accuracy.

A spectrum analyzer may be a makeshift solution to get rid of the major errors you observe, but you'll rarely get better accuracy than +-1dB. Moreover, using an SA requires interconnection cables and probably adapters that all need to be of prime quality, and the input impedance of the SA may also not be accurate enough (though in the relevant frequency range, that's probably no real problem).

I got lucky with my DG4102 since apparently it's been calibrated all the way up to 200MHz in the factory already.


 

Offline Yeson

  • Newbie
  • Posts: 6
  • Country: cn
Re: DG4000 - a firmware investigation
« Reply #446 on: July 28, 2022, 01:44:45 am »
From 20Mhz to 200Mhz。
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5121
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #447 on: July 28, 2022, 10:05:55 am »
My 'upgraded' DG4062, trace max hold. Not sure about the few peaks, maybe interference. I did not touch the calibration at all.

Keyboard error: Press F1 to continue.
 

Offline TurboTom

  • Super Contributor
  • ***
  • Posts: 1388
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #448 on: July 28, 2022, 08:48:45 pm »
And here's my DG4000's channel 1 that started life as a DG4102 at three signal levels. Ch2 performs equally well.
 

Offline Kujo

  • Newbie
  • Posts: 5
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #449 on: April 13, 2023, 04:47:33 am »
Thanks to all for their efforts and patience on this topic.

So noting that this thread has been quiet for some time i just wanted to add some USB drive combinations that ended up working out for me.

I initially tried SanDisk Cruzer 16GB usb 2.0 drives. They were recognised by the device in normal operation but would not load a new firmware file. I noticed that someone mentioned that they had used a microSD adapter. Now also remembering that someone else had mentioned that they felt the USB controller implementation at boot was maybe a bit off i grabbed the dodgy microSD adapted that came with my Ender 3D printer. I dropped a 16GB Strontium Nitro sd card (came with a phone i think) formatted to FAT32 with default allocation size and lo and behold. It worked a treat. Interestingly (well to me anyway) when updating the license file i used the original Cruzer stick and that worked fine. So this seems to support the fact that the USB implementation at boot is different from that once up and running. Anyway in case this is helpful to anyone in the future.

Kujo
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #450 on: November 04, 2023, 05:35:26 pm »
I just got an accurate 10MHz source (Leo Bodnar, Mini) and I thought about calibrating the freq of my DG4102  (not hacked, yet, FW1.07 HW1.01)

In the manual they mention:
Quote
Warm DG4000 up for at least 30 minutes. Press Utility Test/Cal
Secure Code, use the knob and direction keys to enter the correct password, press
Secure and the calibration safety protection turns off.

Do we know what this secure code is? (I didn't find it in this thread?)

The internal frequency is only off  by 1.2Hz too low though.
« Last Edit: November 04, 2023, 05:42:09 pm by KedasProbe »
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline Orange

  • Frequent Contributor
  • **
  • Posts: 346
  • Country: nl
Re: DG4000 - a firmware investigation
« Reply #451 on: November 04, 2023, 05:56:57 pm »
I just got an accurate 10MHz source (Leo Bodnar, Mini) and I thought about calibrating the freq of my DG4102  (not hacked, yet, FW1.07 HW1.01)

In the manual they mention:
Quote
Warm DG4000 up for at least 30 minutes. Press Utility Test/Cal
Secure Code, use the knob and direction keys to enter the correct password, press
Secure and the calibration safety protection turns off.

Do we know what this secure code is? (I didn't find it in this thread?)

The internal frequency is only off  by 1.2Hz too low though.

Secure code is 2010 - this will enable the Test/Cal Submenu on the DG4062/FW 00.01.04
 
The following users thanked this post: KedasProbe, RoGeorge

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #452 on: November 05, 2023, 12:55:25 pm »
I got access to the calibration menu and tried to update the frequency but something isn't right.
When I press the up or down button it adds a lot of jitter so I didn't press save.
Pressing the other button doesn't restore it to what is was. (1 up + 1 down should have changed nothing)

It stayed in this bad situation until I power cycled,  I didn't press save.

I'm just going to keep my 10Mhz attached to it.
I only find it annoying that it changes the 10Mhz ref input to output without asking my OK, if it doesn't see a signal.
It would be ok if it also switch back to external when it sees a signal. (power on delay)
So it's very easy to end up with two signal outputs connected and not be aware of it. (not good for my reference output)
(I used my DHO914S Gen to see what it did since I didn't want to risk my 10Mhz ref)

Yellow is my stable reference, triggered on blue = Out CH1 of DG4102
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #453 on: November 11, 2023, 06:39:34 pm »
Anyone know where I can find the odler firmwares for the DG4000?

I need an older one to be able to upgrade starting from 1.07
On the Rigol website they say contact Rigol in case of an older firmware but they just ignore my email.

I understand that I need to upgrade the bootloader first before I can update to the latest versions.
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #454 on: November 11, 2023, 06:56:36 pm »

Offline Darkover

  • Contributor
  • Posts: 23
  • Country: de
Re: DG4000 - a firmware investigation
« Reply #455 on: November 12, 2023, 05:35:35 am »

I have V1.04, V1.06, V1.07, V1.08, V1.09, V1.10, V1.12.
Give me your mail and I can send it to you.

Olaf
 
The following users thanked this post: KedasProbe

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #456 on: November 12, 2023, 10:48:37 am »
I didn't try the hacked version, I prefer to stay official for now, I see I can always do it later if needed.

It has the advantage if something is wrong I can blame Rigol instead of myself ;D
« Last Edit: November 12, 2023, 12:11:25 pm by KedasProbe »
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #457 on: November 12, 2023, 11:40:37 am »
AFAIK, firmware downgrades are not possible when using original Rigol firmware.

You must use the hacked .GEL attached by TV84 in order to downgrade from your current version, then run the 'cengen' on a Windows machine.  Once the instrument is unlocked (the *IDN? name and the model reported by your AWG will become DG4202), the instrument will remain as DG4202 for any further firmware updates.  Then, update the instrument to the latest firmware from Rigol.

Read a few posts before and after the TV84 post linked above, for the exact instructions.  The hacked .GEL is inside that 'DG4000 ... .zip' file attached by TV84 at the end in that post.
« Last Edit: November 12, 2023, 11:44:51 am by RoGeorge »
 

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #458 on: November 12, 2023, 12:12:04 pm »
But I need boot loader version 6 first anyway, not included in the zip file. (currently I have v4, firmware 1.07)
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 6145
  • Country: ro
Re: DG4000 - a firmware investigation
« Reply #459 on: November 12, 2023, 12:22:29 pm »
1. Did you run 'cengen' on yor computer already?  Did you manually input the generated licenses in your instrument (input the generated numbers only, no hack on the instrument is needed for now)?  What message do you get?

2.  What versions do you have now inside the instrument?


-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

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #460 on: November 12, 2023, 01:17:20 pm »
Bootloader 00.06.02 attached.
 
The following users thanked this post: KedasProbe

Offline KedasProbe

  • Frequent Contributor
  • **
  • Posts: 646
  • Country: be
Re: DG4000 - a firmware investigation
« Reply #461 on: November 14, 2023, 06:53:47 pm »
I haven't updated it yet, I got this answer from Rigol:
Quote
Generally speaking, we do not recommend the upgrade of the DG4000 firmware with series before 00.01.08.002 or the keyboard version before 05.01.
After upgrading the DG4000 using the bootloader program, the calibration data will be cleared, and the unit needs to be recalibrated. This cannot be completed on the customer side, as bootloaders are usually not directly developed for the customer's use.

However, if customers emphasize on upgrading the firmware, the unit will have to be returned for replacing the DG4000 mainboard. This will imply a charge of the service.

So I would lose calibration data when I load the bootloader, but not sure why the mainboard would need replacing.
Not everything that counts can be measured. Not everything that can be measured counts.
[W. Bruce Cameron]
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: DG4000 - a firmware investigation
« Reply #462 on: November 14, 2023, 07:18:32 pm »
 :wtf: I find that totally BS. Did you talk with their house cleaner?

Why is it that all guys that bought the device in the days of the old versions, today are running the latest version??

But they are the manufacturer of your device. So, your call.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf