Manually set resolvable address.

[jon pry]

I am using S132V3 on NRF52832 device. In my application we need to set a static, non-rotating, private resolvable address. I can't get into why that is here. In theory this should be easy, just compute a valid address and call sd_ble_gap_addr_set(), however that function checks the MSB's for the type and won't accept private resolvable as an address type. So no dice there.

Then I turned MWU off, and located the MAC address in softdevice memory and swapped it out with the right one. Something like (volatile uint8_t)0x200001be&=0x7F; plus a couple more addresses.

Strangely enough, I got this to work in peripheral mode, I can bond to it from a phone. However I need simultaneous central/peripheral and things are a bit hairy. Certain calls to SD seem to require that high bit to be set or they crash, and other calls need the MAC address "restored" or bonds don't work.

I've yet to get everything working 100% in central. Is there some other way to work around this?

[Hung Bui]

I afraid this is restricted by the spec that the resolvable address shouldn't be set manually. This is due to the main purpose of the random resolvable address, to provide privacy.

Modifying RAM may not be a good idea, as you already experienced, in some functions, we do check the first bit.

Why do you need a static resolvable address ?

[jon pry]

I can't say why I need it except under NDA. The S132 V2 API provides the functionality I need, since it requires the user to generate the addresses, but I would prefer not to use the aging SDK.

As a work around, I could potentially deal with the randomly generated addresses, but I've run into an interesting bug. When I enable privacy through sd_ble_gap_privacy_set. The first address after power on it always the same. I am concerned that the sequence of addresses used may always be the same. I've also encountered bugs where the address rotation fails to happen even though a private resolvable address is clearly being advertised.

I guess that is my real problem with this new API. There is no control over how/when these "random" addresses are generated. There's really a lot of non ideal times to be rotating the address when operating as a central. For example when I see a device advertise I want to connect to, it would be best if the SD did not change my address for the next few seconds so that the connection attempt does not fail.

[Hung Bui]

Hi Jon,

How exactly did you set the sd_ble_gap_privacy_set() ? I just tested here with S132 v5.0.0 on SDK v14, it worked fine, I have new address everytime I called it and updated every minute. Here what I used:

privacy_param.privacy_mode=BLE_GAP_PRIVACY_MODE_DEVICE_PRIVACY;
privacy_param.private_addr_cycle_s=60;
privacy_param.private_addr_type=BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE;
privacy_param.p_device_irk= NULL;
err_code = sd_ble_gap_privacy_set(&privacy_param);