Example code to write to UICR

I am trying to store data to the UICR using SDK16, mesh SDK 4.2.0 and the nRF52840 chip.

I want to write to the UICR once on runtime and never again. To avoid messing with the softdevice, I am trying to write to the UICR before calling ble_stack_init() and after __LOG_INIT to get logs working.

This is the code:

NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

uint32_t * consumer0 = (uint32_t *) 0x10001080;
*consumer0 = 0x00000005;

NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "%d\n", *consumer0);

NVIC_SystemReset();

So we put the NVMC in Write enable, wait for it to be ready, write to consumer0, put it in Read enable, wait for it to be ready and reset the device. I can see 5 logged to Segger console.

Then I comment what I don't need:

//NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
//while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

uint32_t * consumer0 = (uint32_t *) 0x10001080;
//*consumer0 = 0x00000005;

//NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
//while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "%d\n", *consumer0);

//NVIC_SystemReset();

And I see -1 logged to Segger console, meaning the flash still has the 0xFFFF on that position. I can confirm it on Segger Memory explorer that 10001080 is never filled with the data I wanted. Am I doing something wrong?

Parents
  • Beware that sometimes Flash memory is cached by Segger and does not exactly show what you expect. I refer explicitly to 

    exec SetAllowFlashCache =0   

    Have you tried exiting Segger and starting it again to see if flash isn really set?

    In addition add a check in your coded to see what the value is.

    Finally choose your values wisely since if there PREVIOUS value of customer[0] was FFFFFFFF this will work BUT if the previous value was 05000000 it will not since write to flash can only reset bits. It is necessary to erase flash to set it to FFFFFFF

  • I tried exiting Segger and rechecking the memory, all was the same. I also added a small check for looking for the change in the flash like so:

    //NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
    //while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
    
    uint32_t * consumer0 = (uint32_t *) 0x10001080;
    //*consumer0 = 0x00000005;
    if(*consumer0 == 5){
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "*consumer0 = 5\n");
    }
    else {
        __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Flash not correct, *consumer0 = %d\n", *consumer0);
    }
    
    //NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
    //while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
    
    //NVIC_SystemReset();

    As soon as I comment the lines commented in the code I get the second __LOG: Flash not correct, *consumer0 = -1

  • Learner said:
    Can I use the same code snippet with other Soc version e.g. QDAAA0?

    If you refer to the code snippet to write to flash, then yes. Writing to flash (including the UICR) is the same for all revisions. (As mentioned deleting the UICR page is special though, as it can only be done with a full chip erase).

    Learner said:
    Also, when I use nRF Programmer v2.3.3 to flash the same debug version of the firmware merged.hex the UICR content gets erased. However, when I use SES Nordic Edition v5.60 to flash the same debug version merged.hex the content of the UICR is preserved.

    The nRF Connect Programmer version >= 2.0.0 unfortunately always does an erase on write, and this is a full chip erase and not a sector erase (erasing only sectors to be writtne to). This has been reported, but is unfortunately the case at the moment. So you must use another tool in order to program without erasing the whole chip (including the UICR). A simple tool for this is nrfjprog.

  • Hi Thorsrud,

    Thank you for your support.

    The nRF Connect Programmer version >= 2.0.0 unfortunately always does an erase on write, and this is a full chip erase and not a sector erase (erasing only sectors to be writtne to).

    Unfortunately, this is what we were planning to use. It looks like we will have to go to plan B.

    A simple tool for this is nrfjprog.

    nrfjprog is plan B. I have never used it before. I have now downloaded v10.15.

    nrfjprog version: 10.15.4 external
    JLinkARM.dll version: 7.58b

    I have read the documentation but I am still not sure how to use 'sectorerase'. I would like to use the following command line to flash our firmware using nrfjprog and avoiding to erase UICR,

    nrfjprog -f NRF52 --program merged.hex –-sectorerase <????>

    Thank you for your help.

    Kind regards
    Mohamed

  • Hi Mohamed,

    What you have found is correct (specifying family is optional). Specifically, nrfjprog never does an erase without "being told so", so that is no problem. To just flash your firmware if there was nothing there before, you can simply use "nrfjprog --program <hexfile>". If you want to overwrite an existing application (the pages you are writing to are not all FFFF), then add --sectorerase like this: "nrfjprog --program <hex> --sectorerase". With this, all pages that will be written to are erased first, but non of the others, and then the hex file is written.

  • Hi Thorsrud,

    I see, I thought I needed to explicitly specify the pages I wanted to erase because 'sectorerase expects arguments. so I don't need to specify the pages number after --sectorerase at the end of the command line. 

    I tried the command 

    nrfjprog -f NRF52 --program merged.hex –-sectorerase

    First I got this error,

    C:\Sandbox\HomeBeacon_dev_sb\build_nrf52833dk_nrf52833_v133_rel\zephyr>nrfjprog -f NRF52 --program merged.hex --sectorerase
    ERROR: The operation attempted is unavailable due to readback protection in
    ERROR: your device. Please use --recover to unlock the device.
    NOTE: For additional output, try running again with logging enabled (--log).
    NOTE: Any generated log error messages will be displayed.

    Then I tried

    C:\Sandbox\HomeBeacon_dev_sb\build_nrf52833dk_nrf52833_v133_rel\zephyr>nrfjprog -f NRF52 --recover --program merged.hex --sectorerase
    ERROR: Two arguments were provided that cannot be combined. Use --help to read
    ERROR: about the valid argument combinations.
    NOTE: For additional output, try running again with logging enabled (--log).
    NOTE: Any generated log error messages will be displayed.

    Finally, I tried

    C:\Sandbox\HomeBeacon_dev_sb\build_nrf52833dk_nrf52833_v133_rel\zephyr>nrfjprog -f NRF52 --recover --program merged.hex
    Recovering device. This operation might take 30s.
    Parsing image file.
    WARNING: A programming operation has been performed without --verify.
    WARNING: Programming can fail without error.

    But I ended up erasing the content of the UICR which I wanted to avoid.

    What am I doing wrong?

    Actually, I think the reason the command nrfjprog -f NRF52 --program merged.hex --sectorerase did not work it is because the device had the release version of the code which has CONFIG_DEBUG_PORT_ACCESS=n.

    So, I flashed the debug version (CONFIG_DEBUG_PORT_ACCESS=y) into the device then I tried the same command nrfjprog -f NRF52 --program merged.hex --sectorerase again and this time the UICR register was not erased. So, we can flash the device without erasing the whole flash including the UICR only if  CONFIG_DEBUG_PORT_ACCESS=y.

    Kind regards
    Mohamed
  • Hi Mohamed,

    This is a special case. Reading the output from nrfjprog you see that readback protection is enabled (APPROTECT). And the only way to disable it is to perform a full chip erase (nrfjprog --recover). Clearly you want to avoid this issue in the future, as you want to be able to program/debug several times after the initial programming:

    • If you are using older revisions, simply do not enable APPROTECT. As long as it is never enabled, you will not have this problem.
    • If you are using the newest revision ICs, you need to recover first with for instance nrfjprog: nrfjprog --recover. This will disable APPROTECT in the UICR and add a small code snippet that unlocks the debug port so that it can be used in the future. However, when you flash your firmware this temporary firmware is deleted, and you must ensure that your firmware does this. For that you must use a MDK version >= 8.40.2, which for instance is included in nRF5 SDK 17.1.0. See IN-142 for more details.
Reply
  • Hi Mohamed,

    This is a special case. Reading the output from nrfjprog you see that readback protection is enabled (APPROTECT). And the only way to disable it is to perform a full chip erase (nrfjprog --recover). Clearly you want to avoid this issue in the future, as you want to be able to program/debug several times after the initial programming:

    • If you are using older revisions, simply do not enable APPROTECT. As long as it is never enabled, you will not have this problem.
    • If you are using the newest revision ICs, you need to recover first with for instance nrfjprog: nrfjprog --recover. This will disable APPROTECT in the UICR and add a small code snippet that unlocks the debug port so that it can be used in the future. However, when you flash your firmware this temporary firmware is deleted, and you must ensure that your firmware does this. For that you must use a MDK version >= 8.40.2, which for instance is included in nRF5 SDK 17.1.0. See IN-142 for more details.
Children
  • Hi,

    nRF Connect SDK 1.7.0 OK (that is the oldest nRF Connect SDK with support for the latest revision the nRF52833). nRF Connect SDK 1.7.0 use nrfx 2.5.0 which include MDK 8.40.2. Finding it is a bit tedious, but the easiest is to check the README for nrfx which you find under modules/hal/nordic/nrfx/README, and which tells you which version you are using. Then check the CHANGELOG.md in the same folder, which states which MDK version is used.

    There are separate documents for each device, but the content is virtually the same. For nRF52833 it is IN-149.

  • Thank you Thorsrud.

    It is all clear now.

    If you are using the newest revision ICs, you need to recover first with for instance nrfjprog: nrfjprog --recover. This will disable APPROTECT in the UICR and add a small

    So, for the newest revision ICs, I must perform the firmware flash operation and setting the device id in three  the steps. Step 1 will erase all user flash memory and disables the readback protection mechanism if enabled. Step 2 will write the device id in the UICR customer[0] location. Finally, step 3 will flash the firmware without erasing the UICR. The firmware will then re-enable the readback protection mechanism at boot-up.

    Step 1: Disable APPROTECT:  nrfjprog --recover 

    Step 2: Flash device id:            nrfjprog --memwr 0x10001080 --val <device id>

    Step 3: Flash firmware:             nrfjprog --program merged.hex –-sectorerase --reset

    Am I right?

    Kind regards
    Mohamed
  • Yes, that looks correct (note that if you want to debug/program after step 3, it is a requirement that the firmware continues to enable debugger access. That is the default behavior with the SDK though, so it should be good).

    I forgot about this post before, but you can read a bit more in Working with the nRF52 Series' improved APPROTECT if you want more details.

  • Thank you for sharing the link.

    note that if you want to debug/program after step 3, it is a requirement that the firmware continues to enable debugger access. That is the default behavior with the SDK though, so it should be good).

    Understood. The three steps mentioned above are for a production environment. We do all development and debugging in Segger Embedded Studio. 

    Kind regards
    Mohamed
  • Related