ASRock Taichi TRX40 & ADATA XPG SPECTRIX D41 RGB issue with HWiNFO64

[Teknophage]

I've discovered that having HWiNFO64 loading causes even the numbered banks of RGB RAM to no longer accept requests from the Polychrome RGB controller. I attempted to exclude SMBus address x6A, which did not resolve the issue. This address is reported to be the Nuvoton NCT6796D address for RGB control (per OpenRGB) -- although this address may be different on my board as I'm still investigating.

Process to identify:

• Booting and not loading HWiNFO64 -- Making changes to RAM RGB works on all sticks.
• Loading HWiNFO64 -- 50% of installed sticks (even banks [Channels C & D, I believe]) fail to respond to RGB changes. No other motherboard RGB issues other than an occasional reset to "rainbow" (related).
• Rebooting with HWiNFO64 set to auto-start -- Issue returns immediately after HWiNFO64 loads, can prevent Polychrome Software from operating any motherboard RGB settings properly and settings are occasionally reset to "rainbow".
• Rebooting without HWiNFO64 -- Confirmed issues did not return.

Note: The sticks that stop listening to RGB changes remain in their previous configuration.

Configuration of RAM is 4 ADATA XPG Spectrix D41 RGB 16GB sticks in quad-channel configuration. Motherboard supports eight sticks in total. It's uncertain if the issue is with the HWiNFO SMBus scan of the motherboard's RGB controller or if there's something related to the RAM hardware information scan. I've noted that the RAM information shows eight memory devices. Four of these have no associated memory mapping. Assumption is that these devices may be the RAM's onboard RGB controller or interface.

Screenshot of Memory Device without an associated Memory Array Mapped Address:

Screenshot of Memory Device with an associated Memory Array Mapped Address (Same Channel):


Working theory is that the Memory Device without an associated array mapped address is actually the RGB segment. As the same sticks cease communication, could they be out of range of a filter? I have attempted to use the latest beta, which did not resolve the issue. Current version of HWiNFO64 Pro is licensed (personal). Are there additional SMBus addresses to exclude? I can provide additional information as requested.

 

[Martin]

The issue is most likely a different SMBus address that when scanned causes loss of RGB control.
I'd start with disabling entire SMBus support in HWiNFO to confirm if it's the case. If yes, enable it again and try to disable SMBus devices around 0x6A. You might try with disabling entire rows to narrow down the search and figure out the final address causing this.

 

[Teknophage]

The issue is most likely a different SMBus address that when scanned causes loss of RGB control.
I'd start with disabling entire SMBus support in HWiNFO to confirm if it's the case. If yes, enable it again and try to disable SMBus devices around 0x6A. You might try with disabling entire rows to narrow down the search and figure out the final address causing this.

Confirmed to be SMBus related. Thanks for the pointers. I'll reply back once I've identified the address exclusion to provide for others.

​

 

[Teknophage]

Solution was found in blocking SMBus Device x71 on the ASRock TRX40 Taichi. Blocking this returned functionality to the Polychrome RGB controller. Also disabled the Intel ME and SVID support as it's an AMD, which perhaps coincidentally allowed a new device to appear in the Sensor Status window. The Intersil ISL69269 returned additional information, reporting telemetry directly from the Voltage Regulator for VR Loop 2. This was previously blank.

Thank you for your assistance @Martin and keep up the great work!

 

[Martin]

Thanks for the feedback, this will be useful for others.
You should not need to disable IME and SVID support, this has no effect on AMD.