This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

P0.09 and P0.10 as GPIO (nRF52832 + IAR + custom board)

Hello, 

I know this issue has been discussed extensively in different posts, and I believe I read all of them, but still I can't get it working. 

I'm trying to drive three LEDs on pins P0.09, P0.10 and P0.11 of an nRF52832 on a custom board, using IAR as IDE. The LED connected to PIN 11 works fine, but the others don't. I understand these two are pins dedicated to the NFC functionality, and they require the last bit of NFCPINS to be set to 0 if you want to run them as GPIO. 

(I know if using the DK, there is a HW issue regarding a couple of missing resistors, but that's not my concern since I am using my own board, and PINS 9 and 10 are connected directly to the LEDs circuit.)

I tried to add this line of code in "uicr_config.h":

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

But it didn't solve the problem. Besides, I'm getting a warning about the "at" attribute, but maybe that's not an issue, since it's actually not an error...(?)

I have included the "uicr_config.h" file in my libraries and I have defined "CONFIG_NFCT_PINS_AS_GPIOS" in my "main.c", but no luck yet. 

Can anyone suggest other things to try, please? 

Many thanks! 

Parents
  • Adding the CONFIG_NFCT_PINS_AS_GPIOS is correct, but not in main.c. Instead in IAR add this macro in Options->C/C++ Compiler->Preprocessor->Defined Symbols

    This macro is then applied in system_nrf52.c the first time power is applied thus:

        /* 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)
            if ((NRF_UICR->NFCPINS & UICR_NFCPINS_PROTECT_Msk) == (UICR_NFCPINS_PROTECT_NFC << UICR_NFCPINS_PROTECT_Pos)){
                NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos; // Write Enable
                while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
                NRF_UICR->NFCPINS &= ~UICR_NFCPINS_PROTECT_Msk;
                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

  • Thank you for your reply! I have added CONFIG_NFCT_PINS_AS_GPIOS in the Defined Symbols as you suggested, but it still doesn't work. Could it be something else? 

  • I got it working by calling SystemInit(); in my main.c

  • Good news, but SystemInit() should already have been called from within iar_startup_nrf52.s:

    __vector_table
            DCD     sfe(CSTACK)
            DCD     Reset_Handler
    
    Reset_Handler
            LDR     R0, =SystemInit
            BLX     R0
            LDR     R0, =__iar_program_start
            BX      R0

    Have you used a different Reset_Handler?

Reply Children
  • I have the same question! I also had to call SystemInit() in my main() to get it to work. Why??

  • Reset_Handler() should call SystemInit() either in c code or asm code before invoking depending on how old the software is. Maybe try an erase all before testing to see if that works. This may also be an APROTECT issue, best if Nordic engineers respond on that point; this would depend on the nRF53832 die version see INFO.PART and INFO.VARIANT.

    As an aside, in rare cases the UICR write number limitation Nwrite (=811 writes)  may have been exceeded by something writing periodically to the same flash block, in which case an erase UICR or erase all is required to restart the life count. A double attempt to write once this number has been exceeded may work, but this is unspecified; exceeding Fwrite may result in adjacent bits being adversly affected, or may require more writes to clear a given bit.

Related