Generation of a serialized ID code at load time.

[Robin]

Hello Nordic Pros,

I am a retired old school hardware guy doing some firmware for an NRF51822 product using the Kiel IDE.  In my prior life, doing similar work, I recollect adding some lines to a linker script in the load section that increments a variable each time a load is performed to a new board, and then using the variable from with the c code as (part of) a unique ID field for the device.  Does anyone have an example or any ideas of how to such a thing these days?  

Thanks in advance,

RobIn@TL

[Turbo J]

Just use FICR->DEVICEID[0] and FICR->DEVICEID[1].

These contain a 64 bit number that will be unique for each chip.

[Robin]

Hello again Turbo, and other Nordic Pro's,

So I have dropped the idea of generating my own unique idea, in favor of using something on the chip.  To test our boards we are using a BLE UART central device that reports a "target" ID number when it connects.  Do any of you know where this ID come from and whether or not is unique among chips, and where in the Nordic documentation maze that this information might reside?

What a zoo trying to find this seemingly simple information!

Thanks

Robin

[Robin]

Hello Einar,

When we test we use a Nordic 10028 usb dongle running the ble uart central code as the uart interface for command/resopnse.  When the central connects, it print an ID number reference as the "target" it is connected to.  What is this number and is it unique for a product serial number?

Thank you

[RK]

You have all the code, take a look and see what it's printing out. The only reference to 'target' I can see in the ble central uart code is 

// Scan is automatically stopped by the connection.
141              NRF_LOG_INFO("Connecting to target %02x%02x%02x%02x%02x%02x",
142                       p_connected->peer_addr.addr[0],
143                       p_connected->peer_addr.addr[1],
144                       p_connected->peer_addr.addr[2],
145                       p_connected->peer_addr.addr[3],
146                       p_connected->peer_addr.addr[4],
147                       p_connected->peer_addr.addr[5]

is this what you're talking about? If so then it is the peer address. If not, what 'target ID' do you mean

[Robin]

Hello RK,

Yes I have the code, and yes this is the "target" ID I am interested in possibly using as our board Serial#.  But this only tells me where it is in the central, not where it comes from in the peripheral.  Nor do I know if it is unique to each board (ie nordic chip). 

Thanks again,

Robin

[Robin]

OK folks,

I found this case that might get me part way to an answer: Case ID: 102111

Quoted from this case:

"By default, the BLE address is derived from the NRF_FICR->DEVICEADDR[] and is of 48 bits length (6      bytes). This registers are randomly generated in our production, and they are unique for each device          (2^46 different combinations, due to MSbits set to '11').

You can read out the address using the API call, "sd_ble_gap_address_get(..);" or reading the FICR-      >DEVICEADDR[x] registers.

Example: My device advertises with "0xE724 08C78790"

DEVICEADDR[0] = 0x08C78790 DEVICEADDR[1] = 0xYYYYA724

The reason why "A7" becomes "E7" is because the specification says that the 2 MSBit of the address    must be set '11' (if you're very interested, see Bluetooth Core v4.0, Vol 3, Part C, chapter 10.8.1.)"

However, I am not sure I can resolve how unique this number is once it is "scrambled"

     Connecting to target 8018236d5ed8

If I read NRF_FICR->DEVICEADDR[x] I get:

     6d231880, 23cad85e

Does it matter that there is word and byte swapping going on here between what is in the FICR and what the central prints?  Will the swapped result be as unique as the original?  Where might his swapping be occurring?  When sent, or when received/printed.

Thanks again,

Robin

[Turbo J]

The softdevice uses little endian addresses, contrary to almost anything else in networking (which usually uses big endian "network byte order"). One needs to remember this when printing MAC addresses that originate from SD.

I think the sd needs the address in little endian format in order to process it properly, especially in cases like "private resolvable addresss". The Cortex-M0 MCU core runs little endian, too.

[Robin]

So, whoever wrote the ble uart central example did not perform the proper bit swapping when printing out this ID?

Again, should I care?  It seems a truly random generated code, bit shuffled, would still be random, so long as the shuffle is always the same, no?

Thanks again all,

Robin

[RK]

yes it's unique, no it doesn't matter whether it's bit and byte swapped or not as long as you use it consistently.