[Bug] RGB issues from CannonKeys discord

[tzarc]

Describe the Bug

CannonKeys discord has discussed an RGB issue which, for some vendors, resulted in then choosing a known-good version of QMK and pinning their releases to it.

Unfortunately nobody seems to have raised a bug, nor has anyone mentioned it to us until now (afaik).

Spoke with @awkannan last week and he said he'd shoot someone our way when the next report came along. The following is a transcript from Discord:

[6:11 AM] krautcat: Hi there, Is it good place to find help with Atlas keyboard issues, especially RGB underglow ones?
[6:14 AM] Luca_Lo - Sockhead Champion: right here i think
[6:20 AM] Rajing Panda: There are some fixes in the pins
[6:21 AM] krautcat: Ok, I will describe issues as much as I can understand.

First of all, I don't checked RGB and flashed firmware from VIA site. Then I used design JSON from Atlas' GB thread on Geekhack to enable VIA for Atlas. I tried to change lightning but keyboard doesn't respond to changing colour and mode. It seems board applies settings only after full reset (replugging the USB). Also any lightning animations doesn't work. So I only can get solid color or the first frame of effect.

Then I tried to flash and compile firmware for VIA from current master. Nothing changed.

Also I tried flash and compile current master for default keymap. It seems board doesn't respond to RGB keycodes.
[6:21 AM] krautcat: And they're not merged into master branch of QMK?
[6:22 AM] Rajing Panda: https://discord.com/channels/547219063269490765/772835813297487903/831733499563474955
[6:22 AM] Rajing Panda: Idk much about it but that is the fix I know of
[6:25 AM] krautcat: Thanks! Iirc this is applicable for MX/Alps solderable PCB with Atmega 32U4 as MCU.

My PCB is hotswap and is based on STM MCU (cannot recall the exact model).
[6:30 AM] Upas: @krautcat we think current QMK master has an issue, try pulling a commit from early november and trying
[6:32 AM] Goose: Yeah this has affected RGB on a few boards now
[6:32 AM] Goose: lots of vendors just having to build firmware on old versions of QMK and deliver it to their customers manually to resolve
[6:38 AM] krautcat: I knew this monorepo structure will explode one day (that's why I adopted repo tool for my keymaps)
[6:38 AM] krautcat: Ok now trying to flash 0.10.45, will see is there any issues or no.
[6:40 AM] krautcat: Everything is working now, thank you so much! I thought it was my mistake and I destroyed lightning completely
[6:46 AM] Upas: @krautcat if you're willing, can you describe more of the behavior you were seeing?
[6:46 AM] Upas: and which keymap you flashed? (via vs default)
[6:46 AM] Upas: basically we can write this up as a QMK issue which will give them some idea of what to look for
[6:47 AM] Upas: tzarc (qmk contributor) was in here as well and was looking for someone to help him git bisect to isolate the issue
[6:48 AM] Upas: the more info we can put in the issue the better
[6:58 AM] krautcat: I flashed QMK with VIA support. The firmware is pulled from VIA site. I don't know the version of it. Then I tried to change the layout using GUI. Everything works. Then I tried to tune the backlight via VIA's tab for backlight. Backlight after flashing has state, let's call it default state. I tried to change the colour, but the colour of backlight didn't change. Then I tried to change the animation effect, and animation didn't start. Notice: backlight still in default state. Then I set some solid color without animation. Then I repluged the board, and the colour of backlight changed to the one I set before replugging the board.

Then I tried to use animations. I set animation effect in VIA, changed color and then replugged the board. Color changed but animation didn't start. Something like it freezes on the first frame.

Then I tried to tune backlight via keycodes. I used current master and something 0.11.xx (my master I use for many boards as base). I flashed firmware and tried use stock keymap and keycodes to tune the RGB. RGB toggling and hue tuning didn't work, lighting was in the initial default state.
[7:00 AM] krautcat: For 0.10.45 VIA seems to work. I will check non-VIA firmware soon (currently fighting out keymap to code, but I can test asap).
[7:08 AM] krautcat: It seems the issue is not connected with VIA-specific features.
[7:08 AM] Upas: Got it
[7:08 AM] Upas: appreciate all that info :slight_smile:
[7:12 AM] krautcat: I am not familiar with QMK codebase and too afraid to dig into (it terrifies me with its structure) but you can connect me with tzarc (I don't know his username here), I can be a tester and maybe QMK junior developer haha

System Information

• Keyboard:
  • Revision (if applicable):
• Operating system:
• AVR GCC version:

• ARM GCC version:

• QMK Firmware version:

• Any keyboard related software installed?
  • AutoHotKey
  • Karabiner
  • Other:

Additional Context

[krautcat]

After bisecting from HEAD of develop branch and known-good commit (0.10.45 tag) I found that breaking commit is c66df16, tag 0.11.0.

[tzarc]

I've had conflicting reports -- others on the discord say that the c66df16 commit is the last-known-good one.

Apr 15 2021:

[8:18 AM] chippy: this is what I checked out iirc: c66df16
[8:20 AM] tzarc: @chippy so is that commit good or bad?
[8:20 AM] chippy: that is the one I use
[8:20 AM] tzarc: @chippy is that good or bad?
[8:21 AM] Goose: should be good
[8:21 AM] chippy:
git clone https://github.com/qmk/qmk_firmware.git
cd qmk_firmware
git checkout c66df16
make git-submodule

[tzarc]

I've resurrected the previous version of the develop branch, named pre-develop-merge-nov20.
This has all of the constituent PRs, would be great if you could do a bisect with this branch against your 0.10.45,

[chippy]

I was really confused about why I was being @'ed on a repo I have never been involved with, but I see now it's just someone from a Discord chat with the same name as me!

[tzarc]

Apologies for that!

[Croktopus]

I can confirm that c66df16 is where the issue starts, as the previous commit 15385d4 does not have the problem on my stm32f072 proto. Any update on this issue?

[krautcat]

Currently I don't have Atlas keyboard on hands. As soon as I will get the board at hands I will investigate the issue further.

[tzarc]

I can confirm that c66df16 is where the issue starts, as the previous commit 15385d4 does not have the problem on my stm32f072 proto. Any update on this issue?

No update -- I asked for a git bisect for branch pre-develop-merge-nov20 but got no response.

[krautcat]

@tzarc, I will give any update soon, sorry for long delays!

[sigprof]

The cannonkeys/atlas keyboard uses WS2812_DRIVER = spi with SPID2 on B15.

Looks like PR #10214 changed platforms/chibios/GENERIC_STM32_F072XB/board by removing local board.c and board.h files, so that lib/chibios/os/hal/boards/ST_NUCLEO64_F072RB/board.h is used instead. However, these files contain different GPIO setups — in particular, the old file was configuring the SPI2-related pins as:

 * PB13 - SPI2_SCK                  (alternate 0).
 * PB14 - SPI2_MISO                 (alternate 0).
 * PB15 - SPI2_MOSI                 (alternate 0).

The new file does not select any SPI2 alternate functions on these pins:

 * PB13 - PIN13                     (input pullup).
 * PB14 - PIN14                     (input pullup).
 * PB15 - PIN15                     (input pullup).

ws2812_spi.c configures the alternate function only for the MOSI pin, but does not attempt to configure MISO or SCK pins, so with the new code SPI2_SCK is probably not connected to any MCU pin. However, some unofficial sources suggest that on some STM32 MCUs the receiver part of the SPI controller actually takes the SCK input from the external SCK pin, even when the controller is in the master mode; because of this, the SPI receiver does not work when the SCK signal is not assigned to any pin. And the ChibiOS SPI driver uses the RX DMA completion interrupt to detect the transfer completion; if the receiver does not work, that interrupt never comes, and any subsequent attempts to send something over SPI are blocked. I did not actually try to test the above hypothesis on a real STM32F072 hardware though.

So a possible workaround might be stuffing

void board_init(void) {
    palSetLineMode(B13, PAL_MODE_ALTERNATE(0));
}

into atlas.c. Alternatively, the ws2812_spi driver could be extended to take some SCK-related defines from config.h.

Yet another option is using #define WS2812_SPI_USE_CIRCULAR_BUFFER (added in #12216) — when the circular mode is used, a non-working SPI receiver mostly does not matter (the completion or half-completion callbacks won't work, but the WS2812 SPI driver does not use them anyway). However, the WS2812 bitstream is transmitted continuously in this case (similar to how the pwm driver works).

BTW, another reason why the SPI driver may not work is that some code might invoke ws2812_setleds() before the previous transfer had actually completed (this seems to put the SPI controller or DMA into some broken state that prevents further transfers). This bug may be triggered by some other code changes; if #define WS2812_SPI_SYNC helps, then it's this bug (but if the problem is that the receiver does not work, adding #define WS2812_SPI_SYNC will result in a complete lockup, and it's not a good solution anyway). With #define WS2812_SPI_USE_CIRCULAR_BUFFER this problem is avoided too (in this case ws2812_setleds() just updates the data buffer and does not actually touch any hardware).

[Croktopus]

can confirm that the board_init workaround did, in fact, work. stuffed it into my keyboard.c and bam. what a hero

[tzarc]

Can I get some people afflicted by this to try #13022, please?

[HeliosPanoptes]

Tried #13022 on a CannonKeys Atlas, and it seems to work. I didn't do any rigorous testing, but the LEDs change color when the appropriate command is called, instead of going to EEPROM and only showing up on a power cycle.