dataset recovery problem

62 views
Skip to first unread message

Yasmine Safi

unread,
Mar 29, 2022, 5:57:40 AM3/29/22
to openthread-users
Hello everyone, 

We are using MGM210P MCUs from SIliconlabs as Openthread FTD node. 

We performed  commissioning when the firmware of the FTD node was using the openthread commit cf21d5760 ( Siliconlabs SDK  v3.2.2 ).

We updated the firmware of the FTD node which points to OpenThread commit 55af6ce2c  ( Siliconlabs SDK  v4.0.1).

The Problem is that FTD node is not able to read its stored dataset. and it results to a HardFault. 
This problem is solved by adding this define -DOPENTHREAD_CONFIG_PLATFORM_KEY_REFERENCES_ENABLE = 0 to the build. 

After adding this define, FTD was able to recover the stored dataset. However, if we erase the dataset and perform a new commissioning, the FTD node is not able to join the existing network, unless we remove the define  (mentioned above).

As for our existing Thread border router, it is using  MGM210P MCU from Siliconlabs as Openthread RCP, using the openthread commit cf21d5760 ( Siliconlabs SDK  v3.2.2 ).

Any help would be appreciated. 
Thanks in advance :)

Hemanth Rao

unread,
Mar 29, 2022, 6:58:35 AM3/29/22
to openthread-users
Hi Yasmine,

There seems to be 2 separate issues here.

1. Moving the device from commit cf21d5760 (Siliconlabs SDK  v3.2.2) to 55af6ce2c (Siliconlabs SDK  v4.0.1) causes the device to fault.
2. Device in commit cf21d5760 is unable to join the existing network.

I suspect that you are seeing an assert and not a hard fault in the first issue and this is expected. This is because in 3.2.2 all the security materials were stored as literal strings in the NVM. In 4.0.1 we moved towards PSA and now the Openthread supports storing all security keys inside PSA and use only key references for all the crypto operations. As you are storing literal keys in 3.2.2 and doing a FW upgrade, to key references, the dataset manager sees that the device is not factory new and tries to read the NetworkKey and other security keys from PSA. This fails, because they are not stored in PSA yet causing the assert.

I am a bit unclear on the second issue. Can you elaborate a bit more on what you are seeing? Am I correct in my understanding that with commit cf21d5760 if you erase a dataset and try to join a existing network, with -DOPENTHREAD_CONFIG_PLATFORM_KEY_REFERENCES_ENABLE = 0, the device does not join the network and it is only able to join if you remove  -DOPENTHREAD_CONFIG_PLATFORM_KEY_REFERENCES_ENABLE = 0 from the build?

Please share some more information on the second issue to help us understand the issue more clearly.

Best Regards,
Hemanth
Message has been deleted

Yasmine Safi

unread,
Mar 29, 2022, 8:51:15 AM3/29/22
to openthread-users
Hello Hemanth, 
Thank you for your answer. 

for the 1. issue : What solution do you  suggest for the firmware update ?  We would like to move to the new SDK without losing any dataset or having any hard fault 
for the 2. issue : this is what happened : 
1- We erased the FTD dataset
2- We updated the FW  (commit 55af6ce2c / SDK 4.0.1) with -DOPENTHREAD_CONFIG_PLATFORM_KEY_REFERENCES_ENABLE = 0 added to build
3- We tried to rejoin the same network ( it was created by the RCP with OT commit cf21d5760 / SDK 3.2.2) 
-> Commissioning failed 
We added -DOPENTHREAD_CONFIG_PLATFORM_KEY_REFERENCES_ENABLE = 0 so that we can restore the dataset but apparently it was causing an issue with commissioning 

Best regards,
Yasmine

Yasmine Safi

unread,
Mar 29, 2022, 11:37:38 AM3/29/22
to openthread-users
update: Issue was solved by:

 adding -DOPENTHREAD_CONFIG_PLATFORM_KEY_REFERENCES_ENABLE = 0 to build 
and 
removing this define MBEDTLS_USE_PSA_CRYPTO from mbedtls_config file
Reply all
Reply to author
Forward
0 new messages