nrf52 stacked in a reset loop after setting NFCPINS as GPIO

RE: nrf52 stacked in a reset loop after setting NFCPINS as GPIO

Dionisio — Tue, 01 Nov 2022 20:55:35 GMT

UPDATE

The problem was in the analog side of the board, bad footprint causing short circuiti between 3.3V and GND. Fixed and now works smoothly. Thank you for the support

RE: nrf52 stacked in a reset loop after setting NFCPINS as GPIO

Dionisio — Tue, 01 Nov 2022 09:41:13 GMT

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.

RE: nrf52 stacked in a reset loop after setting NFCPINS as GPIO

Einar Thorsrud — Tue, 01 Nov 2022 09:08:49 GMT

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?

RE: nrf52 stacked in a reset loop after setting NFCPINS as GPIO

Dionisio — Tue, 01 Nov 2022 09:02:33 GMT

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".

RE: nrf52 stacked in a reset loop after setting NFCPINS as GPIO

Einar Thorsrud — Tue, 01 Nov 2022 08:21:35 GMT

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.