ble_bondmngr.c:bond_info_store() issue

[aras]

Hi, Regarding the bond_info_store() routine, I am having issues where after several calls to this function (client pairing forget/reconnect), my p_bond gets corrupted. This problem invariably occurs after the second call to pstorage_store(). Please verify that the dest_block variable MUST remain in scope, even if the function returns NRF_SUCCESS. Thus, my quick fix is to make this variable static. Regards, Ara

[John]

Most of the pstorage API calls have to enqueue the command for processing between radio activity. The return of NRF_SUCCESS merely means the command has been successfully queued and it does not mean the command has completed. So, your variables must remain in scope for this to work.

[Håkon Alseth]

dest_block (type pstorage_handle_t) should not be a static function, as this struct will be populated by the pstorage in the call to pstorage_block_identifier_get with the specific block/ID, which is then given into pstorage_store-functions.

Do you get any error code returned when this corruption happens? Be sure to use the ASSERT-handler, and check every error code. by default, the error_handler will reset the chip, but if you comment in the call to ble_app_assert_handler in app_error_handler(), then it will give you line/errorcode/file.

[aras]

Thanks for your replies.

It failed at MODULE_ID_RANGE_CHECK in pstorage_store(), where module_id was corrupted (strangely enough it contained the previously calculated CRC). dest_block must remain in scope as it is being passed by reference. My problem vanished when I made it static (not a perfect solution since another caller can crush this variable to early).