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

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

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

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

Ah, good to know. I actually started to suspect nrfjprog indeed to do such a thing. As far as I know it's not open source, pity!

I'll check next week if I can actually erase the entire UICR page with just the JLink and then see if nrfjprog is overwriting the value on a recover action.