Sloeber 4.4.0.202107240421 ESP32 2.0.0 RC1 esptool_py problem

[kayae]

Sloeber [4.4.0.202107240421]
Board: Wemos LOLIN
Compiles without a problem.
Serial upload fails with ESP32 2.0.0-RC1

---->

Starting upload
Uploading project "Test" with "esptool_py"

Launching: D:\Programs\Sloeber\arduinoPlugin\packages\esp32\tools\esptool_py\3.1.0/esptool.exe
Output:
esptool.py v3.1
usage: esptool [-h]
[--chip {auto,esp8266,esp32,esp32s2,esp32s3beta2,esp32s3beta3,esp32c3,esp32c6beta}]
[--port PORT] [--baud BAUD]
[--before {default_reset,usb_reset,no_reset,no_reset_no_sync}]
[--after {hard_reset,soft_reset,no_reset,no_reset_stub}]
[--no-stub] [--trace] [--override-vddsdio [{1.8V,1.9V,OFF}]]
[--connect-attempts CONNECT_ATTEMPTS]
{load_ram,dump_mem,read_mem,write_mem,write_flash,run,image_info,make_image,elf2image,read_mac,chip_id,flash_id,read_flash_status,write_flash_status,read_flash,verify_flash,erase_flash,erase_region,merge_bin,version,get_security_info}
...

esptool.py v3.1 - ESP8266 ROM Bootloader Utility

positional arguments:
{load_ram,dump_mem,read_mem,write_mem,write_flash,run,image_info,make_image,elf2image,read_mac,chip_id,flash_id,read_flash_status,write_flash_status,read_flash,verify_flash,erase_flash,erase_region,merge_bin,version,get_security_info}
Run esptool {command} -h for additional help
load_ram Download an image to RAM and execute
dump_mem Dump arbitrary memory to disk
read_mem Read arbitrary memory location
write_mem Read-modify-write to arbitrary memory location
write_flash Write a binary blob to flash
run Run application code in flash
image_info Dump headers from an application image
make_image Create an application image from binary files
elf2image Create an application image from ELF file
read_mac Read MAC address from OTP ROM
chip_id Read Chip ID from OTP ROM
flash_id Read SPI flash manufacturer and device ID
read_flash_status Read SPI flash status register
write_flash_status Write SPI flash status register
read_flash Read SPI flash content
verify_flash Verify a binary blob against flash
erase_flash Perform Chip Erase on SPI flash
erase_region Erase a region of the flash
merge_bin Merge multiple raw binary files into a single file for
later flashing
version Print esptool version
get_security_info Get some security-related data

optional arguments:
-h, --help show this help message and exit
--chip {auto,esp8266,esp32,esp32s2,esp32s3beta2,esp32s3beta3,esp32c3,esp32c6beta}, -c {auto,esp8266,esp32,esp32s2,esp32s3beta2,esp32s3beta3,esp32c3,esp32c6beta}
Target chip type
--port PORT, -p PORT Serial port device
--baud BAUD, -b BAUD Serial port baud rate used when flashing/reading
--before {default_reset,usb_reset,no_reset,no_reset_no_sync}
What to do before connecting to the chip
--after {hard_reset,soft_reset,no_reset,no_reset_stub}, -a {hard_reset,soft_reset,no_reset,no_reset_stub}
What to do after esptool.py is finished
--no-stub Disable launching the flasher stub, only talk to ROM
bootloader. Some features will not be available.
--trace, -t Enable trace-level output of esptool.py interactions.
--override-vddsdio [{1.8V,1.9V,OFF}]
Override ESP32 VDDSDIO internal voltage regulator (use
with care)
--connect-attempts CONNECT_ATTEMPTS
Number of attempts to connect, negative or 0 for
infinite. Default: 7.
The execution of command "3.1.0/esptool.exe" is done.

[jantje]

Updated: the remind issue was not #1363 but #1362
This reminds me of #1362
Which uploader do you use?

[BriscoeTech]

Looks like I also found the same issue

Which uploader do you use?

It looks like it is calling esptool_py 3.1.0

[jantje]

What json file do you use?
I use https://dl.espressif.com/dl/package_esp32_index.json and that one does not contain version 2.00-rc1

[jantje]

Note that I updated the remind reference above as it was wrong.
This reminds me of #1362

[BriscoeTech]

Ohh I see the confusion, yes we are using a different repo.
https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_dev_index.json

That repo houses all the current development and release candidates for the esp32, and right now is the only repo with the esp32-s2 candidate code. The other repo is the stable releases of the esp32 code. I just switched to the other repo and confirm that esp32 1.0.6 did work and was able to program a board no problem.

I just noticed another bug, will make a different ticket for that.

[ecobdoor]

Hello, I have similar problem on Eclipse 2021-06 Sloeber 4.4.0.202107110422 with

• https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json
• https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_dev_index.json

Arduino Upload Sketch menu launch python /home/myid/embedcpp-latest-released/eclipse/arduinoPlugin/packages/esp32/tools/esptool_py/3.1.0/esptool.py and fails...
I replace esptool.py (v3.1 from Sloeber plugin) by esptool.py (v3.2-dev from 2.0.0-rc1) in /home/myid/embedcpp-latest-released/eclipse/arduinoPlugin/packages/esp32/tools/esptool_py/3.1.0.
The project builds correctly, but Arduino Upload Sketch menu always fails... BUT when I launch the script below in terminal, Uploading is ok:

TOOL_PATH="/home/myid/embedcpp-latest-released/eclipse/arduinoPlugin/packages/esp32/tools"
HARD_PATH="/home/myid/embedcpp-latest-released/eclipse/arduinoPlugin/packages/esp32/hardware"
INO_NAME="000_Esp32_test-Serial"
BIN_PATH="/home/myid/cdt-master/ws/$INO_NAME/Release"
PORT="/dev/ttyUSB0"
BAUD="921600"
/usr/bin/python $TOOL_PATH/esptool_py/3.1.0/esptool.py
--chip esp32
--port $PORT
--baud $BAUD
--before default_reset
--after hard_reset
write_flash -z
--flash_mode dio
--flash_freq 80m
--flash_size detect
0xe000 $HARD_PATH/esp32/2.0.0-rc1/tools/partitions/boot_app0.bin
0x1000 $BIN_PATH/$INO_NAME.bootloader.bin
0x10000 $BIN_PATH/$INO_NAME.bin
0x8000 $BIN_PATH/$INO_NAME.partitions.bin

it is not practical,because we have to close serial monitor view in eclipse an to open again after sketch upload
Script is also running in post build command when serial monitor is close... It seems that parameters are not passed to esptool by Sloeber 4 for Esp32 boards. What to do? I believe Esp-Arduino 2.0.0 is based on Esp-IDF 4 and 1.0.6 on an older (may be a little bug).

Cordially yours...

[jantje]

I checked this problem and it is indeed a arduino IDE incompatibility introduced with Sloeber 4.4
In the platform.txt the upload pattern is defined as
tools.esptool_py.upload.pattern="{path}/{cmd}" {upload.pattern_args}
and in platform.Sloeber.txt it is defined as
tools.esptool_py.upload.pattern="${tools.esptool_py.path}/${tools.esptool_py.cmd}" ${upload.pattern_args}
but that should be
tools.esptool_py.upload.pattern="${tools.esptool_py.path}/${tools.esptool_py.cmd}" ${tools.esptool_py.upload.pattern_args}

If it works in Arduino IDE the easiest fix would be to change the platform.txt from
tools.esptool_py.upload.pattern="{path}/{cmd}" {upload.pattern_args}
to
tools.esptool_py.upload.pattern="{path}/{cmd}" {tools.esptool_py.upload.pattern_args}
I'm not sure this will work in Arduino IDE and there may be more instances like this.

The root cause is that Sloeber does not interpret tool patterns in the same way as Arduino IDE

The arduino configuration https://arduino.github.io/arduino-cli/latest/platform-specification/#sketch-upload-configuration states

The tool configuration properties are available globally without the prefix. For example, the tools.avrdude.cmd.path property can be used as {cmd.path} inside the recipe, and the same happens for all the other avrdude configuration variables.

Note that is says "can be used" and not "has to be used"
Sloeber does not interprete the key value pairs like Arduino IDE does and that makes it hard to extend cmd.path to tools.avrdude.cmd.path.

Pre Sloeber 4.4 sloeber searched for the existence of tools.avrdude.cmd.path at run time. However in Sloeber 4.4 all this processing is doen at the creation of platform.sloeber.txt at which time the "exists method" is not readily available .
Therefore Sloeber 4.4 only ads the tools.TOOL_NAME. for very specific variable names https://github.com/Sloeber/arduino-eclipse-plugin/blob/master/io.sloeber.core/src/io/sloeber/core/txt/WorkAround.java#L204

And this is why Sloeber does not expand {upload.pattern_args} in the upload command

[ecobdoor]

Thank you for your quick reply, it runs...

Launching: python /home/bigboss/embedcpp-latest-released/eclipse/arduinoPlugin/packages/esp32/tools/esptool_py/3.1.0/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0xe000 /home/bigboss/embedcpp-latest-released/eclipse/arduinoPlugin/packages/esp32/hardware/esp32/2.0.0-rc1/tools/partitions/boot_app0.bin 0x1000 /home/bigboss/cdt-master/ws/000_Esp32_test-Serial/Release/000_Esp32_test-Serial.bootloader.bin 0x10000 /home/bigboss/cdt-master/ws/000_Esp32_test-Serial/Release/000_Esp32_test-Serial.bin 0x8000 /home/bigboss/cdt-master/ws/000_Esp32_test-Serial/Release/000_Esp32_test-Serial.partitions.bin 

• After editing platform.sloeber.txt, restart Eclipse
• Rebuilding project is unnecessary

Question: will this patch lost after a esp32...index.json update, adding a new json or reattach?

Best regards

[jantje]

Editing platform.sloeber.txt is never final. The sloeber files are considered temporary files and will be created/deleted/updated as needed.

The Sloeber workaround is to delete platform.sloeber.txt and modify platform.txt
The line
tools.esptool_py.upload.pattern="{path}/{cmd}" {upload.pattern_args}
to
tools.esptool_py.upload.pattern="{path}/{cmd}" {tools.esptool_py.upload.pattern_args}
Then goto you project properties -> arduino->apply and close
or close and open the project
or close and open sloeber

If the change in platform.txt also works in Arduino IDE I propose this as the fix for the problem

[jantje]

I'm closing this issue as a duplicate of #1371 which is fixed in the nightly

[rmerriam]

If running on Linux the next line needs to be changed to:

tools.esptool_py.upload.pattern.linux=python "{path}/{cmd}" {tools.esptool_py.upload.pattern_args}