Nordic, please fix your documentation on nRF52 UICR Registers

[DaveElam]

Hi Nordic, you should add a BIG warning label, as show below, under the UICR description for all nRF52 devices, saying UICR registers cannot be erased when APPROTECT is enabled!  This should be in the first paragraph so users know to avoid them.  This change should look something like what I have below.  Developers can design the firmware using in-application configurable UICR registers with APPROTECT disabled, only to find out at production that their design is as worthless since UICR registers can't be modified with APPROTECT enabled.  Even worse yet, depending how often these configuration registers change, they may find out after production, as in our case.

UICR — User information configuration registers

The user information configuration registers (UICRs) are non-volatile memory (NVM) registers for configuring user specific settings.

WARNING! UICR registers cannot be erased when APPROTECT is enabled.

For information on writing UICR registers, see the NVMC — Non-volatile memory controller and Memory chapters.

[ovrebekk]

Hi Dave

Thanks for the heads up. I agree this sounds like something we could make more clear in the documentation. 

Just for clarity though, are you saying the UICR can neither be written to or erased from the MCU when APPROTECT is on?

Erasing the UICR is blocked because this would allow the application to disable the APPROTECT feature (if you have an application glitch, or someone manages to inject their own code somehow). 
Write should be allowed though, as you can not clear APPROTECT by a write alone, since 0 bits can only be reset by an erase. 

Also, if you can confirm which chip type and revision you have that would be helpful. 

Best regards
Torbjørn

[DaveElam]

We are using the nRF52840.  UICR registers cannot be erased with APPROTECT enabled.  I understand that they can be "written", but this is a very unique case where only 1 can be changed to 0, which is not at all clear this is implied in the term "written".  I think all engineers understand this is how flash works, but from the documentation, it's not clear what type of technology is underlying these UICR registers, and Nordic makes it seem like they are something unique, especially since they are called "registers" and not flash.  Plus Nordic goes out of the way to talk about how they can be written X times, but in reality they can't by most people's understanding of "written".  So I think adding the warning, and removing the references to how they can be written X times would be helpful so others don't make the same mistake we did.

[ovrebekk]

Hi Dave

I agree there is some room for improvement here, and if I am to summarize I would say it comes down to two things: 

1) Make it more clear that the UICR registers are stored in flash

2) Make it more clear that the UICR can not be erased when the APPROTECT is enabled

I am not sure I agree that we don't properly document what 'written' means in this case. The second line of text in the UICR documentation links to the NVMC chapter, where the 'Writing to flash' paragraph goes through all the implications and limitations of writing to flash memory. As long as it is crystal clear that the UICR is indeed flash I believe this way of documenting it should be sufficient. 

Then it should be possible to solve 1) and 2) by updating the text in the UICR chapter to reflect clearly that the UICR is stored in flash, and that the page can not be erased when APPROTECT is enabled. 

If you agree I can register this as a formal request to the team working on our documentation. 

Best regards
Torbjørn

[DaveElam]

Hi Torbjørn,

If you the only change you make is adding item 2.) to the UICR description in the OPS, that would have solved our issue.

All of the contents of sections 4.3.3 and 4.3.4 of the OPS v1.2 are invalid when APPROTECT is set, so that would be a good spot to mention APPROTECT.

Thanks,

Dave