CoreInk wakeup from USB power

IndianaTux

@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

Hello @IndianaTux

ok, so if setting POWER_HOLD_PIN to LOW doesn't shutdown the device then something else is probably keeping it alive. According to the schematic USB, the power button, the hold pin and the RTC can wake up / keep alive the device.

Maybe the power button is stuck? (but on 20 devices?)
Maybe some component got soldered on incorrectly?
Maybe the RTC is in alarm state, creating an interrupt and holding INT LOW?

The last one you could test. According to the schematic the INT output of the RTC is also connected to GPIO19. So if GPIO19 reads LOW it would mean that INT is LOW and that would prevent the M5CoreInk from shutting down.

Thanks
Felix

IndianaTux

@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

Hello @IndianaTux

thank you for reporting back. I guess that means it is not USB, not the HOLD_PIN, not the RTC and most likely not the power button which keeps your M5CoreInks alive.

At this point I must assume some missing component, like a missing pullup resistor R32 or a missing pulldown resistor R33, or some short circuit keeping the devices alive.

I am curious to hear what M5Stack support eventually comes back with.

Thanks
Felix

IndianaTux

@felmue Yeah they are supposed to come back to me on Monday.

IndianaTux

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

Hello @IndianaTux

that is interesting. I am curious about whether this actually works.

BTW: looks like the proposed fix has been included in the latest M5CoreInk library.

Thanks
Felix

IndianaTux

@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...

IndianaTux

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

Hello @IndianaTux

does that work with real loads (and not just the multimeter) attached to the output? I am asking because it looks like the MOSFET keeps conducting after M5.shudown() is called and only putting ESP32 into deep sleep (and by doing so reducing the current) makes the MOSFET to finally open. If my thinking is correct a real load on the output would keep the current high and thus the MOSFET closed. (I hope I am wrong.)

Thanks
Felix