pstorage update sometimes doesn't update, prevents BLE reconnect

[Dan K.]

Hello,

I am using SDK version 9 with softdevice s130 operating as both a central and peripheral. I provide a custom peripheral BLE service, and when it receives some information in one of the characteristics, it is supposed to write this information to persistent storage. I do this in a function that looks like this:

void save_settings_to_flash(uint8_t *settings, uint16_t dsize)
{
	pstorage_handle_t block_handle;
	uint32_t err_code;

	err_code = pstorage_block_identifier_get(&app_data_flash_manager_handle, 0, &block_handle);
	APP_ERROR_CHECK(err_code);

	err_code = pstorage_update(&block_handle, settings, dsize, 0);
	APP_ERROR_CHECK(err_code);
}

No errors are reported at any time, and my callback is being called with no problem. However, about 20% of the time, the data does not actually get saved, and if I disconnect from the service after this happens, apparently it stops advertising, as the service is no longer visible and I cannot reconnect to it. Note that if I remain in the connection, I can still communicate through the service, and it's responding normally. It's just that once I disconnect, I can't reestablish the connection.

It appears that the scanner is continuing to receive advertisements from another peripheral even after it loses the ability to connect as a peripheral.

app_data_flash_manager_handle and block_handle are the same each time for both reading and writing.

I have tried:

1. performing the save operation in a scheduled event, rather than directly in the response to receiving the characteristic data.
2. implementing the workaround in this thread.
3. using a pstorage_clear() operation before the update (this makes it worse).

But nothing I do seems to fix this problem.

Any help would be appreciated. Thanks!

[John]

Just a guess, but I think you want to make your block_handle a static or global. The address of it is passed to pstorage and queued up with the update operation. If the stack is reused in that time the handle could be changed on you.

[Dan K.]

Thanks. That's a good point. However, I just tried it with block_handle (and app_data_flash_manager_handle) as static globals, and it still seems to behave the same.