NRF51822: Bonds not saving with SDK5.1.0

[Paul]

I am finding that bonds are not saved to flash when using the latest SDK and S110 SoftDevice.

To test this, I am using the HTS example code, and the Master Dongle. I open Master Control Panel, and [Start Discovery] to list the advertising device.

First, I [select device], then do [Service discovery], [Bond], and [Enable services]. The temperature service starts notifying.

I then click [Disconnect] and [Back] and repeat the process. The bond is still in nRF51822 RAM, so temperature notifies fine.

I then click [Disconnect] and [Back], CYCLE POWER, and repeat the process. Temperature does not notify, the bond is not made since the nRF51822 looses it on power cycle.

I then click [Disconnect] and [Back] and then click [Delete bond info] and repeat. A new bond is created, and temperature is notifying again.

I am using: SDK 5.1.0 S110 6.0.0 production

When using old SDK and S110 (prior to pstorage) the Bond persists over power cycle.

[Paul]

Okay, my investigation shows that bonds are written to the flash, but they don't seem to be loaded after the bond manager is initalised after a power cycle.

m_centrals_in_db_count is zero

however, the flash (page 254) contains:

ffffffff 00000000 00030000 f0960c09 7f85a695 af05078c 461907a2 a2a3af6c |
2ec80020 ead43ed4 624a8a25 ee066541 3a009d83 23db544d 000000d0 00000000 |
f0960000 f9020000 ec738ddf 00000069 ffffffff ffffffff ffffffff ffffffff |
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff |
...
...
...

[Krishna Shingala]

Hi Paul,

I am unable to reproduce the problem, however do note that if you are automating the application to turn to enter system off as soon bond manager API returns, the it is possible that you are turning off the device before flash operation could be completed by SoftDevice. Do note that the flash access is SoftDevice is of asynchronous nature and an event is notified to indicate completion of an operation. Also, only one flash access operation is permitted at a time, hence a queue is implemented in the pstorage module to ensure application is not impacted.

An improvement noted for the pstorage interface however is to provide an API that the application can wait on to know there is no flash access pending to know definitively when a System Off could be entered. This is planned for future SDK release.

Hope this helps!

[Paul]

Hi Krishna,

No I am not turning the entire system off, so this is not the problem.

The problem is in the function bond_info_store in the file ble_bondmngr.c.

This function first writes the bond data to the flash, and then writes the CRC to the same page of flash (located immediately before the bond).

It seems that pstorage does not function correctly when doing two seperate writes to the same page of flash, without any erase operation in between. Indeed, as you can see from my memory dump above, the second write, the CRC, is not written and remains as 0xFFFFFFFF.

This corrosponds with your own documentaton which states: "Flash memory is unreliable when writing to a block already containing data, a clear operation is needed." devzone.nordicsemi.com/.../a00131.html

When I change the function bond_info_store to write both CRC and bond to an array*, and then write the array to the flash (using a singe pstorage_store, instead of two), then the bond saves fine.

This finding has made me very doubtful as to the reliability of the bond manager, particularly since you are unable to reproduce the issue.

• if anyone else is attempting this fix, make sure your array is persistant! the proper approach is probably to include a field for crc in the structure central_bond_t.

[Krishna Shingala]

Paul,

You statement:

"It seems that pstorage does not function correctly when doing two seperate writes to the same page of flash, without any erase operation in between. Indeed, as you can see from my memory dump above, the second write, the CRC, is not written and remains as 0xFFFFFFFF."

is incorrect. PStorage has no problems with writing to any flash valid location. You are misinterpreting the requirement of having to clear the page before an update. The update is required if and only if there was information at a certain location in the flash and you were trying to update the same location (this is not the same as page). CRC and bond information are written to the same block on the same flash page but different addresses, hence there is no requirement to clear to write the CRC once bond information has been written.

Also, I did notice that CRC was not written in your dump, which makes me suspect that all flash operations could not be completed before system was turned off.

Also, CRC is also a persistent global array, one for each bond and system attribute. Hence CRC is already persistent. What you are saving by including CRC in central_bond_t is performing flash write in one operation instead of two. However, you should be aware if you do that, you would be calculating CRC on CRC field as well.

[Paul]

Hi Krishna,

The problem is not that flash operations are incomplete before system turn off. I wait several seconds after they have started before cycling the power.

After further investigation, it seems that pstorage_store is not working correctly when called twice in close succession, and that is why the CRC, the second store, is not written.

When i put the following (hacky) code after the first pstorage_store in bond_info_store (write bonding informatin), it works perfectly. The CRC (and bond manager data signature) are written to the first 32-bytes of the flash page.

volatile int t;
for (t = 0; t < 100000; t++){}

Without this forced delay, the second pstorage_store does not write the CRC (and bond manager data signature).

No idea why this is, but I'd guess it's something to do with adding an operation the queue at the same time as the handler is removing an operation. It could be something completely different though, I haven't investigated the internals of pstorage.