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
[LTE/Electron] Fast OTA Fixes [ch16346] #1558
Conversation
system/src/system_task.cpp
Outdated
@@ -310,7 +310,7 @@ void establish_cloud_connection() | |||
cellular_device_info(&device, NULL); | |||
if (device.dev == 8/*DEV_SARA_R410*/) { | |||
DEBUG("Device is SARA_R410, disabling Fast OTA!"); | |||
CLOUD_FN(spark_set_connection_property(particle::protocol::Connection::FAST_OTA, 0/*disabled*/, nullptr, nullptr), (void)0); | |||
CLOUD_FN(spark_set_connection_property(particle::protocol::Connection::FAST_OTA, 1/*disabled*/, nullptr, nullptr), (void)0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need this, given that FastOTA is enabled by default? (I'm assuming 1 means Enabled, despite the succeeding comment.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, I just flipped the 0 to 1 for quick Fast OTA testing.
We wouldn't need this code any longer, but I wonder if we should create a Wiring API to allow users to toggle this if they so desired. Although after all of these fixes get implemented I can't think of a reason anyone would want to OTA update slower. Once we test and it looks good though, we can just remove this code, since we have the history in github. No need to even leave it commented out.
…unks received, plus a small growth factor. This ensures that when the network drops many of the chunks sent by the server, that the device requests fewer chunks.
- Wait for confirmable messages to be sent (fixes resetting too soon which was causing the server to hang around for 16 minutes) - Also remove extra UpdateDone sent from device (fixes a race condition of how we complete Fast OTA) - If a CHUNK or UPDATE_DONE CoAP message is received when we don't expect it, instead of forcing an INVALID_STATE error, simply throw NO_ERROR to give a silent error. TODO: Return to throwing INVALID_STATE once we add a method to know when the server receives the UpdateDone ACK we send. This is so we can properly call reset_updating() after we are done and we also know the server is done with the Fast OTA process.
54e627c
to
72a80b8
Compare
@@ -299,7 +279,11 @@ ProtocolError ChunkedTransfer::handle_update_done(token_t token, Message& messag | |||
{ | |||
updating = 2; // flag that we are sending missing chunks. | |||
DEBUG("update done - missing chunks starting at %d", index); | |||
error = send_missing_chunks(channel, MISSED_CHUNKS_TO_SEND); | |||
chunk_index_t increase = std::max(chunk_index_t(chunk_count*0.2),chunk_index_t(2u)); // ensure always some growth | |||
chunk_index_t resend_chunk_count = std::min(std::max(2u,unsigned(chunk_count+increase)), MISSED_CHUNKS_TO_SEND); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize this is my code, but written quickly to try out the concept, and on review I see we can make it a little clearer:
resend_chunk_count
can be simplified
std::max(2u,unsigned(chunk_count+increase)
can be simply unsigned(chunk_count+increase)
since it's guaranteed to have a non-zero lower limit (currently 2).
We could add a symbol for MINIMUM_CHUNK_INCREASE = chunk_index(2u)
to avoid magic numbers in the code.
Problem
Solution
Steps to Test
Serial1LogHander logHandler(115200, LOG_LEVEL_ALL);
in the Tinker app.Test App
Completeness