How to disable storage in flash memory all information of bonding/pairing/wititelist/passkey ? Needs for test-fixture that connect just one time

[Cedric M]

Hello,

I have products based on NRF51822, that are central and peripheral.

These products use Softdevice S310, bootloader and application code. It use peer manager, fs storage. I do developpment based on different nordic examples.

Products are connected together with bonding, whitelist, passkey, and there are compliant with standard BLE of smartphone too.

each product include normal and test program (I can access to test function by specific custom registers in application code)

Products works.

My problem is for testing on production line.

I developp a test-fixture based on same chip (and near same code, difference is about adding UART connexion on test-fixture to an external automatic PC program to control BLE chip).

For each card that I want to test, I must connect to it (on BLE) to execute program test (NRF51 under test is wire controlled to I/O that I want to test too under radio link)

To connect to each card (DUT) with the test-fixture, I must do a complete connexion (bonding...) and parameters card are saving in flash storage. To test another card, I must do a total erase to remove all data stored in flash, and this is my problem.

I do not find explicit function of saving at each step (bonding, passkey...), I test several things in code to remove step of saving, but I have a lot of errors, it seems to be more complicated that I think to not use saving and loading from flash (maybe functions included in soft device ?)...

Is there a solution to perform all steps (bonding....passkey) without saving (and loading) anything in flash storage (then running only on actual session on RAM) ?

My objective is to test quickly in series all card... (and without degrade endurance of flash cycle that would be another problem, too)

Thanks,

Cedric

[Cedric M]

Thank you very much, your analysis was perfect and allowed me to find the problem. You got it right:

The "record key" was indeed 0xC007 (you have to swap the bytes). From this key, I went up, as you had noticed, to the function which called somewhere to a record. It is indeed PM_PEER_DATA_ID_BONDING, I would never have found it without you since it is the concatenation of 2 constants in the code, and it is deeply hidden in a long list of function calls.
This is indeed a function of the peer manager when there is a BLE event, and according to the path it is the result of a connection with successful authentication.

this is the "pds_peer_data_store ()" function in <peer_data_storage.c> whose call path is:

ble_evt_dispatch() --> pm_on_ble_evt() --> sm_ble_evt_handler() --> smd_ble_evt_handler() --> auth_status_process() --> auth_status_success_process() --> pdb_write_buf_store() --> pdb_write_buf_store()

I therefore copied the source code of this library into my code (exclude the link in the library so as not to corrupt the other projects in the tree structure of common libraries), and I inhibited the call to this function.

To check the operation, I started with a totally erased chip, then I programmed the softdevice and the application.
I made a series of connections with 2 blank peripherals (with the central and peripherals in full bonding / passkey ....) and I can do my tests with the connection fully operational, and without any writing in the flash.

To answer your remark (1) about pairing vs bonding, I failed to get the code implemented in bonding (with passkey, whitelist, private key) to work by degrading it to pairing, I have a systematic error settings that I cannot resolve.
I too would have liked not to do bonding for the test. I hope to be able to do it later but for the moment the solution and "skipping" the flash step is operational and allowed me to understand its operation for related uses that I implement in the test-fixture.

For your remark (2) about pm_peers_delete (), I recently had the problem to delete devices in "factory" mode for customer use, but unfortunately this does not delete the whitelist data (so in the end I am also stuck). I found some posts on the forum (with replies from Nordic developpers) who knew about this problem and offered solutions to get around it by independently managing the erasure of data from the white list, but it seemed quite complicated.

For your remark (3), this is absolutely correct, it was part of my first notes at the beginning of the initial post (post 07/09/20 12:41 # 1), and it joins the remark (1). After the test, I have to erase each device, but only the data (identified!) by the code by making a direct access (not protected) in erasure. It is less annoying because it only requires one cycle on the flash of a DUT (unlike the test-fixture).

Once again a big thank you

Cedric

[Edvin]

Hello Cedric,

Glad to hear that you found the source. It was a coincidence that I found the ID = 0x07, and I had to check what it was used for. As stated earlier in the conversation, the FDS is quite heavily weaved into the peer manager, so it would take some effort to completely disable it in a smooth way.

Just in case you decide to dig further into the pairing mode:

(1): That is correct. Whitelisting is usually applied to bonded devices, however, it is possible to add it manually. Look at how the peer manager does it by default (I don't know this by heart). 

(2): similar to (1), the whitelist needs to be "reloaded" after you delete bonding data. I think it is usually done in the advertising_init() or advertising_start() functions in the examples that uses whitelisting. The ble_app_gls example is usually the peripheral example I use to look up things with pairing/bonding. The ble_app_hrs_c is the central example I use for the same.

NB: The ble_app_hrs (peripheral) example doesn't initiate pairing nor bonding, but it supports it. I don't think it uses a whitelist.

(3): Yes. If the devices are running the final FW, which supports bonding, then it obviously will contain bonding data after the test. So you need to consider that (I just wanted to make sure you were aware, but it seems like you know this stuff quite well ). You can probably do something like only erasing the FDS pages. The next time the application boots up, it will see that it needs to re-initialize the FDS pages, since they are blank. Just like in the first ever boot up. 

Best regards,

Edvin

[Cedric M]

Hello,

Yes thanks. There is always an element of luck, but there is also knowledge!
For the peer manager, I have indeed searched everywhere and I think I have flushed out all the flash accesses, my tests show that there is no longer access to the data (in writing) on ​​the flash, therefore the data always remains initialized when read, so each test starts from the same initial conditions (without degrading the test bench).

(1) I would indeed like to be able to implement pairing (without bonding). This is a point that I have failed to resolve. What I noticed is that the management of the whitelist is not trivial and is not as well managed natively by the libraries as the other steps like bonding. I have already had several problems with solutions I found on nordic dev zone (this is a problem others have had).

(2) For the removal of the whitelist, I will look in the example project you advise me (ble_app_gls), hoping to find a management of the whitelist. It is already less serious because what I implemented has the merit of having unlocked me but if it is not the cleanest (less maintainable for futur).

-> If I ever get stuck on these two technical points (which are linked), I will open a new ticket.

(3) Yes, I have already implemented the appropriate mechanisms. I had identified the flash sections dedicated to data (with or without a bootloader which shifts the positioning), and I use the function:
ble_flash_page_erase () starting from the address relative to BLE_FLASH_PAGE_END

Best Regards,

Cedric