Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] AVR suspend/power down during sleep #20087

Open
2 tasks
jaygreco opened this issue Mar 11, 2023 · 4 comments
Open
2 tasks

[Bug] AVR suspend/power down during sleep #20087

jaygreco opened this issue Mar 11, 2023 · 4 comments

Comments

@jaygreco
Copy link
Contributor

jaygreco commented Mar 11, 2023

Describe the Bug

I believe there is a long-running bug in AVR suspend during PC sleep. It manifests visibly with GPIOs: RGB goes haywire, the board isn't responsive after the PC sleeps until a power cycle, and on the Bit-C the built-in LED turns on. The common workaround is to define NO_SUSPEND_POWER_DOWN in the config.h, but this also keeps the RGB, backlight, etc enabled when the host is put to sleep.

I've also seen a few cases where internal flash gets corrupted (at least on 32U4) and the board needed to be flashed again to bring it back to life. There have been a few attempts to work around and fix this issue, but despite that it pops back up from time to time. When I was originally digging into this, it seemed possible that it was related to clocks since almost all clocks are disabled during power-down, but I never got to a root cause. @drashna advised me to open this issue to brainstorm/track mitigations. Disabling the AVR deep sleep by undefining WDT_vect (required to enter sleep, see https://github.com/qmk/qmk_firmware/blob/master/platforms/avr/suspend.c#L18) fixes this but is a hack.

A few possible examples:
#19192
#14127
#6822
#6726
#5239

There's a separate class of issue related to sleep on M1 Macs -- this is different from that one. The two don't seem to be related.

Keyboard Used

No response

Link to product page (if applicable)

No response

Operating System

No response

qmk doctor Output

No response

Is AutoHotKey / Karabiner installed

  • AutoHotKey (Windows)
  • Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

@skagon
Copy link

skagon commented May 29, 2023

I think I'm affected by this on my ErgoDox keyboard (self-made). I'm not using any LEDs or lighting, I've taken the ErgoDox EZ code and stripped all irrelevant settings and pieces (relating to RGB LEDs and such), and it absolutely won't start up after a sleep/wake cycle. I have to unplug and reconnect it manually. I've also experienced flash corruption twice so far.
For the record, it's on a powered USB hub, along with a few other hand-wired keypads I've made, and only the ErgoDox exhibits this behaviour. [see #19871 for the others]

@jaygreco
Copy link
Contributor Author

jaygreco commented May 29, 2023

Any chance of trying the fix in #20201? It cleared it up for me, although it hasn't seen any movement in the last few months.

Another datapoint + a bump/comment (if it appears to help) would be helpful in getting it merged.

You can also try to #undef wdt_vect, as it effectively ends up doing the same thing.

@Kodehawa
Copy link

Kodehawa commented Jan 8, 2024

I've also seen a few cases where internal flash gets corrupted (at least on 32U4) and the board needed to be flashed again to bring it back to life

I had this issue on my IK75v3 (Atmega32u4) after sleep. That was really annoying, and I had to reflash the entire board because everything decided to go haywire (ex. pressing fn would do nothing, and the keyboard would decide to type random keys)

I'm hitting this sleep bug almost daily (at least the "firmware corruption" part of it only happened once), which is quite a Thing.

EDIT: Now it forgot the RGB mode it was set to after suspend lol

@jacropad
Copy link

I have a custom board with ATMega32U4 that's been having issues waking from sleep. It consistently fails when waking up, Windows displays the error "Unknown USB Device, device descriptor request failed".

#define NO_SUSPEND_POWER_DOWN seems to solve the problem, but I tried replacing that with #undef wdt_vect and the problem comes back unfortunately. But I'm content with using NO_SUSPEND_POWER_DOWN because I don't have any LEDs or anything to make it obvious that the board isn't asleep.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants