Unpredictable behaviour in B350 TOMAHAWK

[JocPro]

Hello there.

I tried your software in an Ubuntu installation running in my MSI B350 Tomahawk + R7 1700 combo, and couldn't get it to run consistently: first of all, I could only get the LEDS to lit with full FFFFFFFF values and couldn't get any colors other than some of the known 7 colors present in the MSI Gaming App; also the leds sometimes just refused to work, or took a long time to respond to the commands. Your Hue Wheel example didn't work at all... the leds just turned off. ¿May this be related to the red leds present in the motherboard, instead of the white ones of the Mortar Artic that you have? They appear to work with every command. As their config is independent of the 'extended' leds in the header, maybe they use another offset or something?

I'm really interested in this, so if I can help you in any way to test for something or check stuff, please let me know.

PS: I contacted MSI for extra color support for this motherboard, and they said that this was a hardware limitation...

[nagisa]

Please see #2. It has discussion about the same Tomahawk. I’m not sure why the tool does not work on Tomahawk.

I’m fairly confident that the colour of the leds on the motherboard has nothing to do with the tool not working quite well, though.

[nagisa]

Now that I re-read the discussion in #2, it could very well be that it is necessary to set some other register on the Super I/O chip to get rid of the fading behaviour, but without having an access to a disposable motherboard, I do not really have any means to figure out the register, sadly.

[nagisa]

So the best next step to try would be to try and run the Gaming App on Windows at least once and then reboot back into linux and see if this utility works properly afterwards.

[JocPro]

I did some fiddling yesterday night with RWEverything and I can confirm two things:

1. The offsets are the same. I got to the same 12h bank and F0 addresses, as in your blog screenshot, and while changing colors in Gaming App, they reacted as expected. Then I thought, what if I change them directly with RWE? I did, and the lights changed. I could get an orange color, something impossible with Gaming App.
2. I noticed what maybe a little difference: the bits in the E0 addresses were a little different from what you had in your screenshot. I was trying to decode them based in the information that you provided in your source code, but it was kind of late and RWE order the bits in reverse from your diagram and my head was already spinning, so I was unable to... but I'll give it another go tonight.

Is there something akin to RWEverything under Linux that could monitor this addresses in realtime? That way I could monitor if your utility is doing what is supposed to do in the Tomahawk too.

[nagisa]

could you give me a screenshot of your rweverything window?

…

On Jun 15, 2017 4:23 PM, "JocPro" ***@***.***> wrote: I did some fiddling yesterday night with RWEverything and I can confirm two things: 1. The offsets are the same. I got to the same 12h bank and F0 addresses, as in your blog screenshot, and while changing colors in Gaming App, they reacted as expected. Then I thought, what if I change them directly with RWE? I did, and the lights changed. I could get an orange color, something impossible with Gaming App. 2. I noticed what maybe a little difference: the bits in the E0 addresses were a little different from what you had in your screenshot. I was trying to decode them based in the information that you provided in your source code, but it was kind of late and RWE order the bits in reverse from your diagram and my head was already spinning, so I was unable to... but I'll give it another go tonight. Is there something akin to RWEverything under Linux that could monitor this addresses in realtime? That way I could monitor if your utility is doing what is supposed to do in the Tomahawk too. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApc0hdtLh2f1kBlhc4BZDObzQLoDwbuks5sETBJgaJpZM4N6ZHX> .

[nagisa]

and no i do not know of a similar app on linux. maybe for the better because monitoring super i/o realtime has a tiny chance to cause weird problems. You can print out super i/o manually with this tool (flag --print) or superiotool from the coreboot project.

…

On Jun 15, 2017 5:25 PM, "Simonas Kazlauskas" ***@***.***> wrote: could you give me a screenshot of your rweverything window? On Jun 15, 2017 4:23 PM, "JocPro" ***@***.***> wrote: > I did some fiddling yesterday night with RWEverything and I can confirm > two things: > > 1. The offsets are the same. I got to the same 12h bank and F0 > addresses, as in your blog screenshot, and while changing colors in Gaming > App, they reacted as expected. Then I thought, what if I change them > directly with RWE? I did, and the lights changed. I could get an orange > color, something impossible with Gaming App. > 2. I noticed what maybe a little difference: the bits in the E0 > addresses were a little different from what you had in your screenshot. I > was trying to decode them based in the information that you provided in > your source code, but it was kind of late and RWE order the bits in reverse > from your diagram and my head was already spinning, so I was unable to... > but I'll give it another go tonight. > > Is there something akin to RWEverything under Linux that could monitor > this addresses in realtime? That way I could monitor if your utility is > doing what is supposed to do in the Tomahawk too. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#6 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AApc0hdtLh2f1kBlhc4BZDObzQLoDwbuks5sETBJgaJpZM4N6ZHX> > . >

[JocPro]

Here
http://imgur.com/a/xIXeS

[nagisa]

I noticed what maybe a little difference: the bits in the E0 addresses were a little different from what you had in your screenshot.

Ok, so the interesting part is indeed in the E0 address. I have no idea what the 0x7 in 0xe7 does, but the code in msi-rgb specifically tries to preserve the other bits in this area.

Did you try rebooting back into Linux after changing a colour in Windows and trying the msi-rgb again? If it works then it is certainly some detail, such as some bit being set somewhere, that we’re missing. If it still does not work, then this utility is overwriting some crucial bit somewhere. (I certainly hope it is the 2nd case, because this means we only need to be more careful about overwriting irrelevant bits).

This is probably the most outstanding question right now.

---

Some other observations/comments:

I got to the same 12h bank

Bank number in RWEverything does not matter. It only ever sets the bank once, MSI Gaming App then switches to another bank and RWEverything ends up writing and reading from the said bank.

I did, and the lights changed. I could get an orange color, something impossible with Gaming App.

That is super encouraging.

[CyanBlob]

I can confirm that this utility is not working on my Tomahawk (the LEDs just turn off). I don't have a Windows installation any more, unfortunately. I have changed the colors on Windows previously, but the cmos has been cleared by then. Is there anything that I can do to help getting this fixed?
EDIT: My behavior matches that of @adrianstaniec in #2

[nagisa]

Short of donating hardware or installing windows and doing some testing/reverse engineering, there’s nothing, I fear.

Alternatively, you can wait until a cheap 2nd hand board somewhere. Also, do nag MSI for specsheets via all communication channels you can find.

[matt6hub]

Why, hello there.
I was just scrolling along for a linux utility to control B350 Tomahawk RGB Chips, and it looks like you need help. I have a Tomahawk Motherboard with Linux and Windows 10, so just tell me what I need to do, and what utilities I need to install and tests to conduct and I should be able to help you. After trying out these tools, only F colours work properly. If you need any help, just ask me, and I may be able to help you conduct tests if I'm not that busy. Thanks for your hard work so far. -Matteo Pio

[MinDBreaK]

Hi,
I noticed that on my B350 Tomahawk, statics color are working "fine" :
The colors are correctly set but it took 15-30s to turn on at half of their power.

Some options are working, so far : -p and -b
These options are still limited by the half-powered LED.

Interesting fact : Using -p option turn on LEDs instantly

[btrummer]

Hi, I think I found out some news regarding MSI B350 Tomahawk boards:

1. In the current state of msi-rgb, only the value 'ffffffff' means "on", everything else is "off"
2. When turning on a color channel, it won't be on right away, but instead fades in over about 15 seconds.
3. When turning off a color channel, it will be turned off right away. So it looks like there is no fade-out, or I just didn't find it out yet.

Now the interesting part:

After looking at those TTT bits (comment on top of main.rs), I saw that there are 3 unused bits.
And after playing around with them I found out that with these I can switch each channel between two modes (sort of).
If those bits are '0' (like in the current code), then you'll have above's behavior.
But when setting them to '1', then basically all examples from the README work as expected: having 4 frames of arbitrary RGB values, the -d option defining the transition speed through the 4 frames, etc.

I added a "--disable-fade-in" option, so in order to get the examples working, you have to specify all three channels. For example the police light: ./target/release/msi-rgb -d15 FF00FF00 0 00FF00FF --disable-fade-in=r --disable-fade-in=g --disable-fade-in=b
You even can combine the fade-in effect on one channel with the 4-frame mode of others.
So modifying the heartbeat example this way will start the heartbeat in yellow color and the blue color will fade in and then stays at maximum after 15 seconds:
./target/release/msi-rgb 206487a9 206487a9 ffffffff -ir -ig -d 5 --disable-fade-in=r --disable-fade-in=g

For the code changes, see commit 0a04c04 of my fork at
https://github.com/btrummer/msi-rgb.

[nagisa]

Awesome! I’ll test if those bits on my board as well.

[nagisa]

Okay, those bits do nothing on my board. Which… is not terrible, but also weird? I suspect there might be some bit somewhere which is responsible for “enabling” this, but for now I guess I’ll just take this with somewhat adjusted user interface.

[nagisa]

@btrummer I pushed your suggested changes to master with slightly different UI. Namely, the meaning of the --fade-in flag is inverted and not providing any flags should just work by default. Please test and tell me if it does not work so I can close this issue.

[btrummer]

Current master works fine for me.
Having --fade-in instead of --disable-fade-in makes perfectly sense. :-)

Please also add a note, that if --fade-in is used, that the respective color value has to be 8x 'F', otherwise the channel just keeps black.

PS: maybe this "fade in" effect is just an additional feature of the Nuvoton NCT6795D-M chip used on (at least my) Tomahawk board...