Problem reconnecting after dfu on IOS

[ckoechli]

Hello,

I am developing an app based on the the buttonless_dfu example and the secure bootloader and it works fine with Android.

I have the following problem with IOS:

The dfu process works fine but when the app reboots after dfu. nrf connect on iOS still shows the bootloader services and characteristics and I cannot reconnect unless I switch bluetooth off in the settings menu or "forget" the ble device.

I can solve that in calling pm_local_database_has_changed() (if the peer is connected) but I am wondering if there is something that I missed in the configuration of the app or in the bootloader.

NRF_SDH_BLE_SERVICE_CHANGED is enabled in both the app and the bootloader.

I am using the sdk 17.1

Thank you in advance !

Christian

[Sigurd]

Hi!

I can solve that in calling pm_local_database_has_changed() (if the peer is connected) but I am wondering if there is something that I missed in the configuration of the app or in the bootloader.

I think this is the way to do it. See e.g. this answer:  RE: Problems after DFU on IOS 

[ckoechli]

Thank you for your answer !

I still have the problem after calling pm_local_database_changed() but it's a little more vicious this time.

I call pm_local_database_has_changed() right after peer_manager_init() and it worked for a while doing dfu tests.

At some point, it stopped doing its job and the service changed notification was not sent anymore after dfu. Erasing the chip and reflashing it with a fresh firmware solved the problem (erasing the peer table with delete_bonds() doesn't solve the problem ). However after further dfu tests, it reappeared.

The problem is hard to trigger but once it is there, the notification is systematically not sent after dfu.

I traced the problem down to the pds_peer_data_store and pds_peer_data_read calls

pds_peer_data_store writes the right data (1) to enable the notification but then pds_peer_data_read reads 0 and the notification is not sent.

As a workaround, I could force the notification at each connection without relying on the peer table but I'd rather have it work correctly.

Christian

[ckoechli]

I was able to solve the problem in calling pm_handler_flash_clean_on_return() at startup.

So I guess that the peer manager database gets corrupted somehow during the dfu testing process. I was able to reproduce the problem several times but I don't know exactly how.

I can live with that provided that there is a way to detect the problem or to avoid it in doing garbage collection preemptively.

My question is: can I call pm_handler_flash_clean_on_return() at startup every time before I start advertising ?

Christian

[ckoechli]

I was wrong, calling pm_handler_flash_clean_on_return() at startup didn't solve the problem in all cases.

The problem that I have is that there are duplicate records in the fds "database" of the peer manager

So my problem is related to the one of this thread:

 RE: Flash Data Storage (FDS) fds_record_update() -> Reset -> Two valid records possible? 

I was wondering if enabling the crc would solve it and I noticed that a failed CRC check is ignored in peer_data_storage.c:

// It is safe to ignore the return value since the descriptor was
// just obtained and also 'record' is different from NULL.
(void)fds_record_open(&record_desc, &record);

My questions are the followings:

1) What happens when the peer manager timeouts when writing to the flash?

2) Is there a way of avoiding it (my app. downloads a log file right after startup and I optimized the data transfer just for that)?

3) Is there a built-in way of detecting  that there are duplicate records ?

4) Does enabling the crc check solve it?

Thank you

Christian

[Sigurd]

Hi!

I assume you have pm_handler_flash_clean(p_evt); in your pm_evt_handler() 

Generally, you should only call pm_handler_flash_clean_on_return() when a pm_* function returns   NRF_ERROR_STORAGE_FULL