UICR won't be completely erased (APPROTECT)

I think part of the problem here is that we want the tools to be useful for both development and production programming, and due to backwards development compatiblity if you like, some of the parameters might not do what you intuitively expect. E.g. if recover and eraseuicr did erase flash main block/uicr, then it would quickly become a hazzle for anyone developing an application and for instance were debugging. That is why they disable readback protect when used, this is also mentioned for the recover parameter (not for eraseuicr though):

--recover Erases all user available non-volatile memory and
disables the read back protection mechanism if
enabled.

So how to enable readback protection from nrfjprog?

Any other value than 0x5A to the APPROTECT register will enable readback register, so there is no need to set this register to 0xFF to enable it really. This means that to enable readback protection you can use the rbp parameter with ALL to set the register to 0 after programming, thereby readback will be enabled after a power on reset.

In general I also recommend to check out:
https://infocenter.nordicsemi.com/topic/ps_nrf52840/dif.html#concept_udr_mns_1s 

Best regards,
Kenneth

I think part of the problem here is that we want the tools to be useful for both development and production programming, and due to backwards development compatiblity if you like, some of the parameters might not do what you intuitively expect. E.g. if recover and eraseuicr did erase flash main block/uicr, then it would quickly become a hazzle for anyone developing an application and for instance were debugging. That is why they disable readback protect when used, this is also mentioned for the recover parameter (not for eraseuicr though):

--recover Erases all user available non-volatile memory and
disables the read back protection mechanism if
enabled.

So how to enable readback protection from nrfjprog?

Any other value than 0x5A to the APPROTECT register will enable readback register, so there is no need to set this register to 0xFF to enable it really. This means that to enable readback protection you can use the rbp parameter with ALL to set the register to 0 after programming, thereby readback will be enabled after a power on reset.

In general I also recommend to check out:
https://infocenter.nordicsemi.com/topic/ps_nrf52840/dif.html#concept_udr_mns_1s 

Best regards,
Kenneth

On the PCA10056 I just have 0xFF in APPROTECT. No, 0x5A

I don't want to have it "Closed" on a pin reset. Seems a simple request to me to leave the 0xFF in that register alone.

It doesn't truly make sense what you say. The readback protection is removed on --recover just because 0xFF gets written to those registers. And I'm not talking about enabling it. Just read my question.

Mmm, clicked on the vote thing by accident... I can't undo it, but I don't want to vote it up either. :-D

user3223 said:

The readback protection is removed on --recover just because 0xFF gets written to those registers.

This was true on the earlier chip revisions, but unfortunately it no longer applies on the latest silicon.

EDIT: Ok, protection is removed by an erase, but it won't stay that way after a reset unless you do the required actions.

(Removed some of what I wrote because it may have been incorrect.)

This new revision is simply different. You can't make it behave like the old one.

Be aware that there was a change in behaviour and implementation when going from rev2 to rev3 of the nRF52-series:
https://infocenter.nordicsemi.com/topic/comp_matrix_nrf52840/COMP/nrf52840/nRF52840_doc_ref_design_files_overview.html 
https://infocenter.nordicsemi.com/pdf/in_141_v1.1.pdf

The nrfjprog tool will identify the revision and handle them slightly differently due to this, e.g. on rev2 the UICR.APPROTECT likely will be set to 0xFF (disabled), while on rev3 it likely will be set to 0x5A (disabled) when using --recover option. 

Also be aware that there are two APPROTECT registers, one in UICR (https://infocenter.nordicsemi.com/topic/ps_nrf52840/uicr.html#register.APPROTECT) and one in RAM (https://infocenter.nordicsemi.com/topic/ps_nrf52840/dif.html#topic).

Best regards,
Kenneth