Impact of eraseuicr on Bootloader

[beemavishnu]

Hello,

 

I am using nRF52840, SDK_16.0.0, SoftDevice S140 V7.0.1 and Segger for flashing the image. I am using ‘ble_app_blinky’.

 

In our setup we load merged hex file with “MBR + SoftDevice” + BLE application + “Secure Serial Bootloader” + “Bootloader Settings Page”.

I loaded merged hex file and it worked fine. Later to crosscheck I executed below commands

 

nrfjprog -f NRF52 –eraseuicr

 

From then I am not seeing any BLE activities.

 

My queries are:

1) As per below link, as part of Nordic factory, whether UICR registers are written with some data (Calibration, Hardware version etc..). In this case should not we use ‘eraseusir’ at any time ?

nrfjprog -f NRF52 –eraseuicr

https://devzone.nordicsemi.com/f/nordic-q-a/50948/erase-uicr-and-merge-bootloader-problem

 

2) (Or) Whether eraseuicr should be executed very first time before loading any hex file.

 

Thanks & Regards

Vishnu Beema

[Edvin]

Hello Vishnu,

1) The UICR is not written during production, but there is another set of registers, the FICR registers. The FICR registers should not be tampered with. They are in fact written during the production of the chip. But the UICR you are "free to use as you like". At least almost. You can see here that there are some registers that are reserved for Nordic Firmware design, and some registers that are just reserved. 

But as I mentioned, the UICR is not programmed during the production of the chips. In addition, every time you run "nrfjprog --eraseall", the UICR registers are also erased. (the FICR registers are not erased using --eraseall.

2) Yes. That is probably what you are seeing. You mention a bootloader, and that is probably the reason it fails when you erase the UICR after programming your bootloader hex file, and an application that supports a bootloader. You see, the bootloader uses one of the UICR registers to hold the start address of the bootloader, and some applications such as the buttonless_dfu uses this register to check that there is a bootloader present. So the reason it worked before you erased the UICR is that the bootloader hex file also will write to the UICR, or the NRFFW register, to be more precise, to tell the application and softdevice where the bootloader starts.

You can check what is stored in the uicr after you programmed the merged hex file by using "nrfjprog --readuicr my_uicr.hex". You will see something like this (except this is from an nRF52832) :

my_uicr.hex

You can see that there is also something around 0x10001200, which is the reset button configurations, which is also stored in the UICR. 

So there are a lot of registers in the UICR that is reserved for the customers (you), but they are intended to be written to in (your) production, and then remain the same for the lifetime of the product. 

Best regards,

Edvin

[beemavishnu]

Thank a lot for your quick and detailed explanation.