Products > Test Equipment
Sniffing the Rigol's internal I2C bus
Macbeth:
I had a whale of a time trying to get Blackfin toolchain working with Olimex ARM-USB-OCD on Win 8/10. I gave up.
I did get it running on Ubuntu, though for some reason when using the bfin-* commands like bfin-urjtag vs the plain old urjtag found in the Ubuntu repositories, I find all my cursor keys and history turn into escape characters instead of working normally. It's really annoying!
I also have to run everything using sudo. I've seen some workarounds for this, using udev rules, but they don't seem to work with newer Ubuntu versions. :(
Any hints on getting it working seamlessly with Ubuntu 16.04 LTS?
OsiViper:
I got this one "blackfin-toolchain-2014R1_45-RC2.x86_64.tar.bz2" , and I use the tools under /opt/uClinux/bfin-uclinux/bin and it seems to work just fine for me. The dumping that is.
I am having a problem though, I have done 3 dumps and when I do "sudo ./rigup scan ds2k_00_sdram.bin" it tells me that there are no keys found.
--- Code: ---:~$ sudo ./rigup scan ds2k_00_sdram.bin
rigup scan - Version 0.4.1
Hacked up for MSO1000Z(-S) rmd79, 0ff eevblog.com
Scanning 'ds2k_00_sdram.bin' failed: No keys
--- End code ---
OsiViper:
Well, I learned something.. I got it working for the MSO2072A.. Aparently Rigup 0.4.1 will not work for it, I downloaded Rigup 0.4.0 and it generated the keys just fine. Got a 200 MHz scope now with all the options.. Thanks everyone for the info here
pvico:
Did anybody have any luck with the DS1xxxZ Plus?
I have a very recent DS1104Z Plus with SN DS1ZCxxxxxxxxx, software 00.04.03 SP2, board 2.1.1 & boot loader 0.0.1.4.
I spent more than 2 full days doing the following:
I obtained the dump file with an Olimex ARM-USB-OCD-H.
I compiled rigup-0.4.1-mso1000z (I did it both on Mac OS X and Ubuntu 14, they give the same results).
A rigup scan of the dump file gives apparently correct keys and the SN is correct, but the licenses generated with 0x1C00x are all invalid.
Looking into my dump file, the only long string that could be a character map is "ABCDEFGH234JKLMNPQR567STUVWXYZ89", so I replaced all instances of charMapDecode and charMapEncode in encode.c and decode.c with that string. The licenses are still invalid.
IMHO, the causes could be:
- Codes other than 0x1C00x are needed
- The private key is not correct. This is a bit scary: the code to transform the public key into a private key is quite complex (using of the MIRACL library) and there are a lot of 'magic' values involved (the ECC parameters in solver.c). Is there any way to verify if these values are still ok?
- A completely different encoding method has been used for this model (I hope not)
In the dump file, there are a few 28 character strings (with characters in ABCDEFGHJKLMNPQRSTUVWXYZ23456789) which are, I guess, the trial licenses.
Should they verify with rigup info (they don't)?
I played a bit with rigup-0.4.0, tried to apply the patches but that did not work either.
Many thanks to anybody who could answer some of these questions.
arobincaron:
Here's my experience "testing" the ability to setup MSO1074z scope option capabilities:
I do not have a JTAG cable to get a memory dump. I researched alternatives (USB Blaster, Bus Pirate, etc) and I saw the following: https://github.com/synthetos/PiOCD/wiki/Using-a-Raspberry-Pi-as-a-JTAG-Dongle. As I use Windows 10 I liked the idea of avoiding driver issues by using openocd on Linux.
I purchased a Raspberry Pi 3 (thanks Amazon for same day delivery!). I hooked it up and followed the instructions from the article to get openocd compiled. I removed the 2 references to "--enable-ft2232_libftdi" as "configure" indicated that that driver is obsolete and I wasn't planning on using it anyway. I stopped following the instructions where downloading of the tcl script (i.e. "sudo wget https://gist.github...") is indicated as from there the instructions are for connecting the Pi to an Arduino Due.
With the Raspberry Pi and openocd ready I proceeded to open the scope as documented by others. I initially attempted to remove the warranty sticker using a plastic instrument only. After seeing some label separation I used a heat gun on low heat to soften the glue. It was much easier that way. I highly recommend using heat!
To figure out how to connect the Raspberry Pi GPIO pins to the scope JTAG port I used info from the article above, the scope JTAG information in https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg720691/#msg720691, reviewed the sysfsgpio-raspberrypi.cfg interface file and http://pinout.xyz/pinout/uart. Here's what I came up with:
JTAG signalScope Header PinPi GPIO SignalPi Header PinTCK11123TMS32522TDI51019TDO4921TRST71126Gnd8Gnd25
I used very short cables (~6 inches) and quadrupled checked my connections as I was a bit paranoid about wrecking the scope processor. You should verify yours too :)
I started openocd using the following command line:
openocd -d2 -f interface/sysfsgpio-raspberrypi.cfg -f target/imx28.cfg
I installed telnet (sudo apt-get install telnet) and connected to openocd using:
telnet localhost 4444
Next turned the scope on. Once I saw the scope options screen I tried to halt the processor from the telnet session (i.e. "halt") but got an error saying that openocd could not communicate with the target. I checked the scope and it was clearly not stopped. I turned off the scope, reviewed my wiring. Everything was ok so I reviewed the openocd output and noticed an error in the openocd logging during startup indicating that it couldn't setup events. I surmised that openocd expected to be able to communicate with the target right from the get go so I decided to start the scope first and then start openocd.
That sequence worked and I was able to halt the processor. I did a small (4KB) memory dumps. The contents looked binary so I figured it was probably ok. The download rate was 6KB/s. I tried using various commands I found to turn up the speed (e.g. adapter_khz) but it appeared that those are not implemented by the Raspberry PI GPIO interface. I tried a larger dump of 1MB and found the rate consistent. That meant the required 64MB dump was going to take 3 hours.
I started the dump. As the scope case was not closed I decided to check whether anything was running hot. The device with a heatsink was running at ~130F so I hooked up a case fan to push air towards it and it cooled to ~90F. After ~3 hours the dump completed.
I built rigup 0.4.1 for the MSO1000Z using the content at http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip. Note that you need to change the makefile replacing "-dead_strip" with "--gc-sections -s". I used make clean to remove the existing/prebuild objects. I then used rigup to scan for the various keys. That worked! Next I generated a key for the triggers option (0x1c001). I double checked the key and input it in the scope. The scope accepted the key -- those options now showed "Official". I generated the other keys (0x1c002, 0x1c004, 0x1c008 and 0x1c080) and input them. I made a few mistakes inputting the keys in the scope so some were initially rejected but after correction all were accepted. I restarted after adding the last one (0x1c080 - Bandwidth) and now the scope reported itself as an MSO1104z with all options "Official".
I am thankful for all those who figured out the JTAG pin out, how to get the keys from the dump, wrote rigup. Thank you also to all who documented their experience to make mine possible -- it's great that this community exists!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version