As others have reported, the m5stack "AC-Measure-Unit" (HLW8032) stops updating after about 18seconds if no current is flowing through it.

Specifically the LED on the unit goes out, and the Voltage and Current registers stop updating (the UNIT_ACMEASURE_GET_READY_REG returns 0=not-ready).

However you can still use functions such as "Serial.printf("getFirmwareVersion()=%u\n",sensor.getFirmwareVersion());"

But when current starts again (even as little as 5mA) the "AC-Measure-Unit's" LED turns on again it starts reporing the voltage and current again. (AC Voltage changes do not cause it to start reporting again.)

There is a "sensor.jumpBootloader()" function, but this seems to lock up the i2c bus, so you can no longer talk to the module.

I am uncertain whether this "stops updating" issue is caused by the m5stack-firmware in the module, or caused by the HLW8032-chip itself stopping updating.

The only way I have found to resolve this is to disconnect the 5V power to the AC Measure Unit, and then reconnect it. The "JFET-reset" circuit I use is shown below.

Note that the AC-Measure-Unit draws about 30mA at all times, irrespective of if it is reporting data or not.

Note also that the AC-Measure-Unit very ocasionally says its working but always returns 0V and 0W. The unit needs resetting to fix this, which can be achieved by completely removing the 5V power (eg. using the below "JFET-reset" circuit).

Finally note that (strangelly) the Voltage measurement reported by the AC-Measure-Unit appears to be more accurate when current is flowing: It appears to overread the voltage by approx 5% when it is first turned-on/rebooted (which you need to do if you want a voltage reading when no current is flowing).

Hi Felix,

Many thanks for your comments - I appreciate them!

That said, I am curious to know your motivation to put ESP32 into deep sleep while running from USB?
I am asking because the overall power consumption of M5CoreInk with ESP32 in deep or light sleep is about the same.

Because the DeepSleep wakes by re-running the setup() code, whereas the LightSleep wakes by just continuing from the line after the "esp_light_sleep_start()" command.

This means that you can't use the same sleep code when running (ie.charging) on USB as you do when running on Battery.

And specifically the basic example software such as "github.com/m5stack/M5Core-Ink/tree/master/examples/Basics/RTC_Clock" just go to DeepSleep, and when connected to USB power (ie. when on-charge) never wake to update the time or anything again, until they wake again when the USB is disconnected (which sometimes doesnt happen reliably either).

(IE. one would have to write extra different sleep-code which would not have been necessary if the RTC-interrupt-pin was connected to an ESP32-RTC-GPIO.)

However, as I said one can add a:

esp_sleep_enable_timer_wakeup(seconds * 1000000); // or * 1100000

into the https://github.com/m5stack/M5Core-Ink/blob/master/src/M5CoreInk.cpp:

int M5CoreInk::shutdown(int seconds) {

code, which then uses a timer to wake the ESP32 from DeepSleep when on USB, and not the RTC-interrupt-to-GPIO19.

Although this is not ideal as you then can't use any of the BM8563-RTCs Weekly or CountDown-Timer functions to wake the ESP32 from DeepSleep when being charged.

On my version of CoreInk (R211-200908) the RTC is connected to the ESP32-GPIO19, but this is NOT an RTC-GPIO.

My understanding is that this means it can NOT wake the ESP32 from DeepSleep (whenever the CoreInk is powered from the USB).

(This is not an issue when running on battery, as in that case the power is completely disconnected from the ESP32, and then the RTC can restart the ESP32 by reapplying the power - ie not using GPIO19.)

The "int M5CoreInk::shutdown(int seconds)" software in "https://github.com/m5stack/M5Core-Ink/blob/master/src/M5CoreInk.cpp" tries to use:

gpio_wakeup_enable(GPIO_NUM_19, gpio_int_type_t::GPIO_INTR_LOW_LEVEL);
esp_sleep_enable_gpio_wakeup();
...
esp_deep_sleep_start();

to do this, but it appears that this will only wake the ESP32 from "esp_light_sleep_start()" NOT from "esp_deep_sleep_start()".

The only way round this I can find is adding:
esp_sleep_enable_timer_wakeup(seconds * 1000000); // or * 1100000
(after the "esp_sleep_enable_gpio_wakeup();")
(which uses a timer to wake the ESP32, and not the RTC-GPIO19).

However this is far from ideal as you can't use the RTC to wake the ESP32 from DeepSleep for any one-off or weekly RTC timers if powered from the USB.

(It would therefore seem to me to be a design-error to use GPIO19 as the RTC-wake-interrupt-pin and not an RTC-GPIO?)

If I am mistaken then I would like to know how to use RTC/GPIO19 to wake the ESP32 from DeepSleep?

(Note this is a different issue to https://community.m5stack.com/topic/4332/coreink-wakeup-from-usb-power.)

Any comments would be appreciated.

@HappyUser

TimePageSprite.drawString(20, 20, "Hello", (const lgfx::FixedBMPfont*) &fonts::FreeMonoBold12pt7b);