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

0 Members and 2 Guests are viewing this topic.

Offline cybernet

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

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

  • 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: 431
  • 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: 2007
  • 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 cybernet

  • 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: 570
  • 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 cybernet

  • 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: 570
  • 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 cybernet

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

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

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

  • 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: 71
  • 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)
Ununpentium
 

Offline cybernet

  • 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: 570
  • 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: 7338
  • 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 cybernet

  • 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: 431
  • 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 cybernet

  • 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: 431
  • 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: 2094
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: 1201
  • 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: 1925
  • 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: 431
  • 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 cybernet

  • 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: 431
  • 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.
 

Offline bingo600

  • Super Contributor
  • ***
  • Posts: 1525
  • 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: 431
  • 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 cybernet

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

Offline cybernet

  • 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: 431
  • 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: 1201
  • 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: 1201
  • 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: 431
  • 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: 1201
  • 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: 431
  • 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: 568
  • 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 cybernet

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

  • 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: 7338
  • 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 cybernet

  • 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: 431
  • 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: 492
  • 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: 438
  • Country: au
Re: DG4000 - a firmware investigation
« Reply #69 on: November 16, 2013, 08:03:42 am »
awesome work :-+
 

Offline Harvs

  • Super Contributor
  • ***
  • Posts: 1195
  • 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: 438
  • 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: 1195
  • 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: 497
  • 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: 1195
  • 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: 1195
  • 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: 438
  • 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 cybernet

  • 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: 937
  • 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 cybernet

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

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

  • 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: 1195
  • 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 cybernet

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

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 3722
  • 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: 393
  • Country: ca
  • 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 cybernet

  • 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: 1201
  • 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: 393
  • Country: ca
  • 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: 568
  • 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: 449
  • 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: 393
  • Country: ca
  • 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: 393
  • Country: ca
  • 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 cybernet

  • 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: 393
  • Country: ca
  • 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: 393
  • Country: ca
  • 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 cybernet

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

  • 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: 71
  • 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:
Ununpentium
 

Offline cybernet

  • 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: 570
  • 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: 393
  • Country: ca
  • 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 cybernet

  • 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: 393
  • Country: ca
  • 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 cybernet

  • 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: 937
  • 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: 568
  • 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: 568
  • 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 cybernet

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

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

  • 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: 36
  • 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: 393
  • Country: ca
  • 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: 7
  • 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: 937
  • 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

  • Contributor
  • 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: 568
  • 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

  • Contributor
  • 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: 570
  • 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 cybernet

  • 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: 393
  • Country: ca
  • 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: 568
  • 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: 393
  • Country: ca
  • 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: 568
  • 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: 568
  • 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: 393
  • Country: ca
  • 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: 393
  • Country: ca
  • 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: 2094
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: 393
  • Country: ca
  • 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: 2094
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: 393
  • Country: ca
  • 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: 570
  • 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: 497
  • 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: 393
  • Country: ca
  • 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: 393
  • Country: ca
  • 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 cybernet

  • 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: 393
  • Country: ca
  • 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: 393
  • Country: ca
  • 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: 393
  • Country: ca
  • 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: 497
  • 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: 570
  • 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: 568
  • 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: 317
  • 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

  • Contributor
  • Posts: 7
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: 431
  • 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: 431
  • 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: 431
  • 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: 317
  • 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: 431
  • 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: 431
  • 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: 146
  • 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: 570
  • 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: 393
  • Country: ca
  • 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: 570
  • 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: 497
  • 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: 393
  • Country: ca
  • 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: 524
  • 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: 497
  • 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 cybernet

  • 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: 1762
  • 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: 1762
  • 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: 1762
  • 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: 1762
  • 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: 393
  • Country: ca
  • 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: 55
  • 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: 393
  • Country: ca
  • 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: 55
  • 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: 393
  • Country: ca
  • 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: 393
  • Country: ca
  • 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: 1762
  • 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: 317
  • 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

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

  • Contributor
  • 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: 1
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: 4513
  • 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: 4513
  • 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: 431
  • 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: 4513
  • 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: 55
  • 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: 524
  • 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: 4513
  • 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: 55
  • 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: 524
  • 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: 4513
  • 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: 524
  • 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: 4513
  • 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: 317
  • 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: 524
  • 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 cybernet

  • 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: 4513
  • 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 cybernet

  • 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: 4513
  • 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: 4513
  • 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 cybernet

  • 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: 4513
  • 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 cybernet

  • 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: 4513
  • 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: 4513
  • 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 cybernet

  • 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: 497
  • 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: 55
  • 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: 431
  • 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: 55
  • 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: 497
  • 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: 55
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: 431
  • 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: 431
  • 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: 497
  • 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: 431
  • 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: 431
  • 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: 3453
  • Country: cn
  • Born 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 »
If practice and theory is not equal it tells that used application of theory is wrong or the theory itself is wrong.
-
Harmony OS
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 497
  • 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: 148
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: 497
  • 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: 148
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: 3453
  • Country: cn
  • Born 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".
If practice and theory is not equal it tells that used application of theory is wrong or the theory itself is wrong.
-
Harmony OS
 

Offline H.O

  • Frequent Contributor
  • **
  • Posts: 681
  • 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
  • *