Zigbee MAC vs IEEE.EUI64 - what is the difference and is the BLE mac the same?

[Envin]

I have my code working correctly and for site testing of the first 20 units the customer wants to know the

MAC address so that any glitches can be identified to a particular device by its MAC address.

I have read, and been told, conflicting information that the EUI64 is NOT the MAC address and that

the MAC address can be derived from the first 6 octets of the EUI64.

My code prints out the EUI64 when the board boots up so we could use this if it can be used to

identify the mac address.

What I'd also like to know is (1) whether the BLE mac address is the same as the Zigbee mac address

as they may share part of the same radio interface hardware for IEEE802.15.4 and IEEE802.15.1.

If there is a simple way to get the Zigbee mac address can someone tell me ?!

[Edvin]

Hello,

Just for clarification:

There isn't really something called BLE MAC addresses. MAC is not mentioned in the BLE specification. We usually call it the BLE address. 

An nRF's default BLE address is generated from the NRF_FICR->DEVICEADDR[n], n = <0..1>.

These two registers make up 8 bytes, but only 6 of these are used. In addition, the 2 most significant bits depends on the address type, and are overruled by the device type, where the most common (in our samples) is a random static address, meaning the most significant bits of this 6 byte address will be '1' (0b11)

To use my DK as an example, if I read out 0x100000A4 (DEVICEADDR[0]) it is 0x945FFEA5, and 0x100000A8 (DEVICEADDR[1] is EA9829C7:

When I read out the address actually being used by the bluetooth stack, I can use:

    bt_addr_le_t my_addr;
    size_t count;

    bt_id_get(&my_addr, &count);

    LOG_INF("my addr %02x:%02x:%02x:%02x:%02x:%02x", my_addr.a.val[0],
                                                    my_addr.a.val[1],
                                                    my_addr.a.val[2],
                                                    my_addr.a.val[3],
                                                    my_addr.a.val[4],
                                                    my_addr.a.val[5]);

And it prints:

[00:00:00.012,908] <inf> app: my addr a5:fe:5f:94:c7:e9

So you can see that addr[0] matches the last byte in DEVICEADDR[0], the next byte is the second  last byte, etc. Then the 5th byte is the last line on DEVICEADDR[1], and the last byte, myaddr.a.val[5] is the second last byte, 0x29, but the two most significant bits are '11', so 0x29 becomes 0xE9 (0b 0010 1001 -> 0b 1110 1001).

When it comes to the Zigbee address:

I used this snippet to print the address:

    zb_64bit_addr_t my_addr;
    zb_get_long_address(my_addr);

    LOG_INF("my_addr(1): %02x:%02x:%02x:%02x", my_addr[0],
                                                my_addr[1],
                                                my_addr[2],
                                                my_addr[3]);
    LOG_INF("my_addr(2): %02x:%02x:%02x:%02x", my_addr[4],
                                                my_addr[5],
                                                my_addr[6],
                                                my_addr[7]);

And it printed:

I: my_addr(1): c6:4c:de:48
I: my_addr(2): 24:36:ce:f4

(just splitting it in two because LOG_INF() takes maxiumum 6 input parameters)

If you look at the NRF_FICR->DEVICEID[n], n=<0..1> registers, in my case they are:

The last 3 bytes of my_addr(2) are standard to nordic devices (corresponds to MAC addr). The remaining 55 bytes are from the DEVICEID[n] registers, as you can see.

I see now that it is probably easier to compare both the Zigbee and BLE addresses if I printed them in the opposite order (5 -> 0 and 7 -> 0 instead of 0 ->5 and 0 -> 7). You can do that when looking at your addresses. 

Best regards,

Edvin