How program serialnumber on nRF54L15 in factory setup

[Tommy F Kristensen]

Hi Nordic support

We have ealier used your legasy SDK16.0 on nRF52840 where we where programming our device serial number in the UIRC area. 

NRF_UICR->CUSTOMER[0-4] where NRF_UIRC is at adress    0x10001000UL

It was done by generating a small hex file that contains the UIRC data and then flashed with NRJPROG 

I can see that the new way on NRF Connect SDK 2.9.0 and nRF54L15 the UIRC register is not present and it is advised to use the  NVC 

Im expect I should use the zephyr settings API to get the production parameters like serialnumber manufactor model etc.

I have added below in my prj.conf, to support settings api

# Below is setup to let DIS information be read from settings

CONFIG_BT_SETTINGS=y

CONFIG_SETTINGS_RUNTIME=y

CONFIG_SETTINGS=y

CONFIG_SETTINGS_NONE=y

CONFIG_BT_DIS_SETTINGS=y

CONFIG_BT_DIS_STR_MAX=21

Is there a tool to set the serialnumber, hw_rev, model_number in flash, so it can be done in production ? 

Can i use nrfjprog with a specific address ?

Do you have an example on how this can be done ? 

Best Regards

Tommy F Kristensen

PS. I have hardcoded it in the prj.conf as below, to do testing, but need to be able to generate the serial dynamically

# Bluetooth Device Settings config

CONFIG_BT_DIS=y

CONFIG_BT_DIS_PNP=n

CONFIG_BT_DIS_MODEL="0007-00-000-001"

CONFIG_BT_DIS_MANUF="MyFirm"

CONFIG_BT_DIS_SERIAL_NUMBER=y

CONFIG_BT_DIS_FW_REV=y

CONFIG_BT_DIS_HW_REV=n

CONFIG_BT_DIS_SW_REV=y

CONFIG_BT_DIS_SERIAL_NUMBER_STR="65533-255-311540"

CONFIG_BT_DIS_FW_REV_STR="0.0.0"

#CONFIG_BT_DIS_HW_REV_STR="Zephyr Hardware"

CONFIG_BT_DIS_SW_REV_STR="0.0.0"

[Hung Bui]

Hi Tommy, 

This is something we are looking at to find a solution. 

Until we find a better solution you will need to use the flash area to store the serial number. You can either store it using NVS or Settings, or other nonvolatile module to store the serial number. 
It can be a challenge if you also use the module to store other data because NVS or settings will move the data around for garbage collection, wear leveling. 
If you configure a partition only for storing the manufacturing data separated from any other flash activity in the application and don't do any other activity on the partition,I think it should be safe. And you should be able to use the programmer to write a hex file directly to the partition's address. 

[Tommy F Kristensen]

Hi Hung Bui 

 Im loooking into if it is possbile to store the serial number and other factory specific data in the UICR ->OTP area. 

It has 320 adresses reserved for OTP. 

I will use the nrfutil to set the serial numner

nrfutil device x-write --address 0x00FFD504 --value 0x0100FF19

or 

nrfjprog  --program serial.hex // that flashes the hexfile containing the serial number etc for the device

Then read it back in the code like this

Best Regards

Tommy F Kristensen

[Hung Bui]

Hi Tommy, 
I'm aware of the OTP register in the UICR. But the reason that the name changed from CUSTOMER[] to OTP[] is that the OS/drivers will also use some of the registers to store data. We are working on defining where the safe location for custom user data is.  

[Tommy F Kristensen]

Hi Hung Bui 

Thanks for you answer. 

We are planning to go into mass a month from now, so we would really appriciate that this could be prioritized.

We are using the serial numbers as unique identifiers of our products in the system, so it is quite important that we have a  solution.

We only need 4 32 bit registers, to store the data in, so if you have some of the OTP registers that could be reserved to the costumer it would be great

Best Regards

Tommy  F Kristensen

[Hung Bui]

Hi Tommy, 
I has reported the request internally. The team is looking at it. But I am not sure if we will have a solution available in your time frame. 

From my point of view, if you decide to use the OTP for the purpose, the biggest risk is when we start using it in the future for other modules in NCS and you need to do DFU update there can be a conflict.  
When you do DFU update to the newer firmware and there will be a chance that the firmware will try to write to the OTP registers that you already written. 

However the chance is quite small, from my point of view, as you only use 4 out of 320 registers. And there still a solution that you can modify the firwmare to avoid using the same area before you do DFU update. 

I would suggest if we don't come up with a office solution,  you can just use the OTP (if using the flash is proven to be too much work). My suggestion is to choose the registers at the bottom of the OTP area. 
This is just my personal suggestion, as the proper way of doing this for now is still using flash. I can't guarantee it will not cause any problem in the future.