fix: short-press power button to wakeup by ngxson · Pull Request #482 · crosspoint-reader/crosspoint-reader

ngxson · 2026-01-22T01:33:23Z

Summary

Based on my observation, it seems like the problem was that inputManager.isPressed(InputManager::BTN_POWER) takes a bit of time after waking up to report the correct value. I haven't tested this behavior with a standalone ESP32C3, but if you know more about this, feel free to comment.

However, if we just want short press, I think it's enough to check for wake up source. If we plan to allow multiple buttons to wake up in the future, may consider using ext1 / esp_sleep_get_ext1_wakeup_status() to allow identify which pin triggered wake up.

Note that I'm not particularly experienced in esp32 developments, just happen to have prior knowledge hacking esphome.

Additional Context

N/A

AI Usage

While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it
helps set the right context for reviewers.

Did you use AI tools to help write this code? NO

olearycrew · 2026-01-22T03:19:42Z

@ngxson this looks pretty good - thanks for it!

I'd love if we don't define the "10" in two places - mabe we could

Add a static constant in the CrossPointSettings class near the SHORT_PWRBTN enum

Something like:

enum SHORT_PWRBTN { IGNORE = 0, SLEEP = 1, PAGE_TURN = 2 };
static constexpr uint16_t SHORT_PRESS_DURATION_MS = 10;
static constexpr uint16_t LONG_PRESS_DURATION_MS = 400;

Then update both locations:

CrossPointSettings.h line 104 return (shortPwrBtn == SHORT_PWRBTN::SLEEP) ? SHORT_PRESS_DURATION_MS : LONG_PRESS_DURATION_MS;
main.cpp line 157 if (SETTINGS.getPowerButtonDuration() <= CrossPointSettings::SHORT_PRESS_DURATION_MS)

What are your thoughts there?

olearycrew

See my other comment above

ngxson · 2026-01-22T10:25:50Z

Yes that sounds good, thanks! I applied your suggestions in the last commit

osteotek · 2026-01-22T12:02:17Z

In my experience, esp_reset_reason() and esp_sleep_get_wakeup_cause() return different results based on whether the device is connected via USB or not. Has this not been an issue for you?

ngxson · 2026-01-22T12:30:34Z

@osteotek I cannot find a way to test it without USB cable connected, but what I found was:

Upon connected to USB, I get ESP_SLEEP_WAKEUP_UNDEFINED and ESP_RST_POWERON that triggers wake up
When USB stays connected, I got ESP_SLEEP_WAKEUP_GPIO and ESP_RST_UNKNOWN as expected

Waking up when USB is connected is a side effect of this PR. We can optionally check isUsbConnected() to avoid this. But in terms of UX, I think it make more sense to wake up when usb is connected. WDYT?

Just realized that isWakeupAfterFlashing() is now left unused. I'm not sure if we still want to keep it around.

ngxson · 2026-01-22T13:12:16Z

src/main.cpp


  inputManager.update();
  // Verify the user has actually pressed
+  // Needed because inputManager.isPressed() may take up to ~500ms to return the correct state


@Eloren1 as explained here, it seems like inputManager.isPressed() take a bit of time to report the correct value. Due to this, I'm a bit doubt if this logic can reliably tell if power button held for 400ms or 600ms. Not sure if you have the same problem on your side?

Re. removal of the constexpr, I think I can simply check shortPwrBtn == CrossPointSettings::SHORT_PWRBTN::SLEEP

Hmm I left 400-600ms variants almost untested because the difference should be barely noticeable. Maybe I keep just one of them like 500ms? I mainly used 1000ms and it worked without problems.

osteotek · 2026-01-22T14:01:10Z

@osteotek I cannot find a way to test it without USB cable connected, but what I found was:

Upon connected to USB, I get ESP_SLEEP_WAKEUP_UNDEFINED and ESP_RST_POWERON that triggers wake up

When USB stays connected, I got ESP_SLEEP_WAKEUP_GPIO and ESP_RST_UNKNOWN as expected

Waking up when USB is connected is a side effect of this PR. We can optionally check isUsbConnected() to avoid this. But in terms of UX, I think it make more sense to wake up when usb is connected. WDYT?

Just realized that isWakeupAfterFlashing() is now left unused. I'm not sure if we still want to keep it around.

We probably shouldn't wakeup after connecting to usb. That's not how ereaders work in general.

I output to screen. My testing results:

device wakes up from power button:

usb is not connected: wakeup cause - ESP_SLEEP_WAKEUP_UNDEFINED, reset reason - ESP_RST_POWERON
usb is connected: wakeup cause - ESP_SLEEP_WAKEUP_GPIO, reset reason - ESP_RST_DEEPSLEEP

This is likely explained by the fact that the device disconnects the battery when it enters deep sleep mode (when it is not connected via USB).

Also when device wakes up after flashing firmware (hard reset via RTS pin) and usb is connected:

wakeup cause ESP_SLEEP_WAKEUP_UNDEFINED, reset reason - ESP_RST_UNKNOWN

osteotek · 2026-01-22T14:33:20Z

@ngxson based on my findings above I propose following logic for determining if device woke up from power button:

bool isWakeupByPowerButton() {
  const auto wakeupCause = esp_sleep_get_wakeup_cause();
  const auto resetReason = esp_reset_reason()
  if (isUsbConnected()) {
    return wakeupCause == ESP_SLEEP_WAKEUP_GPIO;
  } else {
    return (wakeupCause == ESP_SLEEP_WAKEUP_UNDEFINED) && (resetReason == ESP_RST_POWERON)
  }
}

I haven't tested it though. Need to be careful testing this, I managed to softbrick my device once working on this part before, device was going to deepsleep immediately after waking up without checking any logic 🙂 probably some kind of safe guard would be nice

ngxson · 2026-01-22T14:48:37Z

Thanks, that works!

I haven't tested it though. Need to be careful testing this, I managed to softbrick my device once working on this part before, device was going to deepsleep immediately after waking up without checking any logic 🙂 probably some kind of safe guard would be nice

It seems to me that the current check guard can be SdMan.begin(), simply removing SD card will skip the isWakeupByPowerButton / verifyPowerButtonDuration

Probably should write a small comment so that this use case is visible in the code.

osteotek · 2026-01-22T14:53:08Z

It seems to me that the current check guard can be SdMan.begin(), simply removing SD card will skip the isWakeupByPowerButton / verifyPowerButtonDuration

@ngxson It will work for now. But I actually tried implement checking power button duration before SD init, to avoid constant io work on every button press using RTC Attributes, but it didn't work, likely because of the aforementioned issue with battery disconnect on entering deepsleep
#447

ngxson · 2026-01-22T15:01:57Z

It will work for now. But I actually tried implement checking power button duration before SD init, to avoid constant io work on every button press using RTC Attributes, but it didn't work, likely because of the aforementioned issue with battery disconnect on entering deepsleep

Interestingly, I gave it a try on my side for a different reason (was wondering if I can improve the boot speed). But I decided it's not worth the effort as the action taking the most boot time was display initialization.

Just out of curiosity, is there circuit diagram available? I was a little bit regretful buying this device because for some reasons they decided to cramp multiple buttons into an analog GPIO, which make light sleep impossible 😂 Before buying it, I though one button == one GPIO (or maybe 3 digital GPIO, which make it 2^3-1 button combination)

ngxson · 2026-01-22T15:10:07Z

Another idea for the safe guard path, does it make sense if we enter a "debug mode / safe mode" if the down button is held on wakeup? Kinda like holding vol down for download mode on android

(I can add it in a follow-up PR)

DaniPhii · 2026-01-23T10:36:03Z

Hi team, I have no idea whether the following idea would be possible and/or safe, but I was reading this thread, and this made me think about the possibility of dual booting between the original firmware and CrossPoint with a key combination, for those who want to use both firmwares. This would allow to jump between them without connecting the device to a PC in order to change the active app partition.

ngxson · 2026-01-23T10:53:46Z

@DaniPhii I don't think it would be possible (or possible but requires hacking bootloader, which is hard to do)

Implementing on custom fw can allow switching custom -> stock but not the way around, because the stock fw doesn't know how to handle the key combination

osteotek · 2026-01-23T13:17:21Z

@ngxson I've just tested this with and without short power button setting, works nicely.

@daveallie this PR fixes #288

daveallie · 2026-01-27T10:18:59Z

src/main.cpp

@@ -288,6 +296,16 @@ bool isWakeupAfterFlashing() {
  return isUsbConnected() && (wakeupCause == ESP_SLEEP_WAKEUP_UNDEFINED) && (resetReason == ESP_RST_UNKNOWN);
 }


Looks good, this can be removed now as it's no longer used.

osteotek · 2026-01-27T16:47:49Z

now device wakes up from USB connect because it sends exactly same signal as wakeup from power button 😭 Trying to fix that (if CrossPointSettings::SHORT_PWRBTN set to SLEEP)

ngxson · 2026-01-27T17:22:31Z

src/main.cpp

+  if (isWakeupByPowerButton()) {
+    // For normal wakeups, verify power button press duration
+    Serial.printf("[%lu] [   ] Verifying power button press duration\n", millis());
+    verifyPowerButtonDuration();
  }


@osteotek hmm right, I just realized the logic fault here: if the wakeup is not caused by button press, we skip and nothing is checked

here we just need to add the else branch:

} else { // Case: when USB is connected, do not wake up automatically startDeepSleep(); }

I'll push a fix for that

hmm, we also need to wake up after flash completed

## Summary Fix crosspoint-reader#288 Based on my observation, it seems like the problem was that `inputManager.isPressed(InputManager::BTN_POWER)` takes a bit of time after waking up to report the correct value. I haven't tested this behavior with a standalone ESP32C3, but if you know more about this, feel free to comment. However, if we just want short press, I think it's enough to check for wake up source. If we plan to allow multiple buttons to wake up in the future, may consider using ext1 / `esp_sleep_get_ext1_wakeup_status()` to allow identify which pin triggered wake up. Note that I'm not particularly experienced in esp32 developments, just happen to have prior knowledge hacking esphome. ## Additional Context N/A --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? NO --------- Co-authored-by: Dave Allie <[email protected]>

fix: short-press power button to wakeup

1eed75e

olearycrew requested changes Jan 22, 2026

View reviewed changes

apply suggestion

1867b55

fix clang-format

bab513c

ngxson commented Jan 22, 2026

View reviewed changes

ngxson added 2 commits January 22, 2026 16:02

better isWakeupByPowerButton

482a4c3

revert constexpr def

ca1178e

ngxson requested a review from olearycrew January 23, 2026 12:42

osteotek previously approved these changes Jan 23, 2026

View reviewed changes

daveallie reviewed Jan 27, 2026

View reviewed changes

Remove unused function

f6f57a8

daveallie dismissed osteotek’s stale review via f6f57a8 January 27, 2026 11:02

daveallie approved these changes Jan 27, 2026

View reviewed changes

daveallie merged commit 1b9c8ab into crosspoint-reader:master Jan 27, 2026
1 check passed

ngxson commented Jan 27, 2026

View reviewed changes

ngxson mentioned this pull request Jan 27, 2026

fix: do not wake up on usb connected #572

Closed

		@@ -288,6 +296,16 @@ bool isWakeupAfterFlashing() {
		return isUsbConnected() && (wakeupCause == ESP_SLEEP_WAKEUP_UNDEFINED) && (resetReason == ESP_RST_UNKNOWN);
		}

Uh oh!

Conversation

ngxson commented Jan 22, 2026

Summary

Additional Context

AI Usage

Uh oh!

olearycrew commented Jan 22, 2026

Uh oh!

olearycrew left a comment

Choose a reason for hiding this comment

Uh oh!

ngxson commented Jan 22, 2026

Uh oh!

osteotek commented Jan 22, 2026

Uh oh!

ngxson commented Jan 22, 2026

Uh oh!

ngxson Jan 22, 2026

Choose a reason for hiding this comment

Uh oh!

Eloren1 Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

osteotek commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

osteotek commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ngxson commented Jan 22, 2026

Uh oh!

osteotek commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ngxson commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ngxson commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DaniPhii commented Jan 23, 2026

Uh oh!

ngxson commented Jan 23, 2026

Uh oh!

osteotek commented Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

daveallie Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

osteotek commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ngxson Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ngxson Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Eloren1 Jan 22, 2026 •

edited

Loading

osteotek commented Jan 22, 2026 •

edited

Loading

osteotek commented Jan 22, 2026 •

edited

Loading

osteotek commented Jan 22, 2026 •

edited

Loading

ngxson commented Jan 22, 2026 •

edited

Loading

ngxson commented Jan 22, 2026 •

edited

Loading

osteotek commented Jan 23, 2026 •

edited

Loading

osteotek commented Jan 27, 2026 •

edited

Loading

ngxson Jan 27, 2026 •

edited

Loading