Skip to content

Coreink power hold - #106

Closed
fredvangoolen wants to merge 2 commits into
m5stack:masterfrom
fredvangoolen:coreink-power-hold
Closed

Coreink power hold#106
fredvangoolen wants to merge 2 commits into
m5stack:masterfrom
fredvangoolen:coreink-power-hold

Conversation

@fredvangoolen

Copy link
Copy Markdown

No description provided.

CoreInk latches its own power rail on with GPIO12. Out of reset that pad is
an input, and nothing in this firmware drives it until M5GFX's board
autodetect does so as a side effect of M5.begin() - measured ~2000ms after
reset. On battery the rail is held up by nothing at all during that window,
so the board switches itself off after any reset, and powering it on means
holding the power button down for two seconds or more instead of pressing it.

Drive the pin from a MICROPY_BOARD_STARTUP hook, which app_main runs before
creating the MicroPython task. Measured on hardware, reset to latch asserted:

  stock                            ~2000ms
  M5Stack factory Arduino build     ~400ms
  this hook                         ~980ms

M5Unified already asserts a hold pin this way for the Timer Cam in
Power_Class::begin(); the CoreInk branch of that switch sets ADC and wake
pins but never touches power_hold.

980ms is not yet short enough on battery - see the following commit.
With the startup hook in place the power-hold latch is still not asserted
until ~980ms after reset, because the bootloader SHA-256s the whole ~3.4MB
app image before app_main is reached. That is spent entirely before any
application code runs, and on battery it is long enough for the rail to
collapse.

Deep-sleep wakes already skip validation (BOOTLOADER_SKIP_VALIDATE_IN_DEEP_
SLEEP=y), so the normal wake path never paid this cost - only resets did.
Skipping it on power-on as well brings the latch to 50ms after reset.

Verified on hardware, running on battery: a machine.reset() loop counting in
RTC memory reboots indefinitely, where on stock firmware the board switches
off at the first reset and stays off until USB is connected.

This board has a single factory partition and no OTA slot, so a failed
validation was never recoverable anyway.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant