Paper S3 questions

felmue

well, looking at the schematics there shouldn't be a difference about whether M5PaperS3 is running from USB or battery.

That said, is the battery of your M5PaperS3 charged? My M5PaperS3 battery was fully depleted when I got it and it took several hours for it to be fully charged.

Thanks
Felix

wsanders

I am using M5.Power.timerSleep(int) in a sketch and it sort of works. The sketch displays the date and is supposed to wake up and refresh the date a few sec after midnight.

Sketch here: https://github.com/wsanders/M5PaperS3-Stuff/blob/main/papers3badge.ino

I used the int form of timerSleep since for now it was easier than reverse engineering the rtc_time struct. Utimately, the alarm should be set in the chip with a ?mumble?-bit int with value in ?mumble?-seconds. (*)

There are some problems:

The device seems to randomly wake up at times.
Occasionally the Status LED is illuminated continuous orange when the device is supposed to be asleep.

At first I thought I was passing timeSleep a 16-bit Arduino int which was limited to 2^16 sec (not a whole day) but the int in the sketch compiles into a ESP32 int which is 4 bytes.

The source for the _timerSleep private class starts at line 724 in Power_class.cpp FWIW. I haven't dug all the ay down to where it calls the chip, but the BM8563 chip is the RTC in almost all the M5 products and should be OK. (*)

PMS150G data sheet here: https://www.padauk.com.tw/upload/doc/PMS15B,PMS150G datasheet_EN_V008_20230216.pdf

(*) I coded up a wristwatch based on the StickCPlus and after nearly a year the RTC is only off by a few sec. )

felmue

Hello @wsanders

there are two issues I can see with M5.Power.timerSleep(time):

calls M5.Rtc.setAlarmIRQ(time) which can only handle up to 255 minutes. See comment here.
calls _timerSleep() which calls _powerOff(true) which never really powers M5PaperS3 off as this functionality has not yet been implemented and therefore uses ESP32 deep- or lightsleep as fallback. See here.

The first point is probably responsible for the premature wake-ups you are seeing.
The second point is probably the reason for the status LED not always turning off.

Edit: I've created a PR to fix the power off functionality.

Thanks
Felix

wsanders

@felmue Thanks again ....

Sure enough, the device rebooted 4.25 hours after the last reboot this morning. This isn't too bad a limitation for my badge test skeptch, the sketch will set the date anyway, and if it's less than 4.25 hr before midnight it will still reset at midnight.

Digging deeper into setAlarmIRQ, the 255 min limit is not in the rtc_time_t instance; the rtc_time_t instance should be able to handle an alarm up to a week away.

So far, the LED has not illuminated after M5.Power.timerSleep does whatever it does.

You have to be care to actually send M5.Power.deepSleep the right uint64_t, something like:

M5.Power.deepSleep(1000000L * uint64_t(w), false);

ESP deep sleep should be almost as good as a power off, assuming setAlarmIRQ works.

felmue

Hello @wsanders

you are correct, rtc_time_t is not the limiting factor, it's the 8 bit register in the RTC holding the time for the timer functionality.

Well, it depends on what you consider "almost as good". With M5PaperS3 fully powered off (with my PR) at the battery I measure about 9.6 uA (which is close to the advertised 9.28 uA) whereas in ESP32 deep sleep I get about 5.1 mA (which is about 550 times higher).

Thanks
Felix

aleekwen

@felmue thanks I will try this later I was using the ESP32 deep sleep methods directly vs the M5 ones.

wsanders

@felmue Are you sleeping the IMU with M5.Imu.sleep when you deep sleep the ESP? I think by default the IMU stays awake.

felmue

Hello @wsanders

above measurements are with IMU off. You can find all numbers here.

Thanks
Felix

wsanders

@felmue Your measurement for ESP deep sleep + Imu.sleep is accurate. My device is drawing the battery down about 5-7% per day, which is roughly 5ma.

I tested your patch. Unfortunately it doesn't seem to work once the RTC countdown timer is set. If one uses Power.shutdown, the Rtc timer is bypassed in the code in favor of the ESP timer since M5UNIFIED_PC_BUILD is not defined (why?).

Rtc.setAlarmIRQ does work in its integer form, if followed by Power.powerOff. I could not get Rtc.setAlarmIRQ to work in its date,time form.

Your patch does turn off the PaperS3 otherwise, but with the ESP completely powered down its timers aren't functional.

So I think we're stuck with ESP deep sleep for now. It would be interesting to see the code for the PMS150G. I'm not sure what all that FET logic around it is for, maybe an AXP192 wouldn't fit on the board. (And why a USB chip that would prevent the device from frying when plugged into a USB PM port wasn't included.)

I tested skipping M5.begin but the PaperS3 would do nothing. Tested with Display.init and it worked, but battery readings were undfined. Tested that with M5.Power.begin and battery readings were still undefined, probably because board_t isn't set.

Something besides the IMU is sucking that power though, the BMI270 should use less than 1ma even when fully awake. The PMS150G uses only a few uA when running, I don't think it ever turns off.

fonix232

@wsanders said in Paper S3 questions:

So I think we're stuck with ESP deep sleep for now. It would be interesting to see the code for the PMS150G. I'm not sure what all that FET logic around it is for, maybe an AXP192 wouldn't fit on the board. (And why a USB chip that would prevent the device from frying when plugged into a USB PM port wasn't included.)

Yeah, just like the OG M5Paper, the PaperS3 has a bunch of shortcomings that stem from, well, I don't want to say bad design... Just not properly thought through.

The PMS150G for example is OTP, so one can't change its behaviour. Using a slightly smarter, programmable MCU would've allowed for things like forwarding of interrupt signals based on logic, and deeper management of power states or their handling.

I would've also included the following changes:

Full quad SD data pins (there's enough free pins on the S3 according to the schematics)
separate MCU (like an RP2040 or similar low power MCU) for EPD handling, similar to how the M5Paper used the IT8951 (which itself was a mistake, as that MCU is super power hungry, and there was no way to reprogram it either), with open firmware, to offload display update tasks
USB hub controller so both the S3 and this EPDC MCU could be natively connected to a host for flashing/debugging
Better charge controller (the one used won't let the battery charge faster than 250mAh@5V, which is why you need to keep it on charger for hours).
Utilising the GT911 capacitive touch "buttons" similar to the ESP32-S3-BOX, with three or four zones available on the display bottom (fat) chin