GATT Local database (or pairing) corrupted in iOS

[mectronicsinc]

Hi all,

I'll explain the problem. Our device (that uses a nRF52832) works with a custom app developed for iOS (v 13.4.1) and we've a custom set of services/characteristic besides other SIG's standard services, like the Battery Service or the TX Power Service. Obviously, since we're working with iOS, we use full ANCS implementation.

Also, we use the CTS Client implementation, modified to support also the Local Time characteristic (that is optional in the CTS, but implemented by iOS) and the DFU Buttonless Service.

Moreover, we use the fds module to store some data (like the setup of the i2c sensors, a lightly log system and so on...); obviously we respect the fds indication about the File_ID/Record_Key, and we do not use the forbidden set reserved to the Peer Manager.

All characteristics, except one, works in JUST_WORK, so, the device requires a bonding with the Apple device. Moreover, we use a customized bootloader (but the core, not modified, is the Nordic's Buttonless bootloader) to perform the DFU OTA.

All works very well without any problem, and, from the DFU OTA to the data exchange between the device and the Apple phones, the system is very stable and reliable.

But, sometime, we've experienced very boring problems. In few words, from one connection to another, the phone reported that the bonding data are lost (or corrupted), so, we can only remove the bonding data and perform a new bonding procedure.

This is frustrating, and we are not able to understand why/when this happens.

We've check the files saved by the Peer Manager (3 files: Bonding Data, Rank Data, GATT Local Database Data) and all seem always correct (just to be clear, for the first 2 files we've also know the format, but for the last one, Nordic's library does not provide any information. We only suppose that an entry like (0x) 03-00-00-00-56-00-0D-00-02-00-02-00-11-00-02-00-02-00-15-00-02-00-00-00 ... -64-1E is composed by a uint32_t field (flags = 03-00-00-00), an uint16_t field (# of 4-B words, 56-00) and then the list of the CCCD's of the characteristics (f.e 0D-00-02-00-02-00, where 0D-00 is the handle, the first 02-00 is unknown to we and the last 02-00 is the flag that indicates if the notifications are active or not). At the end (64-1E), we suppose there are something like a CRC (?))

Unfortunately we're not able to catch when the data are corrupted, so, I would ask if some one has experienced a similar problem...

Moreover, to lost the bonding data is sufficient that only one of the three files will be corrupted? Or, as in our opinion, only the first file (Bonding Data) must be corrupted?

Our setup is: nRF52832, SDK 16.0, IAR 7.50. Apple devices with iOS 13.4.1

[Vidar Berg]

Hi,

The peer manager should not delete the bonding information unless it's forced because there are no freeable data records left to delete. This is something that should only happen if you keep adding new data to flash without deleting/updating existing data.

I did not manage to replicate this with the original ANCS example in SDK 16.0.0. I set the number of FDS_VIRTUAL_PAGES to 2 to reduce available space then made repeated re-connects to fill FDS data page. But as expected, only the dirty records were deleted. The bonding information was kept. 

I think it may be easier to find out what's happening in your case if you try to monitor the flash usage with fds_stat E.g. confirm if there are indeed no dirty records when you receive the PM_EVT_STORAGE_FULL event.