Implications of turning off read access

RE: Implications of turning off read access

Randy Lee — Mon, 26 Feb 2024 15:12:55 GMT

Beauty... That looks like that got it. Once I come back from the reset, the debugger is lost and I can't get it to work like that again till I reflash the part (F5)

RE: Implications of turning off read access

Edvin — Mon, 26 Feb 2024 08:57:01 GMT

Hello,

Yes. Perhaps I was a bit fast.

You will still be able to debug after enabling APPROTECT, but only until the next reboot. I don't remember if you need to power cycle, or just a reset. You can experiment with this.

[quote user="Randy Lee"]I get an infinite loop, at least doing debug and the register is always reading as 0xFFFFFFFF[/quote]

I guess the APPROTECT register doesn't get time to update before you reset.

WARNING: Read the last part before testing this.

	uint32_t Protected = NRF_UICR->APPROTECT;
	if (Protected != 0x00){
		debug("Protected=%X",Protected);
		NRF_UICR->APPROTECT = 0x00;
		while (NRF_UICR->APPROTECT != 0x00)
		{
		    // Wait for the register write to finish.
		}
		NVIC_SystemReset();
	}

It might be a good idea to add a small delay (1 second or so) when experimenting with this. If something goes wrong and you enter a very fast reset loop with the APPROTECT enabled, it may be difficult for your debugger to be able to connect to the device. This would cause it to be hard to --recover it as well. When everything is working as expected, you can remove the delay.

Also, when you are working with the UICR registers, you need to make sure that it is set to write mode. Please look at how this is done in the system_nrf52.c, e.g. if the CONFIG_GPIO_AS_PINRESET is set.

Therefore, it should look something like this:

        nrf_delay_ms(2000);                 // Use this for easier recovery while experimenting. Needs: #include "nrf_delay.h"
        if (NRF_UICR->APPROTECT == 0xFF)
        {
            NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
            while (NRF_NVMC->READY == NVMC_READY_READY_BUSY){}
            NRF_UICR->APPROTECT = 0x00;
            while (NRF_NVMC->READY == NVMC_READY_READY_BUSY){}
            nvmc_config(NVMC_CONFIG_WEN_Ren);
            while (NRF_NVMC->READY == NVMC_READY_READY_BUSY){}
            while (NRF_UICR->APPROTECT != 0x00)
            {
                // Wait.
            }
            NVIC_SystemReset();
        }

Best regards,

Edvin

RE: Implications of turning off read access

Randy Lee — Fri, 23 Feb 2024 14:54:56 GMT

One thing here: I'm doing this as one of the first things in code:

NRF_UICR->APPROTECT = 0x00;

I don't get a fault for it or anything but I can continue to debug in that session or any other session which, according to your note #1 above, I shouldn't be able to do.

In fact, with this code:

	uint32_t Protected = NRF_UICR->APPROTECT;
	if (Protected != 0x0){
		debug("Protected=%X",Protected);
		NRF_UICR->APPROTECT = 0;
		NVIC_SystemReset();
	}

I get an infinite loop, at least doing debug and the register is always reading as 0xFFFFFFFF

RE: Implications of turning off read access

Randy Lee — Fri, 23 Feb 2024 13:04:40 GMT

Thank you... this is instructive.

RE: Implications of turning off read access

Edvin — Fri, 23 Feb 2024 09:44:35 GMT

Hello,

[quote user=""]1) Does this stop the debugger from doing things like breakpoints? Or Disassembly?[/quote]

Yes. If you enable APPROTECT you will no longer be able to debug (set breakpoints, etc.). You will also not be able to program the device without running a recovery, which will erase the flash before unlocking the APPROTECT.

[quote user=""]2) What effect, if any, does this have on the bootloader operation? Can it go and erase place and reprogram those? I'm assuming the new program would then set that register again.[/quote]

The bootloader will still have access to update the FW, since it is not dependent on a physical programmer. It is only the external programmer port that is disabled (or restricted, really. You can still do the recover command). The APPROTECT is stored in UICR, so it will remain enabled until you recover the chip. No need to enable it from every new application after DFU.

[quote user=""]3) Any other sideaffects this action creates to watch out for?[/quote]

Other than the fact that you will not be able to access the device with a debugger, there is not really that much to look out for. Just be aware that if you encounter any issues out in the field (after selling/deploying the device), in case something bad happens, you will not be able to debug the application without completely re-programming it without the APPROTECT enabled.

Best regards,

Edvin