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. >
