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

Full shutdown while backlight is off and waiting for button press #99

Open
felmue opened this issue Aug 17, 2020 · 9 comments
Open

Full shutdown while backlight is off and waiting for button press #99

felmue opened this issue Aug 17, 2020 · 9 comments
Labels
enhancement New feature or request

Comments

@felmue
Copy link
Contributor

felmue commented Aug 17, 2020

Good day

first of all let me say thank you very much for such a great framework and for sharing it with the world. Thank you!

I am running the M5Stack from a 750mAh battery and the inactivity timeout is set to 30 seconds. I found that when the inactivity timeout kicks in I can reactivate the system if I press button A, B or C within a couple of seconds (<30s).

However if I wait longer than about 1 minute I can no longer reactivate the system by pressing button A, B or C. Only the power button allows me to restart the system.

The reason for that I believe is due to the power IC (IP5306) which turns off its boost (5V) output under light load and so everything including the ESP32 is fully shutdown.

The power IC has a setting which allows for the boost output to be on all the time. I've given that a try and it works as expected and the system can be reactivated by pressing button A, B or C even after a prolonged period of being inactive.

However as one could expect this keeps everything (ESP32, WiFi etc.) turned on and the battery is depleted in about 10 hours.

Have you had a similar experience or am I doing something wrong?

Have you explored putting the ESP32 into light sleep instead of waiting in a while loop for a button press when inactive?

Thank you very much in advance.

Best
Felix

@ropg
Copy link
Collaborator

ropg commented Aug 17, 2020

Thank you for researching that. From memory I think there's a difference between the older M5stack units and the M5stack Fire. Hmmm. maybe we should have two timeouts: one for screen off and one for everything off...

We'll look into this further...

@vkichline vkichline added the enhancement New feature or request label Aug 17, 2020
@felmue
Copy link
Contributor Author

felmue commented Aug 18, 2020

Hi Rop

yes, that is what I found too - older M5Stack models use the stock power IC (IP5306) which uses a fixed set of parameters whereas newer models use a customized power IC (IP5306_I2C) which can be controlled via I2C.

I am using a newer model M5Stack Gray. I do not (yet) possess a M5Stack Fire so I cannot tell whether there are further differences regarding power IC.

BTW: I haven't been able to find specific schematics for different M5Stack models. There only seems to exist a generic schematic which covers the M5Stack Basic Core model. But no schematic I found so far shows MPU6886, BMM150 or PSRAM (Fire). So for instance on my M5Stack Gray the MPU and BMM ICs are mounted on a small daughter board which is then soldered on the bottom of the Groove connector (plus an additional connection to supply 3.3V).

Thanks
Felix

@ropg
Copy link
Collaborator

ropg commented Aug 18, 2020

Please ask the M5stack people, because I have sent enough queries asking for more info. They are (understandably, I guess) much more interested in their new products than in providing all relevant information about their old products.

@felmue
Copy link
Contributor Author

felmue commented Aug 18, 2020

Hi Rop

sorry, I didn't mean to bother you about schematics - I simply wanted to describe the current state as I see it. And yes, I already opened the question to the M5stack people in their forum. No response yet.

Anyhow, I've create a pull request with my modification to use light sleep instead of the while loop while waiting for a button press during inactivity. Please feel free to use it as you see fit.

#101

Cheers
Felix

@paultech
Copy link
Collaborator

merged. We plan to address platform support shortly where we can handle the nuisances of M5Stacks ever-changing power IC's

@paultech
Copy link
Collaborator

Reopened - Made a mistake earlier, PR is still pending review as we needed to test the change on a few HW revisions.

@paultech paultech reopened this Aug 30, 2020
@vkichline
Copy link
Collaborator

felmue - I tested and found auto-connect does not re-engage on wake up. (An issue, because auto-connect is a primary feature, and works fine w/o the change.) Also, I could not reproduce the original genesis of the issue - "if I wait longer than about 1 minute I can no longer reactivate the system by pressing button A, B or C." My M5Stack Gray reactivated instantly after 15 minutes with a button press without the change.
I love the idea of using the ULP instead of a spin-loop. It's what the ESP32 is designed to do. But I'm not sure we have enough hardware info to implement this reliably. I'm working on an extension feature, maybe that's where this fits in: you could activate it if you wanted to use it on a specific device known to be compatible...

@felmue
Copy link
Contributor Author

felmue commented Aug 31, 2020

Hello @vkichline

thank you for taking the time to test my code - much appreciated.

Hmm, my M5Stack Gray (or Fire) auto-reconnects in about 5 seconds after coming out of light sleep (I've double checked with M5EZ_WIFI_DEBUG enabled and the state machine correctly re-engaged, scanned and reconnected.) But yes, I agree that probably needs to be tested some more. Is there something that could be done to force a reconnection coming out of light sleep?

I think I found the reason why in your case, with the original code (spin-loop) the system can be awoken even after 1 minute but with my hardware it doesn't work.
Right at the beginning, when I got my M5Stack Gray and before I discovered M5ez, I started to investigate about which part of the system unnecessarily consumes energy while in light or deep sleep and one of the culprits I found is the speaker amp so I disabled it.
With the speaker amp disabled and the display off the system power consumption is small enough for the PMU to decide to shut down. Reenabling the speaker amp on my hardware increases the power consumption enough that the PMU keeps the boost output enabled. So you are correct, with original hardware the original code (spin-loop) works as intended.

Sorry about that. I should have mentioned that in my original post but it slipped my mind.

Yes, I could see the light sleep solution as an option being activated though your upcoming extension feature. Looking forward to seeing that in action.

Thanks
Felix

@antimix
Copy link

antimix commented Feb 27, 2021

Hello, I am currently using the M5Stack always connected to the power, so it never turn off. Only the LCD goes off in back light mode. However I have discovered that when it loops in the backlite events, no other scheduled events are executed. So I fixed this in my forked version.
I agree with you to have a LCD timeout that is different from a POWER timeout. The LCD should affect the LCD only and re-enable the LCD at touch of a key, while on the contrary POWER timeout are important if you are working in battery mode. This means be able of:

  • Turn on / wakeup for a key press (ON or ABC)
  • Turn on / wakeup for hardware Timer events (e.g. functions that execute once on hour or a day or week...)
  • Turn on / wakeup for incoming signal triggers (e.g. a PIN data line become high or low)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants