You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Pritish Gandhi <pr...@aylanetworks.com> on 2017/03/08 21:48:14 UTC
MyNewt: NimBLE: Does BD_ADDR have to be unique?
Hi all,
I have a bunch of nrf52dk EVBs that I'm running the sample bleprph app on
and I noticed that all the device seems to have the same BD_ADDR (All
0x0a's). Doesn't each device need to have a unique BD_ADDR and shouldn't
that come from the BLE controller?
I see that the bls_hs_startup_read_bd_addr() always returns with a BD_ADDR
of all 0xa's. Does that mean that this device requires us to self program
the BD_ADDR?
Thanks,
Pritish
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by amit mehta <gm...@gmail.com>.
On Wed, Mar 8, 2017 at 10:48 PM, Pritish Gandhi
<pr...@aylanetworks.com> wrote:
> Hi all,
> I have a bunch of nrf52dk EVBs that I'm running the sample bleprph app on
> and I noticed that all the device seems to have the same BD_ADDR (All
> 0x0a's). Doesn't each device need to have a unique BD_ADDR and shouldn't
> that come from the BLE controller?
> I see that the bls_hs_startup_read_bd_addr() always returns with a BD_ADDR
> of all 0xa's. Does that mean that this device requires us to self program
> the BD_ADDR?
On nRF devices, reading the DEVICE field of FICR register is a good way
to uniquely identify the device (Probably similar thing can be achieved
on other Hardware platform as well. This can be then used in the
advertisement packet. However, If I've understood correctly, the BD_ADDR
on BLE device has to be a public address; i.e. a combination of OUI (24 bits)
and remaining bits (another 24 bits) generated using IEEE 802-2001
specification.
Thanks,
Amit
--
Sent from Bahamas, while drinking chi-chi and piña colada.
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by will sanfilippo <wi...@runtime.io>.
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 <pr...@aylanetworks.com> 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 <gm...@gmail.com> wrote:
>
>> On Mon, Mar 13, 2017 at 10:24 PM, will sanfilippo <wi...@runtime.io>
>> 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.
>>
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by Pritish Gandhi <pr...@aylanetworks.com>.
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 <gm...@gmail.com> wrote:
> On Mon, Mar 13, 2017 at 10:24 PM, will sanfilippo <wi...@runtime.io>
> 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.
>
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by amit mehta <gm...@gmail.com>.
On Mon, Mar 13, 2017 at 10:24 PM, will sanfilippo <wi...@runtime.io> 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.
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by will sanfilippo <wi...@runtime.io>.
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?
2) If you want to put the API in ble_hw.c in hw/drivers/nimble/src/ I would not name them nrf5xxx. I would use the current naming convention of ble_hw_xxxx. I would have this return an int and pass in a pointer to the device address structure (ble_addr_t). This way if the HW does not support having random static addresses or other addresses they can just return -1.
Also, be careful about “endianness" and how you write the code to access the FICR and “copy it” to the device address pointer. There is a structure called “ble_addr_t” and that is what should be passed. I do not think I would have two different API for address type and such. I think I would do something like Szymon mentioned:
int ble_hw_read_random_static_addr(ble_addr_t *addr); /* Remember what Szymon pointed out. You have to set the upper two bits appropriately here. The chip does not do this */
int ble_hw_read_public_addr(ble_addr_t *addr); /* Nordic does not come programmed with one so not sure what I would do here. Either not implement it or have it return -1 */
Note on “endianness” and device address. If you look at ble_addr_t and the macros defined to access it, you will see that the least significant byte is in location 0 (val[0]) and the most significat is in val[5]. I realize it is a bit confusing to talk about endianness with all this but just wanted to point it out.
I do have to say, I am still not sure if these API belong in hw/bsp as opposed to hw/drivers/nimble/nrfxxx/src.
What do others think?
> On Mar 13, 2017, at 1:32 PM, amit mehta <gm...@gmail.com> wrote:
>
> On Mon, Mar 13, 2017 at 6:06 PM, will sanfilippo <wi...@runtime.io> wrote:
>> amit:
>>
>> There is already a function to return the device id. It is named hal_bsp_hw_id() and exists in hw/mcu/nordic/nrf52xxx/src/nrf52_hw_id. Many chips come with some form of unique id which was why this was placed in hw/mcu.
>
> Yes, thank you. I can reuse this API (for demo purposes), something like:
>
> rc = hal_bsp_hw_id(g_dev_addr, BLE_DEV_ADDR_LEN);
> assert(rc == BLE_DEV_ADDR_LEN);
>
>> I do not think I would put the API for ble device address in the same place. Why? Because it is BLE specific. This device id is not. I guess folks can make an argument that a public device address is just a 6-byte MAC address and thus could be used for protocols other than BLE. The random static address is BLE specific though.
>>
>>
>> My vote would be to place this API in one of the following directories:
>> hw/drivers/nimble/nrf5xxx/src/ /* there is a file called ble_hw.c in this dir that might be a good fit */
>> hw/mcu/nordic/nrf5xxx/src/ /* depending on whether we think this should be a hal */
>
> Agree with you and I'm also more inclined towards:
> hw/drivers/nimble/nrf5xxx/src
>
>> Finally, as for the naming convention, if this thing is going to be called generically by code outside a nordic specific directory I would not name it nrf_xxx. Once we have consensus where to place these API I think the name will follow...
>
> if above is agreed, then nrf5xxx_get_devaddr_type() and
> nrf5xxx_get_devid() might be okay.
>
> Thanks,
> Amit
> --
> Sent from Bahamas, while drinking chi-chi and piña colada.
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by will sanfilippo <wi...@runtime.io>.
Amit:
I do not have a really strong opinion here, so would be interested to hear what others think. I am referring to the API. Certainly, the “get_devaddr” API is appropriate for the nrf chips but not sure if we would want to have multiple API in case we want to port this to other chips and also to support the fact that a device can have both a random address and public address.
> On Mar 13, 2017, at 2:16 PM, amit mehta <gm...@gmail.com> wrote:
>
>> if above is agreed, then nrf5xxx_get_devaddr_type() and
>> nrf5xxx_get_devid() might be okay.
>
> Small typo; please read nrf5xxx_get_devid() as nrf5xxx_get_devaddr()
>
> Thanks,
> Amit
>
> --
> Sent from Bahamas, while drinking chi-chi and piña colada.
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by amit mehta <gm...@gmail.com>.
> if above is agreed, then nrf5xxx_get_devaddr_type() and
> nrf5xxx_get_devid() might be okay.
Small typo; please read nrf5xxx_get_devid() as nrf5xxx_get_devaddr()
Thanks,
Amit
--
Sent from Bahamas, while drinking chi-chi and piña colada.
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by amit mehta <gm...@gmail.com>.
On Mon, Mar 13, 2017 at 6:06 PM, will sanfilippo <wi...@runtime.io> wrote:
> amit:
>
> There is already a function to return the device id. It is named hal_bsp_hw_id() and exists in hw/mcu/nordic/nrf52xxx/src/nrf52_hw_id. Many chips come with some form of unique id which was why this was placed in hw/mcu.
Yes, thank you. I can reuse this API (for demo purposes), something like:
rc = hal_bsp_hw_id(g_dev_addr, BLE_DEV_ADDR_LEN);
assert(rc == BLE_DEV_ADDR_LEN);
> I do not think I would put the API for ble device address in the same place. Why? Because it is BLE specific. This device id is not. I guess folks can make an argument that a public device address is just a 6-byte MAC address and thus could be used for protocols other than BLE. The random static address is BLE specific though.
>
>
> My vote would be to place this API in one of the following directories:
> hw/drivers/nimble/nrf5xxx/src/ /* there is a file called ble_hw.c in this dir that might be a good fit */
> hw/mcu/nordic/nrf5xxx/src/ /* depending on whether we think this should be a hal */
Agree with you and I'm also more inclined towards:
hw/drivers/nimble/nrf5xxx/src
> Finally, as for the naming convention, if this thing is going to be called generically by code outside a nordic specific directory I would not name it nrf_xxx. Once we have consensus where to place these API I think the name will follow...
if above is agreed, then nrf5xxx_get_devaddr_type() and
nrf5xxx_get_devid() might be okay.
Thanks,
Amit
--
Sent from Bahamas, while drinking chi-chi and piña colada.
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by will sanfilippo <wi...@runtime.io>.
amit:
There is already a function to return the device id. It is named hal_bsp_hw_id() and exists in hw/mcu/nordic/nrf52xxx/src/nrf52_hw_id. Many chips come with some form of unique id which was why this was placed in hw/mcu.
I do not think I would put the API for ble device address in the same place. Why? Because it is BLE specific. This device id is not. I guess folks can make an argument that a public device address is just a 6-byte MAC address and thus could be used for protocols other than BLE. The random static address is BLE specific though.
My vote would be to place this API in one of the following directories:
hw/drivers/nimble/nrf5xxx/src/ /* there is a file called ble_hw.c in this dir that might be a good fit */
hw/mcu/nordic/nrf5xxx/src/ /* depending on whether we think this should be a hal */
Finally, as for the naming convention, if this thing is going to be called generically by code outside a nordic specific directory I would not name it nrf_xxx. Once we have consensus where to place these API I think the name will follow...
> On Mar 11, 2017, at 8:51 AM, amit mehta <gm...@gmail.com> wrote:
>
> On Thu, Mar 9, 2017 at 8:56 AM, Szymon Janc <sz...@codecoup.pl> wrote:
>> Hi,
>>
>> On 9 March 2017 at 02:52, Christopher Collins <ch...@runtime.io> wrote:
>>> Hi Pritish,
>>>
>>> On Wed, Mar 08, 2017 at 02:47:01PM -0800, Pritish Gandhi wrote:
>>>> So it seems like the nrf52dk should have a RANDOM STATIC address which
>>>> should be programmed once in the hardware. However I'm not able to read
>>>> that address from the host.
>>>> Would appreciate any help.
>>>
>>> You can configure the device with a random static address using this
>>> function:
>>>
>>> int ble_hs_id_set_rnd(const uint8_t *rnd_addr)
>>>
>>> (http://mynewt.apache.org/latest/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd/)
>>>
>>> The argument that you pass to this function would be the address
>>> that was preprogrammed into the board. I'm afraid I am not sure how to
>>> read this preprogrammed address out of the nRF hardware.
>>
>> There is FICR register in nRF5X that can be used as a permanent source
>> for static random
>> address (it is basically a random number so we would still need to
>> mask bits for proper static
>> random address). The thing is that there is no standard HCI command
>> for reading static
>> random address from controller. So we would need to have vendor
>> command for this or
>> use global for time being.
>
> I think, there is a use case to utilize the Nordic's random static
> (FICR::DEVICEADDRTYPE = 1) device address to use in advertisement
> packet. I was wondering, where should I add (if agreed) these APIs
> (say, nrfxx_get_devaddr_type(), nrfxx_get_devaddr(), nrfxx_get_devid() ) ?
>
> Comments please.
>
> Thanks,
> Amit
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by amit mehta <gm...@gmail.com>.
On Thu, Mar 9, 2017 at 8:56 AM, Szymon Janc <sz...@codecoup.pl> wrote:
> Hi,
>
> On 9 March 2017 at 02:52, Christopher Collins <ch...@runtime.io> wrote:
>> Hi Pritish,
>>
>> On Wed, Mar 08, 2017 at 02:47:01PM -0800, Pritish Gandhi wrote:
>>> So it seems like the nrf52dk should have a RANDOM STATIC address which
>>> should be programmed once in the hardware. However I'm not able to read
>>> that address from the host.
>>> Would appreciate any help.
>>
>> You can configure the device with a random static address using this
>> function:
>>
>> int ble_hs_id_set_rnd(const uint8_t *rnd_addr)
>>
>> (http://mynewt.apache.org/latest/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd/)
>>
>> The argument that you pass to this function would be the address
>> that was preprogrammed into the board. I'm afraid I am not sure how to
>> read this preprogrammed address out of the nRF hardware.
>
> There is FICR register in nRF5X that can be used as a permanent source
> for static random
> address (it is basically a random number so we would still need to
> mask bits for proper static
> random address). The thing is that there is no standard HCI command
> for reading static
> random address from controller. So we would need to have vendor
> command for this or
> use global for time being.
I think, there is a use case to utilize the Nordic's random static
(FICR::DEVICEADDRTYPE = 1) device address to use in advertisement
packet. I was wondering, where should I add (if agreed) these APIs
(say, nrfxx_get_devaddr_type(), nrfxx_get_devaddr(), nrfxx_get_devid() ) ?
Comments please.
Thanks,
Amit
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by will sanfilippo <wi...@runtime.io>.
I do not think I am adding much here but the BLE stack definitely “punted” on the method for providing the public device address. It is up to the product developer to determine how to get the public address from storage on the device. For the nordic chips there are non-volatille registers that can be written but these can be erased (UICR).
What I always suspected folks would do with the nordic chips is that they would get their public addresses programmed into FICR. FICR cannot be erased. There is a DEVICEADDRTYPE register (which tells you if the address is public or random) and the address itself. As folks have pointed out, the development boards come programmed with a random address in this space. We could provide a hw-based API in the controller to read this information if desired.
Personally, I do not think the public address should be put into FCB nor UICR as these can be erased. Thus, an API to store this information would not be needed. You really want to make sure your public address is not eraseable by any means. Just my opinion of course. I understand that, for development, being able to program a board with some unique public address would be desirable. I thought folks would just add their own function to do this as it is quite simple to do. You would “hand-program" a UICR register on your development board and then add code to read it.
On a final note, it is interesting that this discussion came up as I am attending a Linaro Connect conference and there has been discussion to add vendor-specific commands to do the following:
* Read static random addresses from the controller.
* Set the public device address to be used by the controller.
Of course that will not help you getting the actual public address to send to the controller :-) Nor does that store the public address into non-volatile memory.
> On Mar 8, 2017, at 11:56 PM, Szymon Janc <sz...@codecoup.pl> wrote:
>
> Hi,
>
> On 9 March 2017 at 02:52, Christopher Collins <ch...@runtime.io> wrote:
>> Hi Pritish,
>>
>> On Wed, Mar 08, 2017 at 02:47:01PM -0800, Pritish Gandhi wrote:
>>> So it seems like the nrf52dk should have a RANDOM STATIC address which
>>> should be programmed once in the hardware. However I'm not able to read
>>> that address from the host.
>>> Would appreciate any help.
>>
>> You can configure the device with a random static address using this
>> function:
>>
>> int ble_hs_id_set_rnd(const uint8_t *rnd_addr)
>>
>> (http://mynewt.apache.org/latest/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd/)
>>
>> The argument that you pass to this function would be the address
>> that was preprogrammed into the board. I'm afraid I am not sure how to
>> read this preprogrammed address out of the nRF hardware.
>
> There is FICR register in nRF5X that can be used as a permanent source
> for static random
> address (it is basically a random number so we would still need to
> mask bits for proper static
> random address). The thing is that there is no standard HCI command
> for reading static
> random address from controller. So we would need to have vendor
> command for this or
> use global for time being.
>
>>
>>> On Wed, Mar 8, 2017 at 1:48 PM, Pritish Gandhi <pr...@aylanetworks.com>
>>> wrote:
>>>> I have a bunch of nrf52dk EVBs that I'm running the sample bleprph app on
>>>> and I noticed that all the device seems to have the same BD_ADDR (All
>>>> 0x0a's). Doesn't each device need to have a unique BD_ADDR and shouldn't
>>>> that come from the BLE controller?
>>>> I see that the bls_hs_startup_read_bd_addr() always returns with a BD_ADDR
>>>> of all 0xa's. Does that mean that this device requires us to self program
>>>> the BD_ADDR?
>>
>> The only way to change the device's public address (BD_ADDR) is by
>> hardcoding it in main. This is not a great solution, so we'll
>> definitely need to add support for reading the public address from flash
>> at startup.
>
> Indeed. I was thinking on some sort of 'BT storage' API that would
> hide storage details
> from BT stack and would be implemented by app (or some other component). This
> could include reading public (or static random) address too and should
> simplify devices
> provisioning.
>
> --
> pozdrawiam
> Szymon K. Janc
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by Szymon Janc <sz...@codecoup.pl>.
Hi,
On 9 March 2017 at 02:52, Christopher Collins <ch...@runtime.io> wrote:
> Hi Pritish,
>
> On Wed, Mar 08, 2017 at 02:47:01PM -0800, Pritish Gandhi wrote:
>> So it seems like the nrf52dk should have a RANDOM STATIC address which
>> should be programmed once in the hardware. However I'm not able to read
>> that address from the host.
>> Would appreciate any help.
>
> You can configure the device with a random static address using this
> function:
>
> int ble_hs_id_set_rnd(const uint8_t *rnd_addr)
>
> (http://mynewt.apache.org/latest/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd/)
>
> The argument that you pass to this function would be the address
> that was preprogrammed into the board. I'm afraid I am not sure how to
> read this preprogrammed address out of the nRF hardware.
There is FICR register in nRF5X that can be used as a permanent source
for static random
address (it is basically a random number so we would still need to
mask bits for proper static
random address). The thing is that there is no standard HCI command
for reading static
random address from controller. So we would need to have vendor
command for this or
use global for time being.
>
>> On Wed, Mar 8, 2017 at 1:48 PM, Pritish Gandhi <pr...@aylanetworks.com>
>> wrote:
>> > I have a bunch of nrf52dk EVBs that I'm running the sample bleprph app on
>> > and I noticed that all the device seems to have the same BD_ADDR (All
>> > 0x0a's). Doesn't each device need to have a unique BD_ADDR and shouldn't
>> > that come from the BLE controller?
>> > I see that the bls_hs_startup_read_bd_addr() always returns with a BD_ADDR
>> > of all 0xa's. Does that mean that this device requires us to self program
>> > the BD_ADDR?
>
> The only way to change the device's public address (BD_ADDR) is by
> hardcoding it in main. This is not a great solution, so we'll
> definitely need to add support for reading the public address from flash
> at startup.
Indeed. I was thinking on some sort of 'BT storage' API that would
hide storage details
from BT stack and would be implemented by app (or some other component). This
could include reading public (or static random) address too and should
simplify devices
provisioning.
--
pozdrawiam
Szymon K. Janc
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by Christopher Collins <ch...@runtime.io>.
Hi Pritish,
On Wed, Mar 08, 2017 at 02:47:01PM -0800, Pritish Gandhi wrote:
> So it seems like the nrf52dk should have a RANDOM STATIC address which
> should be programmed once in the hardware. However I'm not able to read
> that address from the host.
> Would appreciate any help.
You can configure the device with a random static address using this
function:
int ble_hs_id_set_rnd(const uint8_t *rnd_addr)
(http://mynewt.apache.org/latest/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd/)
The argument that you pass to this function would be the address
that was preprogrammed into the board. I'm afraid I am not sure how to
read this preprogrammed address out of the nRF hardware.
> On Wed, Mar 8, 2017 at 1:48 PM, Pritish Gandhi <pr...@aylanetworks.com>
> wrote:
> > I have a bunch of nrf52dk EVBs that I'm running the sample bleprph app on
> > and I noticed that all the device seems to have the same BD_ADDR (All
> > 0x0a's). Doesn't each device need to have a unique BD_ADDR and shouldn't
> > that come from the BLE controller?
> > I see that the bls_hs_startup_read_bd_addr() always returns with a BD_ADDR
> > of all 0xa's. Does that mean that this device requires us to self program
> > the BD_ADDR?
The only way to change the device's public address (BD_ADDR) is by
hardcoding it in main. This is not a great solution, so we'll
definitely need to add support for reading the public address from flash
at startup.
Chris
Re: MyNewt: NimBLE: Does BD_ADDR have to be unique?
Posted by Pritish Gandhi <pr...@aylanetworks.com>.
Hi again,
So it seems like the nrf52dk should have a RANDOM STATIC address which
should be programmed once in the hardware. However I'm not able to read
that address from the host.
Would appreciate any help.
Thanks,
Pritish
On Wed, Mar 8, 2017 at 1:48 PM, Pritish Gandhi <pr...@aylanetworks.com>
wrote:
> Hi all,
> I have a bunch of nrf52dk EVBs that I'm running the sample bleprph app on
> and I noticed that all the device seems to have the same BD_ADDR (All
> 0x0a's). Doesn't each device need to have a unique BD_ADDR and shouldn't
> that come from the BLE controller?
> I see that the bls_hs_startup_read_bd_addr() always returns with a BD_ADDR
> of all 0xa's. Does that mean that this device requires us to self program
> the BD_ADDR?
> Thanks,
> Pritish
>