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! 

  • 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