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

[Edvin]

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

[Cedric M]

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

[Edvin]

Cedric M said:

Then I try to do pairing on test-fixture, I try it last day,  but it not works (error code returns).

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

 

Cedric M said:

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)

 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

[Cedric M]

#1

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.

#2

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)

[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,