Core2 Esptool.py flash fail
-
I do not think you have a defective unit.
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.
-
I am actually working with the idf 4.
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.
-
@barbiani
Try 115200 baud setting with esptool. This should fix it. Flashing will be slower but won't fail. -
@barbiani
If you are using this command line:
esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 460800 write_flash -z 0x1000 esp32-20190125-v1.10.binChange baud 460800 to 115200
-
Unfortunately it did not help. I did try other baud rates also.
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.
-
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.
-
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.
-
@barbiani
I am blank now.
If anyone has an idea can step in now :) -
I am still here!
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.
-
Hello @barbiani
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
lowfor download mode. However the CAN interrupt (active low) ishighwhen 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 -
Yes it makes sense! Made a table to help other users.
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.
