Products > Test Equipment
RIGOL DP711 and DP712 new 1ch PSU
Dwaine:
I can honestly say that I miss the good old serial port.
fki82:
Has anybody tested this device yet?
Eric-H:
--- Quote from: fki82 on February 19, 2017, 08:07:23 pm ---Has anybody tested this device yet?
--- End quote ---
I've received my DP711 a few weeks ago form Conrad and I'm very happy with it. I especially like the display and the user interface. One minor complaint: the fan is a bit loud.
I'm also looking for a way to enable the options ;)
ElectronMan:
I've done some playing around with my DP712. Slurped the main firmware image off the SPI flash chip inside before and after the trial ran out. Unfortunately the license data is actually stored on an FRAM chip that I missed the first time I took it apart.
The main processor appears to be a CME-5 (http://www.capital-micro.com/PDF/CME-M5_Family_FPGA_Simplified_Data_Sheet_EN.pdf), an FPGA and 8051-based MCU combo. There is a JTAG port available, but I haven't managed to do anything useful with that yet.
The FRAM appears to be a Fijitsu (https://www.fujitsu.com/us/Images/MB85RC16-DS501-00001-8v0-E.pdf). It uses i2c, contains 8 x 2kbit pages.
Page 0 (Address 0x50) = Configuration settings
Page 1 (0x51) = Appears to be unused
Page 3 (0x52) = Front panel button lock settings in bytes 0x30-32 (each button is 1 bit) and Serial number at address 0x40-4d with what appears to be a checksum at 0x55-56. Changing the SN causes it to copy the serial # back from SPI flash and rewrite it, probably because of the invalid checksum.
Page 4 (0x53) contains the configured options (licenses) starting at 0x00, with what appears to be another checksum at 0x13-0x14.
Pages 5-7 (0x54-57) Appear to be unused.
I was able to hook up a raspberry pi via i2c and can read-write most of the locations while the unit is powered on, with the exception of 0x52 (SN data). This one you can read/write right after power on before it has booted, so you have to be fast. These areas are read on bootup:
1. i2c FRAM address 0x52 Starting at 0x40, reading 23 bytes (appears to be always 0x10 followed by 9 bytes of serial #, 7 0x0 and the 2 byte checksum)
2. i2c FRAM address 0x50 Starting at 0x00, reading 24 bytes (config data and checksum)
3. i2c FRAM address 0x53 Starting at 0x00, reading 21 bytes (option info and checksum)
4. i2c FRAM address 0x52 Starting at 0x30, reading 4 bytes (First 3 bytes front panel button lockouts, unknown 4th byte. These default to all 0x00)
It also re-reads #3 above (options) every 66 seconds while running. The main blocker on getting further with this is the checksum. When the license data is all 0's (which it fills when it detects a bad checksum) the checksum is 0xcc 0x71).
Hopefully someone more seasoned with reverse engineering can take this further... I haven't given up yet though.
ElectronMan:
Got it.... There are 3, 5 byte fields at the beginning of 0x53. One for each feature. The first byte appears to be license type. 01 is trial, 02 is Official, and 03 is expired trial. There are 2 bytes of 00, followed by 2 bytes that seem to represent the # of minutes of trial elapsed. (See image) The # 08 71 works out to 36hrs runtime.
i2c Address 53:
0x00 = Trigger License type
0x01 - 0x02 = 00's, possibly extended trial time field.
0x03 - 0x04 = Trial time elapsed in minutes.
0x05 = Timer License type
0x06 - 0x07 = 00's, see above
0x08 - 0x09 = Trial time elapsed for Timer
0x0a = High res License type
0x0b - 0x12 = All 0's, possibly room for a trial license but one is never enabled.
0x13 - 0x14 = 16 bit crc checksum of 0x00 - 0x12.
Therefore, we want all 3 license types to be 02, and the checksum needs to be accurate. The data in the attached screen shot checks out. If your trial timer fields are different, those need to be changed to match for the CRC to pass.
This is not an ideal solution as it requires opening it up and leeching onto the FRAM chip with a device that talks i2c, but it works :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version