@sambartle the battery voltage increase is actually because of the charging - the PMIC reports the charging voltage, and without the load of running the M5Paper from battery. Just by using the battery instead of an external power source, voltage can drop by 0.1-0.3V as well. The PMIC in this device is incredibly dumb, and some of the features (e.g. the charging/charged indicators) aren't even hooked up.

@bricox nice work on mapping out the power management system! I've noticed some peculiarities with the charging PMIC (SLM6635, which does not seem to have any english documentation). Specifically, it does not seem to have a proper measuring system set up while charging. Once you connect it to USB power, the indicated battery voltage is actually the charging voltage of the battery, which can be 20-30% higher than the actual (resting) voltage of the battery. This is quite visible if you let the M5Paper with the FactoryTest firmware run out of battery, then connect it to power and head to the factory test screen - the battery indicator will be between 30-50%, and reported battery voltage will be around 3.7-3.8V (which is impossible on a device that was just completely discharged).

The main problem with this is that the battery cutoff voltage for charging seems to be 4.2V - even though the battery is rated 4.35V officially. You can see this, again, on the Factory firmware, by leaving the unit to charge. Once it hits 4.2V stable, charging is cut to that voltage (and the M5Paper displays ~85% battery left). If you disconnect the charger and reconnect it, charging voltage jumps up to 4.35V, however after some time it stops charging (or switches to trickle charging? Not sure about the inner workings of SLM6635), battery voltage slowly drops to 4.2V, and keeps idling there, requiring another disconnect-reconnect to fully charge it again.

I was wondering, since there seems to be some rudimentary control over power management, would it be possible to reset the charging circuit, or somehow fake the disconnect-connect cycle on it? Even if it's a software workaround, it would be nice to be able to properly charge to maximum capacity - and also it would allow to collect appropriate readings while charging.

What I hope for is that the next M5Paper generation gets a better power management solution, even if it's more expensive. Proper PMIC control - especially in low-power applications where one would use an eink screen with an ESP32 for periodic updates - is incredibly important, and right now, by the looks of it, all we have is analog voltage readouts of VBAT, not even the charging/charging complete signals are hooked up (which are arguably important here as well).

Another thing I thought about regarding power saving - would cutting the power to the EXT ports and the EPD display (via methods disableEPDPower() and disableEXTPower()) result in any savings?

The cause of this excess consumption is IT8951.
An alternative to this component is the 74HC4094D, 8-stage shift-and-store bus register, used as IO extander.
A competitor with the same display consumes 65 mA, i measured to.

Uhm... Pardon my ignorance but according to my research the IT8591 is a full-blown EPD timing controller, not just a bus register. I don't see how the 74HC4094D would be an alternative (most definitely not a drop-in replacement).

@veryalien @kevindtimm I'm fairly certain the issues you were facing with SD cards are simply caused by the higher capacity.

Officially, the ESP32 supports SD/SDHC/SDXC cards, however there are numerous reports about SDXC cards often not working properly. As pretty much all high-capacity (32GB and above) cards you can buy today are SDXC, I'm thinking this is the issue at the core. My M5Paper works perfectly with a number of SDHC cards I have lying around, but haven't tested with a larger card yet.

The M5Paper factory test sample is also limited to FAT/FAT32 file systems. It has nothing to do with the SD controller - that is purely just a block device controller, and has no idea about the file system on the storage device. It literally just gives block level access to the storage.

In theory, these MCUs have no actual hardware limitations on the size of SD cards they can read. However, again, the only supported file system for SD cards by default is FAT/FAT32, which does impose a file system limit - 32GB. Most operating systems will in fact by default format your SD cards above 16GB (some above 8GB) to exFAT, and many cards come formatted exFAT from the factory.

On the other hand, you've managed to get your M5Paper working properly, which is good :)

It depends on the protocol, as you said. Check in your router what kind of authentication your WiFi uses, and adapt the WiFi connection to that.

If your home network, for some weird reason, uses WPA2 Enterprise, the ESP32 WiFiClientSecure module should be the one you go for: https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFiClientSecure/examples/WiFiClientSecureEnterprise/WiFiClientSecureEnterprise.ino

@jcabad100 For me the noise happens when

1. The FIRE is turned on and I press the power button (the one next to the USB port)
2. The FIRE is being programmed by the Arduino SDK and switches into the download mode. It lasts maybe 2, 3 seconds in total and always disappears

The reason for this, I guess, is that the speaker pin (GPIO25) is sitting right next to the RST pin, and most likely the lines are interfering.

As for the magnetic dock not providing USB connection... There are two data pins exposed, so I suppose USB communication should be possible up until the GO bottom module. However they're connected to GPIO21 and 22 as I2C pins.

I've got a response on AliExpress from Jimmy Lai, confirming the issue with the button press making a noise on the speaker, and recommended adding the following snippet:

//disable the speaker noise
dacWrite(25, 0);

I'll check and see how it works.

I've returned them and ordered from the official store... And the same model was delivered, with MPU6050+MAG3110, the same screeching of the speaker when I press the power button, and to top it all off, the bottom boards seem to be swollen as well (the bit where the battery is connected to the PCB is pushed and warped upwards, making stacking quite difficult and in some cases, impossible).

I'm really feeling let down by the quality of the product to be frank.

I purchased two FIRE kits from an Amazon UK vendor. However both units have some weird QC issues (on one two of the top buttons are not exactly "clicky" but more mushy, like if there was an issue with the buttons, and the others' LED bar diffusers are not neatly cut, there's a large-ish gap on it), and to top that off... Whenever I press the side button (power/restart) while the FIRE is on, the speaker within produces a quite loud white noise. Oh also, these are the older model with MPU6050+MAG3110 instead of MPU9250.

Are these symptoms normal, or should I return the units?