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

RE: 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 — Thu, 10 Sep 2020 12:35:44 GMT

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

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

Edvin — Thu, 10 Sep 2020 09:33:31 GMT

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

RE: 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 — Wed, 09 Sep 2020 15:25:14 GMT

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

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

Edvin — Wed, 09 Sep 2020 12:25:30 GMT

[quote user="Cedric M"]I have examined the HEX file in link. A priori it is not an NRF51, but whatever the principle remains the same[/quote]

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.

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

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.

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

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

RE: 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 — Wed, 09 Sep 2020 10:21:26 GMT

Hello,

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.

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,

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

Edvin — Wed, 09 Sep 2020 07:47:37 GMT

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:

devzone.nordicsemi.com/.../ble_5F00_app_5F00_hrs_5F00_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?

[quote user="Cedric M"]I do not understand what this data is and what is the function that update this data. Have you an idea ?[/quote]

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

RE: 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 — Tue, 08 Sep 2020 08:43:34 GMT

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,

RE: 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 — Tue, 08 Sep 2020 08:29:39 GMT

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,

RE: 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 — Mon, 07 Sep 2020 17:17:44 GMT

For this example, I am using the test fixture (with the initial code coming from a device developped in the central role). I am using a device (DUT) in peripheral mode. Each one are configured initially for bonding with passkey and whitelist.
The central code is changed to bonding = 0 instead of 1. The rest of paremeters are unchanged

-------------------------------------------------------------------------------------------------------------------------------------------

#define SEC_PARAM_BOND                                0//tbd1                                       /**< Perform bonding. */
#define SEC_PARAM_MITM                                0                                       /**< Man In The Middle protection required. */
#define SEC_PARAM_LESC                                         0                                          /**< LE Secure Connections not enabled. */
#define SEC_PARAM_KEYPRESS                                 0                                          /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES                         BLE_GAP_IO_CAPS_KEYBOARD_ONLY           /**< No I/O capabilities: defined to keyboard only in order to launch MITM protection. */
#define SEC_PARAM_OOB                                   0                                       /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE                          7                                       /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE                          16

-------------------------------------------------------------------------------------------------------------------------------------------

on startup of central, I have an error come from peer manger (function peer_manager_init() ), 0x7 that correspond to invalid param.

yes indeed I had seen that flash pages were reserved and used from the end, either just before the bootloader if it exists, or at the very end of the memory without a bootloader.
I have 3 reserved pages with a few bytes established. I had clearly identified the bonding page that evolves after a pairing. The other 2 I don't know what they are for.

0x3F400 - 0x3F7FF : ?

0x3F800 - 0x3FBFF : bonding

0x3FC00 - 0x3FFFF : ?

I do test without bootloader to more lisibility.

I analyzed the memory with an intel HEX editor from a read with nrf connect. I can see the DEADCODE data.

it is therefore the page with the bonding information that I want to bypass (see attached)

memory after 1st boot. I can see data page

location of data after bonding

So I correctly locate the page, now the question is how to redirect the accesses (R / W) on RAM

On the DUT side, your remark is quite correct, but I had not mentioned it because it is not blocking. As the DUT is tested (only once), I can use the built-in "factory" erase procedure because I don't have the memory endurance problem, it's just a bit of a pain because it lengthens the steps and the test time. If I manage to solve the test bench side, I could then I think to solve that too (because it is less complicated or equivalent)

Regards

(I will post independant another question relative to test fixture for better post follow-up)

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

Edvin — Mon, 07 Sep 2020 10:41:18 GMT

[quote user="Cedric M"]Then I try to do pairing on test-fixture, I try it last day, but it not works (error code returns). [/quote]

Where does it return an error code? What function returned it, and what was the value of the error code?

[quote user="Cedric M"]Is it sure that pairing will not save anything in flash ? (I use nrf connect->prog to see sections of flash used, I see it at end of flash before bootloader section, and data were write at boot without any connexion (after load/write/read to compare hex file), then I see that things happen without my knowing why...the use of the flash is rather obscure)[/quote]

If your application uses the peer_manager, it will initialize the FDS pages on first power up, but it doesn't necessarily store something there. This is why you see the lines near the top of the flash after you connected to it. You should see the same lines even if you do not connect to it at all. If you want to investigate further, you can read back the flash using either nRF Connect -> Programmer or nrfjprog (nrfjprog --readcode my_flashdump.hex). If you open that hex file in a text editor, you can check the content of the FDS pages like this:

Search for "DEC0ADDE" (DEADC0DE in reverse byte order). It will have a few occurances in your application region, and then N occurances near the end of the file, where N matches the number of FDS pages in your application (N = 3 by default in the later SDKs, but since you are using the nRF51, this may vary). The word after dec0adde is either FF011EF1 or FE011EF1, where FF011EF1 refers to the swap page, and FE011EF1 refers to data pages.

What you should see, if the application didn't write anything to the FDS pages, the area after DEC0ADDEFE011EF1/DEC0ADDEFF011EF1, and to the end of the page contains records. If they are all 0xFFFFFFFF, then it means that the FDS is only initialized, but there is no data written to the flash.

Another thing that you may already have thought about, if you manage to disable the FDS part of the peer manager, what happens to the DUT? Will it store bonding information, or do you intend to disable it in the DUTs as well?

BR,

Edvin

RE: 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 — Fri, 04 Sep 2020 13:31:22 GMT

Hello,

Yes you are right. I do not need bonding because I do not need to re-connect (faster / better) later between test-fixture and DUT. I just want to establish a full connexion (one time for test) that can transfert data between each one (one in central role, one in peripheral role).

That's what I feared for the peer_manager and softdevice, flash function will be complicated.

The final product (that is DUT) is configured by defaut to "bonding" (constant in source code at "sec_param.bond"), there is no user input to make a configuration. Then I can't configure it in an alternately pairing mode (I specify it because I thought it was a limitation).

Then I try to do pairing on test-fixture, I try it last day, but it not works (error code returns). I deduced that we could not have one device configured in "bonding" and the other in "pairing", but I may be wrong.

So is it possible to combine a device in bonding and other one in pairing mode, and have full access of data transfert ? If it can be works, I must search why I can not do it (before launching into code to substitute the flash to RAM access)

Is it sure that pairing will not save anything in flash ? (I use nrf connect->prog to see sections of flash used, I see it at end of flash before bootloader section, and data were write at boot without any connexion (after load/write/read to compare hex file), then I see that things happen without my knowing why...the use of the flash is rather obscure)

Regards,

Cedric

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

Edvin — Fri, 04 Sep 2020 12:25:09 GMT

Hello,

The peer manager is quite tangled into the flash operations, since that is it's only job. Do you really need to test bonding on every device during production? Perhaps you should at least consider testing only pairing.

I don't know what parts of the bonding you want to test. If it is just the bonding procedure (which is almost identical to the pairing procedure), you may be able to find out just where it writes to flash, and comment out that part (and return a fake NRF_SUCCESS). But if you intend to disconnect and connect again, you would also have to fake the part where it looks up the bonding information, which may be a bit more tedious.

One way I can think of is to write a custom backend for FDS that doesn't use NVMC or the softdevice API, but a custom RAM file system of some sort. This way you wouldn't have to touch the peer manager at all. The alternative way is to find out where the peer manager stores the bonding information, and just write this to a custom variable in RAM instead of a flash record. Then, you would need to find out where it reads out these records later, and fetch the data from the custom variable instead.

So can you elaborate a bit on what parts of the bonding you want to test?

Best regards,

Edvin

RE: 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 — Fri, 04 Sep 2020 11:57:34 GMT

I just realize that I make a keyboard entry error, sorry, I use softdevice S130 (and not S310) for both central and peripheral role