Esp8266 Ota Bad Path Sloeber v4.4

[BriscoeTech]

Hello Everyone,

I am currently running Sloeber 4.4 on windows and trying to programm an esp8266 via OTA. This project was created in v4.3 and ported into v4.4, and now OTA is no longer working. Same error occurs when using esp8266 core v2.6.3 or v3.0.2

here is the error I am getting in the console window when trying to upload the code via ota

---

Starting upload
Uploading project "Esp_MQTT_LightSensor" with "esptool"
no reset because we are using network upload

Launching: -I C:\Sloeber-v4.4\arduinoPlugin\packages\esp8266\hardware\esp8266\3.0.2/tools/espota.py -i Light-Sensor.local -p 8266 --auth=no_pwd_found_in_code -f C:\sloeber-workspace-esp\Esp_MQTT_LightSensor\Release/Esp_MQTT_LightSensor.bin
Output:
Cannot run program "" (in directory "C:\sloeber-workspace-esp"): CreateProcess error=87, The parameter is incorrect
failed to upload "L/Esp_MQTT_LightSensor/Esp_MQTT_LightSensor}/Release/Esp_MQTT_LightSensor.hex"

---

What is very strange is the failed to upload line, the path is completely wrong

L/Esp_MQTT_LightSensor/Esp_MQTT_LightSensor}

It appears something is not being interpreted correctly somewhere, because there is a unmatched }
Also Esp_MQTT_LightSensor/Esp_MQTT_LightSensor is not how my project is organized, and have no L directories or drives.

Here is a screenshot of the CreateProcess error

[jantje]

I can confirm the issue.
It is indeed a regression introduced in 4.4
It is a similar issue to #1364
To workaround edit the platform.txt in the tools.esptool.upload.network_pattern where it states network_cmd change that to tools.esptool.network_cmd
delete the platform.sloeber.txt
goto you project properties->arduino select apply and close
There may be other issues but I have no means of testing
So please test this workaround and feed back

[BriscoeTech]

Thanks for the quick reply :-)

That did the trick, it compiled and uploaded right away. I have not noticed any other problems. Ill keep an eye on these threads and am willing to test the next version that addresses these issues.

Here is a screenshot for the exact change I made if anyone has questions

[jantje]

Thanks for the feedback
I'm trying to setup something so I can do regression testing before I start changing the workaround code again.
Once I have this basis I can modify the workaround code with more confidence

[jantje]

This one should be fixed in the nightly after the next nightly build.

[mduchain]

I just had the same issue on NodeMcu-32S (espressif esp32 board) with Sloeber v4.4.0 win64 2021-07-04-48-31.
Work-around fixed the issue.
One of the labels of the issue states "board specific"; does this mean you prefer I open a specific issue against the ESP32 or this comment is sufficient even if the issue is closed?

[jantje]

Board specific means not all boards have this issue.
So no need to create another issue.

[ianr34]

I had this issue (all the ones that link back to this number - ie esp32 won't upload as arguments aren't there) with 4.4, so downloaded the latest nightly and it was still there. Though the edit ("tools.esptool_py.upload.pattern="{path}/{cmd}" {tools.esptool_py.upload.pattern_args}" DID fix it.

It might be worth getting this fix up asap, or semi technical people will try it once for the esp32, it will fail to upload, and they will give up..

[jantje]

@ianr34
Are you now saying it is fixed in the nightly or not.