nrf52 stacked in a reset loop after setting NFCPINS as GPIO

[Dionisio]

Hi, I'm having some trouble with a custom board based on nRF52832.

I need to use NFCPINS (P0.10 and P0.9) as GPIOs.  As IDE I'm using Keil uVision. 

The code works weel till I set PIN10 as Output. If i comment it the device doesn't reset.

If I use one of the following, the microcontroller goes in a reset loop.

First attempt:

const uint32_t UICR_ADDR_0x20C __attribute__((at(0x1000120C))) __attribute__((used)) = 0xFFFFFFFE;

int main(){

    nrf_gpio_cfg_output(27); // P0.27 Connected to a LED
    
    
    nrf_gpio_cfg_output(10); // If I comment this the device doesn't reset
    
    while(1){
	}

	}

Second Attempt:

int main(){
	
	if (NRF_UICR->NFCPINS==0xFFFFFFFF){
		NRF_NVMC->CONFIG = 0x1UL; 
        while(!NRF_NVMC->READY){}
		NRF_UICR->NFCPINS = 0xFFFFFFFE;
		NRF_NVMC->CONFIG = 0x0UL;
		while(!NRF_NVMC->READY){};
	}
	
	nrf_gpio_cfg_output(27);
	
	nrf_gpio_cfg_output(10); //If i comment this the device doesn't reset
	
	while(1){

	}
   
}

Third Attempt:

How can I solve this problem?

Have a great day.

[Einar Thorsrud]

Hi,

The simplest way to do this is your 3rd option, where you define CONFIG_NFCT_PINS_AS_GPIOS. When that is the case, this snippet from modules/nrfx/mdk/system_nrf52.c is run during startup:

    /* Configure NFCT pins as GPIOs if NFCT is not to be used in your code. If CONFIG_NFCT_PINS_AS_GPIOS is not defined,
       two GPIOs (see Product Specification to see which ones) will be reserved for NFC and will not be available as
       normal GPIOs. */
    #if defined (CONFIG_NFCT_PINS_AS_GPIOS) && defined(NFCT_PRESENT)
        if ((NRF_UICR->NFCPINS & UICR_NFCPINS_PROTECT_Msk) == (UICR_NFCPINS_PROTECT_NFC << UICR_NFCPINS_PROTECT_Pos)){
            nvmc_config(NVMC_CONFIG_WEN_Wen);
            NRF_UICR->NFCPINS &= ~UICR_NFCPINS_PROTECT_Msk;
            nvmc_wait();
            nvmc_config(NVMC_CONFIG_WEN_Ren);
            NVIC_SystemReset();
        }
    #endif

This is the correct approach (note that there is an intentional reset if the UICR has been written to, as it needs to have the right value at startup in order to take effect).

As long as you define CONFIG_NFCT_PINS_AS_GPIOS for the project as you have shown in case 3, and remove the other code you had for this that should be good.

If you still get the unexpected reset, I would check a few other things. First, what is the value of RESETREAS after you get the unexpected reset? This will tell you a bit about what caused the reset. The code is so simple that it is not much that could fail, but perhaps GPIO pin 10 is connected to the reset pin? Or perhaps it is is connected so that somehow when you configure it as an output (and the default value then is low) you draw down the supply voltage so much that you get a brown out reset? The RESETREAS would give important information in these cases. And after checking that, it is probably time to take a look at your HW.

[Dionisio]

Hi Einar, thanks for the reply.

In the previous post I made a mistake. The reset is happening when the pin 10 is setted.

In order to print the state of the RESETREAS I'm using the following code:

int main(){


 nrf_gpio_cfg_output(27);
 nrf_gpio_cfg_output(10);
 SEGGER_RTT_printf(0,"%x \n",NRF_POWER->RESETREAS);
 nrf_gpio_pin_set(10);
 
 while(1){}
 


}

NRF_POWER->RESETREAS is equal to 4. So a "Reset from Soft Reset".

[Einar Thorsrud]

Hi,

The first time after programming reset from soft reset is the expected reason (as that is what is done after writing to UICR in the code snippet that is included by CONFIG_NFCT_PINS_AS_GPIOS). So if you do a full chip erase and program, then you should see it the first time, but not afterwards. There is no other code here that can cause a soft reset. Did you test this more than once after the initial programming?

[Dionisio]

Yes, I tested the board all the night witout success. Using an oscilloscope I can see a spike of about 2ms going from 3.4V to 60mV on pin 10 before RESET occurs. A similar spike happens on the VDD. Pin 10 enables a load switch, so this should be the problem. Setting the pin 9 the reset doesn't occur.