Can the SPI pins be used as GPIO on Thingy:91?

[Krawlow]

Hello,

I am trying to understand if I am able to use the SPI pins as GPIO when SPI is not being used. This post says that we could be able to use I2C and SPI pins besides normal GPIO pins, but if there is a way, I can't seem to find it.

Thank you,

Aleix.

[Karl Ylvisaker]

Hello Aleix,

Sorry for the late reply.

Theoretically I too would say this is possible, due to the pin crossbar in both the nRF52840 and the nRF9160 SoC - however, on the Thingy:91 there are some dependencies that might cause troubles when doing this.
For example, the PMIC that controls the different regulators is connected to the I2C, and it is configured during boot of the Thingy. I would think that this could potentially cause problems, depending on whatever you would have connected to these pins - since the I2C lines are pulled up.

For reference, you can download the hardware schematics here.

On the other hand, the SPI bus are not pulled up, and only connected to the two axelerometers. I would therefore think you could use the SPI pins however you would like, as long as the CS pins for the axelerometers are left alone. To do this, you should only have to make a connection to the pins, and reconfigure them in your software.

To avoid the potential issues of using the I2C / SPI pins, I would instead suggest using some of the other alternatives:

- There are 8 pins connected to the nRF52840 on the Thingy:91 ( see page 3 of the schematics ) labeled "nRF52_SPARE". These are connected to the unpopulated P6 pin header, and test points TP25 and TP26 ( page 6 ). Both the nRF52840 and nRF9160 chips are connected to the same I2C bus, so the nRF52840 can function as a GPIO-extender for the nRF9160. This is the option I recommend looking into first.

- The pins controlling the NMOS transistors on page 2, two of which are accessible through TP 32 ( P0.13 ) and TP 33 ( P0.16 ).

If you require even more GPIOS available, we could look into re-configuring the RTS and CTS pins of the two UART instances connecting the chips, or by disabling UART1 entirely, since it is only used for modem tracing. This would yield at least 4 additional GPIO pins.

Please do not hesitate to let me know if something is unclear, or if you have any additional questions!

Best regards,
Karl

[Krawlow]

Hi Karl,

First of all thank you very much for your extended reply.

Now that I know that theoretically it is possible, I give you additional information:

-For consumption purposes, we have disabled the power supply for the nRF52840 and therefore all SPARE pins are unavailable.
-We are already using all of the NMOS pins to control the power supply towards 3 different external sensors.
-To communicate with the sensors we are using I2C so using them is not an option either.
-We are interested in using the SPI pins because we created a little PCB that has a connection to TP34 which if I remember correctly is the SPI-SCK by default, P0.03.
-If this was not possible, we would have a plan B: trying to get rid of the necessity of using this pin. Even a plan C: getting a cable towards pin P0.10 which I think is an additional free (or partially free, with a little hardware change) GPIO.

But I have had trouble trying to configure this SCK-SPI (P0.03) to work as a GPIO. Could you give me some advice on how to do it? I have tried the following:

gpio_dev = device_get_binding("GPIO_0");
gpio_pin_configure(gpio_dev, #pinSCK-SPI(P0.03)#, GPIO_OUTPUT_HIGH);

But I don't see the pin rising.

I have also tried to change the .overlay file redirecting the sck pin to another one, making it "free". But I guess that since I don't have any configuration related to SPI in the proj.conf file, the spi configuration does not update because it is disabled. Just in case, I add my configuration file:

#CONFIG_UART_0_NRF_UARTE=y

# General config
CONFIG_ASSERT=y

# Network
CONFIG_NETWORKING=y
CONFIG_NET_NATIVE=n
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_OFFLOAD=y

# BSD library
CONFIG_BSD_LIBRARY=y

# AT host library
CONFIG_AT_HOST_LIBRARY=y
CONFIG_UART_INTERRUPT_DRIVEN=y

# Stacks and heaps
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_HEAP_MEM_POOL_SIZE=4096

# i2c
CONFIG_LOG=y
CONFIG_I2C_LOG_LEVEL_DBG=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_I2C=y
CONFIG_I2C_NRFX=y
CONFIG_I2C_2=y
#CONFIG_I2C_2_NRF_TWIM=y

# Enabling printf and floats
CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y

# Enabling JSON
CONFIG_CJSON_LIB=y

#gpio
CONFIG_GPIO=y

#debug RTT
CONFIG_CONSOLE=y
CONFIG_RTT_CONSOLE=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_UART_CONSOLE=n
CONFIG_SERIAL=y
CONFIG_LOG_IMMEDIATE=y


#wdt
CONFIG_WATCHDOG=y

Thanks for your time,

Aleix.

[Karl Ylvisaker]

Hello again Aleix,

Krawlow said:

First of all thank you very much for your extended reply.

No problem at all, I am happy to help! 

Krawlow said:

-For consumption purposes, we have disabled the power supply for the nRF52840 and therefore all SPARE pins are unavailable.
-We are already using all of the NMOS pins to control the power supply towards 3 different external sensors.
-To communicate with the sensors we are using I2C so using them is not an option either.

Thank you for the additional information, this is very helpful!
You say that you are using all the NMOS pins, but only mention 3 external sensors - do you mean that you are using all four NMOS? I am just asking to avoid any misunderstandings.

Krawlow said:

-We are interested in using the SPI pins because we created a little PCB that has a connection to TP34 which if I remember correctly is the SPI-SCK by default, P0.03.

You remember correctly, TP34 accesses SPI-SCK at P0.03.

My suggestion would be to instead use the UART1 rts and cts ( hardware flow control pins ), since they are unused anyways, so that you do not loose the SPI.
This can be done like the following:

&uart1 {
 /delete-property/ rts-pin;
 /delete-property/ cts-pin;
};

Krawlow said:

But I don't see the pin rising.

I would think that you should be able to control P0.03 using the modifications you have described.
How did you disable the SPI, something like this: ?

&spi3 {
 status = "disabled";
};

Could you also make sure that you are compiling with the correct .overlay file? Typically, this would be thingy91_nrf9160ns.overlay for non-secure Thingy:91-build.

Krawlow said:

plan B: trying to get rid of the necessity of using this pin.

If you do not mind telling me, what will the pin be used for?

Krawlow said:

plan C: getting a cable towards pin P0.10 which I think is an additional free (or partially free, with a little hardware change) GPIO.

Yes, if you are neither using the nRF52840 nor the INT2 of the ADXL's then you may use this pin as GPIO also, this is correct.

Best regards,
Karl

[Krawlow]

Hello Karl,

I will copy you in the way of answering if you don't mind

Karl Ylvisaker said:

You say that you are using all the NMOS pins, but only mention 3 external sensors - do you mean that you are using all four NMOS? I am just asking to avoid any misunderstandings.

Yes, that was a mistake of mine. We are using all of the NMOS, 3 of them as a power supply switch for 3 different sensors and for the fourth we are using its associated GPIO for an external magnetic switch.

Karl Ylvisaker said:

My suggestion would be to instead use the UART1 rts and cts ( hardware flow control pins ), since they are unused anyways, so that you do not loose the SPI.

We could also consider this, but was not able to find any suitable location on the Thingy where we could connect to these pins, I think they don't appear on the User Guide.

Karl Ylvisaker said:

I would think that you should be able to control P0.03 using the modifications you have described.
How did you disable the SPI, something like this: ?

When I put this lines in "thingy91_nrf9160ns.overlay" I get the following error trying to load the project:

Karl Ylvisaker said:

If you do not mind telling me, what will the pin be used for?

No problem: we will use the additional GPIO to trigger the enable pin of a voltage converter up to 5 volts. We are trying to control power consumption here. To avoid using an additional GPIO we would connect the enable pin directly to the NMOS pins which would have some disadvantages in terms of power consumption:

-We would have to mantain this pin up, and subsequently the sensor of that pin throughout all of the read of the remaining sensors.
-Adding up-time to the first sensor for the necessary waiting of the power converter prior to having an stable voltage.

Thanks for the help!

Aleix.

[Karl Ylvisaker]

Hello Aleix,

Krawlow said:

I will copy you in the way of answering if you don't mind

I do not mind at all! I personally find it far easier to trace the different questions when formatted in this manner, thank you for increasing the readability of your comments even further! :) 

Krawlow said:

Yes, that was a mistake of mine. We are using all of the NMOS, 3 of them as a power supply switch for 3 different sensors and for the fourth we are using its associated GPIO for an external magnetic switch.

No problem at all, thank you for telling me. This is helpful to know.

Krawlow said:

We could also consider this, but was not able to find any suitable location on the Thingy where we could connect to these pins, I think they don't appear on the User Guide.

Yes, this part is a bit trickier - sorry for not mentioning it in my last comment.
To use these pins, it will require that you cut the Solderbridges 10 and 11 ( please see the Hardware schematics ) and solder a connection to only 1 end of the now-cut solder bridge.
This will require some steady hands to do the soldering, since the SB pads are quite small, but its absolutely doable.

Krawlow said:

When I put this lines in "thingy91_nrf9160ns.overlay" I get the following error trying to load the project:

Hm.. Could you share what you have ( had ) previously done to disable the SPI? You mentioned earlier that you had disabled it, but not how you had done it - I just wanted to verify what you had done to achieve this, since you were not able to control the pin using the code snippet you posted. Could you perhaps also share the relevant parts of your .overlay file?

Krawlow said:

No problem: we will use the additional GPIO to trigger the enable pin of a voltage converter up to 5 volts. We are trying to control power consumption here. To avoid using an additional GPIO we would connect the enable pin directly to the NMOS pins which would have some disadvantages in terms of power consumption:

-We would have to mantain this pin up, and subsequently the sensor of that pin throughout all of the read of the remaining sensors.
-Adding up-time to the first sensor for the necessary waiting of the power converter prior to having an stable voltage.

Thank you for the explanation. I concur that having them on the same pin will cause some unnecessary power draw. Could you attempt to solder onto the cut solder-bridge, and let me know if you then get the functionality you were seeking? 

Best regards,
Karl