Author Topic: Sniffing the Rigol's internal I2C bus  (Read 1839177 times)

0 Members and 4 Guests are viewing this topic.

Offline granz

  • Regular Contributor
  • *
  • Posts: 136
  • Country: us
  • 6.62606957
Re: Sniffing the Rigol's internal I2C bus
« Reply #2400 on: January 10, 2014, 09:12:56 pm »
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.

 

Offline granz

  • Regular Contributor
  • *
  • Posts: 136
  • Country: us
  • 6.62606957
Re: Sniffing the Rigol's internal I2C bus
« Reply #2401 on: January 10, 2014, 11:26:42 pm »
For now I have only a Bus Pirate that can act as a slow JTAG device, but if needed I could buy a real JTAG programmer.

I don't think it's worth the time to try to use a Bus Pirate.  You need access to all of the memory available to the Blackfin DSP (BF526), so, the software needs to be aware of the specific bus interface (DRAM for example is attached to the BF526 but not directly to JTAG port).  Since JTAG is just a low-level generic interface, there is more involved in accessing the system.  The Blackfin toolchain uses a modified version of UrJTAG.  Have a look here for supported cables:

http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables

The blackfin-specific tools can be found at blackfin.uclinux.org.  For the least headache it probably makes sense to just use the provided dev tools.

Essentially you run a proxy server (bfin-gdbproxy) which uses the physical JTAG cable and is aware of the BF526 and acts as a server for gdb (GNU debugger).  Then you start up gdb and connect to the server (locally, but using TCP/IP).  In case you're not familiar with why this is the way it is: In the UNIX/Linux world it's fairly common practice to run a gdb server on an embedded system and then connect to it from a development host for debugging.  In this case, we just use JTAG for the physical interface and a local server to make gdb happy. 

Hope that helps.

-Chris
« Last Edit: January 11, 2014, 12:15:15 am by granz »
 

Offline granz

  • Regular Contributor
  • *
  • Posts: 136
  • Country: us
  • 6.62606957
Re: Sniffing the Rigol's internal I2C bus
« Reply #2402 on: January 11, 2014, 03:27:27 am »
OK, memory dumps complete!

I put everything in the same format that tirulerbach posted and followed the same procedure (only interaction was entering code AAAAAAA BBBBBBB CCCCCCC DDDDDDD and pressing apply once).

For some reason I couldn't get the processor instruction cache locations, but I got all dram, and everything else.  I see the dummy code in there when I look at it with a hex editor and also readable strings).

I did the initial dumps with my original firmware 00.02.00.00.04, then updated to 00.02.01.00.03 and did everything again.

Also, until a few days ago I had no experience with this or any Rigol product so I didn't realize that it didn't display full version number without following the procedure in marmad's thread.  I've done that, and updated the README.txt files in each package to match my information.  It's exactly the same as tirulerbach's except for being a DS2072A instead of a DS2202A.

I'm planning to re-assemble my scope now, because I'd like to use it again.  Before I do that is there anything else that would be useful to folks?

https://mega.co.nz/#!MhE22KKZ!Uj3JHCyWlyoLwRNBRO2QxBr46-9sZ1GlDnYA5A73I1Y

https://mega.co.nz/#!8lk2jDRT!do2XD3qit0R9Je7qBaY9GitFSfFUqG6zPuw5I0dDyaI

https://mega.co.nz/#!MpUTXKTS!X9H7S2fEccgtJ5S_xRhizQqIS2QG4XU8ETlDDqIj_yY

https://mega.co.nz/#!s0tHDKYY!RoQZ1XR5ecREZNLoEFXJkRJ_YFhdCeikPaEczS07pb4


 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 572
  • Country: dk
Re: Sniffing the Rigol's internal I2C bus
« Reply #2403 on: January 11, 2014, 09:59:19 am »
I'm planning to re-assemble my scope now, because I'd like to use it again.  Before I do that is there anything else that would be useful to folks?
People have asked for pictures of the  input stage and the SMD jumper settings earlier in this topic: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg352206/#msg352206
Someone can take a better picture of the DS2xxxA's input stage?    Apelly for example.
Busy, but I'll take a look in the next 48 hrs.
Ok, perfect, if you can take pictures of the rest, jumpers, DC / DC ...
Thanks.  :-+
No susprises.

These will have to do for now... The 'scpoe's still open, so can take more, but even a linux buff like me needed to look up a quick way to resize pics.

Just let me know what you want to see.
Can you take pics of the jumper resistor divider just by the battery. Thanks
Jumpers:

HW v1.0:


A or v2.0:

« Last Edit: January 11, 2014, 10:14:38 am by AndersAnd »
 

Offline tirulerbach

  • Contributor
  • Posts: 33
Re: Sniffing the Rigol's internal I2C bus
« Reply #2404 on: January 11, 2014, 11:36:28 am »
Thank you for the dumps. They look good.

I'm planning to re-assemble my scope now, because I'd like to use it again.  Before I do that is there anything else that would be useful to folks?

People are asking for the JTAG connection and so on. Maybe some photos how and where to connect the JTAG dongle are useful.

Beside this, dumps with the old firmware 00.02.00.00.04 are not needed, as far as I know.

Regarding the keygen: Basically it is finished and work nice. Release date: TBD.
 

Offline Pehtoori

  • Contributor
  • Posts: 21
  • Country: 00
Re: Sniffing the Rigol's internal I2C bus
« Reply #2405 on: January 11, 2014, 12:05:39 pm »

I don't think it's worth the time to try to use a Bus Pirate.  You need access to all of the memory available to the Blackfin DSP (BF526), so, the software needs to be aware of the specific bus interface (DRAM for example is attached to the BF526 but not directly to JTAG port).  Since JTAG is just a low-level generic interface, there is more involved in accessing the system.  The Blackfin toolchain uses a modified version of UrJTAG.  Have a look here for supported cables:

http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables

8< snip 8<

Ohh crap  |O

  • Order scope [check]
  • Order JTAG-adapter [check] (TIAO USB)
  • Learn that you likely ordered wrong adapter [check]

I decided to help and open my upcoming scope. Ordered TIAO USB Multi-Protocol Adapter (JTAG) to get memory dump from it. Now I learn that I need specific adapter for uclinux :(

This is one reason why its hard to get those dumps! Not really good instructions for the noobs (like me).

Had someone writen instructions like:
Order this adapter from here! (check that its available around the world)
And connect it to scope pins like this (pictures and diagram)
Download this software from here
Run these commands
Send this file to here

Yes this information is available here and around the net, but its really hard to noobs (like me) to piece this all together and get the results we need. And yes I have read this thread trough and some others but didn't find single post that describes all needed steps in one post.


Second note: Those pics of all options enabled seem to speed up people getting those dumps done  8)
 

Offline Pinkus

  • Frequent Contributor
  • **
  • Posts: 773
Re: Sniffing the Rigol's internal I2C bus
« Reply #2406 on: January 11, 2014, 12:12:02 pm »
Pehtoori wrote down my (and probably many others) thoughts.
 

Offline AndersAnd

  • Frequent Contributor
  • **
  • Posts: 572
  • Country: dk
Re: Sniffing the Rigol's internal I2C bus
« Reply #2407 on: January 11, 2014, 12:33:41 pm »
The Blackfin toolchain uses a modified version of UrJTAG.  Have a look here for supported cables:
http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables
Ohh crap  |O

  • Order scope [check]
  • Order JTAG-adapter [check] (TIAO USB)
  • Learn that you likely ordered wrong adapter [check]

I decided to help and open my upcoming scope. Ordered TIAO USB Multi-Protocol Adapter (JTAG) to get memory dump from it. Now I learn that I need specific adapter for uclinux :(
TIAO USB works with UrJTAG according to this: http://www.tiaowiki.com/w/Program_FPGA_Using_urJTAG
So I think it should work for making a Rigol memory dump.

TIAO USB is based on FTDI FT2232H and most of the FT2232-based JTAG interfaces seems to work with UrJTAG. Not all of them are listed at http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables but many of them are clones or very similar to each other. UrJTAG just mentions this, to cover FT2232-based USB JTAG adapters not listed:
Quote
Other FT2232-based USB JTAG cables (experimental)
« Last Edit: January 11, 2014, 12:42:16 pm by AndersAnd »
 

Offline tirulerbach

  • Contributor
  • Posts: 33
Re: Sniffing the Rigol's internal I2C bus
« Reply #2408 on: January 11, 2014, 12:41:32 pm »
This is one reason why its hard to get those dumps! Not really good instructions for the noobs (like me).

That's life. No pain no gain. It's your chance to improve the situation: Start a tutorial, you already learned some pieces!
 

Offline NikWing

  • Regular Contributor
  • *
  • Posts: 139
  • Country: de
Re: Sniffing the Rigol's internal I2C bus
« Reply #2409 on: January 11, 2014, 12:43:02 pm »
*looks at tirulerbach with puppy eyes*

^^;
 

Offline battlefield

  • Newbie
  • Posts: 8
Re: Sniffing the Rigol's internal I2C bus
« Reply #2410 on: January 11, 2014, 12:51:08 pm »
Ok so I'm getting myself an JTAG cable but its not listed on that page. Mine is Olimex ARM-USB-OCD, now can someone please tell me if it will work or not?
 

Offline Pehtoori

  • Contributor
  • Posts: 21
  • Country: 00
Re: Sniffing the Rigol's internal I2C bus
« Reply #2411 on: January 11, 2014, 01:15:36 pm »
This is one reason why its hard to get those dumps! Not really good instructions for the noobs (like me).
That's life. No pain no gain.

If you know me, you would not say that  >:D I'm sick, in constant pain and can't work because of it. But np you don't know me.

But you miss the point, what I mean is that many people have written instructions on parts of the process, but there is no complete process collected in one place. Would be much easier to point people to that document than write answers over and over again.

Reduce pain, get more gain.  O0

Quote
It's your chance to improve the situation: Start a tutorial, you already learned some pieces!

Waiting for my scope and JTAG-adapter from customs. If I can make the dump and I have energy (sickness eating it) I will do this.
 

Offline buergi

  • Newbie
  • Posts: 1
Re: Sniffing the Rigol's internal I2C bus
« Reply #2412 on: January 11, 2014, 03:59:55 pm »
Hey,
as it took me many hours to gather all the information needed to memdump my DS2KA I'd like to give a short summary to lower the pain for the gain. So here we go.

First of all the principles. Rigol implemented a lot of feature in the scopes that are artificially restricted to work only for a 4000 minutes trial period. After that time you have the opportunity reenable them forever by purchasing license keys from Rigol. These license keys are bound to each specific device via its serial number.

License verification mechanism

Thanks to zombie28's great work he managed to reconstruct the way the signature verification works.
To give you a short overview I'll rougly summarize the mechanism in the following for all the details check out zombie28's code.
The License Key contains the desired options as well as a signature. With this signature the manufacturer signs that the scope with the serial number the license key was generated for is allowed to use the options. The following diagram depicts the process (I dropped some details for simplicity). For details about ECDSA I recommend you kakaroto's blog post.


To verify the signature the scope needs the following information, that thus need to be stored in its memory
  • two RC5 keys to decrypt the signature
  • XXTEA key to encrypt the serial and option codes with
  • ECC Parameters: a, b, p, N, G
  • The scopes public key
For generating signatures we furthermore need the Private key which is not stored in the memory.
Usually the whole sense of public-key crypto algorithms is that you cannot calculate the private from the public key (besides brute force of course). I'm not sure how but it seems tirulerbach has it's tricks: his ecc-smash tool seems to generate the key in milliseconds .

So tirulerbach can now generate valid license codes for us, BUT unfortuately the RC5,XXTEA and public keys differ between the devices. It is currently not known if there is some hidden scheme between the different devices. Thats why currently we have to provide memory dumps to tirulerbach (and to zombie28?). But how to get them?

Memory dumping

Fortunatelly Rigol has integrated a fully functional JTAG debug port to the Blackfin BF526 which is responsible for all the crypto stuff. So all we need to do is to connect to it and grab the dump. However not all of as are JTAG-lords and a big question mark hovers over the heads of a lot of us :D So here comes a step by step guide:

Requirements
  • DS2000A scope with any firmware (you don't need to downgrade!) I use a DS2072A with HW 2.0, SW 00.02.00
  • Torx T10 screw driver
  • A compatible JTAG adapter
    Actually all of them should work, however some are faster and some are slower. The following are known to work
  • A linux or window computer
  • A 3.9k and 10k resistor
  • Some wire (preferably jumper wires)
  • A breadboard or a soldering iron

I'm one of those nerds who owns an OpenMoko phone including debug board and never knew what to do with it now the time has come to brush the dust of my good old OpenMoko Debug Board v3. It includes a FT2232 compatible JTAG connector with a usual ARM 20 pin connector.


Step by Step Guide
  • 1. Void if broken Try removing the 'warrany void if broken' sticker like shown in . The metal layer of the sticker peals of extremely easy so be careful and if it nevertheless breaks don't worry and read this
  • 2. Open up the beast There are 4 T10 screws, two at the bottom and two behind the handle.
  • 3. Unmount the shield There are 8 T10 screws, 4 at the top, 4 at the bottom. Moreover you have to remove the nut arround the BNC connector before pulling of the shield.
  • 4. Find the JTAG connector it is a 2x7 pinhead with pin 3 missing
  • 5. Wiring Now comes the little more complicate part: use the jumper wires, breadboard and the resistors and connect the JTAG port to your adapter.

    I feel that this step demands some further clarification. The image shows the connector on the board, the missing pin is marked with an X. You have to connect the TMS, TCLK, TRST, SRST, TDI, TDO, GND to your JTAG adapter, check its datasheet for its pinout (the most ones have an ARM 20 pin connector). Ignore the confusing pin UTST I guess cybernet used it just to probe the voltage. The two pull-up resistors have to be added externaly. I used a bread board for the wiring, check out the attached image. And one last point: the 3.3V on Pin 1 are not an output, you need to provide them. However, there are multiple pins where you can steal this voltage. I used the 4 pin connector on the opposite side of the PCB labeled VCC.
  • 6. Download and install bfin toolchain Download here. For linux you can choose one blackfin-toolchain or blackfin-toolchain-elf, it doesn't matter. I used linux and blackfin-toolchain-2013R1_45-RC1.x86_64.tar.bz2, unpack with tar xjf blackfin-toolchain-2013R1_45-RC1.x86_64.tar.bz2
  • 7. Power up your scope Switch on your scope, and wait a moment until it's running.
  • 8. Start the gdbproxy Open a command line cd to the bin directory and execute bfin-gdbproxy like the following.
    If errors occur try lowering the frequency or unplug/replug your JTAG adapter.
Code: [Select]
# cd opt/uClinux-45/bfin-uclinux/bin
# sudo ./bfin-gdbproxy --debug bfin --frequency=5000000
Found USB cable: USB-JTAG-RS232
Connected to libftdi driver.
IR length: 5
Chain length: 1
Device Id: 00100010011111100100000011001011 (0x227E40CB)
  Manufacturer: Analog Devices, Inc. (0x0CB)
  Part(0):      BF526 (0x27E4)
  Stepping:     2
  Filename:     ./../share/urjtag/analog/bf527/bf527
warning: USB-JTAG-RS232: untested cable, set wait_clocks to 30
warning:   bfin: no board selected, BF526 is detected
notice:    bfin: jc: waiting on TCP port 2001
notice:    bfin: jc:  (you must connect GDB before using jtag console)
notice:    bfin-gdbproxy: waiting on TCP port 2000

  • 9. Test GDB Keep the bfin-gdbproxy running in background and open a second command line window, cd into the directory and launch gdb like below.
    The manual of the BF526 describes the meening of the different memory regions on page 115&116.
Code: [Select]
# cd opt/uClinux-45/bfin-uclinux/bin
# ./bfin-uclinux-gdb
(gdb) target remote :2000
Remote debugging using :2000
0xffa0142e 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

  • 10. Dump the memory
    The part of the memory that contains the keys is the SDRAM (0x00000000 0x07FFFFFF). To dump it hack the following command into gdb.
    dump binary memory ~/ds2k_00_sdram.bin   0x00000000 0x07FFFFFF
    Depending on your JTAG adapter this might take you 15min or even some hours. With my adapter it took roughly an hour. You can check the progress in the gdbproxy terminal window: when started with --debug it outputs the address range of the dumped blocks.

    If you want to dump GDB script below (only tested on linux). Save the code below as memdump.gdb and run
    ./bfin-uclinux-gdb --batch --comand=~/memdump.gdb
Code: [Select]
target remote :2000
dump binary memory ~/ds2k_00_sdram.bin   0x00000000 0x07FFFFFF
dump binary memory ~/ds2k_01_abank0.bin  0x20000000 0x200FFFFF
dump binary memory ~/ds2k_02_abank1.bin  0x20100000 0x201FFFFF
dump binary memory ~/ds2k_03_abank2.bin  0x20200000 0x202FFFFF
dump binary memory ~/ds2k_04_abank3.bin  0x20300000 0x203FFFFF
dump binary memory ~/ds2k_05_boot.bin    0xEF000000 0xEF007FFF
dump binary memory ~/ds2k_06_dbankA.bin  0xFF800000 0xFF803FFF
dump binary memory ~/ds2k_07_dbankAc.bin 0xFF804000 0xFF807FFF
dump binary memory ~/ds2k_08_dbankB.bin  0xFF900000 0xFF903FFF
dump binary memory ~/ds2k_09_dbankBc.bin 0xFF904000 0xFF907FFF
dump binary memory ~/ds2k_10_ibankA.bin  0xFFA00000 0xFFA07FFF
dump binary memory ~/ds2k_11_ibankB.bin  0xFFA08000 0xFFA0BFFF
dump binary memory ~/ds2k_12_ibankC.bin  0xFFA10000 0xFFA13FFF
dump binary memory ~/ds2k_13_scratch.bin 0xFFB00000 0xFFB00FFF

  • 11. YEAAH you made it Now zip it e.g.
    tar cJf ds2k_memdump.tar.xz ~/ds2k*
    upload it to some one-click hoster and send the link to tirulerbach.

If you are nice to tirulerbach he'll send you a bunch of license keys which you can enter either directly on the scope via Utility>Options>Setup>Editor ON or using
SCPI :SYSTem:OPTion:INSTall <keyhere>

Hope this guide helped you and you will all diligently commit your memory dumps.
Good luck, have fun with your scopes and happy hacking.

Changelog
2014-01-11 Initial post
2014-01-12 Inline attached images. Add some additional clarifications based on comments. Add list of working JTAG adapters.
« Last Edit: January 12, 2014, 03:09:42 pm by buergi »
 

Offline tirulerbach

  • Contributor
  • Posts: 33
Re: Sniffing the Rigol's internal I2C bus
« Reply #2413 on: January 11, 2014, 04:33:34 pm »
Thank you buergi for your tutorial  :-+

For generating signatures we furthermore need the Private key which is not stored in the memory.
Usually the whole sense of public-key crypto algorithms is that you cannot calculate the private from the public key (besides brute force of course). I'm not sure how but it seems tirulerbach has it's tricks: his ecc-smash tool seems to generate the key in milliseconds.
To be precisely, it takes about 70ms on my machine...  :-DD

But that's not the point. I only searched the internet and ripped some tools together. In the meantime, my license generator evolved and is ready. Now it goes to beta test to selected people...  8)

For a appetizer look at the screenshot. Total running time is about 300ms...   O0

« Last Edit: January 11, 2014, 04:36:30 pm by tirulerbach »
 

Offline marmad

  • Super Contributor
  • ***
  • Posts: 2979
  • Country: aq
    • DaysAlive
Re: Sniffing the Rigol's internal I2C bus
« Reply #2414 on: January 11, 2014, 04:53:57 pm »
Hey,
as it took me many hours to gather all the information needed to memdump my DS2KA I'd like to give a short summary to lower the pain for the gain. So here we go.

Nice summary. andyturk (the OP) should copy and paste a link to this post in the first post of the thread.
 

Offline granz

  • Regular Contributor
  • *
  • Posts: 136
  • Country: us
  • 6.62606957
Re: Sniffing the Rigol's internal I2C bus
« Reply #2415 on: January 11, 2014, 05:05:34 pm »
Nice tutorial buergi!  I was going to write something up, but you've saved me the trouble and it looks excellent.

I've reassembled my scope at this point but I took pictures of lots of stuff first, including smd jumpers and the input stage.  As I have a busy weekend, I'll have to unload those and post them tomorrow.

In regards to the JTAG adapters, most any FTDI2232 based atapter *should* work.  I used a cheap knock-off Altera adapter, which is based on that chip (see image).  They've removed the markings for whatever reason (WHY bother on a < $10 imitation product??), but it uses the ftdi driver.

One thing to check with whatever adapter you might have is the signal levels--you don't want to attach a 5V adapter to the board.  There is no real standard for JTAG.  The better adapters (for example, the Amontec JTAGKey) use the the VTref pin to set the signal levels (This is likely the purpose of the 3.3V on the DS2000 JTAG header).  The easiest thing to do is use your scope (before opening it!) to probe the JTAG adapter TCK line and then start up bfin-gdbproxy.  If you get nothing, your adapter might need a VTref input.  No matter what, check the levels on all of the pins before connecting to your scope's header...

Also, you don't absolutely have to connect the target reset and system reset lines to your adapter (nTRST and nSRST), just having the pull-ups on them is fine.  My adapter actually was trying to drive these pins high, so I didn't connect them and just left the pullups to the board's supply.

Happy dumping!

« Last Edit: January 11, 2014, 05:19:33 pm by granz »
 

Offline thinwire

  • Newbie
  • Posts: 2
Re: Sniffing the Rigol's internal I2C bus
« Reply #2416 on: January 11, 2014, 05:23:18 pm »
buergi, excellent summary!  :-+ :-+ :-+
I would have two more questions:
Are still two dumps necessary or is it sufficient to dump after a normal boot?
Is a specific firmware version needed? Will 00.02.00.00.04 be fine?
 

Offline Pehtoori

  • Contributor
  • Posts: 21
  • Country: 00
Re: Sniffing the Rigol's internal I2C bus
« Reply #2417 on: January 11, 2014, 05:40:48 pm »
Hey,
as it took me many hours to gather all the information needed to memdump my DS2KA I'd like to give a short summary to lower the pain for the gain. So here we go.

Thx buergi this is what I meant! Even shorter text would have done it.

And thx to cybernet, tirulerbach, zombie28, marmad and many more! (Not exhaustive list, sorry, can't remember all)

Now I wait to get my scope and adapter.
 

Offline van-c

  • Regular Contributor
  • *
  • Posts: 69
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #2418 on: January 11, 2014, 07:02:53 pm »
I have a Rigol DS2072 (HW 2)

With this version is available the 300MHz BW Option, but i have read that 200MHz BW option give more performance in LF than 300MHz in HW 1. Is the same for HW 2 or i can Install 300MHz BW with no problem in my HW 2?
For HW 2 use 300 MHz.

I have read about newest code for enable 300MHz and CAN, but not understand what enable each code. I have read about DSHH, DSGH etc.
I search for: 200MHz + All Option (include CAN), 300MHz + All Option.
Use DSHH for HW 2 (300 MHz with all options).
Use this keygen http://riglol.3owl.com

Has it actually been verified that the HW 2 version with 300 MHz enabled does not have the overshoot and stability problems demonstrated for HW 1?  Did someone post a graph showing the HW 2 frequency response?  I have re-checked the thread but may have missed it.

--Van
 

Offline sled

  • Contributor
  • Posts: 21
  • Country: ch
Re: Sniffing the Rigol's internal I2C bus
« Reply #2419 on: January 11, 2014, 08:31:50 pm »
I have an Arduino Leonardo and a Teensy 3.1 lying around, maybe I can code/build my own urjtag compatible adapter, doesn't seem to be that hard :)

Is anyone else interested in such a thing?
 

Offline ZeroAviation

  • Contributor
  • Posts: 34
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #2420 on: January 11, 2014, 08:39:10 pm »
@buergi

Epic first post!!!!

Cheers!
 

Offline tirulerbach

  • Contributor
  • Posts: 33
Re: Sniffing the Rigol's internal I2C bus
« Reply #2421 on: January 11, 2014, 10:17:36 pm »
Ok so I'm getting myself an JTAG cable but its not listed on that page. Mine is Olimex ARM-USB-OCD, now can someone please tell me if it will work or not?

Works. I made the dump using this one. The only caveat was the 3.3 Volt reference. The 3.3V reference on the DS2202A JTAG header was to weak for the ARM-USB-OCD. I used 3.3V from a header in the vicinity of the BNC socket:

There is a "SPI BOOT" header oh the right side of the PCB. Pin 7 has 3.3 Volts and it works...

I didn't use any pullup resistors etc. but just connected the ARM-USB-OCD straight to the DS2202A using short (about 6cm) jump-wires and set the JTAG speed to 6 MHz. Dump took about 15 minutes. Too bad, I made no photos.
« Last Edit: January 11, 2014, 10:25:51 pm by tirulerbach »
 

Offline elecBlu

  • Contributor
  • Posts: 25
Re: Sniffing the Rigol's internal I2C bus
« Reply #2422 on: January 11, 2014, 10:21:51 pm »
Has it actually been verified that the HW 2 version with 300 MHz enabled does not have the overshoot and stability problems demonstrated for HW 1?  Did someone post a graph showing the HW 2 frequency response?  I have re-checked the thread but may have missed it.

--Van

did some tests but i'm not able to do a proper frequency response chart during some problems with my generator. check my older posts for details and 300MHz measurements.
 

Offline andyturkTopic starter

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #2423 on: January 12, 2014, 04:09:05 am »
Nice summary. andyturk (the OP) should copy and paste a link to this post in the first post of the thread.

Good idea. Done.
 

Offline cybermaus

  • Frequent Contributor
  • **
  • Posts: 674
  • Country: nl
Re: Sniffing the Rigol's internal I2C bus
« Reply #2424 on: January 12, 2014, 11:36:23 am »
Minor correction to my previous post after some further investigation.

DSHA also enables the 500uV setting and another unknown, (at present), option.

Just a report back in case others DS1074Z users are searching for it: The unknown DSCA option does not seem to be related to the signal generator.

As I had the less common -S model I was thinking (hoping) the unknown option was related to the signal gen, which means most people would not notice its effect. So I memorized all the signal menu and inserted the option. But I found no extra menu or option afterward. (Especially I was hoping for  a SWEEP option, that is a big miss in the SG functionality)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf