nRF52840DK using GPIO P0.18

Hi,

After spending a whole day on trying to figure out why I couldn't toggle GPIO P0.18 in nRF NCS, basic sample, e.g. blinky.

Instructions:

I added this overlay under /boards folder in the basic/blinky sample. So that P0.18 gets toggled every sec 

&led0 {
status = "okay";
gpios = < &gpio0 0x12 0x1 >;
};

This denotes mapping GPIO P0.18 to the LED0.

Next I had to add this to prj.conf

CONFIG_GPIO_AS_PINRESET=n

After much debugging and searching on devzone, and looking at UICR offset 0x200 (NRF_UICR->PSELRESET) found out that:

west flash chooses to apply pin reset by default. i.e. it will overwrite UICR to be able to reset the chip via P0.18!

This is surprising because software reset is also available and I don't see why that wasn't chosen as the default behavior to avoid confusion.

The workaround I use for now is to use nrfjprog -f <family> --program build/zepher/merged.hex or zephyr.hex depending on if it's a multi image build (e.g. with MCUBoot) or not.

Ideally west flash would not overwrite UICR and just program the image as is, using software reset (just as nrfjprog -f <fam> -r does)

Another example of someone running into this issue.

devzone.nordicsemi.com/.../331351

Parents Reply
  • https://devzone.nordicsemi.com/f/nordic-q-a/84537/enabling-pin-reset-is-still-active-even-with-config_gpio_as_pinreset-n

    Is more than 10 months old. It is a workaround for this issue that can "break" a GPIO pin in what is now the only supported IDE.

    Using VSCode with the custom board workaround and CONFIG_GPIO_AS_PINRESET=n, using flash action

    ```

    jwtrueb@dhcp-10-101-37-8 app % hexdump uicr.bin
    0000000 ffff ffff ffff ffff ffff ffff ffff ffff
    *
    0001000 0000 0000 0000 0000 0000 0000 0000 0000
    *
    0100000

    ```

    Using VSCode with only CONFIG_GPIO_AS_PINRESET=n, using flash action

    ```

    jwtrueb@dhcp-10-101-37-8 app % hexdump uicr.bin
    0000000 ffff ffff ffff ffff ffff ffff ffff ffff
    *
    0000200 0012 0000 0012 0000 ffff ffff ffff ffff
    0000210 ffff ffff ffff ffff ffff ffff ffff ffff
    *
    0001000 0000 0000 0000 0000 0000 0000 0000 0000
    *
    0100000

    ```

    If I just use `nrfjprog --program zephyr.hex`, then I don't get a surprise like with the workaround. Discussion is locked on the other issue. Is there a new recommended custom board creation process?

Children
Related