Fix Light-sleep for ESP32 #3521
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Seems likely that #3517 also applies to all ESP32 devices, not just Heltec Wireless Paper. |
|
I can confirm that the program button on Heltec V3 now wakes the device from PowerSave mode as it used to. Thank you. I believe you fixed it. |
todd-herbert
force-pushed
the
fix-lightsleep
branch
from
1a46ac2 to
a26cb31
Compare
thebentern
approved these changes
Apr 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hopefully addresses #3512
Main culprit seems to have been the addition of
enableLoRaInterrupt(), which is competing with the hardware button for use of the EXT0 wake source. Using GPIO wake for the button works around this issue.Secondary issues with ISRs on wake, and PRESS event detection have also been addressed (kludged).
Tested with Heltec Wireless Paper, however this does currently require a hotfix for #3517 to first be applied. Will be separately address soon. Briefly tested with T-Echo. All seems to be running fine, at least at first glance.
I would expect this bug to affect all ESP32 devices(?). It would be good to have the fix independently tested, if anyone has the time / energy to spare.