Sniffing the Rigol's internal I2C bus

[marmad]

Or "they" don't have skill to do it, don't have it yet or don't have job so can't lose warranty from 850€ equipment.
I tick at least last 2 of them atm 
Thats why I suggested fundraising to get one to be hacked. I would happily put >=20€  for it...

Have you just tried downgrading to FW v.01.01.00.02 then using Riglol keygen (for all Trigger, Decode, and Memory options)? The worst that could happen is scope might get frozen - but it's still under warranty (and they would never know what happened). But since the DSO has a bootloader (and since HW v.2 owners have upgraded and downgraded) - and NO ONE has ever managed to brick one of these DSOs (AFAIK) - it's highly unlikely that would happen, so a more likely worst-case scenario is that it just won't downgrade - or the keygen won't work even when downgraded.

[elecBlu]

Thats why I suggested fundraising to get one to be hacked. I would happily put >=20€  for it...

not a bad idea, but my guess is that there are way too less people who want to spent >20€/$ for that.
Even the number of guys around here who hacked their scope and still following this thread seems to be relatively small.

I could do some more signal-generator measurements on my 2.0 HW DS2072 (look 10 pages back), but it seems that my generator drops the output amplitude significantly with frequency (compared to 500MHz scope), so it doesn't look that reliable at the moment. Someone with a known-good generator is needed, maybe we can compare directly. I really don't want to publish these cutoff-freqency measurements at that moment, although it looked like 2.0 HW brings way more that the 315MHz at my scope.
Plus, we still need high-res pictures of DS2072 2.0 HW input stages for last proof if it is the same as DS2072A. Maybe I will do this in some time, the thing with the warranty seal seems to be
feasible.

[neamyalo]

I think I can help out.

I bought a 2072A a couple of weeks ago and thanks to cybernet's JTAG pinout , I currently have it open on my bench with urjtag connected to the BF256 

I should have a memory dump pretty soon...

[NikWing]

that's great
I forgot the jtag at work and it also seems like it's not as easy to read out (as I thought ... need of linux, adapter ...)

[apelly]

Have you just tried downgrading to FW v.01.01.00.02 then using Riglol keygen (for all Trigger, Decode, and Memory options)? The worst that could happen is scope might get frozen - but it's still under warranty (and they would never know what happened). But since the DSO has a bootloader (and since HW v.2 owners have upgraded and downgraded) - and NO ONE has ever managed to brick one of these DSOs (AFAIK) - it's highly unlikely that would happen, so a more likely worst-case scenario is that it just won't downgrade - or the keygen won't work even when downgraded.

I was going to give this a go, but it was pointed out that a pristine dump might be of more initial value. I'll try once there is a firmware dump.

[Pehtoori]

Or "they" don't have skill to do it, don't have it yet or don't have job so can't lose warranty from 850€ equipment.
I tick at least last 2 of them atm 

Have you just tried downgrading to FW v.01.01.00.02 then using Riglol keygen (for all Trigger, Decode, and Memory options)?

"I tick at least last 2", one of them was "don't have it (the scope) yet" (ok bit tired)

But when I get one hopefully in month or two, thats what I'm going to do for it.

[cybernet]

Mode 0 and Mode 1?

likely the BMODE pins of the BFIN - toggle between flash/spi boot - where spi is what they use to flash the bootldr - one of my first posts in that thread was regarding bmode pins.
if somebody wants to mess with them with boundary scan u can check the bfin pins logic levels nicely.

[neamyalo]

I'm getting an error each time I try and dump the memory contents..

Code: [Select]

GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i586-mingw32msvc --target=bfin-elf".
(gdb) target remote :2000
Remote debugging using :2000
0x0011debc in ?? ()
(gdb) info mem
Using memory regions provided by the target.
Num Enb Low Addr   High Addr  Attrs
0   y   0x20000000 0x20400000 rw nocache
1   y   0xef000000 0xef008000 ro nocache
2   y   0xff800000 0xff804000 rw nocache
3   y   0xff804000 0xff808000 rw nocache
4   y   0xff900000 0xff904000 rw nocache
5   y   0xff904000 0xff908000 rw nocache
6   y   0xffa00000 0xffa0c000 rw nocache
7   y   0xffa10000 0xffa14000 rw nocache
8   y   0xffb00000 0xffb01000 rw nocache
9   y   0xffc00000 0xffe00000 rw nocache
10  y   0xffe00000 0x100000000 rw nocache
(gdb) dump binary memory dump.bin 0x20000000 0x20400000
Ignoring packet error, continuing...
Reply contains invalid hex digit 116
(gdb)
I've tried reducing the JTAG freq from 6MHz down to 60kHz, but there's no difference..

I'm running 2013R1 release on Windows and I can successfully dump 1K, but >= 2K and I get the error and no dump file. 

[m-joy]

Huhu, maybe the cable lengh too large which might cause data loss? Thats what cybernet state on post 2082

[neamyalo]

It looks like setting the remotetimeout to 10 has solved it.

[alank2]

It looks like setting the remotetimeout to 10 has solved it.

Do you have the dump yet?

[AndersAnd]

Sorry about the quality.

No problem. Thanks again.

In the input stage they also change a bipolar trt!!! What is the SMD marking code? R2W..? -> BFR93A?

Analog Devices ADR5044A (4.096 V Precision Micropower Shunt Mode Voltage Reference) has a R2W marking on it. (See bottom of page 14): http://www.analog.com/static/imported-files/data_sheets/ADR5040_5041_5043_5044_5045.pdf

http://www.analog.com/ADR5044


Not sure if any other devices has the same R2W marking on them too or not.

[neamyalo]

I'm having a few issues with my JTAG probe and urJtag (using a J-Link on Windows)

I captured the main region from 0x20000000 - 0x20400000, and a few others too, but then the JTAG link hung for some reason and I had to reboot the scope trying to get things talking again, so will need to start again.

Anyway, here is what I managed to get.....

Scope was fully booted and running (its an untouched DS2072A).

SW/FW details are:
- SW 00.02.00.00.04
- HW 1.0.2.0.2
- FPGA:
--- SPU 03.01.09
--- WPU 00.07.01
--- CCU 12.29.00
--- MCU 02.13

[PA0PBZ]

Well, I changed the jumper settings on my non-A version 2 hardware to reflect the -A settings (moved one resistor from the upper row to the lower row), but I can't find anything that has changed. The 50 Ohm is still greyed out and the model is still non-A. It has the latest software, and I tried booting with left-F6. Maybe it needs a factory reset, but I'm not sure how to do that.

[alank2]

neamyalo you have my thanks!

[neamyalo]

It turns out that my JLink/urjtag connection is not hanging, instead its just going really really slow 
I've set the frequency to 6 MHz, but its so slow its more like a few kHz (I would check with my scope but the CPU is halted....)

The main problem is the SDRAM - I'm currently trying to dump the full SDRAM address space (128 MB) and its only 1% through after 30 minutes - its going to take too long.... (50hrs?)

On the board it looks as though there's only a single 32 MB SDRAM chip connected to the bf526. I'm gonna assume that its address range is 0x0000 0000 to 0x01FF FFFF and limit the SDRAM dump to that instead.

Sorry for the bad news, but I'm goin to persevere and will let you know how it goes.

If anyone has a J-Link running with urjtag at a decent speed let me know!

[Fagear]

I have something to say here.
Recently I bought my DS2072A.

It had FW v00.02.00.00.04. Then I updated it to v00.02.01.00.03.
Today I tried some keygens (three of them), and none worked.

So...

Have you just tried downgrading to FW v.01.01.00.02 then using Riglol keygen (for all Trigger, Decode, and Memory options)? The worst that could happen is scope might get frozen - but it's still under warranty (and they would never know what happened).

I have done it.
1) Copied v00.01.01.00.02 FW file to USB stick.
2) Reflashed device using Power on -> Help -> USB stick sequence.
3) Cleared FRAM during first boot.
And got this (serial # stays intact):


Then I used synapsis's Windows GUI keygen. Entered serial # of my device (last letter was left blank) and private key. Randomly generated seed 1333118342.
And generated license key with DSAZ. I have entered license key with on-screen-keyboard (also all of them later).
And TA-DA!!! It worked! 


I had rebooted the 'scope and model number changed to DS2202A, I've got 2 ns timebase and all options stayed in place!


But then I tried to generate and enter DSEA and DSCA options (CAN Decoder and 300MHz) it said "Failed to install option,please ensure the License valid!". Then I tried DSHH with the same result. I also tried to generate keys with command-line Riglol 1.03c but result was the same.

I decided to switch back to the last v00.02.01.00.03 FW. Reflashed 'scope with same procedure successfully (serial # still intact).


But this action cleared off all of the options! "Installed" option is greyed out. And I tried to install all previuosly generated keys and also some generated with another seed. But answer was the same all the time: "License is unavailable!".
But model number DS2202A stayed in place along with 2 ns timebase and "OFF/20M/100M" BW limit option.

Again, I reflashed the device to older v00.01.01.00.02 FW and all options magically apeared again!
But I don't want to use older FW and reflashed the device with v00.02.01.00.03 again, but this time I did it through GUI (inserted USB stick, 'scope asked me if I want to update the FW, I pressed "Update") and did not cleared FRAM during first boot. But options were gone once again (and all of my trial time as well).

Channels' "1M/50" input impedance option was always available (as it was when I bought my DS2072A) on all tested FWs and with all options.

Options with v00.01.01.00.02 FW:


Options with v00.02.01.00.03 FW:



So, the conclusion:
1) You can hack your DS2xxxA oscilloscope!
2) To get all options except of 300 MHz and CAN decoding - switch to older FW v00.01.01.00.02 and apply DSAZ key.
3) If you do not want to use old FW all you can get now - BW up to 200 MHz. For it you must go to older FW v00.01.01.00.02, apply code for 200 MHz (I used old "all options" DSAZ) and then switch back to latest FW.

In my case serial # was not damaged.

[marmad]

So, the conclusion:
1) You can hack your DS2xxxA oscilloscope!
2) To get all options except of 300 MHz and CAN decoding - switch to older FW v00.01.01.00.02 and apply DSAZ key.
3) If you do not want to use old FW all you can get now - BW up to 200 MHz. For it you must go to older FW v00.01.01.00.02, apply code for 200 MHz (I used old "all options" DSAZ) and then switch back to latest FW.

In my case serial # was not damaged.

Good to know - thanks for all the testing you did. I suspected that was what might happen (i.e. losing the options with the upgrade back to FW v.2), although I never thought you'd keep the 200MHz option - so there was at least one bonus for all the time spent. 

BTW, CAN and 300 MHz options are ONLY available in FW >= v.2 - so it will always be impossible for any DS2000 owner (A or non-A) to activate those at FW.01.01.00.02 or below.

[alank2]

I want the trial minutes to run out on my scope - what was the method to lose the trial again?

[alank2]

What happens if a key created by using DSHH is used with earlier versions of the firmware on a DS2000A?  Does it reject the key?
If it accepts it, are all the options then enabled after updating the firmware to the latest?

It won't accept more than the last 6 bits set (no can, no 300)...

[alank2]

I want the trial minutes to run out on my scope - what was the method to lose the trial again?

@alank2
why would you want that?

I was doing some testing and ended up with >6000 trial minutes but I want it out of trial mode now and don't want to wait...

00.01.00.00.03 + self cal did not do it.  Trying 00.00.01.00.05.

[Fagear]

I want the trial minutes to run out on my scope - what was the method to lose the trial again?

Maybe installing some "official" options and then removing them will do the trick?

[JDubU]

I want the trial minutes to run out on my scope - what was the method to lose the trial again?

@alank2
why would you want that?

I was doing some testing and ended up with >6000 trial minutes but I want it out of trial mode now and don't want to wait...

00.01.00.00.03 + self cal did not do it.  Trying 00.00.01.00.05.

Does SCPI command    ":SYSTem:OPTion:UNINSTall"  not work to do that?
 

[alank2]

No, if you have an ongoing trial, it will come back (if it hasn't run out) when keys are uninstalled.  I got it, but it took the very old 00.00.01.00.05 + self cal to do it.

I can see from the memory dump where SN is located and it is guarded by a crc32.  My goal is to try to return my unit's SN and correct model, still working on that, but at least I know what needs to change now.

My theory is that the reason the SN is lost is because something buggy happens and the block that contains it has a bad crc and then the scope regenerates the block and rewrites a good one, with the mangled SN.

[alank2]

Did you notice that  S/N = DS2A0000000001 is one digit longer than normal?
DS2Ayyww123456 is that an Overflow bug error

Absolutely - I've always thought it was likely some sort of bug that they made it one digit longer, but who knows, could be a reason for it.

Interestingly the user's posted memory dump showed 4 recorded keys entered and I wonder if those keys are somehow the method the model and sn are loaded originally.  It records as many as 7 trial keys to prevent the user from entering the same trial extension key more than once.