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

0 Members and 3 Guests are viewing this topic.

Offline phersus

  • Newbie
  • Posts: 9
Re: Sniffing the Rigol's internal I2C bus
« Reply #3750 on: December 21, 2014, 08:54:54 pm »
Thank you hammy,

In that case ... I will open the oscilloscope and move forward.

Cheers,
Gus
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3751 on: December 21, 2014, 09:11:43 pm »
Here are some further notes regarding the DSA815 with bootloader 1.04 and firmware 1.09.

If the WP on the FRAM is disabled, I understand that the network parameters and startup parameters can't be changed.

The WP does not connect to anything, it has a weak pull down internally, so it would appear that just shorting pins 7 & 8 (WP & VDD) would stop the FRAM being updated with the time-on-since-new every 10 seconds, suggesting that there is no need to lift pin 7.

Furthermore, although the I2C SCL line is held low, there is a short period at power up time, about 400ms, when the SCL line is pulled high to VDD with a standard I2C pullup. Both SCL and SDA are open drain high at this point.

By performing a re-write of the time-on-since-new within this 400ms timeframe apparently it is possible to reset the time without disabling the updating of non-volatile parameters

Howardlong:

What are the consequences of disabling updating of the non-volatile memory for the Start-Up Parameters?  Does this just mean that we can't - 1. change the SA815's network address from its default, and/or 2. change the Power ON from its Default (vs. the 'Last configuration settings')?

If we don't care about these two things, then would it be Ok to just solder Pin 7 and 8 of the FRAM (U1105) together. or is there something else that could also be affected?

The FRAM was lifted and WP pad was visually inspected, and also mesured for any protection diodes to both Vss and Vdd. There was no indication that the WP pad was connected to anything.

The consequences are unknown other than that documented already.

What should be noted though is that very early on in the initialisation, there is a test write of 0x01 to address 0x0A of the FRAM at I2C address 0x50, and it is read back. In a non-write protected scenario, it reads back 0x01, and immediately re-writes 0x00. In a write protected scenario, the read back is 0x00, and it doesn't try to write back anything at that stage. What happens as a result of that is unknown as I understand it.

There may indeed be other consequences.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3752 on: December 21, 2014, 09:26:46 pm »
Sorry, to add, there was not a large amount of testing, other than to note that on a brief test it was noted that left as a DHCP client all was fine. Attempting to change to a fixed IP address failed with WP on. With WP off a fixed IP addres was fine.

Regarding the power on settings, little testing was done other than to note that the unit would no return to the same state when powered off and the power up setting requested it to do so. Being able to restore state from a file (internal, USB not tested) still functioned correctly.

It is unclear what, if any, calibration settings are saved in FRAM, or indeed anything else.
 

studio25

  • Guest
Re: Sniffing the Rigol's internal I2C bus
« Reply #3753 on: December 22, 2014, 07:57:31 pm »
I've patched with these files, the FRAM of the DS2000. Seems to be similar to the DSA815...
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3754 on: December 22, 2014, 10:22:38 pm »
I was aware of your work, although the FRAM chip in the DAsA815 is not quite the same as I understand it. The I2C and byte addressing is a little different, and the "window of opportunity" isn't the same. Also the development expertise in the DSA815 shown here is in PICs and not Arduino, and the PICs don't have that semi compatible footprint.

Were you resetting the time-since-on or something else?
 

Offline phersus

  • Newbie
  • Posts: 9
Re: Sniffing the Rigol's internal I2C bus
« Reply #3755 on: December 23, 2014, 11:36:51 am »
Hello Guys,

Anyone who can show me what does the imx28.cfg file contain ? Or point me where I can find it ?

If the context is not clear I'm talking about the command to launch openocd, something like:

G:\openocd-x64-0.8.0.exe -f ./interface/ftdi/olimex-arm-usb-ocd-h-hl.cfg -f ./target/imx28.cfg

Thanks,
Gus
 

Offline MadDog

  • Contributor
  • Posts: 10
Re: Sniffing the Rigol's internal I2C bus
« Reply #3756 on: December 23, 2014, 11:53:54 am »
Hi Gus,

imx28.cfg is a part of openocd. Create your own *.cfg file like "Off" has shown in reply #3740:

source [find interface/ftdi/olimex-arm-usb-ocd-h.cfg]
source [find target/imx28.cfg]
adapter_khz 20000

I have done this some days ago with a non -H olimex adapter (olimex-arm-usb-ocd.cfg), I had to reduce the frequency to 5000kHz.

Many thanks to those who have made this possible and who have shared their knowledge!  :clap:
« Last Edit: December 23, 2014, 03:54:35 pm by MadDog »
 

Offline phersus

  • Newbie
  • Posts: 9
Re: Sniffing the Rigol's internal I2C bus
« Reply #3757 on: December 23, 2014, 11:58:24 am »
Hi again,

Thank you MadDog,

Now it makes more sense those commands, I've seen them but didn't understand why they were there  :palm:
OK, if they are part of the openocd install it is clear.

I will give them a try now,

Cheers.
 

Offline dr.diesel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: us
  • Cramming the magic smoke back in...
Re: Sniffing the Rigol's internal I2C bus
« Reply #3758 on: December 25, 2014, 11:05:12 pm »
Looks like a new firmware available for the 815:

DSA815: 00.01.12

From:

http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm

Offline msraya

  • Supporter
  • ****
  • Posts: 107
  • Country: es
  • EA7EE
Re: Sniffing the Rigol's internal I2C bus
« Reply #3759 on: December 26, 2014, 11:08:12 pm »
No luck with the icebear JTAG  :( ...

The memory dump stop at 6542Kb, the openocd 0.8.0 output is: timeout waiting for syscomp & dbgack last dbg_status: 4
And rigup does not find any keys.

I do not have idea, I will find a solution when I have time....
The cfg files:

Code: [Select]
interface ftdi
ftdi_device_desc "ICEbear JTAG adapter"
ftdi_vid_pid 0x0403 0xc140

ftdi_layout_init 0x0028 0x002b
ftdi_layout_signal nTRST -data 0x0010 -oe 0x0010
ftdi_layout_signal nSRST -data 0x0020

adapter_khz 5000

# i.MX28 config file.
# based off of the imx21.cfg file.

reset_config trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst

#jtag nTRST and nSRST delay
adapter_nsrst_delay 100
jtag_ntrst_delay 100

if { [info exists CHIPNAME] } {
   set  _CHIPNAME $CHIPNAME
} else {
   set  _CHIPNAME imx28
}

if { [info exists ENDIAN] } {
   set  _ENDIAN $ENDIAN
} else {
   set  _ENDIAN little
}


# Note above there is 1 tap

# The CPU tap
if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   set _CPUTAPID 0x079264f3
}
jtag newtap $_CHIPNAME cpu  -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID


# Create the GDB Target.
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm926ejs -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm926ejs

arm7_9 dcc_downloads enable


Regards
Manuel
 

Offline smgvbest

  • Supporter
  • ****
  • Posts: 630
  • Country: us
    • Kilbourne Astronomics
Re: Sniffing the Rigol's internal I2C bus
« Reply #3760 on: December 27, 2014, 05:35:31 am »
I can not see the im28.cnf being an issue as that is processor specific where as the ICEBear itself is not.
I did see in the icebear.cfg file that they warn it is not tested on actual hardware.

Code: [Select]
#
# Section5 ICEBear
#
# http://section5.ch/icebear
#

[b]echo "WARNING!"
echo "This file was not tested with real interface, it is based on code in ft2232.c."
echo "Please report your experience with this file to openocd-devel mailing list,"
echo "so it could be marked as working or fixed."[/b]

interface ftdi
ftdi_device_desc "ICEbear JTAG adapter"
ftdi_vid_pid 0x0403 0xc140

ftdi_layout_init 0x0028 0x002b
ftdi_layout_signal nTRST -data 0x0010 -oe 0x0010
ftdi_layout_signal nSRST -data 0x0020

I found this and maybe you want to give this config a try

Create your own icebear.cfg file with these contents and use it instead of the supplied one.

Code: [Select]
#
# Section5 ICEBear
#
# http://section5.ch/icebear
#
 
interface ft2232
ft2232_device_desc "ICEbear JTAG adapter"
ft2232_layout icebear
ft2232_vid_pid 0x0403 0xc140

I hope it works for you
Sandra
(Yes, I am a Woman :p )
 

Offline mythbu

  • Newbie
  • Posts: 3
Re: Sniffing the Rigol's internal I2C bus
« Reply #3761 on: December 27, 2014, 09:43:02 am »
Hi Guys,

I don't want to disturb, but I have bought me my first oscilloscope - a Rigol MSO1074Z. Yesterday I discovered that the ability of decoding RS232 information is only trial. But the advertisement said, that this is a feature. So I tried to generate a key with the software from "http://gotroot.ca/rigol/". But no success yet. When I now enter a key it displays a message that installation is blocked for 12 hours (also mentioned on page ~ 126 of this thread). So I interpret this as a "NO" and retry in 12 hours. The numbers are:

Model: MSO1074Z
Serial: DS1ZC1xxxxxxxx
Firmware: 00.04.01.SP2
Board: 2.1.1

I've tried the private key 0x6f1106... for DS1000Z series with options DSFR and CSAR without success. I need to retest the private key 0x99fc5... MSO1000Z series for CSAR but I don't think that this will work (because I have possibly tested this).

So could you provide me some help. Do I have the right private key and/or "feature" codes (DSFR, CSAR, ...)? Isn't there a reset possibility to bypass the 12 hour waiting time?

Greetings from Germany,
mythbu
 

Offline msraya

  • Supporter
  • ****
  • Posts: 107
  • Country: es
  • EA7EE
Re: Sniffing the Rigol's internal I2C bus
« Reply #3762 on: December 27, 2014, 10:32:34 am »
Thank You , Sandra.

I have no time right now to again disassemble the scope, I will test it within several weeks.
I compiled the openocd 0.8.0 with new ftdi library, so old interface ft2232 i think not work anymore. However i will try.

I think that slow down the interface can be the solution.

Mythbu, you must get a JTAG adapter, install openocd, dissasemble the scope and follow the Sandra's Tutorial back in 252 page of thread. Good Luck!  :-//

Happy new year!!
Manuel
 

Offline smgvbest

  • Supporter
  • ****
  • Posts: 630
  • Country: us
    • Kilbourne Astronomics
Re: Sniffing the Rigol's internal I2C bus
« Reply #3763 on: December 27, 2014, 10:39:42 am »
So could you provide me some help. Do I have the right private key and/or "feature" codes (DSFR, CSAR, ...)? Isn't there a reset possibility to bypass the 12 hour waiting time?

Look starting at the message from 0ff
msg565557 and from that message forward several of us discussed and detailed how to do it.

Basically you have to open your scope up and use a JTAG programmer to dump memory then use rigup to get the private key then use rigup again to generate the keys.  riglol does not work for the MSO1000Z series.
I posted here where I did this for reference. msg569236
Sandra
(Yes, I am a Woman :p )
 

Offline KD0RC

  • Regular Contributor
  • *
  • Posts: 114
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #3764 on: December 27, 2014, 09:11:03 pm »
Looks like a new firmware available for the 815:

DSA815: 00.01.12

From:

http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm
So has anyone tried this yet?  I am on 01.09, bootloader 01.03.  I am afraid to try it until I know it will not 'un-hack' the box...
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5320
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #3765 on: December 27, 2014, 11:32:38 pm »
I doubt you are alone...
 

Offline mhwlng

  • Contributor
  • Posts: 19
  • Country: nl
Re: Sniffing the Rigol's internal I2C bus
« Reply #3766 on: December 28, 2014, 09:30:04 am »
All my license settings (VSWR etc.) were preserved when I updated from 01.09 -> 01.12
 

Offline dr.diesel

  • Super Contributor
  • ***
  • Posts: 2214
  • Country: us
  • Cramming the magic smoke back in...
Re: Sniffing the Rigol's internal I2C bus
« Reply #3767 on: December 28, 2014, 12:28:48 pm »
All my license settings (VSWR etc.) were preserved when I updated from 01.09 -> 01.12

Any chance you got a change log with your update?

Offline mhwlng

  • Contributor
  • Posts: 19
  • Country: nl
Re: Sniffing the Rigol's internal I2C bus
« Reply #3768 on: December 28, 2014, 12:47:26 pm »
Quote
Any chance you got a change log with your update?

no, sorry...

I think that one new feature may be that the x-axis can now be logarithmic ? (span button -> x scale -> log)
« Last Edit: December 28, 2014, 12:49:32 pm by mhwlng »
 

Offline NortliW

  • Contributor
  • Posts: 21
Re: Sniffing the Rigol's internal I2C bus
« Reply #3769 on: December 28, 2014, 03:38:33 pm »
Is there already any progress on the DSA1030? I can post f.w.
 

Offline calunga

  • Newbie
  • Posts: 1
Re: Sniffing the Rigol's internal I2C bus
« Reply #3770 on: December 28, 2014, 06:28:09 pm »
Ufa !!! at last able to get until I come accompanied this topic from page 160 and personnel bought the DS2072A in October this year and would like to unlock it possible for all functions see that it came with a new firmware Caribe; the question this if there is possibility of release via solft connected by USB or network port or use will be necessary for a w JTAG interface before hand bought a USB AMENDING interface and even the time has not yet arrived but with the ALTERA not serve'll buy the ARM-USB-OCD-H I see comments from friends to be the best interface in order to make this service tale with the help of this wonderful forum friends ... Thanks !!
 

Offline KD0RC

  • Regular Contributor
  • *
  • Posts: 114
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #3771 on: December 29, 2014, 04:31:46 pm »
All my license settings (VSWR etc.) were preserved when I updated from 01.09 -> 01.12

Any chance you got a change log with your update?
I just got the upgrade, but there was no change log.  I sent an e-mail to see if I can get one, and if so, I will post it here.  I am not going to upgrade until I have a better feel for this...  The log frequency scale sounds cool although most of my work is done in narrow enough chunks of spectrum to not really need it.

@mhwlng, did the bootloader version change with this upgrade?  Mine is still at 01.03.

Len
 

Offline Pasky

  • Regular Contributor
  • *
  • Posts: 149
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #3772 on: December 29, 2014, 04:59:53 pm »
Apologies in advance if this was answered somewhere in this large thread, but is there any work on a firmware upgrade for the DG4xxx (4062, 4102, 4162) signal generators?  All three models appear to use the same hardware and it looks like it's just the firmware keeping them from higher bandwidths.
 

Offline mhwlng

  • Contributor
  • Posts: 19
  • Country: nl
Re: Sniffing the Rigol's internal I2C bus
« Reply #3773 on: December 29, 2014, 06:32:58 pm »
Quote
@mhwlng, did the bootloader version change with this upgrade?  Mine is still at 01.03.
bootloader is still 01.03

Quote
Any chance you got a change log with your update?
change log : DSA800(DSP)Version Notes.doc
Version 00.01.12.00.02
Date 2014-11-10

Increase the frequency offset function.
Increase the switch between local and remote command.
Increase the frequency of logarithmic function
Increase the key lock function.
Increase the traditional Chinese features.
Increased access to frequency reference the status of a remote command.
Increase sanitation function.
Increase in Peak List can turn off the display line.
Modify the option name information directly display option.
Modify the Trace preservation order in CSV format, from a list of changes to the three column.
To improve the quality of AM demodulation.
Modify the “Clear All” for “Blank All”, and redefine the “Clear Write”.
To solve the problem of inaccurate measurement of N dB.
To solve the problem of freq Count is not accurate.
To solve the problem of error loading an State file
To solve the problem TX1000 instrument connection after the crash.
The lower limit of TG range from -30dBm to -20dBm.
« Last Edit: December 29, 2014, 06:40:43 pm by mhwlng »
 

Offline KD0RC

  • Regular Contributor
  • *
  • Posts: 114
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #3774 on: December 29, 2014, 07:30:23 pm »
Chinglish at its best - 'Increase the sanitation function'...  Does this mean an upgrade to the flush handle?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf