M5Paper unusable

robski

@turgu have you erased and loaded latest firmware to it via M5Burner?

turgu

@robski Yes, tried several applications. Burning is fine but nothing happen on screen. As indicated, the monitoring shown that the it8951 chip responsible of managing the screen refuses to become ready. As I'm a professional embedded developer, was also able to develop some code that manage properly the battery state, the buttons and the touchscreen. But the eInk screen controller refuses to become ready.

robski

@turgu shame, I do have myself one of M5Basic where lcd just stopped to work, all the rest works just fine except built in screen

turgu

@robski Was ready to buy a new M5PaperS3, but with this issue, I'm becoming less and less interested. I did built some software for the Inkplate eInk/esp32 based devices (an EPub reader and other stuff). This jeopardize my effort to port them to the M5Paper-ish devices.

turgu

@robski You can have a look at the EPub reader I wanted to port here

robski

@turgu sounds like you went in bit too deep in to display firmware maybe? - joking -

turgu

@robski At least on paper, the Inkplate devices are very similar in capabilities to the M5Paper. No reason to not being able to port the app, but hardware stability...

felmue

Hello @turgu

FWIW: in M5PaperS3 the eInk display is directly controlled by ESP32S3.

In M5Paper the GPIO WaitBusy() checks is GPIO27 which comes directly from IT8951 so I guess if the line never goes HIGH either IT8951 is not (properly) powered or defective.

Anyhow, have you tried to change the code to ignore the busy state of IT8951; maybe add some small delay instead.

BTW: I measured GPIO27 and when M5Paper is running it's being pulled up. I don't see a pull-up resistor in the schematics so I guess IT8951 is pulling it up (when not busy).

Thanks
Felix

samlevy0515

That sounds frustrating! Since it's been an issue since purchase, it might be a hardware defect in the IT8951 controller. Try a 'nuclear reset'。 Disconnect the battery for 30 mins + hold power button to drain residual charge, then reflash.

king-333

@turgu That sounds frustrating! Did you solve this problem?

wdehoog

Hi,

In my application the m5paper goes to deep sleep and should wake after 5 minutes. Sometimes it appears to hang at startup and I also get a series of these messages:

[W][Panel_IT8951.cpp:258] _wait_busy(): [Panel_IT8951] wait_busy: timeout

As @felmu suggested it can be a pullup issue.

In M5GFX.cpp the busy pin is configured with:

lgfx::pinMode(GPIO_NUM_27, lgfx::pin_mode_t::input_pullup); // M5Paper EPD busy pin

However in Panel_IT8951.cpp (Panel_IT8951::init(bool use_reset)) the busy pin is configured with

pinMode(_cfg.pin_busy, pin_mode_t::input);

So it looks like the pin is incorrectly reconfigured and the required pullup is missing.

Now how can I override this behaviour in my application without having to modify the M5GFX.cpp file?

(I am using the Arduino IDE with M5GFX 0.2.17 and M5Unified 0.2.11.)

regards,

Willem-Jan

wdehoog

A fix has been submitted. See https://github.com/m5stack/M5GFX/commit/66df6c5f44d5867550d902923bf04ad6338d57cf

wayner.d

M5Paper quirks can definitely slow you down. Curious what steps you’ve tried so far and if any improvements helped.