For the USB module... The Core2 does not power the 5v bus line until the ax192 is initialized.. and the USB module without power holds the reset line down preventing the esp32 from starting.

Thank you very much.

some modules have been developed before M5Core2 and are not fully compatible. The reason being that some GPIOs exposed on the M5-Bus have been moved or replaced from where they were on M5Stack (Fire, Base, Gray). A while ago I've made a comparison sheet that might help. You can find it here.

I think the issue with the COMMU module is the CAN interrupt which on M5Stack is connected to GPIO15 but on M5Core2 it is connected to GPIO2. GPIO2 is a so called strapping pin which according to the ESP32 datasheet needs to be low for download mode. However the CAN interrupt (active low) is high when there is no interrupt. That most likely is the reason the ESP32 is kept from going into download mode.

Without a hardware change I am afraid you'll need to un-stack the COMMU module every time you want to download new firmware.

Thanks
Felix

Bought a few more modules to play with like stepper, servo, usb, bottom2, commu.

The Core2 + steppermotor + servo + bottom2 is flashing well on a linux machine.

When the comm module is attached idf.py flash times out.

With the USB module pcb v1.0 it does not even turn on.

Hmmm, ok my next suspicion is either your USB cable or the version or how you are running esptool.

How is your set up?
are you using windows, linux mac?
Have you updated your platform drivers ?
Have you tried another USB cable?
Are you using a USB hub in between?

My last suspicion is your core2.

It is windows 10 running kali on virtualbox. Idf 4.2, powered usb 3.0 hub.

I have been using the wrover kit, wroom, esp8266 and the core 1 grey without any troubles.

As the flash fails with the core2, simply changing to the core 1 gray completes successfuly.

Also I was able to erase the core2 using the windows esp32 flath tool many times.

Looks like in the new core2 the boot pin is not held low long enough to put it in bootloader mode in this virtualized setup.

Again... where the core2 fails a core1 gray does very well. I did not open them yet to spot the differences.

How is your set up?
are you using windows, linux mac?
Have you updated your platform drivers ?
Have you tried another USB cable?
Are you using a USB hub in between?

My last suspicion is your core2.

All I get is "Connecting.....____......" with a sound and vibration until I press reset a few times and it gets in sync.

This sound/vibration comes from the previous flashed app startup.

After a full flash erase I was able to flash hello-world properly once. Then it needs the reset pressing again.

Change baud 460800 to 115200

Erased it and reflashed it with the trick a few times already.

The same does not happen with the older grey m5.

Seems like gpio 0 and 2 are not toggled at the right time.

The thing is that uiflow is kept running in loops and when you try to flash with estool, or connect with rshell that unit does it in pauses. The same thing happens if you connect to a StickC (uiflow loaded) with rshell.

If you flash a generic Micropython and then try to flash again with esptool this should not happen as Micropython with out running any heavy app is not interrupting.