Pairing specific pairs among many

[June20]

Hello, we're trying to make products using BLE with nRF52840(central) and nRF52833(peripheral).

We did make custom boards and also made a program that once paired(bonded), it won't connect with others.

(eg, once nRF52840 and nRF52833 is paired, it will not connect with others)

We were wondering is there a way to make specific central connect with specific peripheral?

Is there a way to make each central/peripheral unique so that pairing process can be done without interference?

We got concerned that wrongly paired(or bonded) devices might ship out.

At our current stage, pairing wrong central/peripheral is possible.

Other infos.

nRF52840-central has 2 buttons, while nRF52833-peripheral has none

We're using SDK 17.1.0 S140 Segger Studio

has NUS(communication) and BAS(battery check) BLE services

thanks

edit:

extra question: is there a way to write certain unique number/MAC address on flash during flash write and then read it during application?

How do I know which address of flash is used or not?(want to avoid  collision with bonded info)

Is there a download tool beside nRF Connect Programmer?

[Einar Thorsrud]

Hi,

We did make custom boards and also made a program that once paired(bonded), it won't connect with others.

(eg, once nRF52840 and nRF52833 is paired, it will not connect with others)

This sounds like what you normally achieves with whitelisting. I assume that is what you are using?

We were wondering is there a way to make specific central connect with specific peripheral?

If they are already bonded/paired, whitelisting is what you typically use here. That can be used on both the peripheral side and central side. With that, the device will only connect with a peer that has a specific BLE address (either static or derived from a IRK).

Is there a way to make each central/peripheral unique so that pairing process can be done without interference?

If you want to do this without any user interaction and want it to be secure, then it is difficult. But if it is just for convenience, then you could base this on BLE address. Or you could for instance use a unique number in for instance the name of the device and include that in the advertising packets, and have the central search only for a device with a specific name including a unique number.

extra question: is there a way to write certain unique number/MAC address on flash during flash write and then read it during application?

Yes.

How do I know which address of flash is used or not?(want to avoid  collision with bonded info)

If it is just a serial number of address or similar, then the most natural is to put this in UICR. Then it does not conflict with anything else as long as you stay away from the reserved parts. See UICR chapter in  PS for details. Then you can read this like any other part of the flash/memory. If you need to store a lot of data or need to be able to update the data, you need to do this differently. That does not seem to be the case here, though(?).

[June20]

Thanks, what I was looking for was UICR, and it checked out when I used "nrfjprog --memwr 0x10001080 --val 0xcc"

I am now stuck with binary(or hex) files.

nRF Programmer is showing different memory layout  when comparing what I debug via Segger studio versus output/my_app.hex + softdevice_s140.hex.

Are there other hex file I should consider? (I also added bootloader_setting.hex I generated but they don't seem to be identical.)

Top two lines on the right side is bootloader_setting.hex, and the rest are my_app.hex + softdevice_s140.hex

bootloader_setting.hex (nrfutil settings generate --family NRF52840 --application "my_app.hex" --application-version 0 --bootloader-version 0 --bl-settings-version 2 bootloader_setting_uicr.hex)

Also, are there any easy-to-follow nrfjprog tutorial?

Thanks

[Einar Thorsrud]

I assume that the extra block you see close to the top are FSD pages. FDS is (among other things) used for persistent storage by the peer manager module, and these flash pages are initialized the first time after reset. You can hover over it to see the address range to compare with your memory layout to be 100% sure (refer to memory layout figure in the bootloader documentation to get an overview of what you are looking at).

[June20]

The third area at top I was talking about was 0xFD000 ~ 0xFD007 (8byte). I think you're right, Flash Storage - NRF_FSTORAGE_ DEF from info center mentions 0xFD000 address (though mine from fds.c doesn't mention any address). I didn't really used any FDS, is it from SoftDevice?

UICR was very useful, I was able to narrow down to the specific peripheral from BLE central. Since BLE central can use filter, is there a way for peripheral to filter scanners (by ble address/name/etc.)?

[Einar Thorsrud]

June20 said:

I didn't really used any FDS, is it from SoftDevice?

No, the SoftDevice does not use FDS (or persistent flash storage of any kind). However, the peer manager, which is responsible for pairing and bonding use FDS to store bonds. So if you are using the peer manager, you are using FDS. The number of FDS pages are configured in sdk_config.h (default in moste examples are 3, and absolute minimum is 2).

June20 said:

Since BLE central can use filter, is there a way for peripheral to filter scanners (by ble address/name/etc.)?

For peripherals it is a bit different, as it is the central that connects. However, whitelisting is also a concept on the peripheral side. If you advertise with whitelist, only peers that are in the whitelist are allowed to connect. Connections from other centrals are automatically dropped by the stack. This only allows you to filter on address, though. If you need to filter on something else (like name), then you must allow it to connect, read whatever information you want to check, and disconnect if that does not match your criteria.