Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OTA] Fix "Error response from device" if OK response comes to early #1695

Merged
merged 1 commit into from
Jul 30, 2018

Conversation

Gei0r
Copy link
Contributor

@Gei0r Gei0r commented Jul 29, 2018

Using OTA with platformio, I sometimes get an error like this:

20:14:21 [DEBUG]: Options: {'timeout': 10, 'esp_ip': '192.168.178.45', 'host_port': 44255, 'image': '.pioenvs\\d1_mini\\spiffs.bin', 'host_ip': '0.0.0.0', 'auth': '', 'esp_port': 8266, 'spiffs': True, 'debug': True, 'progress': True}
20:14:21 [INFO]: Starting on 0.0.0.0:44255
20:14:21 [INFO]: Upload size: 1028096
Sending invitation to 192.168.178.45
20:14:21 [INFO]: Waiting for device...
Uploading: [============================================================] 100% Done...

20:14:39 [INFO]: Waiting for result...
20:14:39 [INFO]: Result:
20:14:39 [INFO]: Result:
20:14:39 [INFO]: Result:
20:14:39 [INFO]: Result:
20:14:39 [INFO]: Result:
20:14:39 [ERROR]: Error response from device
*** [uploadfs] Error 1

On investigation I found that the target does send "OK" via TCP. However, espota.py does not receive the OK, because it has been "swallowed up" by an earlier call to recv().

This pull request skips the "wait for OK response" if "OK" has already been received in the last call to recv().

Because TCP is stream-based, an earlier read can 'take away' the "OK" response
from the device, so that a later read doesn't get the message.
@me-no-dev me-no-dev merged commit bdc45e3 into espressif:master Jul 30, 2018
@me-no-dev
Copy link
Member

Nice :) Thanks! I've been having this in my to-do list for some time... have not got to it yet :) you saved it!

Curclamas pushed a commit to Curclamas/arduino-esp32 that referenced this pull request Aug 21, 2018
…spressif#1695)

Because TCP is stream-based, an earlier read can 'take away' the "OK" response
from the device, so that a later read doesn't get the message.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants