• State Verified Answer
  • Replies 5 replies
  • Subscribers 74 subscribers
  • Views 4600 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 128749
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Reading just one bit wrong in the device address on FICR (NRF_FICR->DEVICEADDR[1])

nemunoz

Hi to everyone!

I've been testing the Bluetooth on the nRF52832 DK board with some of the examples and I have saved the mac address (obtained from my smartphone).

In other project I'm just tring to get this mac address from FICR (NRF_FICR->DEVICEADDR[1:0]). Every value fits with the saved mac excepts the bit 15 from DEVICEADDR[1].

I mean, in the phone I see the next mac:

FX:XX:XX:XX:XX:XX

And, If I use NRF_FICR->DEVICEADDR, I get:

7X:XX:XX:XX:XX:XX

(X are to hide my real mac, but every value are equal to each other). The only difference is the first bit, where this bit is 1 when I use the bluetooth with the phone and 0 if I read the internal register. The remaining bits are the same.

I know that bits [31:16] from DEVICEADDR[1] are not used, but the bit 15 is the first bit used and I don't know why I get this value changed!

Why is happening this?

Did I read the register wrong?

Thanks in advance!

Parents
  • 0

    There are requirements in the BLE spec on valid device addresses (IE what you call MAC address). This is found in Core Spec 5.0, Vol 6, Part B, Chapter 1.3.2.1.

    The two most significant bits of the address shall be equal to 1

    If you use random static address (which most projects do) then the two most significant bits must be 1.

    for 7X:XX:XX... this is not the case, as the binary representation of 7x is 0111xxxx.

    I doubt that the production of random values in the FICR takes this requirement into account. Therefore I assume that somewhere in the bellows of the SoftDevice, they simply change this to a valid address by setting the most significant bit, making it FX:XX...

    Note that you are free to change the device address advertised by using sd_ble_gap_address_set.

  • 0 in reply to shibshab

    Thank you, I didn't know that!

    I've just read that part of the document and there are two conditions:

    The first one is, as you said, the two most significant bits must be 1. I can fix this by doing an OR operation:

    (NRF_FICR->DEVICEADDR[1] >> 8) | 0xC0

    And the other one condition is the remaining part (random part) of the address must have at least one 0 and one 1.

    Is there a way to get the valid bluetooth address from SoftDevice (or wherever it are)?

Reply
  • 0 in reply to shibshab

    Thank you, I didn't know that!

    I've just read that part of the document and there are two conditions:

    The first one is, as you said, the two most significant bits must be 1. I can fix this by doing an OR operation:

    (NRF_FICR->DEVICEADDR[1] >> 8) | 0xC0

    And the other one condition is the remaining part (random part) of the address must have at least one 0 and one 1.

    Is there a way to get the valid bluetooth address from SoftDevice (or wherever it are)?

Children
Related
Terms of service