UICR won't be completely erased (APPROTECT)

RE: UICR won't be completely erased (APPROTECT)

Kenneth — Thu, 19 May 2022 11:50:56 GMT

This is something that is being looked into, I will update you when I learn more.

Kenneth

RE: UICR won't be completely erased (APPROTECT)

Anne van Rossum — Mon, 16 May 2022 13:51:46 GMT

We can erase UICR using JLinkExe

halt
w4 4001E504, 2
w4 4001e50C, 1
r

We will see subsequently that indeed there's 0xFF written to the register at 0x10001208.

After nrfjprog --recover we will find that this UICR value is overwritten by the Nordic tool to 0x5A.

Hence, hereby clarifying what happens.

@Nordic. Would you mind to add an option to nrfjprog to leave this register alone? Perhaps something like nrfjprog --someoption that erases everything WITHOUT writing to this field. For example, also e.g. nrfjprog --eraseall writes this register.

RE: UICR won't be completely erased (APPROTECT)

Anne van Rossum — Thu, 12 May 2022 14:22:17 GMT

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.

RE: UICR won't be completely erased (APPROTECT)

Kenneth — Thu, 12 May 2022 14:18:29 GMT

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

RE: UICR won't be completely erased (APPROTECT)

mrono — Thu, 12 May 2022 14:08:56 GMT

[quote userid="3223" url="~/f/nordic-q-a/87846/uicr-won-t-be-completely-erased-approtect/367663#367663"]The readback protection is removed on --recover just because 0xFF gets written to those registers.[/quote]

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.

RE: UICR won't be completely erased (APPROTECT)

Anne van Rossum — Thu, 12 May 2022 13:59:27 GMT

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

RE: UICR won't be completely erased (APPROTECT)

Anne van Rossum — Thu, 12 May 2022 13:57:44 GMT

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.

RE: UICR won't be completely erased (APPROTECT)

Anne van Rossum — Thu, 12 May 2022 13:54:11 GMT

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.

RE: UICR won't be completely erased (APPROTECT)

mrono — Thu, 12 May 2022 12:34:33 GMT

[quote userid="3223" url="~/f/nordic-q-a/87846/uicr-won-t-be-completely-erased-approtect/367604#367604"]Thanks for your help, but I want to know why I can't write 0xFFFFFFFF rather than 0x5A towards that register. Or what I've to do to make that happen.[/quote]

The thing is that this new hardware revision doesn't work like that. They've changed the way the chip operates in this respect and we users can only adapt to it.

have you seen the change notice IN141?

[quote userid="3223" url="~/f/nordic-q-a/87846/uicr-won-t-be-completely-erased-approtect/367604#367604"] I don't want this stuff to be suddenly interfering with our flash tools in the factory depending if there has been or has not been a power cycle in that process.[/quote]

I have actually today ordered a sample set of our product to be built with this new revision of 52840, for checking exactly this. So shortly I will be in the same situation as you.

RE: UICR won't be completely erased (APPROTECT)

Kenneth — Thu, 12 May 2022 12:30:13 GMT

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

RE: UICR won't be completely erased (APPROTECT)

Anne van Rossum — Thu, 12 May 2022 12:23:27 GMT

Thanks for your help, but I want to know why I can't write 0xFFFFFFFF rather than 0x5A towards that register. Or what I've to do to make that happen.

I think I understand what's happening, namely that the nrfjprog tool automatically writes 0x5A towards that register after a recover operation.

And of course I've read the documentation as well https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/working-with-the-nrf52-series-improved-approtect and no, I just don't want to do protection in firmware.

If someone wants to glitch the thing, go ahead. Our code is open source and not locked down to begin with. So everything making flashing more cumbersome is to be removed from the process. I don't want this stuff to be suddenly interfering with our flash tools in the factory depending if there has been or has not been a power cycle in that process.

RE: UICR won't be completely erased (APPROTECT)

mrono — Thu, 12 May 2022 12:12:37 GMT

Well, improved in the sense that it is not as easily bypassed I guess.

[quote userid="3223" url="~/f/nordic-q-a/87846/uicr-won-t-be-completely-erased-approtect/367592#367592"]Apart from that, let's just assume I want to write 0xFF rather than 0x5A there. Can I do this?[/quote]

I suppose, but then it would still be locked, I think.

You need the firmware on the device to also write some magic words to keep the device 'unlocked'.

This is copied from the guide I linked above:

1. Start with a CTRL-AP ERASEALL operation.
2. Program code compiled with an MDK 8.44.1 or later, without ENABLE_APPROTECT defined.
3. Write HwDisabled (0x5A) to UICR.APPROTECT
4. Perform any reset to run the code. The programmed code from step 2 will open access port by writing to APPROTECT.DISABLE during start-up.

So you need the firmware to actively allow access. Otherwise the device will be locked after a power cycle.

RE: UICR won't be completely erased (APPROTECT)

Anne van Rossum — Thu, 12 May 2022 11:55:31 GMT

I don't think I'd call it "improved" if it means that after a power cycle I've to clear UICR again to be able to flash a new binary.

Apart from that, let's just assume I want to write 0xFF rather than 0x5A there. Can I do this?

RE: UICR won't be completely erased (APPROTECT)

mrono — Thu, 12 May 2022 10:31:51 GMT

Isn't this the new and improved APPROTECT mechanism? 0x5A is the 'protection disabled' value.

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/working-with-the-nrf52-series-improved-approtect