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