@a213m
I really appreciate your continued effort over the years!
I hope to see it running soon on my Intel B760.

Kepp up the good work!

I didn't have any issues with either 4.7k or 2k, you can use any value, as long as they are the same, or even not use any at all.
Higher value pull up resistor can have issues with some EEPROMs when fast mode is enabled, but if you are not having issues, 4.7k is fine.

I don't have any DIMMs with ST M34E04 EEPROM unfortunately, so I can't really test what you have been experiencing. I did, however, test a couple of older DDR2 sticks that use EEPROMs with pin 7 used for hardware write protection control, and SPD-RW detected write protection properly, when pin 7 was shorted to VCC.
 
Your EEPROM is interesting, because it is partially compatible with older hardware EE1002 definition. According M34E04 product info, it is compatible with Jedec's EE1004 definition, however EE1004 doesn't use pin 7, and EE1004 definition is compatible with EE1002 only protocol-wise. Pin 7 was used for hardware write protection in EE1002 EEPROMs, and write protection is disabled if it is left floating by default, or is grounded. Only when pin 7 is connected to VCC, hardware write protection is enabled. And in TSE2002av definition, pin 7 is used for temperature events, since hardware write protection and permanent software write protections were removed.
 
I have modified the schematic to disable hardware write protection by adding a resistor between pin 7 and the ground (to avoid shorting VCC to ground, if hardware write protection is enabled on a DIMM). (https://github.com/1a2m3/SPD-Reader-Writer/commit/af25beb440f49ede1e157c808aaad74285601e90)
 
I suspect your DIMM is hardware write protected, and by grounding pin 7 you are overriding hardware write protection, thus disabling it. Check the resistance between pin 7 and pin 8 of M34E04 EEPROM on isolated DIMM only.
 
Also, if you are willing to send me your DIMM for further testing, PM me to arrange.

Karalux
Hello, i am trying to find my way to overclock my G.Skill F3-1600C9-8GRSL DDR3 sticks for quite some time and i found a couple problems with my setup. At first i tried using Thaiphoon Burner and when i do the write protection check it says that my ram is hardware write protected so i took a closer look at the SPD chip and i believe its a AT24C02C from Microchip that has a WP (write protection) pin that sets the protection. The funny thing is that this pin is connected to the ground, so write protection is actually disabled by default. Then i found your project (its awesome how much effort you have put into it, thank you for ytour work) and when i try to write something using your software through Smbus it says that writing to EEprom is disabled in bios. My motherboard is AsRock IMB-180 with mobile QM87 chipset so i tried changing the SPD lock byte in the SmBusPei part of the bios image to 0 but pc does not boot after i flash the modded bios (and its the same with my other B85 motherboard). Is there anything that i could try to go around this problem or going the Arduino way is the only way to go for me? I wasnt eager to try flashing with Arduino because im not entirely sure if its possible to connect arduino straight to the spd chip through sodimm socket without any additional circuitry since there is no write protection.

 
Hi, you got several options to try.
 
Check if your motherboard supports enabling SPD write disable bit. (On Asus boards it is available in "Extreme Tweaker > Tweaker's Paradise > SPD Write Disable". Not sure if Asrock has similar option, check your manual to see if it does.)
 
If it doesn't, you'll have to use hardware flasher, whether it's Arduino based or any other I2C capable programmer. Since DDR3 EEPROM uses 256 byte SPD only and doesn't require page switching to access the entire memory array, DDR3 EEPROM can be programmed using any I2C capable programmer, like portable USB CH341A programmer, if you don't want to fiddle with Arduino. If your chip is in SOP8 package, you can use included clip from the kit pictured below to program EEPROM directly, otherwise you'll have to source DDR3 slot/adapter to access your EEPROM. Or desolder the EEPROM off your DIMM and solder it onto one of the included SOIC/TSSOP adapter boards if the clip won't work for you.
 

Liubo
Hi,
I'd like to try this utility, it sounds great, but Microsoft Defender Antivirus finds there a virus Trojan:Win32/Wacatac.H!ml.
I tried last three versions, but everytime is the same. Whats wrong in this case?

False positive, SPD-RW is safe: https://github.com/1a2m3/SPD-Reader-Writer/issues/34
 
Add program files to exclusion list.

void-spark
Have most of the parts lying around already, is the opto-coupler required, or do you think switching high voltage with a mosfet/transistor would also be fine?

Thanks.
 
Yes, you can use mosfet, transistor, or even relay based switch or whatever means to supply 9V to SA0. Optocoupler is just simpler, as it requires less parts and is easier to build.
 
I did consider to update VHV control to use BJT at one point in time, like pictured below, but decided against it for simplicity and backwards compatibility.
 

 
 

void-spark
In the circuit, can I make these simplifications for that?
- I hava a 5v 16mhz Pro-Mini available, if I'm only going to do DDR4 (SODIMM), can I work with 5v instead of 3.3v? The specs for the SPD chips seem to allow up to 6.5v.

You can try, however... going above recommended voltage isn't recommended (). Jedec's maximum operating voltage for DDR4 EEPROMs is at 3.6V, while absolute maximum is 4.3V. (Just because SPD chip datasheet says 6.5V maximum, it doesn't necessarily mean the chip will work fine at that voltage, it may simply mean the chip won't die instantly when its exposed to such voltage).
 
At least, make sure your chip's operating voltage is within or below 5V. But I would recommend getting a 3.3V voltage regulator to be safe. Or get a 3.3V Arduino for better compatibility.
 

void-spark
- I think for just reading on DDR4, SA0-2 can all be tied to ground, right? Only SCL and SDA need to be connected to the Arduino.
 
Thank you again! :)

Yes, for just reading only, data (SCL/SDA) and power (VCC/GND) lines are sufficient. Keep in mind SA2 isn't used on SO-DIMMs.

centralseven
Did some testing with older Crucial DDR4 today as I'm waiting for a DDR5 socket to arrive.
These modules have a ST M34E04 SPD EEPROM which need pin 7 (write control) connected to ground to enable RSWP control.
 
I had soldered the related cable to socket pin 78, but didn't connect it during the first tests.
To disable RSWP was (of cause) not possible, but as I tried to write the EEPROM anyway during playing arround, I got some odd behavior.
When I click on next to some of the write error messages the app crashes or gives me an exeption error message.
After the crash or the error message the EEPROM is completely corrupted, even with write protection enabled.
I've repeated this a few times and got the same result. Random corrupted data all over the EEPROM.
Just letting you know, maybe you can prevent the crash or the error to keep the EEPROM uncorrupted If somebody tries the same.
I'll upload some pics later, sadly no time left today.
 
With write control grounded, as intended, everthing works great as it should.

 
Ok, I just share my experience here.
 
Just sucesfully unlocked/flashed DDR4 sodimm with ST M34E04 in veery dirty way:
-  no soldering
-  Arduino Pro mini (5v/16MHz) feeded by 3.3v. Works just fine!
-  Just GND, SDA, SCL and VCC from arduino (no WP, no SA1 and SA2, and no I2C pull-up resistors either)
 
-  +9V in "manual mode" (I basically connected it by hand and immediately press "disable  RSWP") 
-  short D6 and D9 to make software think it sees 9v :)
 
Then used Typhoon Burner free version to generate JEDEC profile and  DDR4XMPEditor to modify SPD. Now I upgraded from DDR4-2666 to DDR4-3200!
 
It all took me 30 minutes to assemble from what I already had on the shelves )
 
Photos:

Hello. I would like to know if you plan to support Intel Z790 with SMBus. Your program could help repair broken DDR5 sticks (their spd) on any motherboard and set protection on blocks, you showed this function above.

Milestone release: 20230930
 

Core

• Replaced: WinRing0 driver with CPUID driver
• Improved: Arduino connection monitor

GUI

• Fixed: Crash after pressing Backspace key while Hex area is activated when no data is loaded or cursor isn't set
• Fixed: Crash after pressing alphanumeric keyboard keys while ASCII area is activated when no data loaded
• Fixed: Pressing arrow keys showing invalid cursor position in status bar when no data is loaded
• Fixed: Right and left arrow keys behavior when Scroll Lock is on
• Redesigned: Set RSWP dialog window checkbox list design
• Added: Importing DDR5 SPD dumps created with OCTool
• Added: Maximum PCI buses option SMBus setting
• Added: Keep line breaks on copy option
• Added: Keyboard lock keys status

SMBus

• Added: DDR4 & DDR5 support on Intel Alder Lake and Raptor Lake systems (600 and 700 series chipsets)
• Updated: AMD SMBus support on systems with PMIO registers disabled
• Improved: SMBus discovery on supported systems
• Improved: RSWP test reliability

Firmware

• Improved: Stability

Schematic

• Improved: WP compatibility with SDRAM, DDR, DDR2, DDR3, and DDR4 memory

 
This release adds support for DDR4 and DDR5 on mainstream Intel platforms. To read DDR5 SPDs in full, SPD write option must be enabled by BIOS. SPD write disable was introduced with Intel 80 series chipsets, but until now, it only prevented writing SPDs, when enabled. With SPD write disabled you will only be able to read the first 128 bytes of DDR5 SPDs. If SPD-RW detects SPD write is disabled on your DDR5 system, it will give you an option to read the SPD in part or in full, and if you choose to read the entire SPD, without proper page switching read data will repeat after the first 128 bytes. SPD write disabled does not affect reading DDR4 SPDs.

To check if your system has SPD write disabled, connect to your SMBus controller and choose Info from the Device menu.



On some boards you can manually enable SPD write, if it is disabled. To do that on Asus boards, go to UEFI, navigate to Tweaker's Paradise under AI Tweaker section, and set "SPD Write disable" option to False.



Supported chipsets in this release: B660, B760, H610, H670, HM670, H770, Q670, W680, WM690, Z690, and Z790. W790 is not supported.

About:

As you can see, this release is labeled milestone. But it's not because it's the first major release after a long delay or new platform support.

It's the driver.

Ever since I implemented SMBus support in SPD-RW, I relied on WinRing0 driver. While it's been working fine, it is not perfect, because it was not created with security in mind and has been blacklisted by many antiviruses as malicious. Writing and compiling own driver is not an option, as Windows requires drivers to be signed to load (which is expensive) without having to disable driver signature enforcement.

In this release I decided to get rid of WinRing0 and replaced it with CPUID driver, the one that is used by CPU-Z, HWMonitor, and many other CPUID-SDK based projects.

What's wrong with WinRing0?

WinRing0's does not create device object with exclusive flag, meaning it would allow multiple applications at a time to open unlimited number of handles. CPUID driver is created with exclusive flag, which allows only one handle opened at a time. SPD-RW opens driver handle only when needed and immediately closes it to allow other applications to use it.
 


WinRing0 does not check for access rights. That means once it is loaded, any application, even the ones started without administrative rights, can access and use WinRing0. CPUID driver requires certain application's privileges in order to be used.
 


Last, but not least, CPUID driver has a Microsoft WHQL signature, while WinRing0 is signed with a private individual's signature. Many non-Microsoft signed drivers have been blacklisted, like RwDrv (used by RW-everything) and atillk64 used by another SPD program, and require VulnerableDriverBlocklistEnable registry key present in order to work in modern versions of Windows 11.

To increase security further, I modified how SPD-RW interacts with the driver. The driver stays running on the system only when needed. The driver service only runs, while SPD-RW is connected to an SMBus controller. When SPD-RW is closed, the driver is removed.

Also, I decided not to use loader this time, as it additionally provoked false AV positives in the past.

Enjoy.