Sniffing the Rigol's internal I2C bus

[MrsR]

My question is Why does doing a self cal. remove the trial software if that removes it there must be some code activated method of putting it back?

Really good info guys.

Our software division has a LMH6158QN?? sorry didn't write it down as they didn't get it through me it must be a test bed or software/programmer. Will find out in conference Tuesday.
All hardware goes through me unless Head Office by passes me direct to a section and that hasn't happened yet unless their still unhappy with me frying a 7GHz MSO (wasn't my fault honest)
GOOD READ
Rachael

[cybernet]

my guess is more on the FRAM for serial (which probably determines the bandwidth limit in the preamp) as well as license option storage.
there are 100M/200M string references in the code. as well as input mask for the license key entry page. - so its in there somewhere ...

[studio25]

I copied the FRAM. I have used an Arduino UNO with level shifter. The trial period is probably stored at 0x7F6 and 0x7F7. There seems to be no checksum.

[cybernet]

cool stuff ... working on the TWI sub()'s in IDA pro this comes very handy ! ;-)

[cybernet]

btw there should be a 3rd device on the IIC/TWI bus because the ADSP configures itself also for slave mode operation ... maybe an external RTC - i dont see the internal BF one used at all.

Code: [Select]

def TWI_SLAVE_enable_sub_20568(...):

LINK 0x0;               # R0=TWI SLAVE ADDR
B[FP + 0x8] = R0;
R1 = 0x7f (X);          # R1=0x7f
R0 = R0 & R1;           # discriminate lower 7 bits
P1 = 0x1404 (X);        # P1=0x1404
P1.H = 0xffc0;          # P1=0xffc01404
                      -> TWI_CONTROL
R1 = W[P1] (Z);
R0 = R0 | R1;
W[P1] = R0.L;
R0 = W[P1] (Z);
BITSET (R0, 0x7);       # bit  7
W[P1] = R0.L;           # set TWI slave address bit 7 is *always* high
P1 = 0x1410 (X);        # P1=0x1410
P1.H = 0xffc0;          # P1=0xffc03950
                      -> TWI_SLAVE_ADDR
R0 = W[P1] (Z);
R1 = 0x51 (X);          # R1=0x51
R0 = R0 | R1;
W[P1] = R0.L;           # set TWI slave to R0  / 0x51 (101001b)
P1 = 0x1428 (X);        # P1=0x1428
P1.H = 0xffc0;          # P1=0xffc01428
                      -> TWI_FIFO_CTL
R0.L = 0x1;             # R0=0x10001
W[P1] = R0.L;           # flush receiver FIFO
R0.L = 0x0;             # R0=0x10000
W[P1] = R0.L;           # flush transmitter FIFO
P1 = 0x1424 (X);        # P1=0x1424
P1.H = 0xffc0;          # P1=0xffc01424
                      -> TWI_INT_MASK
R0 = W[P1] (Z);
R1 = 0xc2 (X);          # R1=0xc2
R0 = R0 | R1;
W[P1] = R0.L;           # set TWI interrupt mask to:
                        # -> Receive Fifo SIM (RCVSERVM)
                        # -> Transmit Fifo SIM (XMTSERV)
                        # -> Slave Transfer Complere SIM (SCOMPM)
P1 = 0x1408 (X);        # P1=0x1408
P1.H = 0xffc0;          # P1=0xffc01408
                      -> TWI_SLAVE_CTL
R0 = W[P1] (Z);
BITSET (R0, 0x2);       # bit  2
W[P1] = R0.L;           # STDVAL - enable Slave Transmit Data Value
UNLINK;
RTS;
# end function

Code: [Select]

SDRAM:2162C                 R0 = 0x64 (X);          # R0=0x64
SDRAM:21630                 CALL TWI_SLAVE_Setup_Int_CallBack_sub_2076E;
so the BF is having (0x64 & 0xF7 | 0x80) = 0xE4 as slave address

[cybernet]

I copied the FRAM. I have used an Arduino UNO with level shifter. The trial period is probably stored at 0x7F6 and 0x7F7. There seems to be no checksum.

could u also check if u see any matching between your serial number, and values in the FRAM ?

the code makes use of a string reference of:
SDRAM:EFFD94 aDs2a0000000001:ascii "DS2A0000000001",0 # DATA XREF: sub_10C700+48?

my guess would be: DS2A0000000001 + some FRAM value = the serial
and the serial determines the bandwidth limit ...

[marmad]

and the serial determines the bandwidth limit ...

I don't think this makes sense, because it's clear from the FW that Rigol have already coded the possibility of BW upgrades as a purchasable option in the future (if they decide they want/need to).

[cybernet]

what option makes u believe that ? i assume same fw is used for a ds2072 as for a ds2202 - looking at what seems likes options (TRIGGER, MEMORY .. ) i didnt spot something that looks like fw upgrade option.

[marmad]

what option makes u believe that ? i assume same fw is used for a ds2072 as for a ds2202 - looking at what seems likes options (TRIGGER, MEMORY .. ) i didnt spot something that looks like fw upgrade option.

"... the possibility of BW upgrades..."

[studio25]

I have the complete FRAM once overwritten with 0xFF and 0x00. The serial number does not change. The serial number appears to be in Flasch.

[studio25]

I entered a code to renew the trial options. Now my start screen looks like in the picture. It really seems to be bandwidth options in the firmware.

[studio25]

I don't know exactly how the time is calculated. But it is definitely stored in the FRAM at address 0x7F6 and 0x7F7.

Maybe someone finds the exact algorithm.
Here are a few examples:

0x34 0x25 -> 0x2534 -> 926min
0x17 0x25 -> 0x2517 -> 931min
0x00 0x20 -> 0x2000 -> 1165min
0x00 0x1F -> 0x1F00 -> 1210min
0x00 0x10 -> 0x1000 -> 1898min
0x00 0x0F -> 0x0f00 -> 1943min
0x00 0x0D -> 0x0D00 -> 2035min
0x00 0x0B -> 0x0B00 -> 2127min
0x4A 0x0A -> 0x0A4A -> 2159min
0x49 0x0A -> 0x0A49 -> 2160min (max)
0x48 0x0A -> 0x0A48 -> expired
0xFF 0xFF -> 0xFFFF -> expired
0x00 0x00 -> 0x0000 -> expired

[amyk]

I copied the FRAM. I have used an Arduino UNO with level shifter. The trial period is probably stored at 0x7F6 and 0x7F7. There seems to be no checksum.

Last 4 bytes look like one to me...

The data value and minutes remaining are nearly perfectly linear correlated. The minutes remaining from data value is -0.179x + 2630.9. This equation is probably clearer in seconds or ms as they're counting ticks of some odd internal clock frequency.

[Teneyes]

The minutes remaining from data value is -0.179x + 2630.9.

I concur with this equation of Options based on run-time and I think the count down time from 2630 to 2160 minutes are to allow for factory Testing and Burn-in , then turn on Trial options

[Pinkus]

I entered a code to renew the trial options. Now my start screen looks like in the picture. It really seems to be bandwidth options in the firmware.

Mmmhhh - this bring me to the questions:
a) which Rigol Scope do you own (70 / 100 / 200 Mhz)?
b) As now 100/200 Mhz are marked as trial: Do you have 2ns timebase available?

Peter

[studio25]

a) I have a DS2072.
b) 2ns timebase is not available.

[egonotto]

Hello studio25,

when you write the values in FRAM 0x7f6 and 0x7f7 do you have than the corresponding times for the trial options?

Best Regards
egonotto
 

[studio25]

when you write the values in FRAM 0x7f6 and 0x7f7 do you have than the corresponding times for the trial options?

I write the values during the boot phase of the oscilloscope.
If they are not too high or too low, the trial time is adjusted.

offset 0x7f6 -> 0x49 and offset 0x7f7 -> 0x0A = 2160min trial time.
More examples in Reply #44

[marmad]

I entered a code to renew the trial options. Now my start screen looks like in the picture. It really seems to be bandwidth options in the firmware.

If you don't have the 2ns time base setting and the 100MHz BW limit per channel, it's unlikely you have the real 200MHz BW - regardless of whatever the option screen says. There are MANY things that exist in the FW that are partially/completely unimplemented. We have no way of knowing if the BW Trial Option is actually fully implemented.

Edit: Also, considering that the BW is a much bigger selling point to Rigol than the options, I suspect it's a bit harder to invoke - and likely keyed to the model number in FW - at least in the current FW versions.

[studio25]

If you don't have the 2ns time base setting and the 100MHz BW limit per channel, it's unlikely you have the real 200MHz BW - regardless of whatever the option screen says.

Right. I have a rise time of 3.2ns measured. Which corresponds to approximately 109MHz.

[marmad]

If you don't have the 2ns time base setting and the 100MHz BW limit per channel, it's unlikely you have the real 200MHz BW - regardless of whatever the option screen says.

Right. I have a rise time of 3.2ns measured. Which corresponds to approximately 109MHz.

And from everything we've learned so far, there seems to be absolutely NO difference between the 70MHz and 100MHz models.

[marmad]

If you don't have the 2ns time base setting and the 100MHz BW limit per channel, it's unlikely you have the real 200MHz BW - regardless of whatever the option screen says.

Right. I have a rise time of 3.2ns measured. Which corresponds to approximately 109MHz.

@studio25 - I know it's a stupid question, but I don't see it specifically verified anywhere: you have confirmed that all of the options (except BW) are turned on and working (as opposed to just displayed minutes changed), right?

[studio25]

you have confirmed that all of the options (except BW) are turned on and working (as opposed to just displayed minutes changed), right?

Yes.

[studio25]

Code: [Select]

does counter go to ffff or 0000 after expire?
Do I need to test. Maybe tomorrow or Tuesday.

[marmad]

you have confirmed that all of the options (except BW) are turned on and working (as opposed to just displayed minutes changed), right?

Yes.

Ok, just checking    But perhaps because of language difficulties, I'm not 100% sure of the sequence of events. It sounds like you entered a new license code  - then that brought the options back - and then you were able to play with the trial minutes.

I guess the question is: if the options are expired when the scope boots - can you cause them to restart only by changing those two values in FRAM? Or is there a flag somewhere else indicating expiration?