Sniffing the Rigol's internal I2C bus

[whotopia]

Just got a new DS2072A.  I converted to DS2202A with all options (via old FW and old private key).
Will the scope function correctly with the old firmware? Has anyone noted any problems? 

Also, I 'lost' the serial number in the process, and the scope is now using default value.  On the DG4000 via cengen (see elsewhere on this forum) you can generate a license.GEL file through which one can also apparently mod the serial number.  Is such a thing possible for the DS2000?  Is there anyway to restore the serial number ?  Is there any real harm in having the default?
The scope doesn't ever try call Rigol if ethernet connected right?

Thanks
Steven

[AndersAnd]

BUG in latest f/w, 02.01

Delayed sweep malfunctions.
To reproduce:
Ch2 must be enabled, Ch1 optional
acquire:  7M samples, normal
trigger: ch1 or not important, Auto or Normal seems to have no effect
main timebase 500us/div, delayed t.b. 100 us/div or something
Then when you move the delayed t.b. towards 1 ns/div all seems well until you select 1 ns/div..
It locks up for about 10 seconds, no waveform update, no response to keys.
Then it comes good and lets you go back to 2ns/div

I see what you're talking about, but as mentioned earlier in the thread in regards to problems with the 1ns time base:

It's another error (and there's a few of them) in an, as yet, officially unimplemented - and perhaps unfinished? - portion of firmware. As far as I know, Rigol has not started selling BW updates - but if/when someone on the forum has a DS2302A (or DS2302A-S), we can find out if the error(s) exist in the 'official' working version - and if so, report it to Rigol.

I suggest disabling 300MHz on non-A HW v.1 models. Not only is it buggy (I've had a couple of crashes from it), but it's not really perfectly implemented in the input stage.

How is it possible to uninstall only BW option?

Do ":SYSTem:OPTion:UNINSTall" and then generate new keys without 300 MHz option (with 200 MHz for example) and install them.
It can be two keys: DSAZ (200 MHz, MEM, DC, AT) then DSEA (CAN).

Or simply use DSEZ instead as the only key, to combine CAN with all the options included in DSAZ (200 Mhz, Mem, Dec and Trig) into a single key.
Combining the two tables below DSEZ should install CAN, 200 Mhz, Mem, Dec and Trig.
So DSEZ should be the one key solution to use for non A DS2000 with HW 1 and the latest FW if you want 200 MHz with all available options including CAN but without 50 ohm which is not implemented on HW 1 anyway.

EZ derived from the two tables for y (3rd letter) and x (4th letter) below (DSyx):

Code: [Select]

y  CAN, 300, 50ohm   |   x  200, 100, Mem, Dec, Trig
E   on   ==   ==     |   Z   on   ==   on   on   on   <-  All 2202
Table for 3rd letter (y):

Is this correct?
IMHO would be interesting know the entire table, and thus activate the desired options with a single key.

Code: [Select]

Code table: Use DSYX for a official key, and use VSYX for a trial key.

Y  CAN, 300, 50ohm

A   none
B   ==   ==   on
C   ==   on   ==
D   ??   ??   ??
E   on   ==   ==
F   ??   ??   ??
G   ??   ??   ??
H   on   on   on
J   ??   ??   ??
K   ??   ??   ??
L   ??   ??   ??
M   ??   ??   ??
N   ??   ??   ??
P   ??   ??   ??
Q   ??   ??   ??
R   ??   ??   ??
S   ??   ??   ??
T   ??   ??   ??
U   ??   ??   ??
V   ??   ??   ??
W   ??   ??   ??
X   ??   ??   ??
Y   ??   ??   ??
Z   ??   ??   ??

E instead of A as 3rd letter enables CAN but still leaves out the 300 MHz BW and 50 ohm which is not implemented on HW 1 anyway.

Table for 4th letter (x):

Cybernet has done it, again! *ole* 

Now I'm very busy and I can't test anything (check the BW for example).

Anyway. How is the new table?

Code table: Use DSAx for a official key, and use VSAx for a trial key.

x  200, 100, Mem, Dec, Trig

A   none
B   ==   ==   ==   ==   on
C   ==   ==   ==   on   ==
D   ==   ==   ==   on   on
E   ==   ==   on   ==   ==
F   ==   ==   on   ==   on
G   ==   ==   on   on   ==
H   ==   ==   on   on   on

Note: keys A..H wont change the model, only ADD an option.

2102:

J   ==   on   ==   ==   ==   
K   ==   on   ==   ==   on
L   ==   on   ==   on   ==
M   ==   on   ==   on   on
N   ==   on   on   ==   ==
P   ==   on   on   ==   on
Q   ==   on   on   on   ==
R   ==   on   on   on   on   <-  All 2102

2202:

S   on   ==   ==   ==   ==   
T   on   ==   ==   ==   on
U   on   ==   ==   on   ==
V   on   ==   ==   on   on
W   on   ==   on   ==   ==
X   on   ==   on   ==   on
Y   on   ==   on   on   ==
Z   on   ==   on   on   on   <-  All 2202

DONT USE BELOW Not recommended, as activates 2102 and also 2202:

2   on   on   ==   ==   ==
3   on   on   ==   ==   on
4   on   on   ==   on   ==
5   on   on   ==   on   on
6   on   on   on   ==   ==
7   on   on   on   ==   on
8   on   on   on   on   ==
9   on   on   on   on   on

Z as 4th letter for 200 Mhz, Mem, Dec and Trig.


And here's the table to convert between binary values and letters: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg322495/?topicseen#msg322495

[zombie28]

ok, I found out about the 0x before I read your reply lol

it says licence is unavailable

It appears that Rigol changed not only ECC keys, but also license code format.

[PA0PBZ]

I tried option DSBA on my non-A model with the latest firmware, it said "option installed" but I can't find any changes, certainly not the 50 Ohm option. Would there be a key for that since it is build into all A models as a standard?

[marmad]

I tried option DSBA on my non-A model with the laters firmware, it said "option installed" but I can't find any changes, certainly not the 50 Ohm option. Would there be a key for that since it is build into all A models as a standard?

I think it's unlikely. It's a standard feature on new A-models (and so one of their new selling points vs. non-A models), so it I doubt it would ever be sold as an 'option' specifically for HW v.2 non-A owners - thus no key. But perhaps the FW can be patched to enable it.

[PA0PBZ]

I tried option DSBA on my non-A model with the laters firmware, it said "option installed" but I can't find any changes, certainly not the 50 Ohm option. Would there be a key for that since it is build into all A models as a standard?

I think it's unlikely. It's a standard feature on new A-models (and so one of their new selling points vs. non-A models), so it I doubt it would ever be sold as an 'option' specifically for HW v.2 non-A owners - thus no key. But perhaps the FW can be patched to enable it.

I agree, but also wonder what the difference is between the A and non-A models so that the 50 Ohm works on the A but not on the non-A 2.0 hardware. Maybe it is as simple as the model number?

[marmad]

I agree, but also wonder what the difference is between the A and non-A models so that the 50 Ohm works on the A but not on the non-A 2.0 hardware. Maybe it is as simple as the model number?

It could be... changing the model number of the DSOs was all was that required to enable the different BW settings on non-A models. OTOH, as zombie28 pointed out, Rigol has changed a few things to 'enhance' security on the A-models - although that might be irrelevant in this case.

[NikWing]

@zombie28: so what to do ... wait for cybernet to find something? ^^

[PA0PBZ]

OTOH, as zombie28 pointed out, Rigol has changed a few things to 'enhance' security on the A-models - although that might be irrelevant in this case.

It would be interesting to see what they did to enhance the security, because both A and non-A run on the same firmware, and my non-A still responds to the 'old' keys. Maybe the 2 things are related and it is based on the model number.

[staze]

Or serial number.

[zombie28]

@zombie28: so what to do ... wait for cybernet to find something? ^^

yeah, for cybernet or for anyone who will analyze the new firmware and write a keygen

[zombie28]

OTOH, as zombie28 pointed out, Rigol has changed a few things to 'enhance' security on the A-models - although that might be irrelevant in this case.

It would be interesting to see what they did to enhance the security, because both A and non-A run on the same firmware, and my non-A still responds to the 'old' keys. Maybe the 2 things are related and it is based on the model number.

I found function that tells licensing engine which version of keys and decoding subroutines to use. This function checks the 4th character of the serial number (i.e. the character after 'DS2') and when it finds anything except 'A' and 'C', then the new version of decoder will be used. For 'A' and 'C' there are some additional checks, but for now I don't know what they mean.

[PA0PBZ]

I found function that tells licensing engine which version of keys and decoding subroutines to use. This function checks the 4th character of the serial number (i.e. the character after 'DS2') and when it finds anything except 'A' and 'C', then the new version of decoder will be used. For 'A' and 'C' there are some additional checks, but for now I don't know what they mean.

 

[NikWing]

my serial starts with D (after DS2)

[Fagear]

I found function that tells licensing engine which version of keys and decoding subroutines to use. This function checks the 4th character of the serial number (i.e. the character after 'DS2') and when it finds anything except 'A' and 'C', then the new version of decoder will be used. For 'A' and 'C' there are some additional checks, but for now I don't know what they mean.

Good news. So, it was one of options - to detect A-version by serial #.
Non-A versions of DS2xxx have 'A' letter in serial # and A-versions have 'D' letter.

I think that 50 ohm "option" is enabled the same way. Regardless of HW version (is there resistor or not).

I see two ways: either somebody can hack the updated algorithm or somehow patch the FW to supress this check.

[cybernet]

currently on another track that will hopefully make stuff easier in the future - esp no need for JTAG anymore ;-)

Code: [Select]

bfin> bdinfo
U-Boot      = U-Boot 2013.10 (Dec 30 2013 - 18:01:24)
CPU         = bf526-0.0
Board       = bf526-ezbrd
VCO         =    400 MHz
CCLK        =    400 MHz
SCLK        =    100 MHz
boot_params = 0x00000000
memstart    = 0x00000000
memsize     = 0x02000000
flashstart  = 0x20000000
flashsize   = 0x01000000
flashoffset = 0x00000000
ethaddr     = 02:80:ad:20:31:e8
ip_addr     = 192.168.0.15
baudrate    = 57600 bps
bfin> flinfo

Bank # 1: CFI conformant flash (16 x 16)  Size: 16 MB in 71 Sectors
  AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E2101
  Advanced Sector Protection (PPB) enabled
  Erase timeout: 4096 ms, write timeout: 1 ms
  Buffer write timeout: 3 ms, buffer size: 64 bytes

  Sector Start Addresses:
  20000000   RO   20020000   RO   20040000   RO   20060000   RO   20080000   RO
  200A0000   RO   200C0000        200E0000        20100000        20120000     
  20140000        20160000        20180000        201A0000        201C0000     
  201E0000        20200000        20220000        20240000        20260000     
  20280000        202A0000        202C0000        202E0000        20300000     
  20320000        20340000        20360000        20380000        203A0000     
  203C0000        203E0000   RO   20400000   RO   20420000   RO   20440000   RO
  20460000   RO   20480000   RO   204A0000        204C0000        204E0000     
  20500000        20520000        20540000        20560000        20580000     
  205A0000        205C0000        205E0000        20600000        20620000     
  20640000        20660000        20680000        206A0000        206C0000     
  206E0000        20700000        20720000        20740000        20760000     
  20780000        207A0000        207C0000        207E0000        20800000     
  20820000   RO   20840000   RO   20860000   RO   20880000   RO   208A0000   RO
  208C0000   RO
bfin> reginfo

System Configuration registers

PLL Registers
PLL_DIV:   0x0004   PLL_CTL:      0x2000
PLL_STAT:  0x00a2   PLL_LOCKCNT:  0xffff
VR_CTL:    0x70f0

EBIU AMC Registers
EBIU_AMGCTL:   0x00f9
EBIU_AMBCTL0:  0xbbc3bbc3   EBIU_AMBCTL1:  0xb6ab77c3

EBIU SDC Registers
EBIU_SDRRC:   0x0fff   EBIU_SDBCTL:  0x0013
EBIU_SDSTAT:  0x0000   EBIU_SDGCTL:  0x8011998d



[marmad]

Just to keep owners that aren't reading the DS2000 review thread informed:

More bugs keep getting discovered when running the 300MHz option on HW v.1 DS2000 models (I just posted another here).

Whether those bugs exist for HW v.2 or A-model owners, I couldn't say - but considering that we've found a few of them - and that on HW v.1 models the BW only seems to increase by ~60MHz (to somewhere between ~280 - 300MHz), you might want to consider if the advantages outweigh the disadvantages before installing the option (on HW v.1)

[m-joy]

Just to keep owners that aren't reading the DS2000 review thread informed:

More bugs keep getting discovered when running the 300MHz option on HW v.1 DS2000 models (I just posted another here).

Whether those bugs exist for HW v.2 or A-model owners, I couldn't say - but considering that we've found a few of them - and that on HW v.1 models the BW only seems to increase by ~60MHz (to somewhere between ~280 - 300MHz), you might want to consider if the advantages outweigh the disadvantages before installing the option (on HW v.1

But 200MHz works fine?

[marmad]

But 200MHz works fine?

Sure - every version of the DS2000 hardware has been designed to work to 200MHz-2ns/div.

[Git]

Hello,
Just to make sure: Is the JTAG-port on DS2202A at 3.3 Volt?

Yes, I think.

It shouldn't matter anyway,  your JTAG box should power its output stage from the target machines supply. Some, if not most, are happy from 1.8V to 5V.

Git

[alank2]

currently on another track that will hopefully make stuff easier in the future - esp no need for JTAG anymore ;-)

I'm eagerly awaiting what this track will result in!!!

[pascal_sweden]

Just got a new DS2072A.  I converted to DS2202A with all options (via old FW and old private key).
Will the scope function correctly with the old firmware? Has anyone noted any problems? 

Also, I 'lost' the serial number in the process, and the scope is now using default value.  On the DG4000 via cengen (see elsewhere on this forum) you can generate a license.GEL file through which one can also apparently mod the serial number.  Is such a thing possible for the DS2000?  Is there anyway to restore the serial number ?  Is there any real harm in having the default?
The scope doesn't ever try call Rigol if ethernet connected right?

Thanks
Steven

What if you upgrade the FW back to the newer A version? Will the options stay?
Are you up to 200MHz? Or did you even manage to get upto 300MHz?
I am interested in DS2072A but want to wait until the hack is confirmed with new FW and all options enabled, including 300MHz and CAN decoding.
Can still get old DS2072 here in Sweden, maybe that is better? But that one does not get up to 300MHz, so maybe better to wait? Do you really need 50 ohm impedance? That you can fix externally with BNC adapter not?

[neslekkim]

If you just read some pages of this thread at least, it seems that it's very close to fixing it for the A series
At least I ordered the A series in anticipation of the keygen

[marmad]

What if you upgrade the FW back to the newer A version? Will the options stay?

A is model type - v.2 is the newer FW. But upgrading to v.2 FW with options enabled on A models does not retain the options; there is a different version of the key and decoding for them in v.2 FW.

BTW, I've heard Rigol is working on new security measures for all the devices which have been hacked - so if anyone has been on the fence about purchasing one of them (and you want to be certain you can run the current versions of keygens), it might be best to act soon.

[pascal_sweden]

Is somebody actively working on this hack for the DS2072A?

Has it been confirmed already that the HW design is identical between DS2072A and DS2302A?

I know that it has been confirmed between DS2072 and DS2202, but not for the A series AFAIK, and especially not for the new 300 MHz variant.