nRF53 remoteproc_mgr_config overrides pin access

[Kyrre Aalerud]

remoteproc_mgr_config() from nrf5340_cpunet_reset.c that is called during init by zephyr for starting main thread uses hardcoded pin numbers for uart with cts/rts pins and assigns these to network core during init. This is very odd since the comms between these are done in memory and it causes mayhem to the device init of the application core.
My network core devicetree is set up with no rts/cts pair and using different pins all together...

[Carl Richard]

Hello, Kyrre!

Thanks for reaching out. I've gone and opened tickets for this internally and in the Zephyr RTOS GitHub repository. As you see by the /* This should come from DTS, possibly an overlay. */ comment in nrf5340_cpunet_reset.c we are aware of this, but it hasn't been fixed yet unfortunately. 

Currently the you can only work around the issue by either changing the pins defined in nrf5340_cpunet_reset.c or by using pins that doesn't conflict.

Best regards,
Carl Richard

[theIdeaMen]

I have tried editing reset.c in my custom board folder, but it still seems to be preventing interrupts from occurring on the default remoteproc_mgr_config pins.

Unfortunately, I already had boards in-hand before discovering this conflict, so I can't really change physical pins at this time.

Maybe you can take a look at my changes to make sure it is what needs to happen for the workaround?

nrf5340_cpunet_reset.c

/* This should come from DTS, possibly an overlay. */
#if defined(CONFIG_BOARD_DATADISC_NRF5340_CPUAPP)
#define CPUNET_UARTE_PIN_TX  20
#define CPUNET_UARTE_PIN_RX  22
#define CPUNET_UARTE_PORT_TRX NRF_P0
#define CPUNET_UARTE_PIN_RTS 19
#define CPUNET_UARTE_PIN_CTS 21
#endif

#if defined(CONFIG_BT_CTLR_DEBUG_PINS_CPUAPP)
#include <../subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/debug.h>
#else
#define DEBUG_SETUP()
#endif

static void remoteproc_mgr_config(void)
{
	/* UARTE */
	/* Assign specific GPIOs that will be used to get UARTE from
	 * nRF5340 Network MCU.
	 */
	CPUNET_UARTE_PORT_TRX->PIN_CNF[CPUNET_UARTE_PIN_TX] =
		GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
	CPUNET_UARTE_PORT_TRX->PIN_CNF[CPUNET_UARTE_PIN_RX] =
		GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
	CPUNET_UARTE_PORT_TRX->PIN_CNF[CPUNET_UARTE_PIN_RTS] =
		GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
	CPUNET_UARTE_PORT_TRX->PIN_CNF[CPUNET_UARTE_PIN_CTS] =
		GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;

	/* Route Bluetooth Controller Debug Pins */
	DEBUG_SETUP();

	/* Retain nRF5340 Network MCU in Secure domain (bus
	 * accesses by Network MCU will have Secure attribute set).
	 */
	NRF_SPU->EXTDOMAIN[0].PERM = 1 << 4;
}

[KRich]

I recently ran into the same issue. I wrapped the entire UART/pin setup (including the call to DEBUG_SETUP() which I think is key) in a #ifdef CPUNET_UARTE_PORT_TRX ... #endif block. That seems to keep that debug UART from getting setup and taking it over from the app processor when not on the dev kit.