UART PINS REMAPPING AT RUN TIME

RE: UART PINS REMAPPING AT RUN TIME

hugo_98 — Wed, 23 Oct 2024 10:03:09 GMT

Hi,

I encountered the same use case for my application where everything must be reconfigure at runtime and we try not to lose the functionnalities offered by Zephyr Services built on top of the driver api. I found a solution based on the use of Device Runtime Power Management and the pin switching is done via pincontroller API.

My configuration : ncs 2.7.0

This solution works only for UART driver, with the <zephyr/drivers/serial/uart_nrfx_uarte.c> at the end, as far as I know.

What we need to do, in a nutshell :

disable/deinitialise the uart driver ie. uarte peripheral and interruptions basically
retreive the pinctrl config of interest
apply the new pinctrl config
enable/reinitialise the uart driver

From the application perspective, there is no way to deinitialise the uart driver directly. But looking at the <zephyr/drivers/serial/uart_nrfx_uarte.c> PM action callback implementation, I found something really interesting :

You can configure the driver not to handle the automatic pin initialisation when switching power state using Kconfig option CONFIG_UART_n_GPIO_MANAGEMENT (n is the uart instance id). Given that, we are able to deinitialise/reinitialise the uart driver properly using Device Runtime Power Management.

prj.conf (fragment):

CONFIG_PM=y
CONFIG_PM_DEVICE=y
CONFIG_PM_DEVICE_RUNTIME=y

CONFIG_UART_0_GPIO_MANAGEMENT=n # UARTE0 pins must be controlled independantly because the peripheral is used for multiple devices.

CONFIG_PINCTRL_DYNAMIC=y

Now let's configure the pins !

I use the empty pinctrl-N slots to add my other pin configurations in the devicetree.

&uart0 {
    status = "okay";

    pinctrl-0 = <&uart0_default>;
    pinctrl-1 = <&uart0_sleep>;
    pinctrl-2 = <&uart0_gsm>;
    pinctrl-3 = <&uart0_gnss>;
    pinctrl-names = "default","sleep","gsm","gnss";
};

Although "default" state refers PINCTRL_STATE_DEFAULT and "sleep" state refers PINCTRL_STATE_SLEEP as expected, "gsm" and "gnss" states are custom states whose corresponding macro names

PINCTRL_STATE_GSM and PINCTRL_STATE_GNSS will be generated at build time.

These names are unknown from the uart driver's perspective : at this point we hit serious compilations problem in case we try to build the project.

The first option I thought about was modifying the uart_nrfx_uarte.c source code, adding my new pinctrl states definitions on the top of the file like we can see in other drivers. Easy but not sexy.

So I looked for another option more "project specific", end I ended up providing these macro definitions to the compiler via my project's CMakeLists.txt, using Zephyr's cmake extention

zephyr_compile_definitions().

# SPDX-License-Identifier: Apache-2.0

cmake_minimum_required(VERSION 3.20.0)
find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(custom_dts_binding)

# This is a convenience hack : we need it to inform the uart driver that these states exists, without
# having to modify the uart driver itself.
zephyr_compile_definitions(PINCTRL_STATE_GSM=2 PINCTRL_STATE_GNSS=3)

FILE(GLOB app_sources src/*.c)
target_sources(app PRIVATE ${app_sources})

Now gcc shouldn't complain anymore (at least about unknown pinctlr states).

In the application code, the dynamic switch is handled like this:

/**
 * @brief Initialize runtime power management for uart0
 *
 * @return int
 */
static int switch_init__PM_METHOD(void)
{
	int err;
	err = pm_device_runtime_enable(p_uarte0_dev);
	if (err != 0)
	{
		printf("The PM device runtime is not ready.\n");
		return err;
	}

	err = pm_device_runtime_get(p_uarte0_dev);
	if (err != 0)
	{
		printf("The PM device still suspended.\n");
		return err;
	}
	return 0;
}

/**
 * @brief Switch uart0 pins dynamically to gsm pins
 *
 * @return int
 */
static int switch_uarte0_to_gsm__PM_METHOD(void)
{
	int ret;

	// The device (UARTE0) must be configured with CONFIG_UART_0_GPIO_MANAGEMENT disabled,
	// otherwise, this call ant further pm_device_runtime_get() will set pinctrl depending on SLEEP and DEFAULT states.
	ret = pm_device_runtime_put(p_uarte0_dev);
	if (ret < 0)
	{
		return ret;
	}

	// Now we fetch the pin config of interest.
	const struct pinctrl_dev_config *p_config = PINCTRL_DT_DEV_CONFIG_GET(UARTE_NODE);
	ret = pinctrl_apply_state(p_config, PINCTRL_STATE_GSM);
	if (ret < 0)
	{
		return ret;
	}

	// And we can resume our device through PM, which won't
	// touch pinctrl.
	ret = pm_device_runtime_get(p_uarte0_dev);
	if (ret < 0)
	{
		return ret;
	}

	printf("Switched UARTE0 to GSM\n");
	return 0;
}

All the best,

Hugo

RE: UART PINS REMAPPING AT RUN TIME

JakeJ — Tue, 17 Sep 2024 21:50:12 GMT

I know this is an old thread but it might be easiest to just change the PSEL.TXD, and PSEL.RXD registers for the specific UART in the HW versus the other suggested methods. You can have your thread change this and wait a certain amount of time for any current TX transactions to finish (assuming you don't need very tightly timed switch over). Or see this about using pin control groups and dynamically selecting at runtime Pin Control — Zephyr Project Documentation

RE: UART PINS REMAPPING AT RUN TIME

Øivind — Tue, 31 Oct 2023 18:32:33 GMT

Hi again, we prefer that users create a new ticket for issues which do not fall under the topic of the original ticket.

That being said, I believe the data for the event would be stored in:

p_event.data.rx.p_data

The structure for nrfx_uarte_event_t is:

/** @brief Structure for the UARTE transfer completion event. */
typedef struct
{
    uint8_t * p_data; ///< Pointer to memory used for transfer.
    size_t    bytes;  ///< Number of bytes transfered.
} nrfx_uarte_xfer_evt_t;

/** @brief Structure for UARTE error event. */
typedef struct
{
    nrfx_uarte_xfer_evt_t rx;         ///< Transfer details, including number of bytes received.
    uint32_t              error_mask; ///< Mask of error flags that generated the event.
} nrfx_uarte_error_evt_t;

/** @brief Structure for UARTE event. */
typedef struct
{
    nrfx_uarte_evt_type_t type; ///< Event type.
    union
    {
        nrfx_uarte_xfer_evt_t  rx;    ///< Data provided for RX completion events.
        nrfx_uarte_xfer_evt_t  tx;    ///< Data provided for TX completion events.
        nrfx_uarte_error_evt_t error; ///< Data provided for error event.
    } data;                           ///< Union to store event data.
} nrfx_uarte_event_t;

Please make a new ticket if you need further support on how to handle the event data.

RE: UART PINS REMAPPING AT RUN TIME

vinodsdw — Tue, 31 Oct 2023 12:16:44 GMT

Hi,

While using the nrfx driver, what zephyr mechanism I can use to collect the data received inside the below handler ?

/**
* @brief Function for handling UARTE driver events.
*
* @param[in] p_event Pointer to event structure. Event is allocated on the stack so it is available
* only within the context of the event handler.
* @param[in] p_context Context passed to the interrupt handler, set on initialization. In this example
* p_context is used to pass the address of the UARTE instance that calls this handler.
*/
static void uarte_handler(nrfx_uarte_event_t const * p_event, void * p_context)
{
nrfx_uarte_t * p_inst = p_context;
if (p_event->type == NRFX_UARTE_EVT_TX_DONE)
{
NRFX_LOG_INFO("--> UARTE event: TX done");
NRFX_LOG_INFO("Content of TX buffer: %s", m_tx_buffer);
NRFX_LOG_INFO("Content of RX buffer: %s", m_rx_buffer);
}
else
{
NRFX_LOG_INFO("UARTE event: %d", p_event->type);
}
nrfx_uarte_uninit(p_inst);
}

Can I push the data to zephyr os fifo?

RE: UART PINS REMAPPING AT RUN TIME

vinodsdw — Thu, 05 Oct 2023 11:49:11 GMT

Thanks, I will try it and will update you.

RE: UART PINS REMAPPING AT RUN TIME

Øivind — Thu, 05 Oct 2023 11:46:46 GMT

Hi,

For this you should disable uart2 in the devicetree and use our nrfx driver api directly. The Zephyr driver uses this api, but has some limitations, as you correctly point out.

You can find a sample for using uart through this api at <SDK>/modules/hal/nordic/nrfx/samples/src/nrfx_uarte/tx_rx_non_blocking

You will need to uninit the peripheral, then reinit it to change the pins. You also need to make a nrfx_uarte_config_t for each desired setup and use these when you reinit.

Here are the header files with the api for uart and uarte(with DMA), I have highlighted the init and uninit functions for you:

https://github.com/nrfconnect/sdk-hal_nordic/blob/main/nrfx/drivers/include/nrfx_uart.h#L173-L199

https://github.com/nrfconnect/sdk-hal_nordic/blob/main/nrfx/drivers/include/nrfx_uarte.h#L182-L208

You can try using this to make a simple application that switches between two setups, and I will assist you if you run into any issues.