OTA Update ( from 3.7.0 to 5.0.0 ) : modification of DCT structure

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

cross mob
Anonymous
Not applicable

Hello,

I was running a unit on WICED-SDK-3.7.0 but after upgrading WICED to 5.0.0 I face some problems running it,

however I see a difference in the DCT section as mentioned below .I saw also other discussion about an offset in DCT_APP_SECTION. , which I supppose is creating a problem

/* OLD DCT section */

typedef enum

{

    DCT_APP_SECTION,

    DCT_SECURITY_SECTION,

    DCT_MFG_INFO_SECTION,

    DCT_WIFI_CONFIG_SECTION,

    DCT_INTERNAL_SECTION, /* Do not use in apps */

    DCT_ETHERNET_CONFIG_SECTION,

    DCT_NETWORK_CONFIG_SECTION,

    DCT_BT_CONFIG_SECTION,

    DCT_P2P_CONFIG_SECTION,

    DCT_OTA2_CONFIG_SECTION,

    DCT_VERSION_SECTION, /* Do not use in apps */

} dct_section_t;

/* NEW DCT section */

typedef enum

{

    DCT_APP_SECTION,

   DCT_HK_INFO_SECTION,

    DCT_SECURITY_SECTION,

    DCT_MFG_INFO_SECTION,

    DCT_WIFI_CONFIG_SECTION,

    DCT_INTERNAL_SECTION, /* Do not use in apps */

    DCT_ETHERNET_CONFIG_SECTION,

    DCT_NETWORK_CONFIG_SECTION,

    DCT_BT_CONFIG_SECTION,

    DCT_P2P_CONFIG_SECTION,

    DCT_OTA2_CONFIG_SECTION,

    DCT_VERSION_SECTION, /* Do not use in apps */

    DCT_MISC_SECTION,

} dct_section_t;

Is there a  best practice for saving my old configuration before the update and restore it after ( due to differences in DCT )?

Also, I found this morning a new version of WICED (5.0.1) with this modifications :

   * [all WiFi] Speed up DCT reads by keeping track of current DCT verification

   * [all WiFi] Updated DCT padding to be multiple of 8-bytes for backward compatibility in OTA2

It is amendment can solve my problem ?

0 Likes
10 Replies
user_2177781
Level 5
Level 5
25 likes received 10 likes received 5 likes given

I think 5.0.0 should be able to handle an old DCT structure with the right defines. In WICED>platform>include>platform_dct.h, there is a define for DCT_BOOTLOADER_SDK_3_7_0 and it seems that the DCT functions will automatically try to update the DCT structure to the newest version, but I have not yet tried this out my self, since I'm still battling a custom DCT structure.

As far as I can see in the code DCT_HK_INFO_SECTION references the same adress as the DCT_APP_SECTION and regards to the offset, when running homekit, a offset is needed to allow for HomeKit data to be stored, so if you do not use HomeKit, then just ignore the DCT_HK_INFO_SECTION.

FYI: WICED 5.1.0 has also been released

0 Likes

renejos wrote:

I think 5.0.0 should be able to handle an old DCT structure with the right defines. In WICED>platform>include>platform_dct.h, there is a define for DCT_BOOTLOADER_SDK_3_7_0 and it seems that the DCT functions will automatically try to update the DCT structure to the newest version, but I have not yet tried this out my self, since I'm still battling a custom DCT structure.

No, it won't work in practice.

The SDK assumes people knows to OTA from a given old version to a new version.

But that is not true.

For example, Assume a product using SDK_3_6_1 release to market.

At some point, I make new version so the users can OTA to SDK_3_7_0.

Now some users are using SDK_3_6_1 and some users are using SDK_3_7_0.

If I have new release base on SDK_5_0_0, I have no idea which user is using

which version. And I have to make 2 kind of OTA images:

one for SDK_3_6_1 to SDK_5_0_0, the other one for SDK_3_7_0 to SDK 5_0_0.

It's a mess.

I can only suggest cypress "do not break DCT compatibility".

Once a product release to market, it's very important to keep compatibility.

The issue is the bootloader, since this can not be updated, all DCT data used by the bootloader cannot change and must match whatever structure the bootloader has been compiled to know.

But I agree, introducing a non-liniear update path with no control of the updates makes this very challenging.

0 Likes
Anonymous
Not applicable

Thank you for your reply,

The problem seems to come from the DCT_APP_SECTION (and not because of the DCT difference),

I store three variables in the DCT_APP_SECTION used in my project in wiced 3.7.0.
When I download the project with wiced 5.0.0 Framework without changing the DCT,

I cannot use the variables because they are shifted

.
( I printed DCT_APP_SECTION with the wiced reading functions to be clear )

OLD APP SECTION (All values are in the right place)
isConfigured : 1<\r><\n>
  id : 37 36 33 36 33 35 51 18 00 21 00 3d <\r><\n>
  key : 36 66 65 33 65 35 38 30 63 62 39 63 34 31 62 31 61 65 61 <\r><\r><\n>

NEW APP SECTION (values of variable are shift)
Application Section<\r><\n>
isConfigured : 255<\r><\n>
  id : ff ff ff 36 37 36 33 36 33 35 51 18 <\r><\n>
  key : 00 21 00 3d 36 66 65 33 65 35 38 30 63 62 39 63 34 31 62 <\r><\r><\n>

Is there a  best practice for saving my old configuration before the update and restore it after ?

0 Likes

The shift could be caused by changes in the other DCT sections.

I assume the software is already running on some devices, making it hard to store the data before an update?

0 Likes
Anonymous
Not applicable

The software is already running in some devices,

Also, I found this morning a new version of WICED (5.1.0) with this modifications :

   * [all WiFi] Speed up DCT reads by keeping track of current DCT verification

   * [all WiFi] Updated DCT padding to be multiple of 8-bytes for backward compatibility in OTA2

It is amendment can solve my problem ?

0 Likes

jerome_2594171 wrote:

The software is already running in some devices,

Also, I found this morning a new version of WICED (5.1.0) with this modifications :

   * [all WiFi] Speed up DCT reads by keeping track of current DCT verification

   * [all WiFi] Updated DCT padding to be multiple of 8-bytes for backward compatibility in OTA2

It is amendment can solve my problem ?

No, it does not help at all.

0 Likes

Adding the Apps team: ajaigrsrlsrimadyrashkavs

0 Likes
Anonymous
Not applicable

Hi,

We find in changelog :

Updated DCT padding to be multiple of 8-bytes for backward compatibility in OTA2

We thought this changes can resolved the DCT problem but it isn't the case.

We have 2000 products with 3.7 and we need to upgrade with version 5.1 but it isn't possible due to this bug.

Why you don't take into consideration the backward compatibility ?

if we create an hook we will keep it during all other versions and it isn't professional.

Ludo

Ludovic Wiart wrote:

Why you don't take into consideration the backward compatibility ?

if we create an hook we will keep it during all other versions and it isn't professional.

Ludo

sdk-5.2 breaks the compatibility again due to CLM blob file download support.

If your device can OTA application/WLAN firmware and resource file at the same time, it's probably fine.

Otherwise, it won't work.

0 Likes