Generation of a serialized ID code at load time.

RE: Generation of a serialized ID code at load time.

awneil — Fri, 12 Jul 2019 08:24:54 GMT

Apparently, the DEVICEID is not guaranteed to be unique:

https://devzone.nordicsemi.com/f/nordic-q-a/49664/deviceid-is-unique---but-is-it-random/198038#198038

😮

RE: Generation of a serialized ID code at load time.

RK — Sun, 23 Jun 2019 22:40:31 GMT

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.

RE: Generation of a serialized ID code at load time.

Robin — Sun, 23 Jun 2019 15:17:52 GMT

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

RE: Generation of a serialized ID code at load time.

Turbo J — Sun, 23 Jun 2019 08:20:09 GMT

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.

RE: Generation of a serialized ID code at load time.

Robin — Sun, 23 Jun 2019 06:57:30 GMT

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

RE: Generation of a serialized ID code at load time.

Robin — Sun, 23 Jun 2019 04:44:53 GMT

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

RE: Generation of a serialized ID code at load time.

RK — Sun, 23 Jun 2019 01:25:52 GMT

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

RE: Generation of a serialized ID code at load time.

Robin — Sat, 22 Jun 2019 14:57:46 GMT

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

RE: Generation of a serialized ID code at load time.

Einar Thorsrud — Sat, 22 Jun 2019 10:18:46 GMT

Hi Robin,

Can you elaborate on what you mean by "target" ID? Is it the BLE MAC address, or something else? This is the address that is seen by the BLE peer device. If it is the BLE MAC address, then this comes from the DEVICEADDR registers in FICR (if using the default random static BLE address), and is randomly generated for each device. Given the size (48 bit) you can consider it unique for most practical purposes.

If you want an incrementing serial number (as it seems from your original question), then it makes sense to do as RK suggested: put this in the UICR, and make sure that you increment the number for each device in your production programming.

RE: Generation of a serialized ID code at load time.

Robin — Fri, 21 Jun 2019 13:30:09 GMT

Hello Einar,

I understand this, but it is not the same as the "target" ID that the central shows when connecting. Please explain the difference and whether the "target" ID is unique enough to use as a product serial number, and if so, how to access it other than this central message?

Thank you kindly,

Robin@TL

RE: Generation of a serialized ID code at load time.

Einar Thorsrud — Fri, 21 Jun 2019 06:21:15 GMT

Hi,

The nRF51 has a 64 bit DEVICE ID in FICR (see page 22 in nRF51 Reference Manual v3.0.1).

RE: Generation of a serialized ID code at load time.

Robin — Thu, 20 Jun 2019 16:44:11 GMT

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

RE: Generation of a serialized ID code at load time.

RK — Sun, 16 Jun 2019 21:44:10 GMT

There's a customer area in the UICR you can use, there's 32 x 32 bit words there. The easiest way to program that would be to have a custom step after you flash the main software onto the board which just emits the right Segger commands to write a value in there. You can do that with the segger directly or you might find something useful in the Nordic python driver, don't know as I've never looked at it.

Yes you could also do it by stuffing a constant into a linker script and making a section which maps to the UICR and putting the value in however that's probably going to be more of a pain especially as most of the IDEs abstract the whole link process away.

I'd probably put this step in as part of the post flash board testing.

RE: Generation of a serialized ID code at load time.

Robin — Sun, 16 Jun 2019 14:20:39 GMT

Hello Turbo,

Thanks for that info. The ID needs to be easily recognizable ID for our customers. So we need to generate. It is also being used as a count of boards in the field.

Any other ideas are greatly appreciated.

Robin@TL

RE: Generation of a serialized ID code at load time.

Turbo J — Sun, 16 Jun 2019 09:48:16 GMT

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

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