MAC address of peripheral from advertising packet

[jbmillard]

I am creating a peripheral and central.  The peripheral is done and appears to work fine.  The central is in progress.  It will use the serial port to communicate with a host computer system.  One of the things that it has to communicate is the MAC address of the peripheral (printed on the outside of the peripheral's BMD-350) when an advertising packet is received.  The host will then decide to connect of not. 

So far, I can communicate with the host over the serial port just fine, but I'm not sure I understand how to get the MAC address of the peripheral.

I'm using the BMD-350 on a peripheral and the data sheet says the lower three bytes of the MAC address are printed on the chip.  Take a look here https://media.digikey.com/pdf/Data%20Sheets/Rigado%20PDFs/BMD-350_v2.0_1-22-19.pdf on page 12.

What I get in the advertising report (ble_gap_evt_adv_report_t), member peer_addr, doesn't match what is on the outside of the radio.  Nor can I find anything in the advertising packet that matches that address.  Is this the MAC address or some other address.  If not, how can I get the MAC address.

The value of peer_addr is F712931CF0EB (byte 5 -> byte 0).  What is printed on the outside of the chip is AE509162.  I was expecting to see the 0x50, 0x91 and 0x62 somewhere in the peer address.

I'm using nRF5_SDK_16.  For the central, I'm using the Rigado BMD-300 series evaluation kit.  The peripheral is custom hardware using a BMD-350.

Thanks.

[hmolesworth]

A tale of two MAC addresses perhaps. Rigado has defined a MAC address within NRF_UICR as noted, but many of the Nordic examples (eg uart) use the Device Id in NRF_FICR to form a MAC address, which is different and fixed:

// Example:
// BLE MAC Address: Id 71959DCC72DCF09E, Peer 0, Type 1, Addr 9E:F0:DC:72:CC:DD

#if defined(SOFTDEVICE_PRESENT)
   // Get actual BLE address in case it is different from hardware register BLE address
   ble_gap_addr_t device_addr; /**< 48-bit address, LSB format. */
   sd_ble_gap_addr_get(&device_addr);
   snprintf(Settings, sizeof(Settings), "Id %08X%08X, Peer %u, Type %u, Addr %02X:%02X:%02X:%02X:%02X:%02X",
                      NRF_FICR->DEVICEADDR[1], NRF_FICR->DEVICEADDR[0],
                      device_addr.addr_id_peer, device_addr.addr_type, device_addr.addr[0], device_addr.addr[1],
                      device_addr.addr[2], device_addr.addr[3], device_addr.addr[4], device_addr.addr[5]);
#endif

To change this back to the Rigado MAC address, use sd_ble_gap_addr_set() prior to advertising:

// By default the SoftDevice will set an address of type @ref BLE_GAP_ADDR_TYPE_RANDOM_STATIC upon being
// enabled. The address is a random number populated during the IC manufacturing process and remains unchanged
// for the lifetime of each IC.

SVCALL(SD_BLE_GAP_ADDR_SET, uint32_t, sd_ble_gap_addr_set(ble_gap_addr_t const *p_addr));

//ie with p_addr set to Rigado MAC in UICR:
  sd_ble_gap_addr_set((ble_gap_addr_t const *)p_addr);

-

[jbmillard]

Thanks for the explanation.  It looks like I have erased it on my development hardware.  I'll have to find the provisioning doc Rigado references and see what I can do.

[hmolesworth]

Might help to look at a sample UICR update, there are a couple of items to consider. Here's the Reset pin example:

    /* Configure GPIO pads as pPin Reset pin if Pin Reset capabilities desired. If CONFIG_GPIO_AS_PINRESET is not
      defined, pin reset will not be available. One GPIO (see Product Specification to see which one) will then be
      reserved for PinReset and not available as normal GPIO. */
    #if defined (CONFIG_GPIO_AS_PINRESET)
        if (((NRF_UICR->PSELRESET[0] & UICR_PSELRESET_CONNECT_Msk) != (UICR_PSELRESET_CONNECT_Connected << UICR_PSELRESET_CONNECT_Pos)) ||
            ((NRF_UICR->PSELRESET[1] & UICR_PSELRESET_CONNECT_Msk) != (UICR_PSELRESET_CONNECT_Connected << UICR_PSELRESET_CONNECT_Pos))){
            NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos; // Write Enable
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_UICR->PSELRESET[0] = 21;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_UICR->PSELRESET[1] = 21;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos; // Read-only Enable
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            // UICR changes require a reset to be effective
            NVIC_SystemReset();
        }
    #endif

It's a case of waiting for the NVMC signal between steps; the reset would not be required though.