Some GPIO pins don't work in nRF52840

[cjishnu]

I was facing some issues getting PWM peripheral work on my custom nRF52840 board. And then I tried the pwm output on P0.08 instead of P0.06 and the signal came out just fine.

So I tried the following code snippet on a modified ble_app_hrs example on PCA10056 v0.9.0 board.

//Right after advertising_start(erase_bonds);  in ble_app_hrs example

    int i=0;
    for(i=0;i<48;i++){
      nrf_gpio_cfg_output(i);
      nrf_gpio_pin_clear(i); 
    }    

And measured all the GPIO voltages on the PCA10056. Then I replaced the nrf_gpio_pin_clear with nrf_gpio_pin_set() and measured the voltage on all the GPIO pins.

These are my observations:

Following pins are always at 0V, irrespective of pin_set or pin_clear:

P0.00, P0.01, P0.09, P0.10, P0.17, P0.19, P0.20, P0.21, P0.22, P0.23

Following pins are always at 3V, irrespective of pin_set or pin_clear

P0.06, P0.18

Rest of the pins work as expected i.e. 0V for  pin_clear and 3V for pin_set

I realise that P0.09 and P0.10 are NFC pins and P18 is reset. Also a brief look at boards.h shows that pins 17, 20-23 are QSPI pins. 

So is there something I should do to get back control of these GPIOs? Is there some documentation on this? 

Let me know. I am really stuck with this.  

[cjishnu]

Hi,

This is solved. 

Based on the PDK User guide, I realised that P0.00 & P0.01 are used for crystals and the appropriate solder bridges had to be cut to access these. Same for GPIOs 17-23 since they are being used for QSPI.

Got control of P0.06 back after disabling the log. Too bad since our custom board had p0.06 used for something and now we can't have log functionality for that board? Let me know.

Thank you!

[Bjørn Kvaale]

Which SDK version are you currently using? I just took a look at the pca10056.h board file from SDK 15 & that header file sets the TX_PIN_NUMBER from UART to 6. It could be that you are setting the UART TX Pin to 6 in your custom board file & using UART logging. Therefore, when you enable logging, the P0.06 is being used by UART. You could try changing the TX_PIN_NUMBER to an unused GPIO on your custom board.

[cjishnu]

Hi, I am using SDK15.0.0. 

I will try this and let you know. But doing this will affect the whole SDK right? I mean if I change TX_PIN_NUMBER to say pin number 8, and if there are other projects in the SDK that use the pin number 8, those projects will get affected right?

What's the recommended way to edit SDK files for individual projects? Currently we do have problem porting projects from one PC to another due to edits in SDK files that goes untracked and the projects that work on one PC won't compile in another after a simple git pull (unless you create a git repo with the whole SDK which's a bit overkill).

[Bjørn Kvaale]

If you make a change to the pca10056.h header file, then it will affect all sdk examples that have support for the pca10056 board. Sorry if I misunderstood, but I thought you wanted to run this code on your custom board. Either way, if you want to make changes to the regular pca10056.h header file, it is recommended to make your own custom_board.h header file & include that in the project. 

If you take a look at boards.h, you can see this code:

#elif defined(BOARD_CUSTOM)
  #include "custom_board.h"

If you remove the BOARD_PCA10056 definition, replace that with BOARD_CUSTOM in the preprocessor definitions in your IDE & include the custom_board.h header file (you can add the custom_board.h header file in the components/boards/ folder), the custom board definition will be included in the project. It could be a good idea to copy the pca10056.h header file, rename it & use that as a starting point.