The AM4 X570 is not starting when four memory modules are connected.
The AM4 X570 is not starting when four memory modules are connected.
Hello everyone, I own an AM4 X570 system with these specifications: CPU – AMD Ryzen 7 5800X, Motherboard – GIGABYTE X570 AORUS Elite, RAM – 4x 8 GB Corsair DDR4 at 3200 MHz, GPU – AMD Radeon RX 6700 XT. I attempted to upgrade my BIOS from F38a to F38b, removed the CMOS battery, waited for it to reset, and then reinserted it to access Q-Flash for the new BIOS settings. After that, I powered on the system, but it failed to complete the POST. The fans spun, the board lights flashed, and both the CPU and GPU warmed up, yet the UEFI BIOS never loaded. I spent time trying different approaches—swapping memory, checking connections, even testing individual sticks—but nothing worked. Eventually, I found the system would boot with just one or two memory modules, but not more. It’s puzzling because I’d used these modules at full XMP speed for over a year without any problems. I also tried using individual sticks in each slot to confirm if a faulty one was the issue, and they all functioned correctly. It’s worth noting that all modules share the same SPD data, match JEDEC standards, and operate at identical speeds. However, two kits differ in versioning: one is 4.32 (Samsung C-die) and the other is 5.39 (Hynix M-die). Despite everything working smoothly for nearly two years, the BIOS update caused a complete failure. I’ve read about adjusting voltage settings, but I’m unsure of the safe ranges or recommendations. I was previously using auto settings and XMP enabled, and the system worked fine then too. Now, mixing the older 4.32 sticks with newer 5.39 ones breaks everything. Any advice or solutions would be greatly appreciated. Thanks.
Why did you skip the CMOS battery during a BIOS update? Which instruction guided you to do so? You didn’t need to remove the CMOS battery for a BIOS update. You should have simply updated the BIOS directly within the BIOS interface, using a BIOS flash outside of the main update—this method often works. BIOS flashing via BIOSFLASHBACK isn’t reliable and may require several tries. Sometimes it needs memory training; your BIOS was set up for the RAM kit and XMP, but touching it reset everything and forced a full retraining. This process can take a few minutes, particularly when dealing with multiple dimensions. Also, why did you update your BIOS? Was there a specific reason? Usually each BIOS version behaves slightly differently, and you might encounter some instability. These updates are often beta releases, but sometimes they’re released for final use. You might need to install the RAM sticks, clear the CMOS, wait a while, and then power off the system to reset it—leaving it on for up to 10 minutes, then restart if nothing happens.
I apologize for the mix-up. I removed the battery before applying the update to restore everything to a fresh setup, eliminating any issues from XMP, PBO, Curve Optimiser, or similar settings. The twist! I’m considering restarting the memory training, but I paused it for 10-15 minutes earlier and it didn’t progress. 2x 8 GB sticks completed fully in under 5 seconds. 4x 8 GB took longer, never finishing.
I suspect there might be an unusual interaction with the GIGABYTE BIOS. I tried changing a few parameters—adjusting XMP, turning off power-down, raising the SOC voltage—and it still worked. When I reset everything back to defaults, it still boots. It’s really puzzling how this happens. Someone could help clarify what’s going on.
In theory they should match the same specifications, but if you're correct, do you mean placing the Samsung C-die modules in Channel A & B slot 1 and filling the rest, or grouping the die modules together—Samsung C-die in channels A1 & 2 and Hynix M-die in B1 & 2? My motherboard manual (sections 1-4) doesn't specify which slot is primary, so I'd assume A1 and B1 are the main ones.
A2 and B2 are the main connectors. Ensure identical RAM is placed in matching socket pairs.
It turns out the problem is more complex than anticipated. One of my memory chips is displaying the JEDEC 2133 MT/s speed as expected at 1.0 V, which is not within the normal range for desktop DDR4. I accessed Thaiphoon Burner and found at least a corrupted byte—possibly multiple. This isn’t likely a BIOS fault; it seems the RGB software might be writing invalid data to the SMBus memory. Corsair iCUE and OpenRGB appear to be the culprits. I recently installed Corsair iCUE 5, so it could be related. For anyone looking online for similar issues, check if your RAM’s SPD EEPROM data is damaged. My module has corruption at byte 11 (0Bh), which controls the voltage setting. It should read 03h, but it’s showing 01h or 05h instead. Unfortunately, I can’t modify the SPD data without purchasing Thaiphoon Burner and I’m unable to reach checkout. Edited May 8, 2023 by ADAMPOKE111
I finally resolved my problem, though it took me far beyond what I originally anticipated. If you encounter similar challenges—such as a failing POST, incorrect voltage readings, timing mismatches, or frequency errors—reading this might assist you. The main surprise came when my motherboard claimed a JEDEC 2133 MHz profile, but it was actually instructing the modules to run at 1.0 V. There were some minor oversights, like a misspelled "Profile" instead of "Profile," which contributed to confusion. I applied an XMP profile that fixed the timings and voltages, but Windows crashed during installation with CRC errors across all four modules. The RAM SPD data was corrupted, showing incorrect values at location 0x0B in each chip. I tried to fix it using a SPD browser, but the numbers didn’t match expectations. I couldn’t buy Thaiphoon Burner at the time, so I relied on their website for guidance. After some research, I discovered a blog detailing how to alter RAM SPD values via an Arduino over I2C. While I don’t have an Arduino or the tools to probe the chips directly, I found instructions on modifying SPD data using Debian Linux. I also learned from OpenRGB and Arch Wiki documentation that I could load specific i2c modules at boot, though I faced challenges with the process. Once the system was running, i2cdetect confirmed three SMBus buses were active. I adjusted the byte at 0x0B to the correct value (03) and rebooted, which restored proper voltage readings. The issue was resolved, but I remain uncertain about the root cause—possibly OpenRGB or Corsair iCUE interfering with SMBus. I’m considering retesting these products to ensure my RAM’s SPD is intact, but for now, I’m relieved the fix worked.