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]

Hello,

I add complement of #2. I made another test today :

Compared to the last remarks, I investiguated the way in which Flash memory is accessed during bonding.
In the sys_evt_dispatch () function (of BLE source code), we find the function fs_sys_event_handler (), where fs_ = FlashStorage. This function seems to be call after an event bonding.

If I inhibit this function permanently, the application does not start. Compared to if I let it run the first time and then deactivate it afterwards, I have the impression that the bonding is working and is no longer flash savings.

I noticed that the 1st time the memory is written with the data 0xC007 0x0014.

- What does this data correspond to (test condition is : boot without any connexion of peripheral) ?

- is my method consistent with you (to execute function only first boot, and after never) ?

Please see picture of data memory that is written first time :

Regards,

CM

[Cedric M]

If I repeat operation (several test with different DUT), it's work, bonding is not saved, I can do my tests of DUT, but I see memory flash is again updated with 0x0014 0xC007.

Then it solve problem of bonding saving (that is not saving !), but not flash endurance of test-fixture (there is an update of data flash at each test of DUT).

I do not understand what this data is and what is the function that update this data. Have you an idea ?

Please see picture that is the result of 3 tests : (you can see 0xFF data between each test, then correspond to NULL bonding)

regards,

[Edvin]

Hello,

I tested the ble_app_hrs example which has support for bonding with the peer manager, and in my case, it doesn't write anything to the FDS pages, other than the page tag (DEC0ADDE) and the page type tag (FF011EF1/FE011EF1). 

Please see the attached flash dump:

ble_app_hrs_flashdump.hex

Can you please make sure that you erase the entire flash (using nrfjprog -e) before you program the softdevice and application.

Does it write anything to the flash before you connect to anything?

 

Cedric M said:

I do not understand what this data is and what is the function that update this data. Have you an idea ?

The flash records from FDS are stored on the following format:
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.0/lib_fds_format.html

This is the reason i want you to erase the flash before you program it. It doesn't match the record layout. In your case, the record key is 07C0, and the data length is 0x14(20), and CRC 00. But the record ID is 0x00000000, and there are more than 20 bytes between the "records".

What SDK version do you use? And do you use the peer manager?

BR,

Edvin

[Cedric M]

Hello,

#1

I have examined the HEX file in link. A priori it is not an NRF51, but whatever the principle remains the same. I have the same thing when I program, the memories are well initialized without any data. I am using nrf connect by doing an "erase all".
My remarks come after the execution has taken place at least once, that is to say that it is the software which modifies the memory.

#2

Thanks for documentation link.

I understand better how the bytes are used.
I confirm to you that initially the memory is quite empty (erased 0xFF). There is no such data. It is the execution of the software that adds it.
If I understood correctly, to read (and understand) these values, there is no need to swap the bytes, we read the addresses in order in a basic way (not like DECOADDE which becomes DEADCODE).
For now, I haven't figured out what 07 C0 14 00 is yet. According to the documentation 07 C0 would be the record key, and the address range is in 0x0001-0xBFFF, so it's a data range because the peer manager uses 0xC000-0xFFFE.

For the SDK, I checked again if I was up to date, it is. As I indicated at the beginning, the chip is an NRF51, and according to the official Nordic correspondence table, I have to use the S130 softdevice (BLE in central and peripheral role).

here is the link :

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcomp_matrix_nrf51%2FCOMP%2Fnrf51%2Fnrf51_comp_matrix.html

Then, I am using SDK 12.3.0 with softdevice v2.0.1 as requested. Other SDKs do not support NRF51.

nRF5 SDK v12.3.0
----------------
Release Date: Week 19, 2017

For the link of flash storage, I use it (instead of v17). I compared each one, it seems to be identical.

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.0.0%2Flib_fds_format.html

Yes, I use the peer manager.

since yesterday, I still have not managed to identify which function could write data, and what the key record 07 C0 corresponds to.

A new records (07 C0....) is saved (in central) each time I connect a new perripheral while the function fs_sys_event_handler(sys_evt); is disabled.

Regards,

[Edvin]

Cedric M said:

I have examined the HEX file in link. A priori it is not an NRF51, but whatever the principle remains the same

 Indeed. It is an nRF52840. It is what I had connected to the computer. I don't have any nRF51 DKs at the moment, but I used SDK 12.3.0, and the ble_app_hrs example for the nRF52840, which should behave equivalent. At least FDS wise.

 

Cedric M said:

My remarks come after the execution has taken place at least once, that is to say that it is the software which modifies the memory.

 My flash dump was taken after I started the application. The softdevice never writes anything to the FDS pages directly. The only link between the FDS and the softdevice is that FDS uses fstorage, which uses a softdevice backend to read and write to flash, but the softdevice never initiates a flash write without it coming from the application. Typically, the softdevice triggers events, e.g. in the peer manager, which then writes to the FDS -> fstorage -> softdevice backend.

 

Cedric M said:

If I understood correctly, to read (and understand) these values, there is no need to swap the bytes, we read the addresses in order in a basic way (not like DECOADDE which becomes DEADCODE).

 This always confuses me. I suspect that we do. I think that the record key is 0xC007. I guess this comes from PDS_FIRST_RESERVED_FILE_ID or PDS_FIRST_RESERVED_RECORD_KEY, which is used in PEER_ID_TO_FILE_ID, FILE_ID_TO_PEER_ID, DATA_ID_TO_RECORD_KEY and RECORD_KEY_TO_DATA_ID. So the list of places to check quickly becomes very large. 

What happened to not bonding, but just pairing in your production test?

If you want to see where the peer manager uses fds, I guess I would start by commenting out fds_register() in peer_manager_init() -> pm_init() -> pds_init() -> fds_register(fds_evt_handler); Perhaps also fds_init() in the same function.

And then see where it fails. 

I just noticed when checking how pm_init() is set up that there is something relevant in pds_init():

pds_init() -> peer_ids_load():

uint16_t const record_key = peer_data_id_to_record_key(PM_PEER_DATA_ID_BONDING);

PM_PEER_DATA_ID_BONDING = PM_PEER_DATA_ID_BONDING_V2 = 7, and peer_data_id_to_record_key() will add DATA_ID_TO_RECORD_KEY (0xC000) to this. 

So peer_ids_load() will try to find a record with record key 0xC007. It doesn't write it, but this is at least somewhat related. 

pm_peer_data_bonding_store() will store a record using PM_PEER_DATA_ID_BONDING together with pm_peer_data_bonding_store (which makes up 0xC007), so you can check where this is called, and possibly comment out that place. 

However, after a "deep dive" into this, I realized that I don't think any of this is necessary. Why do you need to disable the flash writes? 

1. I don't really think bonding is necessary to test during production.

2. If you want to test bonding, then test it, and call pm_peers_delete() on every disconnect. It will delete all your stored peer data. This will eventually burn out your flash, but that will take a long time. Deleting a peer doesn't delete the flash. It just marks the record as a dirty record. First when all of your flash pages (except the swap page) is full it will do a garbage collection, and actually delete the flash pages. At this point, you have used 1 flash write cycle. 

3. If you bond during testing, you will end up with all of the DUTs having a stored bond in your flash, right? (Or do you intend to erase the flash on these and reprogram them afterwards?) If they contain bonding data, then they would typically advertise with a whitelist (not accepting connections from new devices). Have you concidered this?

My suggestions:

1: Don't test bonding. If it works on one device, it probably works on all.

2: If you decide to test bonding, just delete the bond information in the tester whenever you want to test a new device. This can all be done in the application, so you don't need to do anything inside the peer manager libraries. 

Best regards,

Edvin