All: You should not use DEVICEID for the address. While there is an extremely high probability you will be fine, there is a chance you will not. And yes, I realize the chance is really, really, really small! :-) The address cannot be all 1’s or all 0’s. I asked nordic this question and they say their DEVICEADDR does abide by the rules in the spec so that is the one I would use. Here is the link to the post:
https://devzone.nordicsemi.com/question/101162/deviceaddr-and-resolvable-private-addresses/ I have to say I was not terribly happy with the answer nordic provided since they say "the address is, as you know, a random static address...”. Well, it might not be. You have to set the upper two bits to make it so (as Szymon mentioned). You could also use DEVICEADDR as a non-resolvable private address; you just set the two upper bits to 0. > On Mar 13, 2017, at 3:36 PM, Pritish Gandhi <[email protected]> wrote: > > Hi All, > Sorry I should've confirmed earlier but I used the hal_bsp_hw_id() for this > and was able to get what I wanted (i.e a unique hw id which would persist > over flash writes/re-writes and would stay constant for this device). > > I would suggest that the nimble stack set the bd_addr using this by default > if the application does not set the g_dev_addr. This would eliminate the > need for the application developer to obtain (or generate and persist) a > unique bd_addr for their device. > > Thanks, > Pritish > > On Mon, Mar 13, 2017 at 3:07 PM, amit mehta <[email protected]> wrote: > >> On Mon, Mar 13, 2017 at 10:24 PM, will sanfilippo <[email protected]> >> wrote: >>> amit: >>> >>> A couple of things: >>> >>> 1) For the bsp hw id call for the nrf52, there are actually 64-bits (8 >> bytes) worth of unique date. So you dont need to specify BLE_DEV_ADDR_LEN >> for that. Not sure what you want to do the device ID btw. What are you >> going to use it for? >> >> Will, yes, It is 8 bytes, I was suggesting to use the 48 of those 64 bits >> in sample BLE peripheral application (bleprph and/or similiar), so >> that flashing different target boards, do not end up advertising >> the same current default address, i.e. 0x0a,0x0a,0x0a,0x0a,0x0a,0x0a >> >> I think the originator of this thread, Pritish had this issue, which >> I thought could be solved by using the unique device id value provided >> by nrf5xxx devices. >> >> That was the whole rationale behind this. >> >> Thanks, >> Amit >> >> -- >> Sent from Bahamas, while drinking chi-chi and piña colada. >>
