Dynamic Pin Control/Changing Functionality in runtime

RE: Dynamic Pin Control/Changing Functionality in runtime

DamoL — Fri, 13 Mar 2026 16:55:21 GMT

Hi Kenneth,

I don't have that in the devicetree. I realised why I had the issue though. I had forgotten, that when I print to the com port and I am not expecting any messages back, I use pm_device_runtime_enable() to put it in low power.

I did have to change the pm_device_action_run(uart, SUSPEND/RESUME) to pm_device_runtime_enable() or pm_device_runtime_disable(). I think that must do some extra configuration compared to action_run(), because it would cause the UART to hang after a couple of swicthes.
I have had it running 24 hours and not had an issue, so I think it works!

Thanks,

Damien

RE: Dynamic Pin Control/Changing Functionality in runtime

Kenneth — Wed, 11 Mar 2026 20:28:10 GMT

Sounds good. Can it be that you have "zephyr,pm-device-runtime-auto" for the uart instance in the devicetree? Try to delete it.

Or maybe because you have it in the devicetree you don't need to put it manually to suspend like earlier.

Kenneth

RE: Dynamic Pin Control/Changing Functionality in runtime

DamoL — Wed, 11 Mar 2026 16:53:57 GMT

I can confirm this works.

Based on this answer - https://devzone.nordicsemi.com/f/nordic-q-a/107317/configuring-uart1-using-pinctrl-for-two-uarts/463996

I did a similar thing by switching pins and sending some data over UART every second, and pins do get routed to alternative pins.

Only slight problem is when I call

err = pm_device_action_run(uart, PM_DEVICE_ACTION_SUSPEND);

It always comes back as -120 (EALREADY). If I just ignore it, it works, but I will investigate as to why, I wonder if things have been changed since SDK2.5 to SDK3.1 and I should be calling something else, but that can wait for tomorrow.

Thanks for you assistance Kenneth!

Damien

RE: Dynamic Pin Control/Changing Functionality in runtime

DamoL — Wed, 11 Mar 2026 14:40:27 GMT

I think I understand...

For the majority of the time in my code, the UART is in sleep mode (using pm_device_runtime_enable()), and the RX pin is attached to a GPIO interrupt, so if that fires it wakes up the UART (using pm_device_runtime_disable()). The UART is only really used for configuration and testing. There are already wrappers around code to stop trying to do a UART transaction if in sleep mode, so I guess I can do a similar thing, but use pm_suspend/pm_resume if I need to update the uart pins, do something, then switch back when needed.

I dont think there are any other Zephyr modules that use my UART3, all the logging modules I have used are on RTT.

I may just have to try it and see if it falls over...

Thanks,

Damien

RE: Dynamic Pin Control/Changing Functionality in runtime

Kenneth — Wed, 11 Mar 2026 14:20:21 GMT

Hi Damian,

I can understand the contradiction here now.

It should in theory be possible to do this runtime as suggested in the linked devzone case, but you just need to be very aware of and have full control over when and which UART configuration that is used at any given time, basically you need to ensure that you update at a safe time (e.g. not while it may be running a UART transaction) and that you are the one that is calling any kind of UART transaction at any given time, you can't really allow other zephyr modules use the UART at it's own free will if that make sense.

Kenenth

RE: Dynamic Pin Control/Changing Functionality in runtime

DamoL — Wed, 11 Mar 2026 14:10:40 GMT

Thanks Kenneth, that's very useful.

I am a little confused at this first option though, looking at the code provided, it seems it is using zephyr UART0, and changing the pins, with PM_DEVICE_ACTION_SUSPEND / RESUME

[quote userid="149846" url="~/f/nordic-q-a/127355/dynamic-pin-control-changing-functionality-in-runtime/562923"]However, according to the documentation this should only be used before the device is initialized, [/quote]

Surely this violates what the documentation says though?

Thanks,

Damien

RE: Dynamic Pin Control/Changing Functionality in runtime

Kenneth — Wed, 11 Mar 2026 13:04:01 GMT

[quote user="DamoL"]Seems like disabling the Zephyr UART3, and writing my own UART driver with nrfx that will deinit, and init with different pins is the way to go.[/quote]

Sounds like a good plan.

As long as you have full control of when the UART3 is used, you may find this useful also (think this may still work in recent ncs versions):
https://devzone.nordicsemi.com/f/nordic-q-a/107317/configuring-uart1-using-pinctrl-for-two-uarts/463996

Alternatively, you can use the nrfx drivers directly. An example on how to do this is shown in:
v3.2.1\modules\hal\nordic\nrfx\samples\src\nrfx_uarte

Hope that helps,
Kenneth

RE: Dynamic Pin Control/Changing Functionality in runtime

DamoL — Wed, 11 Mar 2026 08:43:10 GMT

Yea that would be the most ideal way, but we do have to support older hardware devices that have been made in that way. I cannot remember the exact reason for having two I2C ports in the first place, but I have to work with it.
Seems like disabling the Zephyr UART3, and writing my own UART driver with nrfx that will deinit, and init with different pins is the way to go.

RE: Dynamic Pin Control/Changing Functionality in runtime

Kenneth — Tue, 10 Mar 2026 17:13:49 GMT

Hello,

From a hardware perspective the only real limitation is what is described here:
https://docs.nordicsemi.com/bundle/ps_nrf9160/page/peripheral_interface.html#ariaid-title3

However the zephyr drivers do not really support this at all, they rely on static configuration compile time or early init. Only exception is if you were working at a low level driver, then you could for instance use the low level nrfx drivers to do pretty much do whatever you want, e.g. change between interfaces and pins for the same hardware ID instance. However the higher level sensor and serial drivers in zephyr do not support this in any way.

I assume you are not able to do any changes to the hardware? Because if you were able to put both i2c sensors on the same i2c interface, then that would actually work well in zephyr, because the i2c interface is by design built in such a way that if two sensors try to use (read or write to) the i2c interface at the same time, then one would simply be delayed until the other is finished, however that is really the only interface that can do this.

If you are not able to change the hardware, then that limit the number of options here. There is a i2c_gpio (i2c_bitbang) implementation in zephyr, so that might potentially free up one of the i2c hardware instances, but bit-banging i2c will be less efficient and need to be tested in case the sensor have some hard requirements to how low speed the clock can in corner cases be (don't think it's a problem, but it must be tested).

Kenneth

RE: Dynamic Pin Control/Changing Functionality in runtime

DamoL — Tue, 10 Mar 2026 15:01:34 GMT

Surely at the low level it would be possible. It's fairly standard on microcontrollers to init and deinit peripherals in runtime. I am guessing the limitation is coming from Zephyr rather than the nRF9160?

RE: Dynamic Pin Control/Changing Functionality in runtime

FedericaMayorga — Tue, 10 Mar 2026 13:43:52 GMT

Hi DamoL,

Zephyr supports dynamic pin control (CONFIG_PINCTRL_DYNAMIC), which allows updating pin configurations at runtime.

However, according to the documentation this should only be used before the device is initialized, typically during early boot. Changing pin configurations while a device is operating may lead to unexpected behavior, and Zephyr currently does not support device de-initialization.

See the documentation here:
https://docs.nordicsemi.com/bundle/ncs-2.2.0/page/zephyr/hardware/peripherals/pinmux.html

Best regards,

Federica from OWL Services.