nRF9160 - Issue reconfiguring IF5 (P0.23) to Open Drain

[gwagner_emf]

I have a custom board that started life based off of RF9160-DK 1.1.0.

We have a single programming header that can be used to program either the 52840 or the 9160 depending on the switch position.

During regular operation, the 9160 needs to be able to reset the 52840 via 9160:P0.23.

During programming, the JLINK will use the reset line.

So I need to set 9160:P0.23 as an open drain with a pullup.

We have created an overlay file for the 9160 that deletes the node &nrf52840_reset, and then set up 9160 pin 0.23 with GPIO_PULL_UP and as an GPIO_OPEN DRAIN as shown in the following:

/delete-node/ &nrf52840_reset;

/	{
	gpio_pins {
		compatible = "gpio-keys";
		
		nrf52840_reset_gpio: nrf52840_rst{
			gpios = <&gpio0 23 (GPIO_PULL_UP | GPIO_OPEN_DRAIN)>;
			label = "NRF52840 reset pin";
		};
	};
};

However, when the debugger finishes programming the 52840 (star in the image above) and the JLINK asserts the NRESET, it only gets down to 800mjV.

So it seems that the 9160 pin is not behaving as an open drain.  I confirmed this by disconnecting IF5 trace from the 9160 after which the debugger is able to fully pull down the NRESET to the 52840.

Is the snippet of our overlay changes incorrect? ... missing something? ... another way of doing this?

Thanks,

-- Glenn

[Håkon Alseth]

Hi,

 

A programmer/debugger only needs SWDIO/SWDCLK to program, so you can technically omit the nRESET signal.

That being said, it shall be supported to have it present.

 

In your gpios definition, it seems that you do not have a field for the polarity of the pin. Try adding " | GPIO_ACTIVE_LOW" to the properties.

Without any explicit level, it will be determined to be ACTIVE_HIGH.

 

Kind regards,

Håkon

[gwagner_emf]

Hello Håkon,

I added GPIO_ACTIVE_LOW as suggested:

/delete-node/ &nrf52840_reset;

/	{
	gpio_pins {
		compatible = "gpio-keys";
		
		nrf52840_reset_gpio: nrf52840_rst{
			gpios = <&gpio0 23 (GPIO_PULL_UP | GPIO_OPEN_DRAIN | GPIO_ACTIVE_LOW)>;
			label = "NRF52840 reset pin";
		};
	};
};

Unfortunately, I still end up with 800mV when the JLINK attempts the reset.

BR,

-- Glenn

[Håkon Alseth]

Hi,

 

Are you using the board file for nrf52840_reset as-is?

https://github.com/nrfconnect/sdk-zephyr/blob/v3.5.99-ncs1/boards/arm/nrf9160dk_nrf9160/nrf52840_reset.c#L60

Is the problem here that the firmware running on the nRF9160 is trying to reset the nRF52 device while you're connecting the debugger?

 

Have you tried looking at the signal "NRF52_NRESET" with an oscilloscope?

 

Kind regards,

Håkon

[gwagner_emf]

Hello Håkon,

The original issue was that the reset being driven by the JLINK to the 52840 was not being allowed to reach 0V since the 9160 pin 0.23 was not being properly configured as open drain.  Somehow it was being left as an active drive and unintentionally we were ending up with both the JLINK (driving 0) and 9260 (driving 1).  End result being a quasi-low of 0.8V being supplied to the 52840 pin. 

Your comment about using nrf52840_reset as-is gave us an idea to try.

Seems the solution was not to delete the nrf52840_reset node and redefine p0.23 GPIO as we had in the code samples above ... but instead overlay the node taken from here: https://github.com/nrfconnect/sdk-zephyr/blob/d96769facecaba386b642d2c76c92c7694c81da0/boards/arm/nrf9160dk_nrf9160/dts/nrf9160dk_nrf52840_reset_on_if5.dtsi#L9) with the desired  GPIO properties in our overlay file:

&nrf52840_reset {
	status = "okay";
	gpios = <&interface_to_nrf52840 5 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN | GPIO_PULL_UP)>;
};

This worked.  When the Jlink asserts NRESET, there is no more interference from the 9160's p0.23 and the scope is showing the NRESET signal gets down to 0V.

Thank you for your help!

-- Glenn