BT addon upgrade - timeout too short?

[benjaminaigner]

On some of the ~25 upgraded FABI modules with the ESP32 addon, the update didn't work as expected from the WebGUI:

BT addon update failed because: OTA:$FIN not received.

I think the problem might be a too tight timeout for receiving "OTA:$FIN". Normally, this wouldn't be the problem, but
AT SR is sent immediately after the timeout, which might break the ESP32 update procedure.

@klues I will give you that exact FABI next time.

[klues]

Timeout is 15 seconds, defined here: https://github.com/asterics/Addon-Bluetooth-WebGUI/blob/main/webgui/js/communication/ATDevice.js#L206
You can change it, if you want.
I can also change the behaviour so that AT SR is only sent after a successful upgrade.

[benjaminaigner]

👍 THX for the hint, I will have a look!

[klues]

Did you test with a longer timeout? Currently I'm sending AT SR in a finally-block, so in any case in order to restore GUI-functionalities that are dependent on live values. So I think we should just increase the timeout and not change the AT SR behaviour.

What timeout should be sufficient?

[benjaminaigner]

What timeout should be sufficient?
Hard to say, it depends on the binary size and even on the chip revision.

I think your implementation with the finally is the correct choice,
maybe we should increase the timeout. 20s seems very long,
but the GUI is not waiting that long if the "FIN" string is received...

[klues]

OK, I've increased it to 20s: 1db2bb8 - should already be live. Why can this take so long, whats happening in the background? In my current test it took about 5 seconds, how could it happen that it sometimes takes >15 seconds? Maybe the transmission speed is a littlebit too fast and so sometimes the upgrade fails and waiting for OTA:FIN runs into a timeout?! See the throttling code here: https://github.com/asterics/Addon-Bluetooth-WebGUI/blob/main/webgui/js/adapter/sercomm.js#L93
I'm sending chunks of 2048 bytes and then waiting for 50ms. These values I've just found out by trial and error.

[klues]

Hint: for testing purposes you can open the browser console and run logReceived = true in order to get the received raw values logged and see what response is received where "OTA:FIN" is supposed.

[benjaminaigner]

Hint: for testing purposes you can open the browser console and run logReceived = true in order to get the received raw values logged and see what response is received where "OTA:FIN" is supposed.

THX!

Regarding the transmission size: this could be the problem as well.
I'm sending 128Bytes with 10ms delays:
https://github.com/asterics/esp32_addon_bootloader/blob/b803e2d336759a2793094c209ccb36b7a3e2f7d5/update.py#L38

[klues]

OK, then I'll adapt this as well. However your speed is 12,8B/ms and mine is 40,96B/ms - much faster and seems to also work for most cases. So maybe we should use something like 30B/ms?! Do you know what's the limiting factor here?

Edit: Ah, just realized that you're using FABIs and I'm testing with the FLipMouse. So we could simply use two different speeds for both...

[klues]

Changed BT upgrade speeds to:

• FLipMouse: 256B chunk / 10ms pause -> 25,6B/ms
• FABI: 128B chunk / 10ms pause -> 12,8B/ms

Tested both several times and seemed to work.

Additionally added a global variable which can be used to show the upgrade button, even if BT module version is not found or latest:

1. open browser console and write showUpgradeButton = true;
2. go to "Tab General" or switch to other tab and go back to "Tab General" in order to let the variable take effect.