UICR won't be completely erased (APPROTECT)

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

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?

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

user3223 said:

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

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.

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

user3223 said:

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

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.

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.

user3223 said:

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.

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?

user3223 said:

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.

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.