OTA issues, particularly with Firefox

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
GrSm_2135731
Level 2
Level 2
First like received

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?

0 Likes
1 Solution

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.

View solution in original post

4 Replies
GrSm_2135731
Level 2
Level 2
First like received

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.

0 Likes
GrSm_2135731
Level 2
Level 2
First like received

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.

0 Likes

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.

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.

0 Likes