Ok further testing and it seems like if I do:
M5.shutdown();
esp_deep_sleep_start();
I'm getting what I expect as a behavior for a shutdown. When running on battery doing these 3 commands makes ESP-32 shut down and the output 5v and 3.3v drop to 0v. And connecting power to the USB-C connector makes the ESP-32 boot back.
@felmue I finally got around to testing this on a 94 and 4C MAC address CoreInk and there is still a big difference.
I used the same code I used before to test but upgraded the library to v0.0.6 which has the GPIO 1 fix.
With a 94 part when you do the M5.shutdown() the 5v and 3.3v output on the header goes down to 0V showing that the device really powered off and any external circuit that uses this will also power off and not drain the battery.
However, on a 4C part with the same exact code, the 5V and 3.3v output remain active. So any electronics that use these will still be powered and will drain the battery...
Sent this to support and I hope they will have a fix...
Ok sorry for not posting this sooner. This is the answer from support:
We have replaced the USB-Serial chip, from CP2104 to CH9102. These two are pin-to-pin compatible, seems no issue feedback before. You can add before code before shut down the device. It should work.
pinMode(1, OUTPUT)
digitalWrite(1, 0)
// then pull down gpio12 to power off
I have not tried it yet but wanted to post it here before I myself loose the e-mail...
@felmue Yeah they are supposed to come back to me on Monday.
@felmue So I modified my above script to show the GPIO19 state on the screen:
void displayString(char *data) {
M5.M5Ink.clear();
delay(1000);
if( InkPageSprite.creatSprite(0,0,200,200,true) != 0 ){
Serial.printf("Ink Sprite creat faild");
}
InkPageSprite.drawString(35,50,data);
if(digitalRead(GPIO_NUM_19)) {
InkPageSprite.drawString(35,70,"GPIO_19 = HIGH");
} else {
InkPageSprite.drawString(35,70,"GPIO_19 = LOW");
}
InkPageSprite.pushSprite();
}
And it always show HIGH...
@felmue SO I modified a bit my test script so it's easier to read and replaced M5.shutdown() by digitalWrite(POWER_HOLD_PIN, LOW);:
#include <M5CoreInk.h>
Ink_Sprite InkPageSprite(&M5.M5Ink);
void displayString(char *);
// Initial setup
void setup()
{
Serial.begin(115200);
// Initialize the M5Stack object
M5.begin();
if( !M5.M5Ink.isInit())
{
Serial.println("Init failed");
while (1);
}
// Clear screen and display hello world
displayString("Hello World !");
}
void loop() {
M5.update();
if(M5.BtnUP.wasPressed() || !digitalRead(GPIO_NUM_37)) {
Serial.println("Up pressed");
// Clear the screen and display "Sleep"
displayString("Sleep");
// Shutdown
// M5.shutdown();
digitalWrite(POWER_HOLD_PIN, LOW);
// Clear the screen and display "Alive"
displayString("Alive");
}
Serial.flush();
}
void displayString(char *data) {
M5.M5Ink.clear();
delay(1000);
if( InkPageSprite.creatSprite(0,0,200,200,true) != 0 ){
Serial.printf("Ink Sprite creat faild");
}
InkPageSprite.drawString(35,50,data);
InkPageSprite.pushSprite();
}
With digitalWrite(POWER_HOLD_PIN, LOW); the device does not even shutdown... It just goes on and displays "Alive" on the devices with MAC address 4C.
FYI last night I tested 24 CoreInk modules. 4 have the MAC address starting with 94 and work great, and the other 20 which all have MAC address starting with 4C all fail.
I did e-mail support but no response yet.
@felmue Did not think of trying that. Will try to do that tonight.
As I needed to ship I replaces the M5.shutdown() with the following:
void shutdown(void) {
while(1) {
esp_sleep_enable_timer_wakeup(100*1000000);
gpio_wakeup_enable(GPIO_NUM_37, GPIO_INTR_LOW_LEVEL);
gpio_wakeup_enable(GPIO_NUM_38, GPIO_INTR_LOW_LEVEL);
gpio_wakeup_enable(GPIO_NUM_39, GPIO_INTR_LOW_LEVEL);
esp_sleep_enable_gpio_wakeup();
esp_light_sleep_start();
if( esp_sleep_get_wakeup_cause() != ESP_SLEEP_WAKEUP_TIMER) {
ESP.restart();
}
}
}
In my use case I display a message telling the user to toggle the black switch to power it back up. If it runs out of battery while in that loop, plunging in the USB-C power will make it reboot.
I'll let you know tonight about your suggestion.
What s really strange is that it's 100% constant. MAC address 4C* all exhibit the issue while all 94* ones work great.
So I made this really dumb firmware that just goes to shutdown when the switch is toggled up.
Ink_Sprite InkPageSprite(&M5.M5Ink);
// Initial setup
void setup()
{
Serial.begin(115200);
// Initialize the M5Stack object
M5.begin();
if( !M5.M5Ink.isInit())
{
Serial.println("Init failed");
while (1);
}
// Clear screen and display hello world
M5.M5Ink.clear();
delay(1000);
if( InkPageSprite.creatSprite(0,0,200,200,true) != 0 ){
Serial.printf("Ink Sprite creat faild");
}
InkPageSprite.drawString(35,50,"Hello World!");
InkPageSprite.pushSprite();
}
void loop() {
M5.update();
if(M5.BtnUP.wasPressed() || !digitalRead(GPIO_NUM_37)) {
// Clear the screen and display "Sleep"
M5.M5Ink.clear();
delay(1000);
if( InkPageSprite.creatSprite(0,0,200,200,true) != 0 ){
Serial.printf("Ink Sprite creat faild");
}
InkPageSprite.drawString(35,50,"Sleep");
InkPageSprite.pushSprite();
// Shutdown
M5.shutdown();
}
}
Effects on a "working" module and a "non-working" don't can be seen here in this video: https://youtu.be/PA7EKmGJql4
Hi,
I just received a new batch of CoreInk with MAC addresses starting with 4C and on this batch, if the device is put in deepsleep (with the Arduino shtodown function from the M5Stack library) the device will not wake up when the power (via the USB-C connector) is applied.
Most of my previous batches had MAC addresses starting with 94 that would properly wake up when the power (via the USB-C connector) is applied.
I tested the exact same code on both batch.
For example, this one failed to power back up when the power is connected after an M5.shutdown:
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 4c:75:25:97:98:7c
And this one worked:
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 94:b9:7e:92:b3:8c
Any idea or software workaround ?
Thanks.
@felmue Thanks for the pointer !
If there a method to know that the RTC (on an M5 Core2 or M4 CoreInk) was initialized and does not need to be updated in a scenario where Internet (NTP) access is not available ?
Thanks.