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

0 Members and 1 Guest are viewing this topic.

Online egonotto

  • Regular Contributor
  • *
  • Posts: 165
Re: Sniffing the Rigol's internal I2C bus
« Reply #75 on: June 04, 2013, 08:50:54 am »
Hello studio25,

many thanks.

You wrote
"After the self-calibration the counter starts at zero. There seems to be a 32bit counter @ offset 0x7F6 .. 0x7F9"
and
"The trial period is probably stored at 0x7F6 and 0x7F7"

Is it right, that this explains why after a self cal the trial options expired and after 472 minutes the trial option comes back?

Best Regards
egonotto


 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1801
  • Country: 00
    • If you like my hacks, send me a donation
Re: Sniffing the Rigol's internal I2C bus
« Reply #76 on: June 04, 2013, 09:23:03 am »
An answer to a early Question page 2 I think.
The MCU 8051RNL is a USB Serial in out controller it is most likely the point where the SPI code is used.
I am not software only hardware but I have given Teneyes the full data and expect him to post it soon.

???

KSZ8051RNL have nothing to do with any kind of 8051 MCUs, this is ethernet phy, not MCU.

There is second IC next to KSZ8051RNL , and yes it is 8051 based MCU (CY7C68013A) for USB/GPIO, but here is the 8051
core is not visible for the DSO or USB (more or less).

There is RTC IC on board next to FRAM, sems to be I2C? Anyway.
I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline ve7xen

  • Frequent Contributor
  • **
  • Posts: 644
  • Country: ca
    • VE7XEN Blog
Re: Sniffing the Rigol's internal I2C bus
« Reply #77 on: June 04, 2013, 09:34:33 am »
I have set up some storage on my server for files related to this "investigation", including SPI traffic captures and an I2C dump.

http://gotroot.ca/rigol/

I've asked studio25 for permission to mirror his hack archive. Until I get it, it's not downloadable. The other files I have generated myself.

If anyone wants me to host files interesting to this effort, send me a PM and I will happily do so.
73 de VE7XEN
 

Offline darrylp

  • Regular Contributor
  • *
  • Posts: 127
  • Country: gb
Re: Sniffing the Rigol's internal I2C bus
« Reply #78 on: June 04, 2013, 08:34:13 pm »
Hehe, I see Rigol selling a lot more DS2072  in the near future !

--
  Darryl

 

Offline Chet T16

  • Frequent Contributor
  • **
  • Posts: 522
  • Country: ie
    • Retro-Renault
Re: Sniffing the Rigol's internal I2C bus
« Reply #79 on: June 04, 2013, 08:45:49 pm »
Ok perhaps a stupid question but if there is a 200Mhz trial option does this mean you can have a DS2202 indefinitely or has a proper DS2202 got some features the base model doesn't aside from the BW?
Chet
Paid Electron Wrestler
 

Offline marmad

  • Super Contributor
  • ***
  • Posts: 2979
  • Country: aq
    • DaysAlive
Re: Sniffing the Rigol's internal I2C bus
« Reply #80 on: June 04, 2013, 08:51:46 pm »
Ok perhaps a stupid question but if there is a 200Mhz trial option does this mean you can have a DS2202 indefinitely or has a proper DS2202 got some features the base model doesn't aside from the BW?

It seems clear from what studio25 has reported that the Trial Options for bandwidth are NOT implemented in the FW (at least, they're not activated by this). So no extra bandwidth from this technique - indefinitely or otherwise.
 

Offline Chet T16

  • Frequent Contributor
  • **
  • Posts: 522
  • Country: ie
    • Retro-Renault
Re: Sniffing the Rigol's internal I2C bus
« Reply #81 on: June 04, 2013, 09:45:55 pm »
It seems clear from what studio25 has reported that the Trial Options for bandwidth are NOT implemented in the FW (at least, they're not activated by this). So no extra bandwidth from this technique - indefinitely or otherwise.

Ok thanks, I obviously haven't read the thread well enough! So the scopes are the same bar being software limited? I have no use for a >70MHz scope but I'm curious where this might lead.
Chet
Paid Electron Wrestler
 

Offline MrsR

  • Regular Contributor
  • *
  • Posts: 118
  • Country: au
Re: Sniffing the Rigol's internal I2C bus
« Reply #82 on: June 04, 2013, 09:58:21 pm »
It seems clear from what studio25 has reported that the Trial Options for bandwidth are NOT implemented in the FW (at least, they're not activated by this). So no extra bandwidth from this technique - indefinitely or otherwise.

Ok thanks, I obviously haven't read the thread well enough! So the scopes are the same bar being software limited? I have no use for a >70MHz scope but I'm curious where this might lead.
From what I have seen they have  identical hardware.
Rachael :-+
 

studio25

  • Guest
Re: Sniffing the Rigol's internal I2C bus
« Reply #83 on: June 05, 2013, 08:03:03 am »
News:

CH1 BW Limit @ offset 0x90 -> 0x00=20Mhz, 0x01=OFF, 0x02=100Mhz, 0x03=200Mhz
CH2 BW Limit @ offset 0xCC -> 0x00=20Mhz, 0x01=OFF, 0x02=100Mhz, 0x03=200Mhz
CRC32 @ offset 0x7FC .. 0X7FF from 0x0 .. 0x7F5

The bandwidth can not be adjusted with the menu. Otherwise, all of your patched bandwidth settings for this channel lost.
 

Offline JimmyMz

  • Regular Contributor
  • *
  • Posts: 56
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #84 on: June 05, 2013, 08:15:30 am »
Lookin' good  :)
« Last Edit: June 08, 2013, 08:46:51 am by JimmyMz »
If you didn't get this message, let me know, and I'll get you another.
 

studio25

  • Guest
Re: Sniffing the Rigol's internal I2C bus
« Reply #85 on: June 05, 2013, 08:20:21 am »
Great News:
The bandwidth can not be adjusted with the menu. Otherwise, all of your patched bandwidth settings for this channel lost.

  Understandable  that limit checking if menu BW is changed

Did you try 0x05 to see if it stays for 350 MHz  ( the next step up)
as FW is based on DS4000  FW  with more BW than DS2000

No, maybe tomorrow.
 

studio25

  • Guest
Re: Sniffing the Rigol's internal I2C bus
« Reply #86 on: June 05, 2013, 08:23:53 am »
Is there someone with a DS2022 (ideal with all options) who can also dump the FRAM?
 

Offline mimmus78

  • Supporter
  • ****
  • Posts: 645
  • Country: it
Re: Sniffing the Rigol's internal I2C bus
« Reply #87 on: June 05, 2013, 08:31:14 am »
Ohh please don't do it! I don't want to be obligated to buy another scope!

 ;)
 

Offline monster

  • Contributor
  • Posts: 5
Re: Sniffing the Rigol's internal I2C bus
« Reply #88 on: June 05, 2013, 09:01:46 am »
Is there someone with a DS2022 (ideal with all options) who can also dump the FRAM?

DS2202 yes, but no additional options so far, the decoding features weren't too overwhelming during the the official trial period to be honest. My main constraint is: no spare time this week at all. But since the relatively noisy fan is bugging me anyway, I hope I can do that next week. Would that be soon enough?

Grüße,

Daniel
 

studio25

  • Guest
Re: Sniffing the Rigol's internal I2C bus
« Reply #89 on: June 05, 2013, 09:10:30 am »
Is there someone with a DS2022 (ideal with all options) who can also dump the FRAM?

DS2202 yes, but no additional options so far, the decoding features weren't too overwhelming during the the official trial period to be honest. My main constraint is: no spare time this week at all. But since the relatively noisy fan is bugging me anyway, I hope I can do that next week. Would that be soon enough?

Grüße,

Daniel

Sure, I look forward to it.  :-+
 

Offline ve7xen

  • Frequent Contributor
  • **
  • Posts: 644
  • Country: ca
    • VE7XEN Blog
Re: Sniffing the Rigol's internal I2C bus
« Reply #90 on: June 05, 2013, 09:13:08 am »
News:

CH1 BW Limit @ offset 0x90 -> 0x00=20Mhz, 0x01=OFF, 0x02=100Mhz, 0x03=200Mhz
CH2 BW Limit @ offset 0xCC -> 0x00=20Mhz, 0x01=OFF, 0x02=100Mhz, 0x03=200Mhz
CRC32 @ offset 0x7FC .. 0X7FF from 0x0 .. 0x7F5

The bandwidth can not be adjusted with the menu. Otherwise, all of your patched bandwidth settings for this channel lost.

Great work! Maybe it's worth cracking my scope open again after all ;).
73 de VE7XEN
 

Offline metalphreak

  • Frequent Contributor
  • **
  • Posts: 815
  • Country: au
  • http://d.av.id.au
    • D.av.id.AU
Re: Sniffing the Rigol's internal I2C bus
« Reply #91 on: June 05, 2013, 06:44:25 pm »
Do you guys reckon a similar thing is possible with the new function generators? I wouldn't mind pairing a 60mhz function gen (unlocked to 160mhz) with a 70Mhz 2000 series scope (at 200mhz) :D

Offline Pinkus

  • Frequent Contributor
  • **
  • Posts: 551
Re: Sniffing the Rigol's internal I2C bus
« Reply #92 on: June 05, 2013, 07:23:02 pm »
Do you guys reckon a similar thing is possible with the new function generators? I wouldn't mind pairing a 60mhz function gen (unlocked to 160mhz) with a 70Mhz 2000 series scope (at 200mhz) :D
Yeah that would be great, wouldn't it? I would do my share to make that possible. So if someone need my (limited) help......
As the frequency limitation is probably somewhere buried in the firmware and some Eeprom, it probably won't be possible shortly. But as the rise/fall time is different at the three models (8 / 10 / 12ns), there might be some kind of hardware limiter involved. If this is the case the limitation of the rise/fall time can be overwritten/changed of course - the general frequency limitation might be much more difficult to change. Maybe Rigol at one day will offer an option to expand the bandwidth, but probably not.... even today they are still selling DS1052 and DS1102 without offering a bandwidth expansion for 100 bucks for the 1052 owner.

Peter
« Last Edit: June 06, 2013, 01:23:01 am by PeterK13 »
 

studio25

  • Guest
Re: Sniffing the Rigol's internal I2C bus
« Reply #93 on: June 06, 2013, 07:01:00 am »
Great News:
The bandwidth can not be adjusted with the menu. Otherwise, all of your patched bandwidth settings for this channel lost.

  Understandable  that limit checking if menu BW is changed

Did you try 0x04 to see if it stays for 350 MHz  ( the next step up)
as DS2000 FW is based on DS4000  FW  with more BW than DS2000

0x04 = 250Mhz (I can not measure the real bandwidth)
0x05 = no menu text
0x06 = no menu text
 

Offline Harvs

  • Super Contributor
  • ***
  • Posts: 1141
  • Country: au
Re: Sniffing the Rigol's internal I2C bus
« Reply #94 on: June 06, 2013, 08:49:25 am »
@studio25 - did you get the chance to do any test with respect to the bandwidth? i.e. I don't expect you would have completed anything conclusive about actual bandwidth, just wondering if there was a noticeable change in the rise time with the those addresses changed?

Great work by the way :)
 

Offline Harvs

  • Super Contributor
  • ***
  • Posts: 1141
  • Country: au
Re: Sniffing the Rigol's internal I2C bus
« Reply #95 on: June 06, 2013, 10:07:54 am »
@studio25 - did you get the chance to do any test with respect to the bandwidth? i.e. I don't expect you would have completed anything conclusive about actual bandwidth, just wondering if there was a noticeable change in the rise time with the those addresses changed?
@Harvs ,
For what code?
Studio25 did show a rise time of 2nsec for the 200MHz code a few posts back,
and Not knowing the test Pulse risetime,
I think the Test was great and that the BW limiting chip is set for 200MHz,
but does this hardware have any more BW in it, when there is No Limit???

Note 250MHZ prompt in a BW Menu is only on the DS6000
 (same FW for 2000, 4000 & 6000)

Great thanks, I missed that post but looking back I've found it.
 

Offline MrsR

  • Regular Contributor
  • *
  • Posts: 118
  • Country: au
Re: Sniffing the Rigol's internal I2C bus
« Reply #96 on: June 07, 2013, 02:24:10 pm »
IF any interested have a look at these. for tinhead 8051 was developed by INTEL as a MCU the core has been
used by other manufacturers for different components. 
Rachael :-+
NOTE The first PDF is of a component on the front of the main board and is through put for Ch1 (fir) (sec). Ch2 (fir) (sec).
Although the hardware is the same for each Scope it could be modified for each model,The BLACKFIN BF526 has a serial number on it and I was wondering if it is different for each model.
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 246
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #97 on: June 08, 2013, 01:31:31 am »
could someone pls post a screenshot of the license display screen ?
or confirm that
ROM:143CF2                 R1.L = 0x40a0;          # R1=0x40a0
ROM:143CF6                 R1.H = 0xfa;            # R1=0xfa40a0
ROM:143CF6                       -> unk_FA40A0 => "%d/%d/%d %d:%d:%d"

matches the date & time stamp as its displayed there - trying to id some subs()'s

thx

___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline jonese

  • Contributor
  • Posts: 21
  • Country: ca
Re: Sniffing the Rigol's internal I2C bus
« Reply #98 on: June 08, 2013, 02:14:53 am »
I like where this is going.  Modifying the FRAM is a temporary measure, but of course it leads to pointers in the firmware as to how the values are written/calculated.

Does someone have a repository of the latest firmware for the DS2000 please?
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 246
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #99 on: June 08, 2013, 05:52:30 am »
switching internal model type to DS2202 (0x1) allows 2ns Timebase (see attachment) - the settings are read in during boot (TWI i guess, but right sub()s still not found), and then the various strings/settings are applied - changeing the model type has immediate effect ;-)

if somebody whats to check if some of those bytes are in the FRAM try to change em to something like:

RAM:E4DD1F                                         # 0x16=DS2072
RAM:E4DD1F                                         # 0x0= DS2102
RAM:E4DD1F                                         # 0x1= DS2202  (2ns timebase avail)
RAM:E4DD1F                                         # 0x2= DS????? (500ps timebase avail)

update: when powercycling in 2ns mode, it comes back in 2ns mode, if u leave it then it wont let u back to 2ns
so that byte should be in FRAM somewhere then ... ;)
« Last Edit: June 08, 2013, 07:22:52 am by cybernet »
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf