nRF52832 migration from nRF5 SDK for Mesh x.x.x to nRF5 SDK for Mesh 4.2.0 - provision data corrupted

[devbn]

Hello,

I'm trying to migrate my deployed devices to the nRF5 SDK for Mesh 4.2.0 (with connected nRF5 SDK 17.0.2). On the field I have several devices with  nRF5 SDK for Mesh 3.0.0 and other based on nRF5 SDK for Mesh 2.2

I'm setting up DFU, for now I'm programming directly new app and softdevice with jlink. 

When I power up, the device founds data corrupted and the device starts unprovisioned. I'm really interested in save provisioning to not reprovision again hundreds of nodes on the field. I found backword compatibility, managed with ACCESS_FLASH_PAGE_COUNT and DSM_FLASH_PAGE_COUNT that I set to 1.

I also tried to set those variables: NET_FLASH_AREA_LOCATION, DSM_FLASH_AREA_LOCATION,  ACCESS_FLASH_AREA_LOCATION, but I cannot find the right location in the previous version of mesh sdk.

Is it possible to set backword compatibility for provisioning data? does anybody can locate correctly flash area in the older versions?

Regards

Nicola

[Mttrinh]

Hi,

Unfortunately, it is not possible to preserve provisioning data from the older versions of the SDK because the data representation on the flash has changed during the subsequent releases of the SDK. The SDK now detects the invalid data format on the flash and erases it to avoid stack assertions during bootup and initialization.

I suggest you check the mirgration guide, this behavior is documented in the migration guide.

Backward compatibility is possible only in certain cases. To check if your older firmware can be compatible, in the new firmware set `NET_FLASH_PAGE_COUNT`, `ACCESS_FLASH_PAGE_COUNT` and `DSM_FLASH_PAGE_COUNT` to `1` (or to other correct number as required).

To find out flash area locations for the older firmware you can add logging statements in the check value of `p_config->p_area` for each flash manager instance used by various modules. This can be done by printing the value of this variable just before call to `flash_manager_add()` in the respective modules.

Even after checking this, it is unlikely to have complete backward compatible migration from v2.0.0/v3.0.0 to the current SDK due to the following update in the SDK (https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.meshsdk.v4.2.0/md_MIGRATION_GUIDE.html#health_server_subscription) unless the older firmware already has one extra subscription list allocated.