M5Stack PaperMono is a compact ESP32-S3 e-paper device with a touchscreen, frontlight, NFC and LoRa. It makes sense for a handheld reader, a small status terminal or a project that combines a readable screen with local identification or remote sensor messages. For Arduino, start with the dedicated M5PaperMono board profile and current M5Unified/M5GFX libraries.
The hardware choice is straightforward: PaperMono favours a smaller illuminated handheld interface and integrated radios; PaperS3 offers more display area. The software needs closer attention. Their display wiring, peripheral buses and power controls differ, so an existing PaperS3 sketch needs checking before it is moved across.
Display-driver note, checked 14 September 2026: M5Stack currently flags PaperMono’s M5GFX waveforms as unstable and recommends the panel’s OTP waveform example for refresh reliability and panel life. Arduino support exists, but that warning should influence any project with frequent screen updates. See the official PaperMono software notes.
PaperMono hardware at a glance
| Feature | PaperMono C153 |
|---|---|
| Processor and memory | ESP32-S3R8; 16 MB flash; 8 MB Octal PSRAM |
| Display | 3.97-inch, 480 × 800, four grayscale levels; SSD1677 controller |
| Interaction | FT6336G touch, frontlight, two user buttons |
| Wireless | 2.4 GHz Wi-Fi; SX1262 LoRa; ST25R3916 NFC |
| Other peripherals | microSD, BMI270 IMU, RX8130CE RTC, PDM microphone, buzzer and RGB indicator |
| Power | USB-C 5 V; 1150 mAh battery; M5PM1 and M5IOE1 control |
| Size and weight | 62 × 101 × 8 mm; 74.7 g |
This guide covers the full C153 PaperMono. PaperMono-Lite omits the NFC and LoRa hardware. Check the exact model when buying or choosing firmware. Specifications: M5Stack PaperMono reference.
PaperMono vs PaperS3: the differences that matter
| Feature | PaperMono | PaperMono-Lite | PaperS3 |
|---|---|---|---|
| Screen | 3.97-inch; 480 × 800 | 3.97-inch; 480 × 800 | 4.7-inch; 960 × 540 |
| Grayscale | 4 levels | 4 levels | 16 levels |
| Frontlight | Built in | Built in | No built-in frontlight |
| Touch controller | FT6336G | FT6336G | GT911 |
| Display interface | SSD1677 over SPI | SSD1677 over SPI | Parallel direct-drive panel; EPDIY dependency in M5Stack’s software stack |
| CPU / flash / PSRAM | ESP32-S3R8 / 16 MB / 8 MB | ESP32-S3R8 / 16 MB / 8 MB | ESP32-S3R8 / 16 MB / 8 MB |
| Battery | 1150 mAh | 1150 mAh | 1800 mAh |
| NFC / LoRa | ST25R3916 / SX1262 | Neither fitted | Neither built in |
| microSD connection | SD_MMC | SD_MMC | SPI |
| Internal I2C | SDA GPIO47; SCL GPIO48 | SDA GPIO47; SCL GPIO48 | SDA GPIO41; SCL GPIO42 |
| External sensor connector | No PaperS3-style expansion connector is documented | No PaperS3-style expansion connector is documented | HC1.25 four-pin connector: GND, 3.3 V, GPIO1, GPIO2 |
Comparison references: PaperMono hardware, PaperS3 hardware and development notes, and PaperMono microSD example.
Choose PaperMono when you will actually use the frontlight, NFC or LoRa, or want a pocket-sized interface. Choose PaperMono-Lite when you want the same compact display platform without paying for NFC and LoRa you will not use. Choose PaperS3 when a larger reading area, more grayscale levels or the accessible sensor connector matters most. Both PaperMono models and PaperS3 benefit from e-paper-friendly interface design: large text, deliberate page changes and limited animation.
A larger battery does not establish which finished project lasts longer. Runtime also depends on radio use, the frontlight, update frequency and which circuits remain powered between updates. Treat battery capacity as one input to the decision.
PaperMono pinout: internal ESP32-S3 connections
These tables describe internal board wiring, not a row of freely available GPIO headers. A pin labelled GPIO in a schematic can already be occupied by a built-in peripheral. Avoid copying a generic ESP32-S3 sensor pin assignment into this device without checking it.
Display, touch, buttons and audio
| Signal | ESP32-S3 GPIO |
|---|---|
| E-paper MOSI / clock | GPIO14 / GPIO15 |
| E-paper CS / DC / BUSY | GPIO16 / GPIO17 / GPIO18 |
| System I2C SDA / SCL | GPIO47 / GPIO48 |
| Touch interrupt | GPIO4 |
| Button A / Button B | GPIO2 / GPIO3 |
| PDM microphone data / clock | GPIO46 / GPIO45 |
| Buzzer PWM | GPIO42 |
| M5PM1 interrupt / boot control | GPIO1 / GPIO0 |
| M5IOE1 interrupt | GPIO7 |
microSD, LoRa and NFC
| Signal | ESP32-S3 GPIO |
|---|---|
| microSD CMD / CLK | GPIO12 / GPIO13 |
| microSD DAT0 / DAT1 / DAT2 / DAT3 | GPIO11 / GPIO10 / GPIO9 / GPIO8 |
| LoRa MOSI / MISO / clock | GPIO38 / GPIO40 / GPIO39 |
| LoRa NSS / BUSY / IRQ | GPIO41 / GPIO21 / GPIO5 |
| NFC interrupt | GPIO6 |
The display and LoRa use separate SPI signal groups. The card slot uses SD_MMC wiring, while NFC shares the internal I2C bus. Pin references: PaperMono schematic V0.6.2 and the official PinMap.
Power and reset pins belong to other chips
PaperMono delegates several controls to its M5IOE1 expander and M5PM1 power controller. Their pin numbers are separate namespaces. For example, PYG5 on M5IOE1 resets the display; digitalWrite(5, ...) would address the ESP32’s GPIO5, which is connected to the LoRa interrupt.
| Controller | Pin / signal | Function |
|---|---|---|
| M5IOE1 | PYG3 / PYG5 | E-paper power / reset |
| M5IOE1 | PYG13 / PYG6 | Touch power / reset |
| M5IOE1 | PYG14 / PYG1 | microSD power / card detect |
| M5IOE1 | PYG2 / PYG10 | LoRa antenna switch / reset |
| M5IOE1 | PYG4 | NFC enable |
| M5IOE1 | PYG12 | Microphone power |
| M5IOE1 | PYG8 / PYG9 | Green / blue indicator channels |
| M5PM1 | GPIO3 PWM / GPIO2 | Frontlight / LoRa enable |
Use the board-aware drivers first. M5Stack documents a multi-level power system, so putting the ESP32 to sleep and switching off peripheral supplies are distinct operations. Do not cut a rail while its driver is using the device. See M5PM1 and M5IOE1 power management.
Internal I2C addresses
| Device | 7-bit address |
|---|---|
| FT6336G touchscreen | 0x38 |
| RX8130CE RTC | 0x32 |
| BMI270 IMU | 0x68 |
| M5PM1 power controller | 0x6E |
| M5IOE1 expander | 0x4F |
| ST25R3916 NFC | 0x50 |
Use the internal bus on SDA47/SCL48. The charger at 0x75 is a special case: its connection is controlled by M5IOE1 and should not remain connected for extended periods. A generic scanner result is therefore not a complete inventory of healthy peripherals. The official charger note explains the bus-stability concern.
At ESP32-S3 level, remember that GPIO0, GPIO3, GPIO45 and GPIO46 are strapping pins, GPIO46 is input-only, and GPIO19/20 are used by native USB. Flash and Octal-PSRAM connections are also not available for casual reassignment. PaperMono is an integrated device rather than a general-purpose exposed-header development board, so use the documented board functions first and treat its GPIOs as 3.3 V logic.
Arduino IDE setup for PaperMono
Install the board package
Install Arduino IDE, open File → Preferences, and add this official index to Additional Boards Manager URLs:
https://static-cdn.m5stack.com/resource/arduino/package_m5stack_index.jsonOpen Boards Manager, install or update M5Stack, then select Tools → Board → M5Stack → M5PaperMono. The package installation procedure is documented in M5Stack’s board-manager guide.
The current PaperMono examples list these minimum versions: M5Stack board package 3.3.9, M5Unified 0.2.20 and M5GFX 0.2.27. If M5PaperMono is missing, update the package before changing GPIO definitions. Verify that the selected configuration uses 16 MB flash and Octal PSRAM. The minimums are listed with the official touch example; the memory specification is in the hardware reference.
Install libraries and upload
- In Library Manager, install M5Unified, M5GFX, M5PM1 and M5IOE1, accepting prompted dependencies.
- For the complete official NFC/LoRa examples, also install M5UnitUnified, M5Unit-NFC and RadioLib.
- Connect a USB data cable. Hold the side power/reset button for roughly two seconds and release when the indicator blinks.
- Select the detected USB port, compile the sketch, and upload. Briefly press the power/reset button if the application does not start after flashing.
- Open Serial Monitor at 115200 baud. Re-select the port if it changes between download mode and the running application.
Library and flashing reference: PaperMono Arduino quick start. Keep a record of the working board-package and library versions once your first build succeeds; that makes later regression checks much easier.
Optional check: USB, flash and PSRAM
If upload works but the display example behaves strangely, isolate the board configuration before debugging graphics. This small sketch checks the ESP32-S3, flash and PSRAM without touching the e-paper panel. If your Arduino menu exposes USB CDC On Boot, enable it for native-USB serial output.
#include <Arduino.h>
void setup() {
Serial.begin(115200);
const uint32_t started = millis();
while (!Serial && millis() - started < 3000) {
delay(10);
}
Serial.printf("Chip: %s\n", ESP.getChipModel());
Serial.printf("Flash bytes: %lu\n",
static_cast<unsigned long>(ESP.getFlashChipSize()));
Serial.printf("PSRAM bytes: %lu\n",
static_cast<unsigned long>(ESP.getPsramSize()));
Serial.printf("Free PSRAM bytes: %lu\n",
static_cast<unsigned long>(ESP.getFreePsram()));
}
void loop() {
delay(1000);
}The hardware target is 16 MB flash and 8 MB Octal PSRAM. A zero PSRAM result usually points to the selected board/profile or PSRAM configuration before it points to a failed chip. The usable figure reported by software can be slightly below the physical capacity.
A first Arduino sketch: one page and two buttons
This starter sketch follows the documented M5Canvas and button APIs. It draws a black-and-white page once. Button A toggles the frontlight; Button B prints display dimensions to Serial Monitor. The loop does not repeatedly refresh the panel. It is a bring-up example, not a measured battery-life or panel-endurance test.
#include <M5Unified.h>
#include <M5GFX.h>
M5Canvas page(&M5.Display);
bool frontlightOn = false;
void setup() {
auto options = M5.config();
options.clear_display = false;
M5.begin(options);
Serial.begin(115200);
M5.Display.setRotation(0);
M5.Display.setBrightness(0);
M5.Display.setEpdMode(epd_mode_t::epd_quality);
page.setColorDepth(8);
if (page.createSprite(M5.Display.width(),
M5.Display.height()) == nullptr) {
Serial.println("Canvas allocation failed; check PSRAM.");
return;
}
page.fillSprite(TFT_WHITE);
page.setTextColor(TFT_BLACK, TFT_WHITE);
page.setTextSize(3);
page.setCursor(24, 40);
page.println("PaperMono ready");
page.setTextSize(2);
page.setCursor(24, 120);
page.println("A: toggle frontlight");
page.setCursor(24, 160);
page.println("B: serial diagnostics");
page.setCursor(24, 220);
page.println("esp32.co.uk");
page.pushSprite(0, 0);
}
void loop() {
M5.update();
if (M5.BtnA.wasPressed()) {
frontlightOn = !frontlightOn;
M5.Display.setBrightness(frontlightOn ? 80 : 0);
}
if (M5.BtnB.wasPressed()) {
Serial.printf("Display: %d x %d\n",
M5.Display.width(), M5.Display.height());
}
delay(20);
}Allow the initial refresh to finish before judging the result. A page remaining visible after power-off is normal for e-paper. API references: PaperMono display and brightness and PaperMono buttons.
The conservative update pattern above does not remove M5Stack’s waveform warning. For a device that will refresh unattended for months, evaluate the OTP route before settling on the display driver.
Refresh speed, ghosting and the OTP driver
M5Stack reports the following laboratory timings for its M5GFX modes. Treat them as reference measurements; content and operating conditions affect the result.
| M5GFX mode | Reference refresh time |
|---|---|
| epd_quality | 4.71 seconds |
| epd_text | 0.45 seconds |
| epd_fast | 0.34 seconds |
| epd_fastest | 0.07 seconds |
The fastest setting trades image quality and ghosting control for speed. A short refresh time does not make an e-paper screen a suitable replacement for an animated LCD interface. Mode details: M5Stack display documentation.
For development, update when information changes, wait for an update to finish, and avoid endless fast-refresh tests. Follow M5Stack’s recommendation to clear accumulated ghosting with a full refresh after about ten fast partial updates. Avoid experimenting with arbitrary waveform tables.
The official PaperMono OTP demo drives the SSD1677 using waveform data stored in the controller itself. Here OTP means one-time-programmed waveform data; it does not mean the display can only be refreshed once. The demo is an ESP-IDF project, not an Arduino sketch to paste into the IDE. Its reference toolchain is ESP-IDF 5.5.1; it demonstrates partial and full updates, four-level grayscale and sleep between touch-triggered changes.
idf.py set-target esp32s3
idf.py build
idf.py -p YOUR_PORT flashReplace YOUR_PORT with the actual device port. If you are evaluating PaperMono for a long-running unattended application, this OTP example is the manufacturer-recommended baseline to test before committing to a refresh strategy.
My practical approach would be to prove the user interface in Arduino, then validate the production refresh strategy separately. Keep data collection and screen rendering in different functions so the driver can change without rewriting the entire application.
Touch and microSD setup details
Keep touch targets away from the very edge
M5Stack documents a usable touch range of approximately X5–475 and Y5–795 in the native 480 × 800 coordinate space. Use generous button margins and test the chosen screen rotation. For diagnosis, log touch coordinates over USB instead of redrawing for every movement; it makes input debugging easier to separate from refresh behaviour. See the PaperMono touch example.
Use SD_MMC rather than a PaperS3 SPI example
PaperMono’s official card example uses SD_MMC.h, enables the card supply through M5IOE1, and mounts the six-signal bus. A copied PaperS3 SD.begin() configuration targets a different connection.
After M5.begin(...), this is the relevant initialisation pattern for PaperMono. Add #include <SD_MMC.h> at the top of the sketch:
// M5IOE1 PYG14 is index 13 in this M5Unified accessor.
auto& cardPower = M5.getIOExpander(0);
cardPower.setHighImpedance(13, false);
cardPower.setDirection(13, true);
cardPower.digitalWrite(13, true);
delay(10);
// Order: CLK, CMD, D0, D1, D2, D3.
bool pinsOK = SD_MMC.setPins(13, 12, 11, 10, 9, 8);
if (!pinsOK || !SD_MMC.begin("/sdcard", false)) {
Serial.println("Card mount failed: check board, power and card.");
}The expander index and the ESP32 GPIO13 in that snippet belong to different chips. Never translate an expander label into an ESP32 pin call by matching the number. Use a backed-up, known-good formatted card for first tests. The complete M5Stack microSD example also shows image loading.
Battery operation and Home Assistant project ideas
Plan the whole wake cycle: collect data, compose the page in memory, refresh once, finish storage writes, and then enter the appropriate low-power state. Turning the frontlight off between interactions is an obvious first saving. A Wi-Fi retry loop that runs indefinitely can undo the rest of the power-saving work.
Use M5Stack’s power and wake-up examples to choose between ESP32 sleep and board-level power switching. Decide which event must wake the device before switching off its source. An RTC-driven information board and a touch-driven handheld reader need different policies.
For a Home Assistant project, I would start with a small Arduino application that receives selected values through MQTT or retrieves a compact JSON response. Render a few useful values instead of reproducing an entire dashboard. Suitable pages include the next bin collection, indoor temperature, an energy-use summary or a room-availability notice.
Always show when the information was last updated. If Wi-Fi is unavailable, keep the last successful values and mark them stale after a sensible interval. Test this deliberately by disabling the access point. A retained e-paper image otherwise looks current even when the device has stopped receiving data.
NFC could select a user-specific page, while LoRa could carry readings from a separate sensor node. Those are application ideas requiring suitable firmware at both ends. Having the radio hardware does not automatically provide a configured LoRaWAN service or a ready-made Home Assistant integration.
For a larger monochrome alternative, see our PaperS3 Arduino and pinout guide. For colour e-paper, see the M5Paper Color guide. For battery budgeting and wake cycles, the ESP32 deep-sleep and low-power guide covers the wider design method.
Troubleshooting PaperMono
| Symptom | First checks |
|---|---|
| M5PaperMono is absent from the board menu | Update the M5Stack package and restart Arduino IDE. Check the official minimum versions. |
| Display or expander APIs do not compile | Update M5Unified and M5GFX together; check for duplicate older copies in the sketchbook libraries folder. |
| USB port is missing | Try a known data cable, enter download mode, and inspect the available ports again. |
| Canvas allocation fails or the screen stays blank | Confirm the dedicated board profile and Octal PSRAM; first isolate the display using the starter sketch. |
| Ghosting builds up | Stop repetitive fast updates, check the recommended refresh policy and evaluate the OTP demo. |
| Touch misses edge controls | Move targets inward; log raw coordinates and verify rotation before changing the driver. |
| microSD does not mount | Check SD_MMC pin order, expander-controlled card power and the card itself. |
| NFC or LoRa does not respond | Confirm full C153 hardware, power/enable/reset handling and the peripheral’s own example. |
Change one layer at a time. A useful bring-up sequence is USB upload, display, buttons, touch, storage, then networking and radios. Once each part works independently, combine them and measure the effect on memory, update time and power.
If several unrelated I2C peripherals become unstable together, include the charger path in your checks. M5Stack notes that the IP2315 charger interface should not remain connected to the system I2C bus for extended periods, and low battery voltage can also affect its I2C-mode initialisation. Custom charger code should connect only for the required transaction and then release that path; a brief power-button reset is the documented recovery step for the related bus anomaly.
Related ESP32 guides
- M5Stack PaperS3: Arduino and pinout guide
- M5Paper Color: ESP32-S3 full-colour e-paper guide
- ESP32-S3 boards, modules and variants
- ESP32 battery-powered sensors, deep sleep and low-power design
Is PaperMono the right board for your project?
PaperMono is attractive when its integrated features remove hardware you would otherwise have to add. A compact reader with a frontlight, a badge-driven information terminal or a LoRa status display are strong matches. For a larger wall display with simple local sensor expansion, PaperS3 may be the more convenient starting point.
The main development priorities are selecting the correct board profile, respecting the separate power-control chips, and validating the refresh driver. Get those right before adding features. This guide is based on manufacturer documentation and examples, rather than a hands-on endurance review.