ESP32 Flash erase tip

[ghost]

• Operating system: macOS High Sierra 10.13.6
• Python version: 2.7.15
• ESP hardware in use: ESP32

Full esptool.py command line as run:

pwd: /Users/szilveszterfejes/.platformio/packages/tool-esptoolpy
cmd: python esptool.py erase_flash

Full output from esptool.py

Traceback (most recent call last):
  File "esptool.py", line 35, in <module>
    import serial.tools.list_ports as list_ports
ImportError: No module named serial.tools.list_ports

Other information:

macOS High Sierra 10.13.5 successfully erased flash memory.
combined cmd: python esptool.py --chip esp32 --port /dev/cu.usbserial* --baud 115200 --before default_reset --after hard_reset erase_flash

How to solve this problem?

pip install esptool

You get the same python version 2.7.15

• ecdsa-0.13
• esptool-2.5.0 -> maybe this was the bad boy
• pyaes-1.6.1
• pyserial-3.4

I hope this would be useful for somebody.
Opened this issue because in macOS High Sierra 10.13.5 I have no problem with flash erase.

[nixmeer]

#350 seems to be the same problem, probably just on 10.13.6. For me, flashing doesn't work either. Tried to run pip install esptool in tools folder, didn't change anything. It throws the

matplotlib 1.3.1 requires nose, which is not installed.
matplotlib 1.3.1 requires tornado, which is not installed.
matplotlib 1.3.1 has requirement numpy>=1.5, but you'll have numpy 1.8.0rc1 which is incompatible.

Can't install either of these packages.

Anyone any idea?

[ghost]

I have this setup:
please follow the sequence

1. homebrew

CMD: /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)

2. USB serial driver CH4X

CMD 1: brew tap mengbo/ch340g-ch34g-ch34x-mac-os-x-driver https://github.com/mengbo/ch340g-ch34g-ch34x-mac-os-x-driver
CMD 2:brew cask install wch-ch34x-usb-serial-driver

This is neccessary if you use and FTDI flasher

3. USB to UART bridge driver cp210x

WEB https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers

Bridge to ESP32 devboard. On link you will find a macOSx compatible file

4. pip

CMD: sudo easy_install pip

5. nose

CMD: sudo easy_install nose

6. tornado

CMD: sudo easy_install tornado

7. platformio

CMD: pip install -U https://github.com/platformio/platformio-core/archive/develop.zip

for me the best platform for this things using with Visual Code

Don't forget to set in FLASH ENABLE mode your ESP32 like this:

• GPIO00 -> LOW
• ENABLE -> LOW -> HIGH

NORMAL MODE

• GPIO00 -> HIGH or floating (this pin have internal pullup)
• ENABLE -> LOW -> HIGH

Simple wiring for development:
https://community.blynk.cc/uploads/default/original/2X/6/6ab1e685d2745ebea13962d421cca404cef59cea.jpg

[nixmeer]

Oh. I should mention I’m trying to flash an ESP8266 on an sonoff basic.

After upgrading to macOS 10.13, the only working driver would be one called wusbserial.

[ghost]

Try this: https://www.ebay.com/itm/FT232RL-3-3V-5-5V-FTDI-USB-to-TTL-Serial-Adapter-Module-for-Arduino-Mini-Port/381374421597?epid=930497168&hash=item58cbafda5d:g:jk8AAOSwrklVMjIp

• CH4X driver

[nixmeer]

I took some time and prepared the Arduino IDE so i could compile the firmware myself and upload it. But thanks!

Btw: I’m using a flasher module for ESP-01 for every ESP8266 and it works perfectly.

[projectgus]

Hi @fejess ,

This seems like maybe it's an Issue with platform.io rather than an Issue with esptool.py? The "How to Solve this Problem" is given as pip install esptool, which is also how the esptool.py README recommends to install esptool.

I'm going to close this as, despite containing a lot of good advice, it seems like nothing specific which needs fixing in esptool.py itself or the esptool.py docs. If you think there is something which needs fixing here, please let me know.

If platform.io isn't telling users to install pyserial 3.0 or newer (the root cause of the "serial.tools.list_ports ImportError discussed in #350), then please report this to platform.io project as a bug.

[ivankravets]

If platform.io isn't telling users to install pyserial 3.0

@projectgus should we do that?
PlatformIO is a 1-click solution, no need to install make, cmake, Python packages or other extra tools.

---

@fejess See platformio/platform-espressif32#127. Please run pio run -t erase with the latest upstream version. The final release of PlatformIO dev/platform is planned when the next release of Arduino core for ESP32 will out. @me-no-dev promised this week.

[ghost]

Alright, thank you!

[projectgus]

If platform.io isn't telling users to install pyserial 3.0
@projectgus should we do that?
PlatformIO is a 1-click solution, no need to install make, cmake, Python packages or other extra tools.

@ivankravets I don't know specifically how you manage dependencies internally to platform.io, but to work correctly you'll need to make sure users get pyserial>=3.0 The pyserial>=3.0 requirement is part of the esptool package metadata:
https://github.com/espressif/esptool/blob/master/setup.py#L109

And it's explicitly mentioned in the (legacy) manual install instructions.

esptool.py will not work properly with pyserial 2.x.

[me-no-dev]

@ivankravets my update build is stuck on PIO test. We have a "new" lib called "libsodium" but it looks like PIO's parser removes the "lib" prefix and causes "/home/travis/.platformio/packages/toolchain-xtensa32/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: cannot find -lsodium"

Ping me when you fix it :)

[ivankravets]

@me-no-dev please change libsodium in this this line to -llibsodium. SCons automatically strips lib prefix and it seems that it has a bug when double lib in the prefix is used.

... "core", "sdmmc", "-llibsodium", "coap", "tcpip_adapter" ...

[ivankravets]

@projectgus Thanks! PlatformIO Core depends on PySerial >= 3.0 too. @fejess experienced this issue because called esptool.py outside PlatformIO Core environment where he had the oldest version of PySerial.

Please note, that if you call PlatformIO Core directly (pio run -t upload), we will use our internal python packages where PySerial is updated to the latest version. In this case, the user's local version of PySerial will not be used.

[me-no-dev]

@ivankravets while I could have done many things to overcome this, all of them require adding a custom case for that lib on my end. Sure, it's a few lines, but I do think that it's something that should be fixed on your end, rather than mine. I don't think this case is so special, so you might benefit in the future for not having to deal with it again :)

[ivankravets]

@me-no-dev agree with you. I'll report this issue to @SCons team. Just curious, why does this lib call liblib*? :)

[me-no-dev]

well, the lib name itself starts with "lib*", which results in lib archive named "liblib*.a" and "-llib*" in build. Why SCons stripped it, I do not know :)

[me-no-dev]

I'll disable PIO builds in Master so I can get the update in and get on with release. Let me know when we should try again and I will enable them (you can do too)

[ivankravets]

If you pass library name to LIB scope without flag -l prefix, it strips lib. Normally, you do not need lib prefix when passing lib to GCC. It handles this automatically. See verbose output

xtensa-esp32-elf-g++ -o /tmp/pio-build/019a00f9fc/lolin32/firmware.elf -T esp32_out.ld -nostdlib -Wl,-static -u call_user_start_cpu0 -Wl,--undefined=uxTopUsedPriority -Wl,--gc-sections -Wl,-EL -T esp32.common.ld -T esp32.rom.ld -T esp32.peripherals.ld -T esp32.rom.spiram_incompatible_fns.ld -u ld_include_panic_highint_hdl -u __cxa_guard_dummy -u __cxx_fatal_exception /tmp/pio-build/019a00f9fc/lolin32/src/Blink.cpp.o -L/tmp/pio-build/019a00f9fc/lolin32 -L/Users/ikravets/.platformio/packages/framework-arduinoespressif32/tools/sdk/lib -L/Users/ikravets/.platformio/packages/framework-arduinoespressif32/tools/sdk/ld -Wl,--start-group /tmp/pio-build/019a00f9fc/lolin32/libFrameworkArduinoVariant.a /tmp/pio-build/019a00f9fc/lolin32/libFrameworkArduino.a -lgcc -lopenssl -lbtdm_app -lfatfs -lwps -lcoexist -lwear_levelling -lesp_http_client -lhal -lnewlib -ldriver -lbootloader_support -lpp -lmesh -lsmartconfig -ljsmn -lwpa -lethernet -lphy -lapp_trace -lconsole -lulp -lwpa_supplicant -lfreertos -lbt -lmicro-ecc -lcxx -lxtensa-debug-module -lmdns -lvfs -lsoc -lcore -lsdmmc -lcoap -ltcpip_adapter -lc_nano -lesp-tls -lrtc -lspi_flash -lwpa2 -lesp32 -lapp_update -lnghttp -lspiffs -lespnow -lnvs_flash -lesp_adc_cal -llog -lsmartconfig_ack -lexpat -lm -lc -lheap -lmbedtls -llwip -lnet80211 -lpthread -ljson -lstdc++ -Wl,--end-group

I think you can just generate -l{NAME} for all libraries. In this case, SCons will not touch library names and do any strips.

[me-no-dev]

it should not strip "lib" unless a file extension is provided. I will add the "-l", but IMHO this should be fixed in SCons