M5Paper won't execute loaded programs

tahunus

I'm using Windows 11 and Arduino IDE 2.0.3 (although the same behavior occurs with Arduino IDE 1.8.16). I installed both CP210x_VCP_Windows and CH9102_VCP_SER_Windows drivers according to your Driver Installation Instructions along with the rest of the Arduino board and library instructions.

I copied the Hello World program in those same instructions, and correctly compiled (compile result is reproduced at the end of this message). But after loading is finished, the M5Paper display remains unchanged. And worse, the board hangs and becomes unresponsive.

I've gone through the forum and found that the navigation switch on the side can be used to bypass the program to get into the menu, also how to power off and on using the press button on the back and the middle button on the side. None of this solved it.

I downloaded the M5Burner from your download page and the dialog hangs when reaching "Detecting chip type..."

--chip auto --port COM5 --baud 115200 --before default_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x000 C:\Users\pedro\Downloads\M5Burner-v3-beta-win-x64\packages\firmware\jodgieto2t4qvtjb9j2qbfs720dh3rpx.bin
esptool.py v4.1
Serial port COM5
Connecting...
.

Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
.
.

Detecting chip type...

The only thing that works is the EasyLoader of the Factory Test. Even the EasyLoader of the Calculator fails (it messages "Succesfully" but the calculator program is not executed and the M5Paper hangs as when loading the Hello Program via the Arduino IDE.

I am fairly familiar with the ESP32 (one example of something I've made) and this M5Paper behavior is rather frustrating.

Please advise. THANKS!

-------------------------------------------------------------------------------------
Compilation result:

Sketch uses 415833 bytes (6%) of program storage space. Maximum is 6553600 bytes.
Global variables use 18384 bytes (0%) of dynamic memory, leaving 4503600 bytes for local variables. Maximum is 4521984 bytes.
esptool.py v3.3
Serial port COM5
Connecting......
Chip is ESP32-D0WDQ6-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 30:c6:f7:21:18:70
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00005fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x00075fff...
Compressed 17472 bytes to 12125...
Writing at 0x00001000... (100 %)
Wrote 17472 bytes (12125 compressed) at 0x00001000 in 0.4 seconds (effective 359.3 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 129...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (129 compressed) at 0x00008000 in 0.0 seconds (effective 527.0 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 682.8 kbit/s)...
Hash of data verified.
Compressed 416224 bytes to 223943...
Writing at 0x00010000... (7 %)
Writing at 0x0001d105... (14 %)
Writing at 0x0002f46b... (21 %)
Writing at 0x00034eab... (28 %)
Writing at 0x0003a5e0... (35 %)
Writing at 0x000401b1... (42 %)
Writing at 0x00045474... (50 %)
Writing at 0x0004aaed... (57 %)
Writing at 0x0004fd14... (64 %)
Writing at 0x000570ee... (71 %)
Writing at 0x0005f560... (78 %)
Writing at 0x00066fba... (85 %)
Writing at 0x0006c7b4... (92 %)
Writing at 0x00071c96... (100 %)
Wrote 416224 bytes (223943 compressed) at 0x00010000 in 3.9 seconds (effective 864.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

tahunus

Update: Windows' Device Manager reports that my M5Paper is using CH9102. In any case, since both M5Burner and EasyLoader can correctly load "Factory Test" (but ONLY Factory Test), it points to another problem (not a USB/UART issue).

tahunus

Update: I uninstalled CP210x_VCP to force it to use CH9102.

Using the M5Burner, I can flash the "Factory Test", the "To Do" and the "Calculator". With the first 2, the board reboots on its own. With the Calculator a manual reboot (using back button & side button) is necessary. In this case, the Esptool dialog never gets to "Hard reset via RTS pin". It just hangs.

Using the Arduino IDE (ver 2.0.3 or 1.8.19), compilation works fine and then Esptool reports flashing is done and resets via RTS pin. It does not reset on its own. Even after manual reboot, nothing happens on the board. I used the "Hello World" program and even the Calculator code from the GitHub repository (making the appropriate changes to use it in Arduino vs PlatformIO) has the same behavior.

BTW: looking at the M5Burner output, I saw it compiles at --flash_freq 80M and flash_size detect 0x000. I can change the first parameter when compiling with Arduino but the second has to use a predefined partition table. Thinking it might be a memory problem I tried several partitions with the same result.

The Arduino implementation uses Esptool 3.3 (it is hard coded somewhere to search for path m5stack/tools/esptool_py/3.3.0/esptool.exe). M5Burner uses Esptool 4.1. To test for this, I changed the code in your 3.3.0 folder with Esptool 4.2.1 (the latest version in use in the ESP32 Arduino core) with the same results.

So, it's not the Esptool version and apparently, it's not the USB chip.

Since the Calculator load from the M5Burner does not reset on its own as with any Arduino load, it would seem there's something amiss with the reset pin? Can you think of some other tests I can do short of opening the board and searching for something like a malfunctioning pull-down resistor?

tahunus

I added debug printouts after each line in "Hello World" (see code, below) and something is causing the board to reboot. Code sometimes gets to loop() sometimes reboots before even finishing setup(). (see output, below). Note that I commented out M5.EPD.Clear(true); because that line always causes the board to reboot. (The messages "M5EPD initializing..." and "OK" are called in the begin() method of of M5EPD.cpp, lines 36 & 77 respectively)

Compiling the source code for Calculator in M5's Github, I get the same result: board reboots after a few milliseconds.

Since the code loaded using M5Burner does not cause this rebooting (opening Arduino's Serial Monitor after burning shows the dialog of that version of Calculator's setup() running just fine), the only conclusion is that M5's Arduino's implementation is missing something. Perhaps because it was developed thinking of PlatformIO? Any ideas?

Output:

05:53:52.274 -> M5EPD initializing...OK
05:53:55.099 -> 
05:53:55.099 -> M5 Begin done
05:53:55.099 -> SetRotation
05:53:55.099 -> RTC
05:53:55.099 -> createCanvas
05:53:55.099 -> setTextSizw
05:53:55.099 -> drawString
05:53:55.099 -> pushCanvas
05:53:55.099 -> in loop
05:53:55.099 -> in loop
05:53:55.099 -> in loop
05:53:55.099 -> in loop
05:53:55.099 -> in loop
05:53:55.099 -> in loop
05:53:55.099 -> in loop
05:53:55.099 -> in loopM5EPD initializing...OK
05:53:58.782 -> 
05:53:58.782 -> M5 Begin done
05:53:58.782 -> SetRotation
05:53:59.636 -> M5EPD initializing...OK
05:54:02.451 -> 
05:54:02.451 -> M5 Begin done
05:54:02.451 -> SetRotation
05:54:03.664 -> M5EPD initializing...OK
05:54:06.451 -> 
05:54:06.451 -> M5 Begin done
05:54:06.451 -> SetRotation
05:54:06.451 -> RTC
05:54:06.451 -> createCanvas
05:54:06.451 -> setTextSizw
05:54:06.486 -> drawString
05:54:06.486 -> pushCanvas
05:54:06.486 -> in loop
05:54:06.486 -> in loop
05:54:06.486 -> in loop
05:54:06.486 -> in loopM5EPD initializing...OK
05:54:10.159 -> 
05:54:10.159 -> M5 Begin done
05:54:10.159 -> SetRotation
05:54:11.001 -> M5EPD initializing...OK
05:54:13.818 -> 
05:54:13.818 -> M5 Begin done
05:54:13.818 -> SetRotation
05:54:14.658 -> M5EPD initializing...OK

Hello World:

#include <M5EPD.h>

M5EPD_Canvas canvas(&M5.EPD);

void setup(){
   M5.begin();  
   Serial.println("\nM5 Begin done");
   M5.EPD.SetRotation(90);  
   Serial.println("SetRotation");
   //M5.EPD.Clear(true);  
   //Serial.println("Clear");
   M5.RTC.begin();  
   Serial.println("RTC");
   canvas.createCanvas(540, 960); 
   Serial.println("createCanvas");
   canvas.setTextSize(3);
   Serial.println("setTextSizw");
   canvas.drawString("Hello World", 45, 350);  
   Serial.println("drawString");
   canvas.pushCanvas(0,0,UPDATE_MODE_DU4);  
   Serial.println("pushCanvas");
}

void loop(){
 Serial.println("in loop");
}

tahunus

BREAKTHROUGH: if I don't enable the touch driver (FALSE first parameter in M5.begin: M5EPD::begin(bool touchEnable, bool SDEnable, bool SerialEnable, bool BatteryADCEnable, bool I2CEnable), the sketch runs just fine (reboots the board, clears the ePaper display, outputs "Hello World"). When setting this parameter to TRUE is when the board continually reboots.

I added several debug Serial.print() messages in GT911.cpp to confirm that GT911 did not generate any errors (and it doesn't). So, it's not a hardware issue with touch controller since all binaries loaded with M5Burner work fine.

I searched for an updated GT911 driver (manufactured by Goodix) w/o success. The only driver on M5's repository is the one in M5EPD utility folder.

Has anyone been able to load a sketch using the Arduino IDE and enabling the touch driver?

tahunus

I've isolated the problem to the GT911 software.

In GT911.cpp, code lines 53 to 62 are commented out. These lines compare the value returned by register 0x8047 of the GT911 driver to the first value in static const array _kGT911FW540960G2T1602729168 (as defined in line 6). According to the GT911's datasheet, this register contains the Config_Version (page 5)

The returned value from the hardware is 0x42. The first value of the static array is 0x43, so, the full 186 values (from register 0x8047 to 0x8100) would be updated with the values in the static const array (done in line 58).

If these lines (53-62) are uncommented and the "Hello World" sketch recompiled (and thus the firmware is updated), the canvas commands in setup() work fine, and the board then reboots after 70-120 millis inside loop().

Still not a functional product, but at least something moves (as opposed to not updating the firmware, where it reboots without updating canvas).

Since the binaries burned by M5Burner work fine, it's clear it's not a hardware problem. What is impossible to know from what is provided with the product is what firmware version or values for GT911 the binaries are using.

So, DEAR M5STACK: can you PLEASE provide the updated (correct) driver config values?

Output from sample run:

16:19:36.605 -> M5EPD starting...M5EPD Init Ended
16:19:39.086 -> --M5 Begin
16:19:39.086 -> --SetRotation
16:19:39.689 -> --Clear
16:19:39.689 -> --RTC
16:19:39.723 -> --createCanvas
16:19:39.723 -> --setTextSize
16:19:39.723 -> --drawString
16:19:40.777 -> --pushCanvas
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.777 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.811 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> loop
16:19:40.848 -> M5EPD starting...M5EPD Init Ended
16:19:45.009 -> --M5 Begin

felmue

Hello @tahunus

for me the issue happens for ESP32 Arduino framework v2.0.5 (older versions seem fine).

Anyhow commenting out noInterrupts() and interrupts() in GT911.cpp seems to do the trick:

void ICACHE_RAM_ATTR ___GT911IRQ___()
{
//    noInterrupts();
    gt911_irq_trigger = 1;
//    interrupts();
}

Note: probably not the correct fix
Note: touch still works for me

BTW: I've read out the touch config on my M5Paper v1.0 and it is exactly the same as in _kGT911FW540960G2T1602729168[] except for the version number (0x42 vs 0x43) and the checksum at the end.

Thanks
Felix

tahunus

Thanks @felmue. I got an answer from support@m5stack.com stating: "The Arduino library update causes too many compatibility issues, pls switch to our common libraries M5Unified + M5GFX"

So, it makes sense that your changes in RAM_ATTR would make a difference. In my experience, one wrong poke in the ESP's memory and you get overflow and reboot. If the M5Paper were a finished product, it should state these limitations (i.e., ESP32-Arduino library version for stable ops).

Over the weekend I've been using the M5GFX Library and the M5Unified library and so far, all is ok.

felmue

Hello @tahunus

I am glad to hear you're up and running now. And thanks for reporting back.

Thanks
Felix

casascius

At a glance I would say commenting out noInterrupts() and interrupts() is the correct thing to do. Can anyone tell us why are they even there?

The purpose of noInterrupts() is to prevent interrupt handlers from running in the middle of a critical section of code. But this makes no sense -- we are already in an interrupt handler here, where protection from other interrupts is already in effect until the function returns. At least that's the case for other Arduino microcontrollers -- admittedly, I haven't coded much for ESP32. Someone say something if I misunderstand this here.

Furthermore, setting a byte size variable to a constant value like 1 isn't the sort of thing that counts as a critical section of code that would ever need noInterrupts() in the first place.

I say it's safe to comment these two lines out and then I raise the question why were they ever there.