Hi! This error often happens due to unstable USB connections or driver issues. Try these steps: use a different USB cable (preferably a high-quality, data-capable one), connect directly to your Mac’s USB port (avoid hubs), and restart your Mac before uploading. Also, check that your ESP32-S3 drivers are properly installed and up to date. Lowering the upload baud rate (e.g., from 921600 to 115200) in the Arduino IDE can improve stability. If it persists, try uploading from another computer to rule out hardware issues. Hope this helps!

You're clearly doing everything right—this is a common ESP32 upload issue. Since the Core2 boots and shows output in Serial Monitor, the USB connection works, but upload mode isn't triggering.

Here’s what to try (if you haven’t already):

1. Hold Boot Button (if available): While uploading, hold the reset/boot button until upload starts. Some Core2s need manual bootloader mode.

2. Try 115200 Baud: You've tried this—stick with it; higher speeds can fail on some USB ports.

3. Check CP210x or CH340 Driver: Reinstall the correct USB-to-serial driver for the Core2.

If none of that helps, your Core2’s USB-UART chip might be defective. Exchange it through M5Stack support.

The W5500 Ethernet library for Arduino does not natively support setting a DHCP hostname in its standard implementation. If you're using Ethernet.h, it lacks this functionality. For advanced DHCP options like hostname, consider using the EthernetENC or UIPEthernet library, which offer extended DHCP support. Alternatively, you’d need to modify the DHCP client in the library to include the hostname in the DHCP request packet manually.

To fix incorrect timestamps in V-Training photos, update your device's firmware, check and set the RTC (sync via Wi-Fi or manually), and reconfigure the app. Also, format the SD card to FAT32. If issues persist, try a factory reset.

Yes, this is a common issue with M5Stick C flashing. Try holding the G0 button while connecting the USB cable to enter bootloader mode, then start the flash. Also, double-check your USB drivers and try a different USB port directly on your PC (avoid hubs). If problems persist, adding a 10µF capacitor between EN and GND can help stabilize the reset line. Make sure the serial port is correctly selected, and close other apps using it. This usually resolves the “Failed to connect to ESP32” errors.

Port A on the M5Dial is hardwired for I2C and shares pins with the internal screen, so repurposing it for TWAI/serial isn’t feasible without major conflicts. For dual CAN, consider using an external UART-to-CAN adapter or a separate GPIO header (if available) to assign alternate TX/RX pins for the second CAN interface.

It looks like PlatformIO is still uploading your filesystem as SPIFFS despite setting board_build.filesystem = littlefs. This happens because the default partition table might not reserve space for LittleFS. Try creating a custom partition table that supports LittleFS and specify it in platformio.ini with board_build.partitions. Also, ensure your LittleFS_esp32 library is compatible with M5Core2. Without proper partitioning, mounting fails with corrupted directory errors like yours. Let me know if you want help generating a suitable partition CSV file!

For the M5Stack Core2, Grove Port A uses I2C on GPIO 21 (SDA) and GPIO 22 (SCL). However, when using a Pb.HUB, you're communicating with the hub over I2C, and each connected unit (like relays or RGB) is addressed virtually via the hub.

Since openHASP doesn't natively support Pb.HUB devices, you can’t directly control GPIOs through it. Instead, you’d need custom firmware or integrate via ESPHome or Arduino to bridge Pb.HUB control with openHASP.

TL;DR: GPIO 21/22 for I2C, but control of devices via Pb.HUB needs extra handling outside openHASP.

I’m planning to use an M5Stack Core2 with ENV III and Soil Moisture units to monitor temperature, humidity, and soil moisture in my balcony garden. Data will be sent via MQTT to a local server for analysis and alerts. Looking forward to sharing updates!

Thanks for sharing the UiFlow 2.0 resources! I appreciate having a dedicated space for bugs, how-tos, and feature requests. Does anyone have tips on avoiding common firmware burning errors, especially with account binding? Also curious if there’s a timeline for the full API docs release. Looking forward to seeing how this evolves!

Hey Dennis, sounds like you’ve covered most of the basics. A few things to check: make sure the antenna switch (INT/EXT) is physically set correctly on the module. Also, the NEO-M8N can take a few minutes for a cold start—try leaving it powered outside for 15–20 minutes. Lastly, ensure it has a clean 3.3V power source; voltage drops can affect satellite acquisition. If none of that helps, try updating the GPS firmware via u-center. Two dead modules is unlikely, but not impossible. Good luck!

The rom/miniz.h error occurs because newer board definitions (3.2.x) removed legacy ESP32 support. Downgrading to 2.1.x works, but to fix it permanently:

Manual fix: Replace #include <rom/miniz.h> with #include <miniz.h> in pngle.c (as noted in the linked guide).

Disable auto-updates: In Arduino IDE, go to File > Preferences and uncheck "Check for updates on startup."

M5Stack isn’t abandoning older Cores, but newer SDKs drop deprecated APIs. If issues persist, stick with 2.1.x or modify the library.

It sounds like the 5V output on the M5Capsule may not be designed to supply higher current devices directly—30mA is very low. Unlike the M5GO, the Capsule likely has current-limited or protected output. You might try powering the camera from an external 5V source and just connect data lines to the Capsule. Also worth checking if there's a FET or regulator in the schematic limiting output.