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

0 Members and 3 Guests are viewing this topic.

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3700 on: December 10, 2014, 10:22:54 pm »
I don't think the SCPI READ works on the DS/MSO1000Z series scopes, you're going to need to open it up and pop a JTAG adapter on there like an OpenOCD.
 

Offline swanawood

  • Contributor
  • Posts: 16
Re: Sniffing the Rigol's internal I2C bus
« Reply #3701 on: December 11, 2014, 08:20:22 am »
I don't think the SCPI READ works on the DS/MSO1000Z series scopes, you're going to need to open it up and pop a JTAG adapter on there like an OpenOCD.

Oh ! I didn't catch that before ....

Ok, can you (or somebody else) confirm that the Jtag connector is the one in picture at post #3530 by rmd79 , also for DS1054Z ? (in the reply he speaks over "MSO1074Z-S") ....

And also that the correct jtag is this ? :

https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/

Thanks
 

Offline 0ff

  • Contributor
  • Posts: 10
Re: Sniffing the Rigol's internal I2C bus
« Reply #3702 on: December 11, 2014, 09:16:17 am »
Yes, I can confirm that.
 

Offline swanawood

  • Contributor
  • Posts: 16
Re: Sniffing the Rigol's internal I2C bus
« Reply #3703 on: December 11, 2014, 09:20:06 am »
Yes, I can confirm that.

Thank you sir.

 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3704 on: December 11, 2014, 09:28:22 am »
I don't think the SCPI READ works on the DS/MSO1000Z series scopes, you're going to need to open it up and pop a JTAG adapter on there like an OpenOCD.

Oh ! I didn't catch that before ....

Ok, can you (or somebody else) confirm that the Jtag connector is the one in picture at post #3530 by rmd79 , also for DS1054Z ? (in the reply he speaks over "MSO1074Z-S") ....

And also that the correct jtag is this ? :

https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/

Thanks

That is the one, FWIW Farnell part number 2279910 is what I have.

You'll need to make up an adapter from the 20 pin cable of the debugger to the 10 pin header on the board.

The pinout presented in the following post from sptm14 appears correct.

Quote
top row: tck,tms,tdi,trst,3.3v
bottom row: XXX,tdo,srst,gnd,gnd

Here is mine...



The "TL" written above on the DIY adapter board indicates "Top Left" for orientation mating with the header on the board.



Pin 1 of the 20 pin is on the upper left of that connector in the second image.

The RAM in the memory map is 0x40000000 to 0x43ffffff, and it takes about 20 minutes or so to dump. I found I had to specify the jtag speed (adapter_khz) to make it work. In addition, you must stop the CPU before taking the RAM dump. It's been a few months since it so I'm afraid I'm a bit rusty as to the exact steps to take.

I ran openocd in Windows, together with gdb in a VMWare Ubuntu guest. Here is the command line I used:

Code: [Select]
G:\source\rigol\openocd-0.8.0\openocd-0.8.0>bin-x64\openocd-x64-0.8.0.exe -f ./interface/ftdi/olimex-arm-usb-ocd-h-hl.cfg -f ./target/imx28.cfg
Contents of ./interface/ftdi/olimex-arm-usb-ocd-h-hl.cfg

Code: [Select]
#
# Olimex ARM-USB-OCD-H
#
# http://www.olimex.com/dev/arm-usb-ocd-h.html
#

interface ftdi
ftdi_device_desc "Olimex OpenOCD JTAG ARM-USB-OCD-H"
ftdi_vid_pid 0x15ba 0x002b
adapter_khz 6000

ftdi_layout_init 0x0c08 0x0f1b
ftdi_layout_signal nSRST -oe 0x0200
ftdi_layout_signal nTRST -data 0x0100 -noe 0x0400
ftdi_layout_signal LED -data 0x0800


« Last Edit: December 11, 2014, 09:31:48 am by Howardlong »
 

Offline 0ff

  • Contributor
  • Posts: 10
Re: Sniffing the Rigol's internal I2C bus
« Reply #3705 on: December 11, 2014, 09:50:49 am »
Howard, thank you for your writeup, this is really helpful!

I only have 2 additions: You can vastly shorten your config to a single file like this: (and note the increased kHz, the olimex and scope can handle this without any error).
Code: [Select]
source [find interface/ftdi/olimex-arm-usb-ocd-h.cfg]
source [find target/imx28.cfg]
adapter_khz 20000

Then you run it as you said, but for dumping the memory there's no need at all to use gdb. Instead, you can dump it from the openOCD Telnet session like this:
Code: [Select]
$ telnet 127.0.0.1 4444
> halt
> dump_image your_filename_here.bin 0x40000000 0x3FFFFFF

It should take about ~7min to complete at the higher adapter speed.
 

Offline swanawood

  • Contributor
  • Posts: 16
Re: Sniffing the Rigol's internal I2C bus
« Reply #3706 on: December 11, 2014, 10:18:55 am »
WOW!

Thank you so much for the info!
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3707 on: December 11, 2014, 10:24:55 am »
Howard, thank you for your writeup, this is really helpful!

I only have 2 additions: You can vastly shorten your config to a single file like this: (and note the increased kHz, the olimex and scope can handle this without any error).
Code: [Select]
source [find interface/ftdi/olimex-arm-usb-ocd-h.cfg]
source [find target/imx28.cfg]
adapter_khz 20000

Then you run it as you said, but for dumping the memory there's no need at all to use gdb. Instead, you can dump it from the openOCD Telnet session like this:
Code: [Select]
$ telnet 127.0.0.1 4444
> halt
> dump_image your_filename_here.bin 0x40000000 0x3FFFFFF

It should take about ~7min to complete at the higher adapter speed.

That rings a bell, forget what I said about gdb, sorry for the bum steer, the old memory ain't what it used to be! I can't remember what I had to do to stop the CPU I'm afraid, but you do need to do it or the dump won't work.
 

Offline 0ff

  • Contributor
  • Posts: 10
Re: Sniffing the Rigol's internal I2C bus
« Reply #3708 on: December 11, 2014, 10:25:54 am »
Well, you can halt it by just saying "halt" :)
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3709 on: December 11, 2014, 10:45:27 am »
Oh, you mean like you wrote then. Doh! Sorry, hadn't noticed your halt command. I'll just settle back to my demented old self!
 

Offline swanawood

  • Contributor
  • Posts: 16
Re: Sniffing the Rigol's internal I2C bus
« Reply #3710 on: December 11, 2014, 11:09:50 am »
Well, you can halt it by just saying "halt" :)

YEP,

as we use to say : "the devil is in details..."

ahah !
 

Offline swanawood

  • Contributor
  • Posts: 16
Re: Sniffing the Rigol's internal I2C bus
« Reply #3711 on: December 11, 2014, 01:33:28 pm »
I have a doubt:

the SRST and TRST are cross connected ?

i overlayed the picture with labels, and following the wires, this is what I am ending up... Is it correct ?
(follow the wire going from 10pin connector SRST that seems to go to TRST pin into 20pin connector...)

Thanks

 

Offline 0ff

  • Contributor
  • Posts: 10
Re: Sniffing the Rigol's internal I2C bus
« Reply #3712 on: December 11, 2014, 01:35:02 pm »
In fact you can just leave SRST unconnected on the scope.
It will power on on it's own.

You just can't reset it from openOCD in this configuration.
 

Offline rmd79

  • Contributor
  • Posts: 18
  • Country: au
Re: Sniffing the Rigol's internal I2C bus
« Reply #3713 on: December 11, 2014, 01:39:48 pm »
I have a doubt:

the SRST and TRST are cross connected ?

If it helps, here's a picture (attached) of the cable I use with my MSO1074Z-S and OpenOCD.  I can reset from within OpenOCD.  If I remember correctly, I just connected the signals straight through.
 

Offline swanawood

  • Contributor
  • Posts: 16
Re: Sniffing the Rigol's internal I2C bus
« Reply #3714 on: December 11, 2014, 01:42:30 pm »
In fact you can just leave SRST unconnected on the scope.
It will power on on it's own.

You just can't reset it from openOCD in this configuration.

So , to recap :

to be able to reset from openOCD I need to cut the wire going to pin SRST of the 10 pi header ? (and the TRST is still connected from 10 pin header to SRST of 20 pin header)

Correct ?
 

Offline soft4gsm

  • Newbie
  • Posts: 2
Re: Sniffing the Rigol's internal I2C bus
« Reply #3715 on: December 11, 2014, 09:45:35 pm »
Hello,
I plan to buy one of the following oscilloscopes:
MSO2072A, DS2072A. I'm not sure which one, prefer MSO, but DS is fine too.
1. If it comes with latest software / hardware version, can I use JTAG and memory dump method? Is it working or not?
2. I have SEGGER J-link JTAG. Is it fine, or I should buy other one like olimex for example?
Help me please.
Thank You!
 

Offline thn788

  • Contributor
  • Posts: 30
Re: Sniffing the Rigol's internal I2C bus
« Reply #3716 on: December 12, 2014, 10:33:19 am »
Don't worry about JTAG.

I just bought an MSO2000, HW Version 2.2, shipped with firmware 00.03.00 and the SCPI-method posted by HiassofT here https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg508992/#msg508992 together with rigup v0.4 still works just fine. No need for scredrivers, soldering irons, JTAG-adapters, other software or anything. Done in 2 minutes (and most of the time you'll need for entering the option key, if you use the scope's GUI... ;-) )
 

Offline radiogeek97

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #3717 on: December 13, 2014, 02:45:43 am »
has anybody tryied this update meathod with the latest dsa815's with the 109 firmware and latest bootloader?   im still waiting on buying one
 

Offline hammy

  • Supporter
  • ****
  • Posts: 465
  • Country: 00
Re: Sniffing the Rigol's internal I2C bus
« Reply #3718 on: December 13, 2014, 11:24:12 am »
Thank you rmd79, 0ff and Howardlong!  :-+
The procedure worked flawless with my MSO1074z.  :clap:

It took more time to get the ARM-USB-OCD-H running with Windows 8.1 than doing the memory dump.  :palm:
 

Offline rmd79

  • Contributor
  • Posts: 18
  • Country: au
Re: Sniffing the Rigol's internal I2C bus
« Reply #3719 on: December 13, 2014, 11:27:55 am »
Thank you rmd79, 0ff and Howardlong!  :-+
The procedure worked flawless with my MSO1074z.  :clap:

It took more time to get the ARM-USB-OCD-H running with Windows 8.1 than doing the memory dump.  :palm:

Haha, I had trouble on Windows 7 with the drivers.. got there in the end.

Good to hear you had success :)
 

Offline hammy

  • Supporter
  • ****
  • Posts: 465
  • Country: 00
Re: Sniffing the Rigol's internal I2C bus
« Reply #3720 on: December 13, 2014, 11:58:39 am »
Haha, I had trouble on Windows 7 with the drivers.. got there in the end.
Good to hear you had success :)

Thank you for the work you put into this!  :-+

My firmware version: 00.04.01.SP2
Board version: 2.1.1

Cheers
hammy
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3721 on: December 13, 2014, 09:32:47 pm »
Regarding the DSA815 with bootloader 1.04 and firmware 1.09, here is a possible temporary solution...

Firstly, these are not the words of a JTAG god, some other folks clever in that department can look for a less intrusive way to what's proposed here.

You need to have a some trial period left for this: it's dependent on taking back a timer when the unit is switched on - look out Marty. Enabling the write protect on the FRAM (U1105) which appears to be a Fujitsu MB85RC16 seems to make this timer reset at each boot. The WP pin is adjacent to VCC, and it's active high, so you can lift pin 7 from the pad carefully and pop a link to pin 8 (VCC).

It may be that pin 7 is left floating or has a weak pull down other than what's in the chip itself, but equally it could well go off somewhere else, so unless there is evidence otherwise, it's probably better to lift the leg off the board rather than just botch solder across the two pins.

Perhaps a microscope should have been used for this, it's not as neat as it looked under the illuminated magnifier apparently.



Notes...

The way it appears to work is that every 10 seconds when it's on it writes to address 0x200 eight consecutive bytes in little endian format. This appears to be a ticker related to a 400MHz clock, so every ten seconds it's incremented by as near as damn it 4 billion. I guess that's why they use an FRAM and not an EEPROM, the endurance of FRAMs can usually be considered infinite for practical purposes. With an endurance of 10^10 write operations per bit, and one write every 10 seconds, it'll last over 3,000 years by my maths.

The way this FRAM works is a bit different to EEPROMS in the way it's addressed, which confused things a little. There is no pin addressing on the FRAM, it responds to all addresses 50 thru 57, and uses these three bits as the MSBs of the 11 bit address required for addressing purposes.

Perhaps by design (i.e., to stop hacking), unusually the I2C SCL is held low by the master during idle time. This prevents a second master jumping in.

Note that there is more than one I2C bus. The test points marked on the board SCL and SDA are for something else completely, don't waste any time looking at these.

It may be also possible to do some microcontroller thing, and indeed that was the original intention, to auto-sniff the I2C bus and pull down SDA at the appropriate time: being an open drain bus, this is entirely reasonable from an engineering perspective.

Folks may be interested to know that I used an MSO1074Z-S to trigger and decode the I2S, and I take back some of the negative comments I've said before about the decoding feature of this series of scopes. Once you've got your head around its limitations, it's not that bad in practice. The event table though, remains useless due to the limited amount of decode it displays.

Caveats: this may well mean that other things like re-calibration or network settings et al won't save, so I suggest you cal and configure the unit first. I haven't tried changing any non-volatile settings yet. If you're really handy, make an externally accessible jumper. Irrespective, anything that breaks is your responsibility.



 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #3722 on: December 15, 2014, 08:07:57 am »
The way it appears to work is that every 10 seconds when it's on it writes to address 0x200 eight consecutive bytes in little endian format.

...

Caveats: this may well mean that other things like re-calibration or network settings et al won't save, so I suggest you cal and configure the unit first. I haven't tried changing any non-volatile settings yet.

With only 8 bytes, there's no way there's any Cal data there. 

In fact, if each Option had its own independent Trial-time Remaining, I can't see that there would be enough room even for just them in 8B.  I suspect though that each Option is either Unlocked or Trial, and all the Trials are on the same timeout clock?  I don't recall ever seeing differing Time-Remaining values in any of the screen shots posted here, but I may have missed it.

It may be that only 4B of the 8 is used for the Trial-Remaining, and the other 4B being for a Powered-On Time counter (if the Rigols support those).  Otherwise it's likely to be a 2nd copy for validity checking.  (I.e., in the extremely rare case where the power shuts off just as it's writing a new value in, it always has one good copy to fall back on at restart.)
« Last Edit: December 15, 2014, 08:09:32 am by Mark_O »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3723 on: December 15, 2014, 10:32:33 am »
I'm pretty sure it's simply a 64 bit counter running at 400MHz.

Here's what I understand happens:

o SA is switched on
o Sets 64 bit 400MHz hardware counter to the 8 bytes read from address 0x200
o Every 10 seconds, 64 bit hardware counter is written back at address 0x200

There is almost certainly other areas of the FRAM used for other things. The trial times I'm aware of are not necessarily the same on the same unit.
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #3724 on: December 15, 2014, 11:08:22 am »
There is almost certainly other areas of the FRAM used for other things. The trial times I'm aware of are not necessarily the same on the same unit.

Thanks, Howard.  Yes, you're right.  I had overlooked that you had simply identified a single Option (SA), on the 815.  My mistake.  (For some reason, I was thinking option-block.)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf