Upgrade SDK in the field, 3.1.2 -> 6.x.x

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

cross mob
user_108962310
Level 4
Level 4
10 likes received 10 likes given 5 likes given

I asked a question about this a while back, but I am closer to a real deployment now:
I need to update products in the field that are based on the 3.1.2 SDK to the same app built with a new version of the SDK, to get all the latest bugfixes, to try to improve connection reliability, and to cover any known exploits.

I'd like to know if the Cypress folks have any input on a plan for how to accomplish this. The hard part are the little details about upgrading the WiFi FW binary asset.

I have verified that an app ported to the new SDK will indeed boot up with an older version of the WiFi Firmware stored in the sflash. This was the biggest concern.
I have also verified that using the UPDATE_FROM_SDK=3_1_2  APP_USED_BT=1 flags work with the existing 3.1.2 bootloader and the existing app DCT with all our security keys and per-device info survives (or it may be copied or moved internally, I did not go into the deep details).


So the plan is:
1) Update to the new app based on SDK 6.x.x via OTA (not Cypress OTA, but the ELF image is downloaded and stored to sflash in ELF format)
2) New app rewrites the headers in sflash to create space for the new WiFi Firmware asset; existing layout for critical sections remain unchanged (FR app, wifi firmware sections)

3) New app functions as normal on the old Wifi FW

4) New app downloads the new WiFi FW asset at some future time
5) New app does MD5 hash of old WiFi FW and new WiFi FW to ensure that both assets are safely aboard
6) New app erases the old WiFi FW section, copies in the new Wifi FW, does a system reboot.

7) Device should reboot using new WiFi FW and new SDK app

(fallback) If wiced Init not SUCCESS on boot, wiced wlan de-init, erase wifi_fw section and re-do copy, reboot

A thumbs-up on the soundness of this plan from a Cypress employee would be very helpful. Is there anything I am overlooking?

The X factor that I am not sure of is the "NVRAM" header that is part of the platform definition. Are these updatable in the field? Is it expected to need to update the NVRAM parameters with a WiFi FW upgrade for the same hardware?

0 Likes
1 Solution
PriyaM_16
Moderator
Moderator
Moderator
250 replies posted 100 replies posted 50 replies posted

Hello Andrew,

The outline you mentioned for updating the application firmware and wifi firmware sounds good. I believe you are aware that while upgrading the firmware, you also need to include the clm blob file. The clm blob was earlier a part of firmware but now there are two files: firmware + blob.

In step 5) New app does MD5 hash of old WiFi FW and new WiFi FW to ensure that both assets are safely aboard.

This involves computing the MD5 hash of downloaded firmware and comparing it with the downloaded hash of the firmware direclty  to ensure the data integrity.

The NVRAM parameters do not chnage for different firmware versions. So there is no need to update nvram params.

View solution in original post

5 Replies
PriyaM_16
Moderator
Moderator
Moderator
250 replies posted 100 replies posted 50 replies posted

Hello Andrew,

The outline you mentioned for updating the application firmware and wifi firmware sounds good. I believe you are aware that while upgrading the firmware, you also need to include the clm blob file. The clm blob was earlier a part of firmware but now there are two files: firmware + blob.

In step 5) New app does MD5 hash of old WiFi FW and new WiFi FW to ensure that both assets are safely aboard.

This involves computing the MD5 hash of downloaded firmware and comparing it with the downloaded hash of the firmware direclty  to ensure the data integrity.

The NVRAM parameters do not chnage for different firmware versions. So there is no need to update nvram params.

@riya thanks for the feedback.

For the clm blob file: I am using a 43362 radio, which does not appear to have an associated clm_blob file in the resources/ directory.

Are there any special actions that I will need to take?

One concern is that this platform uses a custom implementation of `wwd_bus_write_wifi_firmware_image` provided by the module vendor.

On the MD5 issue:
Yes, the MD5 at download time will be checked against the MD5 provided as part of the HTTP response header, as the data comes out of the TCP stream.
But I am still going to separately do steps for verifying the image as it sits in the flash memory, as final gates before the erase & copy step.

0 Likes

user_108962310 wrote:

@riya thanks for the feedback.

For the clm blob file: I am using a 43362 radio, which does not appear to have an associated clm_blob file in the resources/ directory.

Are there any special actions that I will need to take?

You should be aware the softAP now only supports 2 clients for 43362.

https://community.cypress.com/message/145342#145342

0 Likes

Thanks for brining that to my attention. I'm not using any SoftAP in the current application, so that should not be a limitation here.

0 Likes
AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

user_108962310 wrote:

I asked a question about this a while back, but I am closer to a real deployment now:
I need to update products in the field that are based on the 3.1.2 SDK to the same app built with a new version of the SDK, to get all the latest bugfixes, to try to improve connection reliability, and to cover any known exploits.

I'd like to know if the Cypress folks have any input on a plan for how to accomplish this. The hard part are the little details about upgrading the WiFi FW binary asset.

I have verified that an app ported to the new SDK will indeed boot up with an older version of the WiFi Firmware stored in the sflash. This was the biggest concern.
I have also verified that using the UPDATE_FROM_SDK=3_1_2  APP_USED_BT=1 flags work with the existing 3.1.2 bootloader and the existing app DCT with all our security keys and per-device info survives (or it may be copied or moved internally, I did not go into the deep details).

The main problem of UPDATE_FROM_SDK=x.x.x thing is when you have to upgrade firmware multiple times,

you don't know the bootloader version of the original device.

e.g.

Assume the old devices built with SDK 3.1.2 with application firmware version v1.0.0.

When you have new firmware built with new SDK (assume 5.1) and want to relase to your customers:

Now some new devices relase with SDK 5.1, and the application firmwre is v1.1.0.

Some devices are upgraded by UPDATE_FROM_SDK=3_1_2 to application firmware v1.1.0.

If you want to upgrade again to sdk 6.0.1, you have no idea how to differentiate

above 2 kind of devices because the application firmware is the same but bootloader is different.

i.e. you don't know which device should use UPDATE_FROM_SDK=3_1_2 or UPDATE_FROM_SDK=5_1_0.

Then the firmware management just become a mess.