Z170 Pro4 RAM Issue with latest BIOS (3.20)

geoto wrote:

@parsec - BIOS is telling me that the RAM is running @2133Mhz, but all of the clocks and timings are correctly updated (I think). Also, CPU-Z says the same thing.

RAM S/N - HX424C15FBK2/16

Here's three screenshots. XMP Off, XMP On and XMP On + forced DRAM frequency to 2400Mhz.

http://s28.postimg.org/4l901al0t/xmpoff.png

http://s28.postimg.org/fara7am7h/xmpon.png

http://s28.postimg.org/9lb1mzg19/xmpforcedfrequency.png

I noticed that when I turned XMP on AND forced DRAM to 2400Mhz, the CR, the tRFC and FSB:DRAM changed, compared to "XMP" @2133Mhz.

Is that normal?

So yeah, I know I can manually change the frequency - but is that safe? The XMP profile was working correctly in the old BIOS, so it's kind of disappointing. I hope they fix this in the next update. If ASRock staff reads this forum anyways.

Thanks.

It does seem as if the 3.20 UEFI/BIOS has a bug with the XMP profile. Given your CPU-Z pics, some of the XMP data looks like it was applied, and some of it wasn't.

If you look at the SPD tab of CPU-Z, it should display the XMP profile, and some of the other timing/speed profiles that is included with all memory. For example, this is my G.SKILL Trident Z memory:

In general, as the memory speed increases, there are changes to the CR, tRFC, FSB:DRAM, and other memory settings, that is normal. It becomes increasingly difficult to maintain the same timings and latency as the memory speed increases, so the values of these settings become "looser", they are slower/increase. You can see that in the SPD information for my memory.

At 1066MHz (2133 DDR speed) the timings are 16 15 15 35 50. At 1600MHz (3200 DDR speed) the timings are 16 18 18 38 56. There are many other memory settings that also change (usually increased) as the memory speed increases.

We can manually set the higher timings to lower values after we increase the memory speed, but the memory may not be able to function or be stable with the lower timings.

In the example pictures you posted, we can see in the XMPOn pic, that the timings have increased compared to the XMPOff pic. XMPOff is 14 14 14 32 278 2T, XMPOn is 15 15 15 35 313 1T. The memory speed stayed the same (1066/2133 DDR) in both pictures, which is the problem.

We can further changes in the XMPForced picture, that you asked about.

Given all three pictures, it looks like either some of the XMP data was applied with XMP enabled, while the speed was not changed. Or it is possible that the Auto value for each setting changed the settings. That is the UEFI/BIOS itself was smart enough to increase the settings for the increased speed... which was not applied by the UEFI/BIOS. Programming bugs/errors can do some strange things. Wacko

That's why I want to see what the XMP data is on the CPU-Z SPD tab. I may not be able to tell if the changes in your pictures is the XMP data, or the Auto UEFI settings changing things, but it might provide clues about what is happening.

It is safe to manually change the memory speed, and the memory timings and other settings. Safe here means it won't damage anything. But the manual settings may be "wrong" in the sense the memory won't operate with those values. The PC may not POST or boot, or will BSOD in Windows. Those things usually don't damage anything, except for potential corruption of your Windows installation.

Memory voltage and associated memory voltages (VCCSA and VCCIO) can cause damage if they are set to high. Those are the only potentially unsafe settings, regarding hardware damage.

XMP settings are really a convenience for setting memory timings, which is complicated. All modern memory has SPD data, which tells the UEFI/BIOS what timings to use. SPD data is really the same as XMP data, but XMP data is in a special location, which is looked at when XMP is enabled. That area has the highest performance settings for the memory. The default SPD settings are always easier for the board and memory controller to operate the memory at, and insures that the memory will work on low end mother boards/PCs.

It looks like the new 3.20A Beta UEFI fixed the problems.