Products > Test Equipment

Sniffing the Rigol's internal I2C bus

<< < (751/899) > >>

phersus:
Thank you hammy,

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

Cheers,
Gus

Howardlong:

--- Quote from: ted572 on December 21, 2014, 08:42:18 pm ---
--- Quote from: Howardlong on December 21, 2014, 05:23:50 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

--- End quote ---

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?

--- End quote ---

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.

Howardlong:
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:
I've patched with these files, the FRAM of the DS2000. Seems to be similar to the DSA815...

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

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