- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm trying to track down an issue where my units are being "bricked" during OTA update (ota, not ota 2.)
Running Wiced 3.7.0.7 on a custom board, with an ST32F205 micro and a USI BM13 SIP.
I can reproduce it with the Firefox browser, but not in Chrome. Have had some reports of Chrome having the same issue, but can't reproduce.
With Firefox, instead of it uploading 1024 byte chunks as expected, it uploads two smaller chunks to the same chunk index, like:
Writing chunk 34 of size 742 from offset 33792
Writing chunk 34 of size 282 from offset 34534
Writing chunk 35 of size 742 from offset 34816
Writing chunk 35 of size 282 from offset 35558
Writing chunk 36 of size 742 from offset 35840
Writing chunk 36 of size 282 from offset 36582
Writing chunk 37 of size 742 from offset 36864
Writing chunk 37 of size 282 from offset 37606
Writing chunk 38 of size 742 from offset 37888
Writing chunk 38 of size 282 from offset 38630
Writing chunk 39 of size 742 from offset 38912
Writing chunk 39 of size 282 from offset 39654
Writing chunk 40 of size 742 from offset 39936
Writing chunk 40 of size 282 from offset 40678
This results in the microcontroller firmware having corrupted memory, with a number of bytes showing as 0xFF starting from even addresses, spaced every 1024 bytes.
Chrome will show the chunk size as 1024 bytes and one write to each chunk index, and works fine in testing.
Has anyone experienced this before? Or have any ideas as to why Firefox and Chrome behave differently?
Solved! Go to Solution.
- Labels:
-
Over The Air Updates (OTA)
-
SDK 3.x
- Tags:
- ota
- sdk 3.7.0-7
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
WICED 3.7 is very old version and it will be difficult for us to reproduce the issue.
Can you please try with newer SDK, WICED 6.4 and let us know if you're facing the issue.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Adding some more info:
- Firefox sends the XMLhttp POST in 2 frames; one with header and 742 bytes of payload, and then the remaining 295 bytes of the payload in a second frame.
- Chrome sends the header as one frame, and the full 1024 bytes of payload as a second frame.
It looks like wiced_framework_app_write_chunk() isn't handling the first case properly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
More info: the AVG Free antivirus software "web shield" component makes Chrome/Edge browsers also "brick" modules.
It looks like the network analysis that it does changes the packetisation to be similar to Firefox, with header and partial payload appended into a single frame.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
WICED 3.7 is very old version and it will be difficult for us to reproduce the issue.
Can you please try with newer SDK, WICED 6.4 and let us know if you're facing the issue.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tested on 6.4, and it worked OK. Not able to reproduce.
I have a few thousand units in the field on V3.7. I will just have to work around it via Chome and Antivirus disable.