[Bug] RP2040 cannot wake from S3 Sleep

[scchow]

Describe the Bug

My RP2040-based board cannot wake my computer from S3 sleep on Windows.

I suspect it has to do with the rp2040-based microcontroller I am using, because my other boards that are not rp2040-based do not have this issue.

Steps to Reproduce

1. Put Windows into S3 sleep via Start Menu -> Power -> Sleep
2. Press any key on the board.

Expected behavior

Computer should resume from S3 sleep and the login page should be displayed

Actual behavior

• Computer remains asleep.
• Only the RGB on the master side of the keyboard lights up, but does not perform the breathe animation that it is set to.
• The OLED on the slave side (which has a Bongo Cat animation) briefly turns on (< 1 sec) when keys are repeated pressed. It is as though it turns on, but immediately turns off again when it realizes the computer is still asleep. The OLED on the master side remains off.

Keyboard

I am seeing this problem on the Sofle v3.0 RGB split keyboard with a pair of Elite-Pi rp2040-based microcontrollers and ssd1306 OLEDs.

I am using my own keymap that can be found in my fork here.

Related Issues

• [Bug] Some rp2040 boards will not wake host from sleep on keypress #19008 - Has the exact same issue on Linux. It somehow got resolved with a kernel update? They seem rather unsure of the root cause or what fixed it. I am running into this issue on Windows.
• [Bug] Waking computer from suspend-to-ram (ACPI S3 sleep) using KC_WAKE doesn’t work #16934 - Similar issue, but with a Teensy controller. Apparently their issue was on the Chibios side and it was resolved in this PR by preventing the board from restarting the USB driver.

Keyboard Used

sofle/rev1/scchow

Link to product page (if applicable)

Sofle Keyboard

Operating System

Windows

qmk doctor Output

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: /home/scchow/qmk_firmware
Ψ Detected Linux (WSL).
Ψ Git branch: scchow-sofle
Ψ Repo version: 0.19.8
⚠ Git has unstashed/uncommitted changes.
Ψ - Latest scchow-sofle: 2023-01-21 13:56:41 -0800 (0141b48b01) -- Back to EE_Hands, Config bindings, tap dance type
Ψ - Latest upstream/master: 2023-01-21 04:43:11 +0900 (300a0def4e) -- Change era65 keymap&debounce_type (#19627)
Ψ - Latest upstream/develop: 2023-01-20 19:43:58 +0000 (713003b7fd) -- Merge remote-tracking branch 'origin/master' into develop
Ψ - Common ancestor with upstream/master: 2023-01-10 07:09:09 -0800 (5e5b19cf94) -- Keychron S1 ANSI Layout Touch-Up (#19556)
Ψ - Common ancestor with upstream/develop: 2023-01-11 19:58:27 +0000 (46c85c93f0) -- Revert "De-duplicate platform detection (#19545)" (#19564)
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 9.2.1
Ψ Found avr-gcc version 5.4.0
Ψ Found avrdude version 6.3-20171130
Ψ Found dfu-programmer version 0.6.1
Ψ Found dfu-util version 0.9
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2022-09-18 10:01:17 +0000 --  (0e9d558b5)
Ψ - lib/chibios-contrib: 2022-12-09 23:26:27 +0100 --  (1130173e)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2022-09-19 18:02:44 +0200 --  (8d56ea3)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f)

Is AutoHotKey / Karabiner installed

AutoHotKey is installed, but unrelated to this issue.

Other keyboard-related software installed

No response

[scchow]

Mentioning @npross because they described running into similar issues with a Sofle using rp2040 microcontrollers in another issue.

[ForsakenRei]

It seems the Adafruit RP2040 Macropad didn't have this issue after applied KarlK90's fix, it can wake my PC up from S3...I will double check if I put it into S3 or not once I got home today.

[npross]

... described running into similar issues with a Sofle using rp2040 microcontrollers in another issue.

@scchow Thanks, I have done more testing and @KarlK90's fix resolves the issues. Makes sense because waking from sleep often was after a long delay, Thanks Stefan and Scott.

[scchow]

Thanks for the updates. I'll try testing my setup on a different computer and let you know how it goes.

[scchow]

I found that if I add #define NO_SUSPEND_POWER_DOWN to config.h, my keyboard continues to stay on with LED animations, and even the WPM counter on the OLED working. But pressing keys on the board still does not wake the computer up.

Shows that maybe the board fails to send keypresses to the computer once the computer enters this particular state of sleep?

However, I can wake the computer by pressing any key on a different board or clicking the mouse.

Also, just wanted to note that I am able to use this keyboard on startup to navigate the BIOS and GRUB, so it seems to be a purely a sleep issue.

[kmplngj]

I could also not wake my macOS from sleep with a Tofu Jr (RP 2040).

[KarlK90]

@scchow @kmplngj please test your boards with #19780 applied. This fixes the S3 resume on my side. Please make sure that NO_SUSPEND_POWER_DOWN is NOT defined or the wakeup mechanism will not work.

[scchow]

@scchow @kmplngj please test your boards with #19780 applied. This fixes the S3 resume on my side. Please make sure that NO_SUSPEND_POWER_DOWN is NOT defined or the wakeup mechanism will not work.

I merged #19780 into my development branch. Unfortunately, I am still running into the wakeup issue.
My merged keymap and config can be found here. I have commented out the NO_SUSPEND_POWER_DOWN.
Let me know if there is anything I should try disabling.

[KarlK90]

Could you add DEBUG_MATRIX_SCAN_RATE_ENABLE = yes to rules.mk and see if you still can't wake from s3 sleep? The idea (theory?) here is that this sends a periodic RAW HID report to the host when the keyboard is not in suspense which should wake the host.

[scchow]

Could you add DEBUG_MATRIX_SCAN_RATE_ENABLE = yes to rules.mk and see if you still can't wake from s3 sleep? The idea (theory?) here is that this sends a periodic RAW HID report to the host when the keyboard is not in suspense which should wake the host.

Still no dice with DEBUG_MATRIX_SCAN_RATE_ENABLE = yes added.

Something interesting I noticed is if I plug and replug my keyboard while the computer is asleep, my keyboard enters an unresponsive state (RGB animation of the master side working, but RGB on other side, keypresses, and OLEDs not responding) until I unplug/replug again, even if I wake my computer with another device in the meantime.

Don't know if this is useful information, just noting it here in case it sparks some ideas as to what may be happening.

[KarlK90]

This is very strange indeed. Did you also update your submodules, especially ChibiOS-Contrib to the latest state?

[scchow]

Did a quick qmk git-submodule to update my submodules.
The sleep issue still persists with rebuilt firmware.

One change I did see is when doing the replug test, RGB animations now work on both sides, but the OLEDs and keypresses are still unreponsive.

[KarlK90]

One more try. Could you compile the rp2040 onekey with the fix and latest submodule and see if this is also unable to wake up the host? In the future I have to get myself a real windows machine and try to replicate this error.

[scchow]

Assuming you're talking about this when you mention rp2040 onekey?
Unfortunately the only two rp2040 boards I have are in my Sofle at the moment.
I can do it this weekend once I have some time to disassemble the case/board.

Just making sure, I am using an Elite-Pi which has this pinout. Would bridging pins D4 and D5 cause a keypress? (Are they equivalent to the GP4/GP5 pins that is mentioned in the one-key readme?)

[KarlK90]

@scchow sorry for the late reply. Yes I meant the referenced handwired/onekey keyboard, and bridging the D4/D5 pins would result in a keypress!

[scchow]

@scchow sorry for the late reply. Yes I meant the referenced handwired/onekey keyboard, and bridging the D4/D5 pins would result in a keypress!

@KarlK90 Finally got around to testing the handwire/onekey. I worked on the same branch with the fix and submodules. I built and flashed the handwired/onekey keyboard on my Elite-Pi. Bridging D4/D5 did produce the letter a under normal conditions, so flashing the keymap was successful.

Unfortunately I encountered the same issue where I was unable to wake the computer from sleep using the onekey.

[KarlK90]

One more thing, If you have selective usb suspend enabled under Windows - could you disable it as see if this changes anything? I try to get a hold on a real Windows 11 machine in the meantime.

[KarlK90]

@scchow So good news: I can reproduce the issue with a W11 laptop that I borrowed. Bad news: I can reproduce the issue 😛. I'll investigate and let you know what I've found out.

[scchow]

@scchow So good news: I can reproduce the issue with a W11 laptop that I borrowed. Bad news: I can reproduce the issue 😛. I'll investigate and let you know what I've found out.

Good to hear the problem is not localized to my setup 😅

One more thing, If you have selective usb suspend enabled under Windows - could you disable it as see if this changes anything? I try to get a hold on a real Windows 11 machine in the meantime.

I tried disabling selective usb suspend, but that did not change anything.
Best of luck with the debugging and let me know if there is anything I can do to help! :)

[kmplngj]

I compiled the development branch today. Seems to not fix my problem with the Tofu Jr.

[KarlK90]

@scchow @kmplngj @npross @ForsakenRei complete plot twist on the S3 fix which now allows the keyboard to wake my W11 and Linux machine just fine. Technically I've removed the forced restart of the USB driver in the last iteration of the fix #19780. Could you try if this works as well for you? I'm especially interested if this also works on Mac.

[scchow]

@KarlK90 So good news and bad news.

Good news is I rebased #19780 into my branch and am happy to report that I could wake my computer up with my rp2040 board!

Bad news is that after the computer wakes up, my board is frozen, and I have to replug the board to get it to respond again. All RGBs and OLEDs remain dark and the board is unresponsive as though it is stuck in sleep.

I tried setting #define NO_SUSPEND_POWER_DOWN in config.h and tried it again. This time RGB and OLEDs stay on when computer is asleep, and I could wake the computer with a keypress. However the board once again freezes.

It is interesting to note that the board itself is frozen, as the WPM counter on the OLEDs does not change even when I press keys on the board.

You can see state of my branch here.

Thanks for your help with debugging this issue!

[KarlK90]

@scchow I've found the root cause of the failing in resume and posted a fix to the RP2040 usb driver in ChibiOS/ChibiOS-Contrib#365 the same bug affects STM32f4xx mcus and I've posted a patch on ChibiOS discord. Could you checkout the ChibiOS branch with my fix and test if this fixes your board freezes? I've tested it with W11 and Linux and it works flawless on my side.

[scchow]

@KarlK90 I merged your ChibiOS-Contrib fork into the current branch of qmk/ChibiOS-Contrib and am happy to report I can now wake my computer from sleep and resume without freezing!

I did want to point out that I could not just check out your branch, because it seems like your rp2040-remote-wakeup branch is a couple commits behind the main ChibiOS-Contrib 21.11.x branch, which caused a couple of compilation errors. Might want to rebase your branch to the current head.

Thank you for all the help in debugging and fixing this issue. Have a great day!

[KarlK90]

You're welcome and that is great to hear, so no more hacks required. I've also rebased my fix branch, totally missed that it is based on a old one.

[bdtc123]

@scchow @KarlK90 hello,after reading your discussion and updating my file ，this bug seems to be perfectly solved.but i found a strange situation on macbook today, if I define RGBLIGHT_SLEEP, rgb leds will turn off after pc sleep, but after waking up ，all keys can't input, I have to replug the keyboard. If I don't define RGBLIGHT_SLEEP, the rgb won't turn off after the pc sleep, but I won't need to replug the keyboard for normal use. when i use this board（rp2040) with windows pc and everything works fine.

[npross]

I have a similar problem as @bdtc123 but I am on a DELL laptop. If I let my laptop hibernate or power down, when I restart I cannot use the keyboard without resetting or replug. I applied @KarlK90s recent changes anyway even though i suspected they would not apply).
I haven't had a lot of time to do any systematic testing. My main keyboard is a moonlander. The sofle is supposed to be my travel keyboard .

[bdtc123]

@npross my board is ok on windows after i applied @KarlK90 recent changes. And i found it doesn't matter if define RGBLIGHT_SLEEP or not, it just can wakeup my m1macbook once ,cannot input anyting.

[KarlK90]

@bdtc123 @npross I've found and fixed a bug in the ChibiOS USB stack which fixes the resume hang on a M1 Macbook for me. You have to pull the latest commit in the PR which contains the ChibiOS update and of course apply my fixes to the RP2040 USB driver.

[Roming22]

I'm on the latest Fedora, with a keyboard that has a sea-picro (pro micro clone), and also have this issue.

[KarlK90]

With #19780 merged this issue should be solved now on the latest develop version of QMK.