Example code to write to UICR

RE: Example code to write to UICR

user92434 — Wed, 18 May 2022 10:54:14 GMT

Thank you Einar.

[quote userid="7377" url="~/f/nordic-q-a/82409/example-code-to-write-to-uicr/368285#368285"](The CPU cannot erase the UICR page, though)[/quote]

Does this mean I can only write to UICR->CUSTOMER locations which are FFFF... i.e. the UICR locations that have not been written to since the last erase?

[quote userid="7377" url="~/f/nordic-q-a/82409/example-code-to-write-to-uicr/368221#368221"]You have the same functionality in 1.7.0. There you have nrf52_errata_249() in modules\hal\nordic\nrfx\mdk\nrf52_erratas.h which is used from modules\hal\nordic\nrfx\mdk\system_nrf52_approtect.h. [/quote]

Looking in system_nrf52_approtect.h I can see the code inside the function nrf52_handle_approtect() is disabled because NRF52_ERRATA_249_PRESENT is defined as 1 in nrf52_erratas.h.

Do I need to define ENABLE_APPROTECT?

Yet you said this is handled automatically in the MDK. I must be missing something.

Also, it seems the the function nrf52_errate_249() always returns false unless NRF52_SERIES is defined. How can I add the pre-processor directive -DNRF52_SERIES in Segger Embedded Studio v5.60?

There are many macros and I am not sure which ones I need to define and which ones are handled automatically by the MDK. Please clarify.

/* ========= Errata 249 ========= */
#if    defined (NRF52820_XXAA) || defined (DEVELOP_IN_NRF52820) \
    || defined (NRF52832_XXAA) || defined (DEVELOP_IN_NRF52832) \
    || defined (NRF52832_XXAB) || defined (DEVELOP_IN_NRF52832) \
    || defined (NRF52833_XXAA) || defined (DEVELOP_IN_NRF52833) \
    || defined (NRF52840_XXAA) || defined (DEVELOP_IN_NRF52840)
    #define NRF52_ERRATA_249_PRESENT 1
#else
    #define NRF52_ERRATA_249_PRESENT 0
#endif

#ifndef NRF52_ERRATA_249_ENABLE_WORKAROUND
    #define NRF52_ERRATA_249_ENABLE_WORKAROUND NRF52_ERRATA_249_PRESENT
#endif

static bool nrf52_errata_249(void)
{
    #ifndef NRF52_SERIES
        return false;
    #else
        #if defined (NRF52820_XXAA) || defined (DEVELOP_IN_NRF52820)\
         || defined (NRF52832_XXAA) || defined (DEVELOP_IN_NRF52832)\
         || defined (NRF52832_XXAB) || defined (DEVELOP_IN_NRF52832)\
         || defined (NRF52833_XXAA) || defined (DEVELOP_IN_NRF52833)\
         || defined (NRF52840_XXAA) || defined (DEVELOP_IN_NRF52840)
            uint32_t var1 = *(uint32_t *)0x10000130ul;
            uint32_t var2 = *(uint32_t *)0x10000134ul;
        #endif
...
...
        #if defined (NRF52833_XXAA) || defined (DEVELOP_IN_NRF52833)
            if (var1 == 0x0D)
            {
                switch(var2)
                {
                    case 0x00ul:
                        return false;
                    case 0x01ul:
                        return false;
                    case 0x02ul:
                        return true;
                    default:
                        return true;
                }
            }
        #endif
...
...
        return false;
    #endif
}

Kind regards

Mohamed

RE: Example code to write to UICR

user7377 — Wed, 18 May 2022 10:52:31 GMT

Hi,

[quote userid="92434" url="~/f/nordic-q-a/82409/example-code-to-write-to-uicr/368284#368284"]

If NRF_UICR->APPROTECT is set to UICR_APPROTECT_PALL_Enabled

Will I still be able to write to NRF_UICR->CUSTOMER flash area in the firmware at runtime?

[/quote]

Yes. The APPROTECT mechanism only prevents debugger access. The CPU still has ability to write to the UICR. (The CPU cannot erase the UICR page, though).

RE: Example code to write to UICR

user92434 — Wed, 18 May 2022 10:47:53 GMT

Hi Einar,

Thank you.

The reason I am looking at using nrf52_errata_249() is, as you suggested, to distinguish between chips with the older APPROTECT mechanism and those with the new one in system_SetDebugPortAccess().

There is one thing I am not sure about though.

If NRF_UICR->APPROTECT is set to UICR_APPROTECT_PALL_Enabled

Will I still be able to write to NRF_UICR->CUSTOMER flash area in the firmware at runtime?

Kind regards

Mohamed

RE: Example code to write to UICR

user7377 — Wed, 18 May 2022 08:08:09 GMT

Hi Mohamed,

You have the same functionality in 1.7.0. There you have nrf52_errata_249() in modules\hal\nordic\nrfx\mdk\nrf52_erratas.h which is used from modules\hal\nordic\nrfx\mdk\system_nrf52_approtect.h. So also there, this is handled automatically by the MDK and you don't really need to do anything. But if you for some reason want to have your own code for handing this (like it seems you do in your system_SetDebugPortAccess(), though I don't really see the need thins the MDK handles it for you), you can use this function to distinguish between old revisions with old APPROTECT (HW only based) mechanism and new APPROTECT mechanism (HW + SW based).

RE: Example code to write to UICR

user92434 — Mon, 16 May 2022 09:53:06 GMT

Hello Einar,

Thank you for the clarifications and the link.

I will have a read.

[quote userid="7377" url="~/f/nordic-q-a/82409/example-code-to-write-to-uicr/367925#367925"]Referring to nRF Connect SDK 1.9.1 you have modules/hal/nordic/nrfx/mdk/system_nrf52_approtect.h which handles APPROTECT. There you can see that the nrf52_configuration_249() is checked and this returns true for devices with the new APPROTECT mechanism and false for the older.[/quote]

I would like to avoid moving to v1.9.1 at this moment in time if I can help it.

In SDK 1.7.0 I can only find in stystem_nrf52_approtect.h the function

static inline void nrf52_handle_approtect(void)

Is there something similar in v1.7.0 that will allow me to read the chip revision ?

Kind regards

Mohamed

RE: Example code to write to UICR

user7377 — Sun, 15 May 2022 07:36:17 GMT

Hi Mohamed,

The code in this snippet will not work for older revisions., which has a different APPROTECT mechanism. You need to handle the revisions separately, as is done in the MDK. Referring to nRF Connect SDK 1.9.1 you have modules/hal/nordic/nrfx/mdk/system_nrf52_approtect.h which handles APPROTECT. There you can see that the nrf52_configuration_249() is checked and this returns true for devices with the new APPROTECT mechanism and false for the older.

As you want to disable APPROTECT, and older devices has APPROTECT disabled by default (, you can simply check which revision you have and avoid running any APPROTECT related code on the older devices.

PS: To understand the difference between the old (Access port protection controlled by hardware) and new (Access port protection controlled by hardware and software) scheme, I suggest you refer to the Debug and trace chapter in the product specification.

RE: Example code to write to UICR

user92434 — Fri, 13 May 2022 20:59:23 GMT

Hi Einar,

[quote userid="7377" url="~/f/nordic-q-a/82409/example-code-to-write-to-uicr/366848#366848"]

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).

[/quote]

I am finding that I cannot debug code on an older version QDAAA0. The code boots up and stops at the point where NRF_UICR->APPROTECT is checked, see code below.

void system_SetDebugPortAccess(void)
{
#if (CONFIG_DEBUG_PORT_ACCESS)

    /* Prevent chip from locking itself in hardware (if not already set) */
    if (NRF_UICR->APPROTECT != UICR_APPROTECT_PALL_HwDisabled)
    {
        LOG_ERR("Device debug prevented on next POR (0x%08X), resetting to disable this.", NRF_UICR->APPROTECT);
        system_WriteDebugPortAccess(UICR_APPROTECT_PALL_HwDisabled);
    }

    /* Prevent chip from locking itself in software */
    NRF_APPROTECT->DISABLE = APPROTECT_DISABLE_DISABLE_SwDisable;

#else
    /* Enforce HW protection (if not already set) */
    if (NRF_UICR->APPROTECT != UICR_APPROTECT_PALL_Enabled)
    {
        LOG_ERR("Device debug allowed on next POR (0x%08X), resetting to disable this.", NRF_UICR->APPROTECT);
        system_WriteDebugPortAccess(UICR_APPROTECT_PALL_Enabled);
    }

    /* Belts and braces, enforce SW protection */
    NRF_APPROTECT->FORCEPROTECT = APPROTECT_FORCEPROTECT_FORCEPROTECT_Force;

#endif //CONFIG_DEBUG_PORT_ACCESS
}

This is what I see in Segger Embedded Studio (SES-Nordic Edition) Debug Terminal:

*** Booting Zephyr OS build v2.6.99-ncs1 ***
[00:00:00.025,848] <err> system: Device debug prevented on next POR (0xFFFFFFFF), resetting to disable this.

So, basically NRF_UICR->APPROTECT != UICR_APPROTECT_PALL_HwDisabled

I can debug the same code on a newer version of the chip QDAAB0.

QDAAA0: content of APPROTECT: 10120000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEE

QDAAB0: content of APPROTECT: 1012000012000000120000005A000000FEFFFFFF65

So, I wrote to APPROTECT of the QDAAA0 chip 0x0000005A to disable the protection mechanism.

C:\WINDOWS\system32>nrfjprog --recover
Recovering device. This operation might take 30s.
Erasing user code and UICR flash areas.

C:\WINDOWS\system32>nrfjprog --memwr 0x10001208 --val 0x0000005A --verify
Parsing parameters.
Writing.
Verified OK.

I then read UICR back to check the value of APPROTECT

C:\WINDOWS\system32>nrfjprog --readuicr hb-700078-3.ihex
Storing data in 'hb-700078-3.ihex'.

QDAAA0: new content of APPROTECT: 10120000FFFFFFFFFFFFFFFF5A000000FFFFFFFFEE

But when I flash the firmware in SES and start a debug session I still cannot debug it. I get the same error, <err> system: Device debug prevented on next POR (0xFFFFFFFF), resetting to disable this.

I then tried to read back UICR to check if APPROTECT is still disabled but the read command failed

C:\WINDOWS\system32>nrfjprog --readuicr hb-700078-4.ihex
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.

Why?

It looks as if the APPROTECT enable/disable does not work for older chip version such as QDFAAA0.

Kind regards

Mohamed

RE: Example code to write to UICR

user92434 — Wed, 11 May 2022 08:31:55 GMT

Good Morning Einar,

We managed to solve the problem by just installing nRF Connect for Desktop on the new machine.

Thank you for your support.

Kind regards

Mohamed

RE: Example code to write to UICR

user7377 — Wed, 11 May 2022 06:10:16 GMT

Hi,

I am not immediately able to explain that. Please open a new question/thread for this as it is not directly related to the original topic in this thread.

RE: Example code to write to UICR

user92434 — Tue, 10 May 2022 14:55:05 GMT

Hi Thorsrud,

I have installed nrfjprog v10:15 on another machine running Windows 10 64-bits and I am running into this problem,

C:\>nrfjprog -v
ERROR: JLinkARM DLL is invalid. Please reinstall latest JLinkARM DLL.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.

C:\>nrfjprog -v --log
WARNING: Logging is unavailable. nrfjprog.exe does not have write
WARNING: permission for the log file
ERROR: JLinkARM DLL is invalid. Please reinstall latest JLinkARM DLL.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.

He has installed it twice but he is still facing the same problem.

Thank you for your help.

Kind regards

Mohamed

RE: Example code to write to UICR

user92434 — Tue, 10 May 2022 09:47:46 GMT

Thank you for sharing the link.

[quote userid="7377" url="~/f/nordic-q-a/82409/example-code-to-write-to-uicr/367120#367120"]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).[/quote]

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

Kind regards

Mohamed

RE: Example code to write to UICR

user7377 — Tue, 10 May 2022 09:29:05 GMT

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.

RE: Example code to write to UICR

user92434 — Tue, 10 May 2022 09:21:31 GMT

Thank you Thorsrud.

It is all clear now.

[quote userid="7377" url="~/f/nordic-q-a/82409/example-code-to-write-to-uicr/367066#367066"]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[/quote]

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

RE: Example code to write to UICR

user7377 — Tue, 10 May 2022 08:42:34 GMT

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.

RE: Example code to write to UICR

user92434 — Tue, 10 May 2022 08:31:16 GMT

Good Morning Thorsrud,

Thank you for the tips.

I must admit I get confused with all these different tools versions.

I know I am using,

Zephyr OS build v2.6.99-ncs1

nRF Connect SDK v1.7.0

But I am not sure which MDK version I am using. How do I find out?

[quote userid="7377" url="~/f/nordic-q-a/82409/example-code-to-write-to-uicr/367066#367066"]See IN-142 for more details[/quote]This document refers to nRF52832 but I am using nrf52833.

Does it also apply to nRF52833?

Kind regards

Mohamed

RE: Example code to write to UICR

user7377 — Tue, 10 May 2022 06:56:04 GMT

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.

RE: Example code to write to UICR

user92434 — Mon, 09 May 2022 14:13:35 GMT

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

RE: Example code to write to UICR

user7377 — Mon, 09 May 2022 14:06:03 GMT

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.

RE: Example code to write to UICR

user92434 — Mon, 09 May 2022 13:54:09 GMT

Hi Thorsrud,

Thank you for your support.

[quote userid="7377" url="~/f/nordic-q-a/82409/example-code-to-write-to-uicr/366848#366848"]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). [/quote]

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

[quote userid="7377" url="~/f/nordic-q-a/82409/example-code-to-write-to-uicr/366848#366848"]A simple tool for this is nrfjprog.[/quote]

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

RE: Example code to write to UICR

user7377 — Mon, 09 May 2022 07:56:01 GMT

[quote user="Learner"]Can I use the same code snippet with other Soc version e.g. QDAAA0?[/quote]

[quote user="Learner"]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.[/quote]

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.

RE: Example code to write to UICR

user7377 — Mon, 09 May 2022 07:46:46 GMT

Yes, that is correct. Writing to flash can only flip bits from '1' to '0'. This is an inherent property of flash technology and applies to all flash memory (not just on Nordic products).

To change bits from '0' to '1' you need to erase the page.

RE: Example code to write to UICR

user54487 — Sun, 08 May 2022 12:18:38 GMT

Regarding my statement:

write to flash can only reset bits.
It is necessary to erase flash to set it to FFFFFFF

The second part is NOT correct!

Unfortunately

NRFJPROG incorrectly requires it see:

nrfjprog---memwr-0x10001080---val-0x01010101-shouldn-t-fail-second-time

In fact you could use a "counter" (up to 31) by repeatedly clearing bits.
counter =1: 7FFFFFF, counter=2:3FFFFFFF, counter=3 :1FFFFFFF, =4:0FFFFFFF ... =30:00000003, 31:00000001 with no intervening erasures.

++++++++++++++

You can use nrfjprog

--sectorerase

to only erase the area that is being programmed which can preserve UCIR.

RE: Example code to write to UICR

user92434 — Fri, 06 May 2022 16:01:01 GMT

Hi Thorsrud,

[quote userid="7377" url="~/f/nordic-q-a/82409/example-code-to-write-to-uicr/366694#366694"]The code snippet you have seems to match QDAAB0, which has the improved access port mechanism (IN-149).[/quote]

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

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.

Note, when using nRF Programmer only the 'Erase & write' option is available. The 'Write' only option is disabled, see attached screen shot below.

Thank you.

Kind regards

Mohamed

RE: Example code to write to UICR

user92434 — Fri, 06 May 2022 14:50:17 GMT

Hi Thorsrud,

Before I try what you suggested I would like you to clarify the statement below.

[quote userid="54487" url="~/f/nordic-q-a/82409/example-code-to-write-to-uicr/341951#341951"]write to flash can only reset bits. It is necessary to erase flash to set it to FFFFFFF[/quote]

Is the above statement from dgerman correct?

I see you are not erasing flash in the example code you shared earlier with rmarques.

Please clarify.

Thank you.

Kind regards

Mohamed

RE: Example code to write to UICR

user7377 — Fri, 06 May 2022 11:14:14 GMT

Hi Mohamed,

[quote user="Learner"]So, in debug mode I should NOT be experiencing this problem, right?[/quote]

I do not know everything you do, but yes: as long as debug port access is enabled, then you can erase and write specific sectors and do not need to do a full chip erase.

[quote user="Learner"]Also, isn't the whole purpose of the access port protection is to make sure it is enabled before product deployment?[/quote]

Yes it is. But that also means that debug access is blocked, and to enable it you must do an ERASE ALL (recover), which also erases UICR.

[quote user="Learner"]We are currently using a mixture of N52833 QDAAB0 and QDAAA0 but ultimately we will be using only revision QDAAB0.[/quote]

I see. The code snippet you have seems to match QDAAB0, which has the improved access port mechanism (IN-149). With this debugging is disabled by default and you need to disable it by writing to UICR and also writing to NRF_APPROTECT->DISABLE on every boot. If not, a full erase is needed to be able to debug again.

Note that it is also so that the only way to erase UICR is to erase the whole flash, so if the UICR is "suddenly" erased it is because the tools you use for some reason do an erase all. The question is why. Can you start by reading data from UICR to see if debug access is enabled and the data is still there? then what exactly do you do when the UICR is erased by the debugger?