Problem reconnecting after dfu on IOS

RE: Problem reconnecting after dfu on IOS

Sigurd — Fri, 05 Jul 2024 12:24:37 GMT

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

RE: Problem reconnecting after dfu on IOS

ckoechli — Mon, 01 Jul 2024 14:57:46 GMT

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

RE: Problem reconnecting after dfu on IOS

ckoechli — Wed, 26 Jun 2024 15:07:49 GMT

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

RE: Problem reconnecting after dfu on IOS

ckoechli — Wed, 26 Jun 2024 07:15:54 GMT

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

RE: Problem reconnecting after dfu on IOS

Sigurd — Tue, 11 Jun 2024 11:49:22 GMT

Hi!

[quote user=""]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.[/quote]

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