Unfortunately you did not post your code so no one knows how you try to send the midi messages.
Check first: does the device apear as USB-MIDI-Class in your computers device manager?
Probably it is shown as a USB-Serial-Class device (which MIDI indeed is) but your MIDI application (seems to be a top secret application as you don't wrote which one) expect a MIDI-Class device.

Maybe this helps: https://github.com/esp32beans/ESP32USBMIDI

Hello everyone,

I’ve narrowed down my compilation issue to the epdiy library when working with ESP-IDF on the M5PaperS3 (ESP32-S3). Here’s my setup and error details:

Configuration Without epdiy (Compiles Successfully):

[env:esp32-s3-devkitm-1]
platform = espressif32
board = esp32-s3-devkitm-1
framework = espidf
board_upload.flash_size = 16MB
board_upload.maximum_size = 16777216
board_build.arduino.memory_type = qio_opi
build_flags = -DBOARD_HAS_PSRAM

Add epdiy dep(Compilation fails):
lib_deps =
epdiy=https://github.com/vroland/epdiy.git

Error:
Multiple ways to build the same target were specified for: /epdiy/output_common/lut.o
(from ['/epdiy/src/output_common/lut.S'] and from ['/epdiy/src/output_common/lut.c'])

Hello @cepics

try changing the line to:

Thanks
Felix

Looks like it has to do something with the bootloader.
I previously flashed the full factory-firmware which comes out of ESHome(platformio) build, but if I just flash the firmware to 0x10000, then it boots up all the time from battery as well. Needs more digging what could go wrong with platformio bootloader.

@LordInchcape Using M5CoreS3_SDCard_read_dir_UIFlow2.0.4 the following micropython will work:-
*import machine
import os

card = machine.SDCard(slot=2, sck=36, miso=35, mosi=37, cs=4, freq=1000000)
os.mount(card,"/sd")
print(os.listdir("/sd"))

f = open("/sd/test.txt", "w")
f.write("Hello world\r\n")
f.close()

g = open("/sd/test.txt", "r")
print(g.read())
g.close()
os.unlink("/sd/test.txt")**

Still to determine if it treads on something else.

Hello @silentrain23

I think you probably just need to wait a bit longer for it to register.

From the AT Command document (link here) the 2 in the AT+CREG 0,2 response means: Not registered, but MT is currently searching a new operator to register to

Thanks
Felix

@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.

@felmue I noticed that even logging in UIFLow gives me an error on login, even if the credentials are ok. Still a lot to explore.
Thanks

@felmue I did not see that error.

The afterimages have gone away. Leaving the screen all black and powered off a few minutes will help clear it, this is common EPD behavior.

Now that I think of it, I could not get drawJpgFile to work in a previous project (a fake Nixie watch), and I see from the PaperS3 demo program sample code that the Jpg is stored as a static array.

I got my simple badge display program to work by storing the image as a C array (exported from GIMP) and walking through the pixels, which is how I did it in my previous project. Suprisingly it's not incredibly slow but of course data in this format is incredibly bulky.

This github code is an example of how to convert a file into a statoc C array: https://github.com/notisrac/FileToCArray

In the next few days, maybe I'll figure out if SPIFFS works on the PaperS3 and report back.

I got the bar graph demo to work:

Using the latest M5 board package, you should see a board "M5PaperS3", so the requirement to downgrade the esp32 board package to 3.0.6 is not necessary. Use the "M5PaperS3" board definition instead of the generic ESP32S3 one.

The instructions to install epdiy are somewhat vague. Simply clone the epdiy library to your arduino library directory and it will work, doing a "make" is not necessary.

Follow the rest of the instructions at https://docs.m5stack.com/en/arduino/m5papers3/program, pay careful attention to the special board settings for OPI PSRAM, etc.

@PharkieB My idea, above, works!

Now, I can turn ON my Lipo-powered M5Stack Dial with the "Wake" (front button), it loads my UI Flow program, and then I can tell the software (btn A) to switch it OFF, when that's appropriate:

Screenshot 2024-12-22 at 16.40.40.png Screenshot 2024-12-22 at 16.40.54.png

This is using the "System >> Execute mpy code" block with this for on:

and this for off

Ideally this would be a standard UI Flow block for the M5Dial (keep device on once awake and on battery). It seems odd I've had to invent it, based on detail in the documentation.

@ScheduleDisplay
Connecting to always ON USB Power will permanent charge your battery and hold it at fully charged level. Not the best state to store a lithium battery over longer time. Best will be to remove it (or at least disconnect).