GPIO conflict

RE: GPIO conflict

Edvin — Mon, 01 Jul 2024 21:27:36 GMT

I am glad to hear. Closing the ticket. I will be out of office for a couple of weeks soon. If anything related pops up, please open a new ticket, and someone will be able to handle it before I come back.

Best regards,

Edvin

RE: GPIO conflict

Timothy — Mon, 01 Jul 2024 16:06:38 GMT

Edvin

this is working nicely. This can be closed. Thank you for your support.

RE: GPIO conflict

Timothy — Thu, 27 Jun 2024 13:49:33 GMT

Edvin

I removed all other references to uart0 in prj.conf. The only reference to uart0 is the pinctrl above and an alias. The change worked perfectly. There are no changes to any V2.5.0 file now. Thank you for your help. I will test for a few days before we close it, but all should be OK. Pin 23/26 are defined but not used on the custom board.

RE: GPIO conflict

Edvin — Thu, 27 Jun 2024 10:43:33 GMT

Hello,

I agree that it is preferable not to change any of the SDK files.

The simple workaround is to do the change that you just did, but do it in the overlay file instead. Add something like this to your own overlay file:

&pinctrl {
	uart0_default: uart0_default {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 29)>,
				<NRF_PSEL(UART_RTS, 0, 23)>;
		};
		group2 {
			psels = <NRF_PSEL(UART_RX, 0, 28)>,
				<NRF_PSEL(UART_CTS, 0, 26)>;
			bias-pull-up;
		};
	};

	uart0_sleep: uart0_sleep {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 29)>,
				<NRF_PSEL(UART_RX, 0, 28)>,
				<NRF_PSEL(UART_RTS, 0, 23)>,
				<NRF_PSEL(UART_CTS, 0, 26)>;
			low-power-enable;
		};
	};
};

I see that you tried to delete the node uart0 in your overlay file, but later in the same file, you state:

/ {
	chosen {
		zephyr,bt-uart=&lpuart;
        nordic,nus-uart=&uart0;
	};
};

So without building and looking into your application, it is a bit difficult to say how this would behave.

If you upload the entire project as a zipped folder, I can have a look. If that is not possible, can you please try to do that pin change in yoru prj.conf?

Best regars,

Edvin

RE: GPIO conflict

Timothy — Wed, 26 Jun 2024 16:37:25 GMT

Edvin

I have it working as shown below. I changed Pin 27 to Pin 23 (an unused pin on custom board) in the file C:\Nordic1\v2.5.0\zephyr\boards\arm\nrf9160dk_nrf9160\nrf9160dk_nrf9160_common-pinctrl.dtsi.

so it definitely is uart0 messing up pin 27. any idea what is going on?

I should have taken care of this in my overlay file. It does remove uart0 and redefine it without Pin 26/27.

I can live with this change if I have to but I really did not want to alter any V2.5.0 files at all.

> batmon 0

batmon 0

Battery Monitor: 0 Disabled

> adc

adc

BAT: 0.12 V ADC: 2.85 V

> batmon 1

batmon 1

Battery Monitor: 1 Enabled

> adc

adc

BAT: 3.31 V ADC: 2.84 V

RE: GPIO conflict

Timothy — Wed, 26 Jun 2024 16:31:03 GMT

Edvin

this is my setup for output GPIOs. all others work just a problem with BAT_MON_EN. The overlay file was given earlier.

/* outputs */

#define SW2CTRL_DEV_NODE DT_GPIO_CTLR(DT_ALIAS(sw2ctrl), gpios)

#define SW2CTRL_DEV_PIN DT_GPIO_PIN(DT_ALIAS(sw2ctrl), gpios)

#define SW2CTRL_DEV_PIN_DTS_FLAGS DT_GPIO_FLAGS(DT_ALIAS(sw2ctrl), gpios)

#define CS2N_DEV_NODE DT_GPIO_CTLR(DT_ALIAS(spi_cs2n), gpios)

#define CS2N_DEV_PIN DT_GPIO_PIN(DT_ALIAS(spi_cs2n), gpios)

#define CS2N_DEV_PIN_DTS_FLAGS DT_GPIO_FLAGS(DT_ALIAS(spi_cs2n), gpios)

#define CS3N_DEV_NODE DT_GPIO_CTLR(DT_ALIAS(spi_cs3n), gpios)

#define CS3N_DEV_PIN DT_GPIO_PIN(DT_ALIAS(spi_cs3n), gpios)

#define CS3N_DEV_PIN_DTS_FLAGS DT_GPIO_FLAGS(DT_ALIAS(spi_cs3n), gpios)

#define BAT_MON_EN_DEV_NODE DT_GPIO_CTLR(DT_ALIAS(batmonen), gpios)

#define BAT_MON_EN_DEV_PIN DT_GPIO_PIN(DT_ALIAS(batmonen), gpios)

#define BAT_MON_EN_DEV_PIN_DTS_FLAGS DT_GPIO_FLAGS(DT_ALIAS(batmonen), gpios)

const struct device *sw2ctrl_dev = DEVICE_DT_GET(SW2CTRL_DEV_NODE);

const struct device *spi2_csn_dev = DEVICE_DT_GET(CS2N_DEV_NODE);

const struct device *spi3_csn_dev = DEVICE_DT_GET(CS3N_DEV_NODE);

const struct device *bat_mon_en_dev = DEVICE_DT_GET(BAT_MON_EN_DEV_NODE);

/* set up BAT_MON_EN as output/pullup */

if (!device_is_ready(bat_mon_en_dev))

{

myPrintfW("BAT MON EN device is not ready\r\n");

}

else

myPrintfS("BAT MON EN device is ready\r\n");

gpio_pin_configure(bat_mon_en_dev, BAT_MON_EN_DEV_PIN, GPIO_OUTPUT | GPIO_PULL_UP);

gpio_pin_set(bat_mon_en_dev, BAT_MON_EN_DEV_PIN, 1);

RE: GPIO conflict

Edvin — Wed, 26 Jun 2024 09:41:19 GMT

[quote user="tjm1"]all the other GPIO pins work properly[/quote]

All others?

What about the other GPIOs originally used by the uart0? Have you tried to change the GPIOs of uart0 directly in the .dts file? Just for debugging purposes? This will tell you whether it is the uart that is still holding the gpio, or if it is being set somewhere else.

Also, try to debug, and look at the GPIOs config register. What does it say? We can use this to determine whether the pin is set as an input or output. What does it say if you don't try to use it? Perhaps that can give a hint of what the pin is used for.

BR,
Edvin

RE: GPIO conflict

Timothy — Tue, 25 Jun 2024 12:32:05 GMT

Edvin

thanks for the quick response. If I gave you the project it would only work on our custom board. am I disabling the pins from UART0 and reenabling P0.27 to be used for our custom board properly in the overlay file? all the other GPIO pins work properly.

RE: GPIO conflict

Edvin — Tue, 25 Jun 2024 08:37:12 GMT

Hello,

Is it possible to upload the entire project, or a strip-down project that can replicate the issue that you are seeing? Then I can poke around and see if I can figure out why this pin is not controllable by the application.

Best regards,

Edvin

RE: GPIO conflict

Timothy — Mon, 24 Jun 2024 14:08:24 GMT

Edvin

some more information. maybe this helps. I see a group2 for uart0. I do not know where that comes from. I only have group1 in the overlay. I have included both group1 and group2 info below. The uart0_sleep only has a group1. there is no group2.

RE: GPIO conflict

Timothy — Mon, 24 Jun 2024 13:37:17 GMT

Edvin

I apologize for taking so long to get back to you. I have been working on testing the rest of the custom board. so far all seems to work fine but pin 27. I have attached the latest overlay file. In looking at the device tree I see that for BUSES UART0 P0.27 is gone but it still shows P0.26 as CTS. so I did not remove UART0 completely. I also see from looking at GPIO pins that P0.27 is assigned to bat_mon_en correctly. P0.27 is not toggling when I test it like I do with other GPIO output pins. This is a show stopper since I cannot read the battery voltage unless I can set this pin. The custom boards are created and in pre production testing so I cannot move to a different pin. any idea what I am doing wrong?

devzone.nordicsemi.com/.../3513.nrf9160dk_5F00_nrf9160_5F00_ns.overlay

RE: GPIO conflict

Edvin — Mon, 29 Apr 2024 12:21:44 GMT

When doing this test, and the P0.27 doesn't work, are you testing this on the nRF91DK, or your custom board?

If it is on the DK, please have a look at the back of the DK, and you can see some diagrams of some of the GPIOs. You can see that the P0.27 is not routed out to the pin by default.

In that case, try switching SW6 over to disconnect the InterFace MCU:

https://infocenter.nordicsemi.com/topic/ug_nrf91_dk/UG/nrf91_DK/hw_figures.html?cp=2_1_4_3_0

Best regards,

Edvin

RE: GPIO conflict

Timothy — Thu, 25 Apr 2024 16:17:42 GMT

I have attached my overlay file. The BAT_MON_EN (P0.27) does not work when I toggle with the code above. The other pins seem to work just fine. what am I doing wrong?

devzone.nordicsemi.com/.../6278.nrf9160dk_5F00_nrf9160_5F00_ns.overlay

RE: GPIO conflict

Edvin — Thu, 25 Apr 2024 13:11:20 GMT

Hello,

Did you do anything to disable the UART0 CTS pin before trying to use it as an output pin? If not, then the GPIO is probably controlled by the UART, and you will not be able to control it.

If you look in the file nrf9160dk_nrf9160_common-pinctrl.dtsi, you will see the definition of uart0_default and uart0_sleep close to the top. Don't change this file (you can for testing, but I don't recommend doing so permanently), but copy the part about uart0:

&pinctrl {
	uart0_default: uart0_default {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 29)>,
				<NRF_PSEL(UART_RTS, 0, 27)>;
		};
		group2 {
			psels = <NRF_PSEL(UART_RX, 0, 28)>,
				<NRF_PSEL(UART_CTS, 0, 26)>;
			bias-pull-up;
		};
	};

	uart0_sleep: uart0_sleep {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 29)>,
				<NRF_PSEL(UART_RX, 0, 28)>,
				<NRF_PSEL(UART_RTS, 0, 27)>,
				<NRF_PSEL(UART_CTS, 0, 26)>;
			low-power-enable;
		};
	};

And create a file called "nrf9160dk_nrf9160.overlay" in your application folder (same folder as your prj.conf). Then paste this snippet that you just copied, and add a final line with "};" at the end to close off the bracket. Then try to remove everything about UART_RTS and UART_CTS (make it look like the uart2 definition in the original nrf9160dk_nrf9160_common-pinctrl.dtsi file):

&pinctrl {
	uart0_default: uart0_default {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 29)>,
				<NRF_PSEL(UART_RX, 0, 28)>;
		};
	};

	uart0_sleep: uart0_sleep {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 29)>,
				<NRF_PSEL(UART_RX, 0, 28)>;
			low-power-enable;
		};
	};
};

save the file, and delete your build folder, and build from scratch. Does that allow you to toggle pin P0.27?

Best regards,

Edvin