Products > Test Equipment

Sniffing the Rigol's internal I2C bus

<< < (745/899) > >>

hammy:

--- Quote from: rmd79 on December 13, 2014, 11:27:55 am ---Haha, I had trouble on Windows 7 with the drivers.. got there in the end.
Good to hear you had success :)

--- End quote ---

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

My firmware version: 00.04.01.SP2
Board version: 2.1.1

Cheers
hammy

Howardlong:
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.



Mark_O:

--- Quote from: Howardlong on December 13, 2014, 09:32:47 pm ---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.

--- End quote ---

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.)

Howardlong:
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.

Mark_O:

--- Quote from: Howardlong on December 15, 2014, 10:32:33 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.

--- End quote ---

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.)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod