Sniffing the Rigol's internal I2C bus

[NikWing]

that's really odd, my trial time decreased when it was online, not while switched off and with plug removed

[neslekkim]

I think he means, in use of the features. Just turn on the scope, leave it on, and your trial will disapear, without using them..

[NikWing]

ahhh ok
misunderstood it then ^^

[diyaudio]

I think he means, in use of the features. Just turn on the scope, leave it on, and your trial will disapear, without using them..

yeah. that's what I meant.

[pillex]

Finally I managed to dump the memory of my DS2202A!
I was using a OpenOCD, FTDI2232D based JTAG device, pulling RDI, TMS, TCK and TDO up with 100k to 3V3.

I have uploaded the files to https://mega.co.nz/#!jkRihazT!L2KUHS3tb9nUPgqU1UBUD5gWXdsmSG4Wht7jS3s_HXo
hoping that the experts can send me some keys to enable all features. Furthermore I hope this post will contribute to a purely SW based unlocking solution in the future.

Cheers
Pillex

[cepphus]

OK,

I have an update after trying some more today.  I've gotten the Altera USB-Blaster JTAG adapter to work with the blackfin tool chain.  It seems to work fine on a 32-bit Linux box.

I now have a working gdb interface after starting bfin-gdbproxy and connecting to it.  I can freely access memory and registers at this point.

If anyone else is looking for a JTAG interface for this, the knock-off Altera one (called "mini") is < $10 on eBay (US).  Working on memory dump now.

Is this the JTAG that would work? I just got my 2072A and would just love to open it and play

http://www.ebay.com/itm/150943500360

[Git]

Finally I managed to dump the memory of my DS2202A! ...
I have uploaded the files to...

.tar.xz ?. I have seen .tar.gz, but nothing on windows seems to recognize .xz. I tried renaming it to .tar and .tar.gz. What format is the archive please?. A search on google found linux people asking the same question

...

Later - 7z opens and extracts it. Should ds2k_00_sdram.bin have length of 128MB ?

Git

[pillex]

@Git: xz might be more common in the Linux world --> http://en.wikipedia.org/wiki/Xz

So 7zip should do the job for windows.

[granz]

Is this the JTAG that would work? I just got my 2072A and would just love to open it and play

http://www.ebay.com/itm/150943500360

Yes, that's the one.  In the JTAG connection diagram posted a little while back I used the second setup (pull-ups on TRST and SRST lines -- don't connect these to the programmer at all), but either way should work for you.

Good luck!

[neslekkim]

and that one is fairly fast?
I guess it's better then to buy this, since I dont know how to use my ft2232h card..

[granz]

and that one is fairly fast?
I guess it's better then to buy this, since I dont know how to use my ft2232h card..

If I remember right it took about 15-20 minutes to dump 32MB of DRAM.

For some unknown reason I couldn't communicate with it from the blackfin toolchain on 64-bit Linux or 64-bit Windows 7, so just keep that in mind.  It worked fine once I tried it on a fresh install of Lubuntu 32-bit.  I didn't investigate further after getting the memory dump.  I believe another forum member had a similar issue with a different programmer, so I believe it's something in the blackfin version of UrJTAG.  Just keep it in mind if you want to minimize wasted time.

[neslekkim]

good to know, all my computers use 64bit os, so I guess I'll try from an virtualmachine then

[granz]

good to know, all my computers use 64bit os, so I guess I'll try from an virtualmachine then

Good thing to try.  If it works out for you, definitely post about your success, because I'm sure that would make it easier for lots of folks.

[Posterisan]

Here is my Memory Dump from Rigol DS2072A !

Serial #: DS2D1542.....

https://mega.co.nz/#!IEdgVbiR!7ylPllecGTVCT54WldU8zGFLoa4E1niOeGCFLcnEPfI

took me hours to get the dump - my segger jlink does not work ;-((

Andre

[neslekkim]

Which firmware version is people having when taking a dump?, I want to upgrade, but not sure if one should dump before and after?

[ZeroAviation]

Is this the JTAG that would work? I just got my 2072A and would just love to open it and play

http://www.ebay.com/itm/150943500360

Yes, that's the one.  In the JTAG connection diagram posted a little while back I used the second setup (pull-ups on TRST and SRST lines -- don't connect these to the programmer at all), but either way should work for you.

Good luck!

Excellent! I'm going to pick one up as well. (2-4 week delivery time sucks)

I assume I should restore factory firmware before doing the dump?

-Matt

[eurofox]

Hi Gary,
short question, didn't follow the thread for a while: why do you need to downgrade? Don't the keys work for V. 01.08.00 anymore?
Kind regards
Gunb

He wrote it five messages before. See Reply #2463.

OK, thx!

Hmm, slowly this thread seems to need a TOC 

Hi,

Got my DSA 815-TG yesterday

I'm very happy with it, I upgrade it to the latest firmware version without problem and apply the options with the magic keygen without problems, now I leave it on to "clean" the trial versions, I suppose they will expire and disappear, it will be verified tomorrow.

eurofox

[tirulerbach]

Which firmware version is people having when taking a dump?, I want to upgrade, but not sure if one should dump before and after?

First make an upgrade, then make the dump...

[true]

Which firmware version is people having when taking a dump?, I want to upgrade, but not sure if one should dump before and after?

I might take a dump before or after the upgrade, just depends on the time of day.
But if you want to know if you should dump before or after, I would say during - get it started then go take a dump.

[gbot]

Hey All,

I am ready to pull the trigger on a DS2102A. Has anyone confirmed that the innards of the 2072A to the 2202A are identical? Would I be able to view 200MHz signals without issue with the 2102A - assuming the appropriate "patches" have been applied? I would be more than willing to dump the memory to help the cause.


Cheers!

[bluesmoke]

I would say during - get it started then go take a dump.

... It is hard to resist!

[tirulerbach]

good to know, all my computers use 64bit os, so I guess I'll try from an virtualmachine then

Good thing to try.  If it works out for you, definitely post about your success, because I'm sure that would make it easier for lots of folks.

I made my dumps on a 64 bit systems with no problems at all. I even don't think that 32/64 bit host makes any differences for a cross-toolchain. I suppose that the mentioned problems on that particular case had another cause and the conclusion that it is a 64 bit issue is simply wrong.

[granz]

I made my dumps on a 64 bit systems with no problems at all. I even don't think that 32/64 bit host makes any differences for a cross-toolchain. I suppose that the mentioned problems on that particular case had another cause and the conclusion that it is a 64 bit issue is simply wrong.

Well, I completely agree that it *shouldn't* make any difference at all.  The blackfin tools are literally the same pre-compiled binaries no matter what host you are on (they are 32-bit binaries).  The USB kernel-space driver could be very slightly different or something stupid with ioctl() is going on (this is my guess).  bfin-jtag/bfin-gdbproxy gets to the USB JTAG-cable device in this order: libftdi(user-space library)--->libusb(user-space library)--->usbfs(kernel-space driver).  Examining the bfin-jtag and bfin-gdbproxy binaries also shows that they have statically linked libusb and libftdi and they may have a problem such as this in the versions they used:

http://stackoverflow.com/questions/9258280/whats-different-between-compiling-in-32bit-mode-and-64bit-mode-on-64bit-os-abou

I've had these types of issues in the past with my own software at work.  I guess it's not really fair to say it's a 64/32 bit issue per se, probably more like a kernel compatibility configuration issue.  It's just easier to say 64 or 32-bit.

I'm curious: what variety/version of Linux did you use?

[Co6aka]

I suppose that the mentioned problems...had another cause...

FWIW, most of the 32-on-64 issues I've encountered turned out to be multiarch-related, and tracking them down and fixing them was not often straightforward... At least one was an upstream issue, which eventually got fixed; stuff just started working one day, immediately following an update. (Sometimes it's the other way around too... ) Typically stuff just didn't work or worked incorrectly, with no or little indication of why. Sometimes running GUI apps from the terminal provides a hint, as does pouring over the logs.

(One of my favorite source code comment-gems is "Error reporting could be better." No, REALLY?)

...statically linked libusb and libftdi...

"DLL Hell" of the Linux world.

[thinwire]

Rigol DS2000(A) series oscilloscopes: When installing an option with usbtmc :SYSTem:OPTion:INSTall or uninstall all options with :SYSTem:OPTion:UNINSTall I detected that all system settings are reset to the default  . To avoid this I wrote a linux command line utility to install/uninstall options with restoring system settings. It is based on libusb-1.0 and does not need a usbtmc kernel driver.

Install an option:

Code: [Select]

rigoltmc -o XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX

Uninstall all options:

Code: [Select]

rigoltmc -u

Identify the device:

Code: [Select]

rigoltmc -i
This should return something like:

RIGOL TECHNOLOGIES,DS2072A,DS2D15XXXXXXX,00.02.00


Have fun!