Very cool stuff :)
I'm hoping to tell some XMP 3200 DDR4 sodimms to do their 3200 thing on a NUC11, which in Intel's wisdom they decided not to give support for Intel XMP... :)
Of course just ordering a different set of ram would be the wise move, but where's the fun in that :D
Ordered the cheapest so-dimm socket I could find, hope it will be here in a couple of weeks :)
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?
I will probably try without HV first anyways, I might be lucky and have an unprotected spd :)
 

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.
 

 
 

a213m

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.

Thank you! Some more questions :)
I managed to hand solder a DDR4 SODIMM socket (I'm crazy, don't try this at home, or anywhere else, it's madness :D ).
I'm pretty sure it's good, but would like to quickly go to a read only test just to make sure the basics are correct :)
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.
- 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! :)
 

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.

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

 
Yeah, you're right, I didn't spend enough time reading the data sheet, only looked at the maximum values, operating conditions are <= 3.6v indeed :)
Also only just realized you're using pull ups to 3.3v for SCL/SDA (which of course is how i2c works.. don't use it that often :) ), so those are correct voltage even with 5v arduino :)
I do have a bunch of ams1117 3.3v for working with esp8266/32, so all good, I'll put one of those in :)
 

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

Check :)

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:

Congrats! Glad to see my project helped you. :)

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.

Yes, 600 and 700 Intel series chipset will be supported in the next public release, ETA - end of September.
 
Update: see below.

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.
 
Supported chipsets in this release: B660, B760, H610, H670, HM670, H770, Q670, W680, WM690, Z690, and Z790. (W790 is not supported.)
 
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/Extreme Tweaker page, and set "SPD Write Disable" option to False.




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