Firmware Upgrade - DCT Question

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

cross mob
Anonymous
Not applicable

I have a unit that was running my firmware based off of WICED-SDK-3.3.0.  I have ported my firmware to 3.5.2.  However, when I took the 3.3.0 image and wrote only the application code, I saw that the device would not connect to the wireless access point-- the debug was showing the AP SSID had extended ASCII characters in it.  I opened up the two DCT images (the one from the 3.3.1 build and the one from the 3.5.2), and it looks like there is an 8-byte offset in the first ~32 bytes.  Haven't looked through the DCT .c files to figure out where the change is.

My question is: how do you handle firmware upgrade (eg, OTA) and maintain DCT compatability?  I am tempted to move all my configuration variables into a text-based configuration file, so that it is extensible and there are not binary incompatibilities as we add capabilities (and configuration options).  However, the AP credentials are stored in the DCT.

Is there a  best practice for handling the firmware upgrade and not bricking in-field devices due to differences in DCT?

Thanks!

0 Likes
1 Solution
Anonymous
Not applicable

First this is not correct. We do always provide bug fixes for older SDKs for customers who are actually shipping product in the field. We may not release all the fixes to the community, but in most cases when a customer in the community faces a similar problem we do provide the way for the customer to fix the problem. You can search across the community and see many many cases where we have given specific patches to fix a known issue in an SDK.

Yes it is correct that in general we don't release full patches to SDKs since our goal with the community releases is to minimize the number of variants of SDKs that are being used.

Our patching for SDKs for the community essentially bumps up the SDK revision

So SDK 3.5.2 is a bug fix patch to SDK 3.3.1 (however it does also add new features, so that is where the current reported issue arises).

We are aware of the SDK OTA update issue and are working on a solution that would allow any customer using SDK 3.1.2 or SDK 3.3.0 which were our formal production SDKs to update to a newer SDK. Currently this is planned for SDK 3.6.3 due in May

View solution in original post

17 Replies
AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

This report shows a problem because it means existing users using old SDK

cannot upgrade to image built with new SDK.

From reading the posts on the forum, it seems Broadcom

does not provide bug fixes for older SDK versions.

This means once using a given version of SDK to make product, it's possible

that the user cannot upgrade to new SDK and cannot get bug fixes.

I realize this is a *big* problem especially some bug fixes in library are

released in binary which means the user even cannot backport bug fix

from new SDK by himself.

Anonymous
Not applicable

First this is not correct. We do always provide bug fixes for older SDKs for customers who are actually shipping product in the field. We may not release all the fixes to the community, but in most cases when a customer in the community faces a similar problem we do provide the way for the customer to fix the problem. You can search across the community and see many many cases where we have given specific patches to fix a known issue in an SDK.

Yes it is correct that in general we don't release full patches to SDKs since our goal with the community releases is to minimize the number of variants of SDKs that are being used.

Our patching for SDKs for the community essentially bumps up the SDK revision

So SDK 3.5.2 is a bug fix patch to SDK 3.3.1 (however it does also add new features, so that is where the current reported issue arises).

We are aware of the SDK OTA update issue and are working on a solution that would allow any customer using SDK 3.1.2 or SDK 3.3.0 which were our formal production SDKs to update to a newer SDK. Currently this is planned for SDK 3.6.3 due in May

It's good to know Broadcom provides bug fixes for older SDKs for customers

who are actually shipping product in the field.

But I don't think current way works well as you mentioned that

"SDK 3.5.2 is a bug fix patch to SDK 3.3.1".

AFAICT, the difference between 3.5.2 and 3.3.1 is too big.

It includes data structure change, API change and many code refactor and new features.

The problem is new code can lead to new bug and regression.

I would expect/suggest Broadcom to release 3.3.1 -> 3.3.2 -> 3.3.3 -> 3.3.4... for *bug fix ONLY*.

Then 3.3.x -> 3.4.x -> 3.5.x -> 3.6.x -> 3.7.x... for new features/new platforms.

*Don't mix new feature release with bug fix release*.

And don't limited bug fixes for customers with shipping products.

If Broadcom can maintain *bug fix only* releases, everyone get benefits.

Anonymous
Not applicable

Our expectation is that customers who have started on 3.3.1 and want to stay on that branch will stay there and only pick bug fixes relevant to them by posting on the community or via our formal support channels - distributors and partners

And customers who have not yet gone to production and want to pick up new features will move to the newer SDKs

We do provide incremental bug fixes within a SDK line where the bug fixes affect a majority of customers

So for example 3.5.0 3.5.1 and 3.5.2 were all released

And similarly for some of you 3.6.0 3.6.1 3.6.2 and 3.6.3 will be relevant

The 3.3.1 series of SDKs did not have major bug fix releases and only minor patches were issued and hence there was never a formal release of 3.3.2 as a bug fix only SDK

Anonymous
Not applicable

Hi nsankar,

Thanks for the comments about how Broadcom supports manufacturers shipping units.  I've been impressed with the level of support in this forum.

Can you add more context on what version should be standardized on?-- what SDK versions may be considered Long Term Support?  It sounds like 3.6.3 may be the best version to target for our product launch?  We transition to mass production in June.

Thanks!

0 Likes

nsankar wrote:

We do provide incremental bug fixes within a SDK line where the bug fixes affect a majority of customers

I'm afraid this is not true.

All previous SDKs have problem connecting to IIS server using TLSv1.2, but I don't know any fix available for the older SDKs.

0 Likes

Our expectation is that customers who have started on 3.3.1 and want to stay on that branch will stay there and only pick bug fixes relevant to them by posting on the community or via our formal support channels - distributors and partners

nsankar Agreed that it's best to stay on the same 'line', given the incompatibilities between 3.x versions, but in reality, upgrades are unavoidable if customers want to take advantage of newer features. Since SDKs aren't built with upgradability in mind, it makes for those who do want to upgrade a little painful.

With respect to bugs and patches, there's no easy way to find those, other than searching hard and often.

Sometimes I don't know what to search for, especially when the issue or symptom isn't obvious nor clearly defined.

I could very well be mistaken, and if so, could someone point me in the right direction? This forum used to have dedicated subspaces for bug reports, different versions, etc., presumably for easier searching, but those were rarely used and removed altogether -- makes sense since forums aren't a great way to track bugs in the first place *wink wink*.

Can you point out where to find the *defines* you mentioned.

axel.in, most of the instructions and defines are in WICED/platform/include/platform_dct.h

nsankar wrote:

We are aware of the SDK OTA update issue and are working on a solution that would allow any customer using SDK 3.1.2 or SDK 3.3.0 which were our formal production SDKs to update to a newer SDK. Currently this is planned for SDK 3.6.3 due in May

Hi nsankar

I found below thread:

https://community.broadcom.com/message/22702#22702

I remove all the new fields introduced in new SDK.

But OTA from SDK-3.1.2 to SDK-3.5.2 still fails.

(OTA from SDK-3.5.2 image to the image built on the same SDK version works.)

Do you have a summary about the OTA update issue in additional to DCT change?

If you can provide more information about the OTA issue, I will try to

fix it myself.

0 Likes
Anonymous
Not applicable

We would not recommend you use 3.5.2 for the platforms you are currently working on

0 Likes

nsankar wrote:

We would not recommend you use 3.5.2 for the platforms you are currently working on

Well, then I have no choice but waiting for next 3.6.x release.

0 Likes

nsankar wrote:

We would not recommend you use 3.5.2 for the platforms you are currently working on

When test OTA from 3.1.2 to 3.5.2 with BCM4390 platform.

If found it always hangup at wwd_bus_enable_dma_interrupt().

On 4390, host_platform_bus_enable_interrupt() is binary release.

Just in case this is not a known issue, so report here.

Hope this will also be fixed in next release.

0 Likes

nsankar wrote:

We are aware of the SDK OTA update issue and are working on a solution that would allow any customer using SDK 3.1.2 or SDK 3.3.0 which were our formal production SDKs to update to a newer SDK. Currently this is planned for SDK 3.6.3 due in May

I'm pretty sure the OTA won't work because the data structure of platform_dct_data_t is different between 3.7.0 and older SDKs.

Please explain how to upgrade 3.1.2 or 3.3.0 to the latest SDK (3.7.0).


0 Likes

As far as I can see, a series of defines is used to indicate to 3.7.0, which platform dct header is used on the "original" bootloader. The application converts the old dct structure to match the new rules defined in 3.7.0 and keeps the header in the format needed for the bootloader.

0 Likes

Can you point out where to find the *defines* you mentioned.

Thanks.

0 Likes

I have seen some of them In the platform dct files inside the WICED folder. I have not found  any documentation for this yet.

0 Likes

I want to take a look at the code.

But I don't know which *define* you mean.

0 Likes
Anonymous
Not applicable

3.3.1 for all platforms


3.5.2 for 43362 and 43340 only


3.6.3 for all platforms