It's more than just an idea, it's a good idea. They already have it in the M5 Unified library, they just need to backport it to Core2. I filed a pull request. I hope they accept it:
https://github.com/m5stack/M5Core2/pull/138
I thought that you could use the RTC::ReadReg method directly to read the bit, something like return Rtc.ReadReg(0x02) & 0x80;, but unfortunately the method is private.
Hope this helps
--Louis

I am using the CORE2 with an external battery. The rear cover and battery are removed and the M-BUS connector is plugged into a header on the system main board. I have a SPST On/Off switch between the battery and the BATT pin (M-BUS pin 30).
With the original CORE2, using the AXP192, the module would power up on battery connection when the switch was closed. Now, with the AXP2101, it's a two-step operation: close switch, then hold the power button on the side of the module to power up.
What I'm trying to do is restore the original behaviour: switch only.
Reading the AXP2101 datasheet:
6.5.2
Power up from BAT
If only battery is present and VBAT is higher than depletion threshold (VBAT_DPLZ), BATFET, connecting battery to system, is off by default and need to be turned on by pressing the PWRON key or inserting an adapter.
It seems pretty hopeless. Is there something else in the CORE2 v1.1 that I'm missing that could be used as a work-around?
Thanks

It's more than just an idea, it's a good idea. They already have it in the M5 Unified library, they just need to backport it to Core2. I filed a pull request. I hope they accept it:
https://github.com/m5stack/M5Core2/pull/138
I thought that you could use the RTC::ReadReg method directly to read the bit, something like return Rtc.ReadReg(0x02) & 0x80;, but unfortunately the method is private.
Hope this helps
--Louis

@felmue That was helpful, thanks!
I added this to my platformio.ini:

build_type = debug
monitor_filters =
  default  ; Remove typical terminal control codes from input
  esp32_exception_decoder  ; Decode the backtrace

Hello,
I've been working on porting a data collection / IoT application from ESP32 to M5Stack Core2 using C++, PlatformIO and Arduino framework. The high level stuff is the same but I am slowly replacing some of the low level hardware dependent code.
I have a mystery abort() and reboot and I can't find where it's happening. At the moment I have been writing in lots of println and printf, but that can only go so far. I read on the PlatformIO site that PlatformIO debug environment won't work on Core2 because one of the JTAG pins is used for the LCD. There is a hack, but I would prefer something simpler as a first approach.
Any suggestions where I can find out what source lines correspond to the PC address and backtrace?
Thanks in advance.

millis=631 In Context::set_state, State* is 3ffbb8d4 and calling entry_action().
millis=638, In InitReadingState::entry_action(), entered state InitReadingState 3ffbb8d4.   
millis=646 In Context::set_state, State* is 3ffbb8d4 and returning from entry_action().     

abort() was called at PC 0x401f81cf on core 1


Backtrace: 0x4008390d:0x3ffd0f60 0x40095ee1:0x3ffd0f80 0x4009b979:0x3ffd0fa0 0x401f81cf:0x3ffd1020 0x401f8216:0x3ffd1040 0x401f8177:0x3ffd1060 0x401f954b:0x3ffd1080 0x400d62ea:0x3ffd10a0 0x400d6310:0x3ffd10c0 0x40214cbe:0x3ffd10e0 0x400d38fd:0x3ffd1100 0x400d64b7:0x3ffd1130 0fd1020 0x401f8216:0x3ffd1040 0x401f8177:0x3ffd1060 0x401f954b:0x3ffdx400d703a:0x3ffd1150 0x400ed671:0x3ffd1170                                                   0x400d64b7:0x3ffd1130 0x400d703a:0x3ffd1150 0x400ed671:0x3ffd1170