nRESET on nRF52840 shortened to GND (ground); Is it possible to map the nRESET to another pin and execute any pin-mapping while P0.18 is stuck low

Question

We have a PCB production with bug where AC13 (P0.18) accidently has a via shortenede to GND plane on internal layer. Thus nRESET is stuck low and cannot be pulled high without drilling out the via. Question is if the "mapping of nRESET" ability by changing the PSELRESET registers as descried in the datasheet could help us out?
Its seems possible to not expose the nRESET function on a GPIO, which could "cut" the connection from the short to the internal logic.
However, we suspect the FW will not start executing the mapping due to the low status on P0.18.
Question is if there is any suggestions how to overcome the GND-logic low problem on nRESET by changing any registers, and how to manage to start the program execution with this HW bug in the PCB

hmolesworth · Answer

Luckily the fix is to simply erase all the flash and then not programming the reset pin to be active. This can be done by not including CONFIG_GPIO_AS_PINRESET in the project options. When the reset pin is required to be enabled the UICR register enable bits both have to be programmed to '0' from the flash erased values of '1'. Normally this is done via the programmer tool or in the user's code on first reset such as here in system_nrf52.c (832) or maybe system_nrf52840.c:

    /* Configure GPIO pads as pPin Reset pin if Pin Reset capabilities desired. If CONFIG_GPIO_AS_PINRESET is not
      defined, pin reset will not be available. One GPIO (see Product Specification to see which one) will then be
      reserved for PinReset and not available as normal GPIO. */
    #if defined (CONFIG_GPIO_AS_PINRESET)
        if (((NRF_UICR->PSELRESET[0] & UICR_PSELRESET_CONNECT_Msk) != (UICR_PSELRESET_CONNECT_Connected << UICR_PSELRESET_CONNECT_Pos)) ||
            ((NRF_UICR->PSELRESET[1] & UICR_PSELRESET_CONNECT_Msk) != (UICR_PSELRESET_CONNECT_Connected << UICR_PSELRESET_CONNECT_Pos))){
            NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos; // Write Enable
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_UICR->PSELRESET[0] = 21;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_UICR->PSELRESET[1] = 21;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos; // Read-only Enable
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            // UICR changes require a reset to be effective
            NVIC_SystemReset();
        }
    #endif

PSELRESET[0] and PSELRESET[0] must both have bits 31 '0' for the reset pin to be active, as well has having the correct reset pin number 18 in both these registers. Removing CONFIG_GPIO_AS_PINRESET and doing a full flash erase before programming should therefore correct the hardware issue.

It is not possible to use another pin, by the way; only pin 18 is allowed when the reset function is required.