Update: some further notes and a workaround solution.

I decided to dig a bit deeper into how the BM8563 RTC works and how it is initialized by the M5Stack Arduino C++ library. Without going into all the details I have so far found out the following:

Taking out the battery and leaving the CoreINK powerless does not in it self lead to the problem, as I have stated earlier in this thread. I seems the reason is some registers of the RTC sometimes become corrupted. Exactly how this happens, I'm not sure of, but one way may be when power (aka. the battery) is removed while data are written via I2C to the RTC. Important is however the matter of the fact: it can happen!

Apparently the the UIFlow firmware does not reset these registers correctly at start up. Digging into the Arduino library (which I knew could fix problem) I found the RTC init routine which resets the three control registers* of the BM8563. I then thought I could do the same with the I2C library in UIFlow. And sure enough, it works. So the workaround is to run the following code:

import i2c_bus

i2c0 = i2c_bus.easyI2C(i2c_bus.M_BUS, 0x51, freq=400000)
i2c0.write_u8(0x00, 0x00)
i2c0.write_u8(0x01, 0x00)
i2c0.write_u8(0x0D, 0x00)

some where in your script before the

m5stack.power.restart_after_seconds(n)

is called.

I haven't tested but I suppose it is the same if you use:

m5stack.power.restart_on(minutes=n, hours=n, date=n, weekday=n)

Notes to above code:
Please use the UIFlow I2C library (import i2c_bus) as the native Micropython I2C library (machine.I2C) messes up the "internal" I2C communication of the UIFlow firmware.
i2c_bus.M_BUS = (21,22) aka I2C pins for the BM8563 on the CoreINK
0x51 is the I2C address of the BM8563
0x00,0x01 and 0x0D are the control registers which are set to 0x00
The Arduino library for RTC init for comparison :

void RTC::begin(void) {
    Wire1.begin(21, 22);
    WriteReg(0x00, 0x00);
    WriteReg(0x01, 0x00);
    WriteReg(0x0D, 0x00);
}

*) please refer to the BM8563 datasheet for further details.

The "deepsleep" function of the M5StickC PLUS2 is taken care of by an external hardware-RTC (RTCBM8563). Have a look at the electric diagram on the doc page. I don't think you can use the "generic" Micropython machine.deepsleep()

You should use the Power.timerSleep(sec) which is a part of the "built-in" M5 library.

A tip if you are programming directly in Micropython and uploading via the serial port. You can use the UIFlowl web site as a kind of "API-reference". Go in and find the UIFlow "brick/function" you'll like to use and then see what Micropython code it generates.Here is an example:

Sorry!
For some reason I completely overlooked that you wanted to connect two devices together.

So the answer is yes! Get a Grove cable:
https://shop.m5stack.com/products/4pin-buckled-grove-cable?variant=16804807082074

Remove/cut the the red (+5v) wire and setup the UARTs on both devices with "crossover" pin-config.
I.e.:

• Device A UARTx Tx=32 Rx=26
• Device B UARTx Tx=26 Rx=32

or vice versa.

I'm not sure what you mean by "using interrupt", but you could (with same cable) define say pin 32 as output on device A and the same pin as an input defined to an interrupt on Device B and then perhaps the opposite with Pin 26

@nzmikec said in EXT unit to measure engine RPM:

..... i2c device to count these pulses and send my device an RPM value.

What is the device you're going to use to receive the values on I2C?

Maximum RPM (and pulses per minute) would be 11,000RPM.

Maybe you don't need an external device for counting. 11,000 RPM with 1 pulse pr revolution is about 190 Hz which an ESP32 should be able to count directly by it self via one of its GPIO's.

And maybe also upgrade to version 2.0.4:

If you look at the electric diagram I referenced you'll see that there is a power circuit that relies on a software implemented power-on hold function.
The ESP32 must pull up GPIO4 ("HOLD") to keep the system power on which include the power for the ESP32 itself.
When you call the standard machine.deepsleep() which is designed to use the ESP32 internal deep-sleep which relies on power to the ESP32, then the GPIO4 will turn low and cause the external power circuit to cut power to the entire system - expect for the BM8563 RTC. Now the ESP32 has no power and will never wake up again.
The only way to power on again is to press the power button (designated S3 on the diagram) or if the BM8563 RTC pulls down the INT signal at some point. The BM8563 must be set up on beforehand with a timeout or date to pull the the INT signal.
"Under the hood" in UIFlow firmware the GPIO4 will be pulled high just after boot i.e. when the power is turned on either by the power button or the INT signal from the BM8563 RTC. That is also why you have to keep the power button pressed a few seconds for the system to start - the ESP32 has to reach the point where it holds power on by itself - i.e. pulling GPIO4 high.

I had a look at the UIFlow 1.x for M5stickC Plus 2 and there are some functions under RTC where you can set timeout and interrupt. I think you might bee able to do the following:

• Enable timer interrupt (from RTC section)
• set timer value (from RTC section)
• power off (from Power section)

@NVERD

I have burned my camera with the latest firmware (1.1.0) and the the long press on the side to get access to the config does not work by me either. But if I burn it with version 1.0.0 the long press works:

However, if you can see an IP on the serial interface you have probably connected the camera to a network with a DHCP and you should be able to stream if your PC is connected to the same network.

But note that the urls are:
http://<CAM_IP>/stream for v 1.0.0.
and
http://<CAM_IP>/ for v 1.1.0.

@nzmikec said in EXT unit to measure engine RPM:

..... i2c device to count these pulses and send my device an RPM value.

What is the device you're going to use to receive the values on I2C?

Maximum RPM (and pulses per minute) would be 11,000RPM.

Maybe you don't need an external device for counting. 11,000 RPM with 1 pulse pr revolution is about 190 Hz which an ESP32 should be able to count directly by it self via one of its GPIO's.

The RTC (BM8563) is a separate chip on the M5Dial board (it is also used on some other M5Stack products).
It is literally hardwired to the battery which means you can keep track of the clock even while the M5Dial board is shut down - that is as long as you always keep an un-depleted battery connected to the board. The BM8563 chip consumes less than 3 µA@"stdLiIonVoltage"

@felmue said in M5Dial, no wake up with button:

please find my measurements here.

What voltage did you use?

M5Dial.h includes M5Unified.h. See here.

Ah OK! I see you are using a "dedicated" library for M5Dial which in term relies on the "general" M5Unified library. I found a similar "dedicated" for the CoreINK but that seem not to use M5Unified.
So I stick with using M5Unified "directly"..

@felmue said in M5Dial, no wake up with button:

please find my example here.

I can see you import M5Dial.h is this supposed to be a part of M5Unified?
I use M5Unified.h in my code for my Core INKs..

@felmue said in M5Dial, no wake up with button:

BTW: as an experiment to prove the above I removed the 5 V connection between M5Stamp and M5Dial board and now I can power M5Dial from the green connector and it does a proper shutdown (same as when powered from battery) and can be woken by the wake button.

Excellent! Now I'm curious : what is the current consumption on the external power input when the board is powered off or "sleeping"

@felmue said in M5Dial, no wake up with button:

everybody can call any of the sleep / shutdown modes as they like. I try to be consistent in writing deep or light sleep when I mean the sleep modes of the ESP32 and shutdown mode when I mean it is done via MOSFET.

Agree and I know you are. Unfortunately M5Stack are not very consistent! They call it "sleep" when the board is shut down. Their timerSleep() function is supposed to shut down their boards with BM8563 RTC.

I also agree the M5Dial should be able to "shutdownsleep" (new term 😜) when powered from the green power terminals (P5 ?).
However, where does this one lead?

@happyuser said in M5Dial, no wake up with button:

external power.

External power as-in via the green power terminals?

@felmue said in M5Dial, no wake up with button:

On the other hand when M5Dial is in shutdown mode the MOSFET is off (the only thing still running is the RTC IC). So then either the wake button or the RTC can power the M5Dial back on.

Agree!
This is completely similar to the CoreINK, but as I mentioned in this post: when the board is shut down but the BM8563 RTC is setup to wake it up then this is in "my book" also a kind of sleep mode.

The M5stack way of "sleeping" is not possible if you power via the USB..
Unless there is a bug in M5Unified library for the M5Dial I'm pretty sure M5.begin will take care of keeping G46 high.