UART pins change in a runtime

RE: UART pins change in a runtime

Hieu — Thu, 23 Jan 2025 14:02:37 GMT

In the MCUmgr communication you are referring to, is MCUboot running, or is the application running?

MCUboot runs its own DeviceTree and you can still use UART normally with it.

As for the application, if you still define the node on DeviceTree and enable the Zephyr driver, then you will be able to use it. You can use nrfx alongside to change the pin as you want. However, you need to understand the Zephyr UART driver implementation and how other subsystem, like MCUmgr, uses the Zephyr UART driver to be able to switch safely.

At this point, the most proper solution would be to write your own UART driver for Zephyr that allow this functionality.

RE: UART pins change in a runtime

tdfilip — Wed, 22 Jan 2025 12:23:11 GMT

What I want to do with that uart1 is to communicate using mcumgr with mcuboots of two nRFs. If I use nrfx driver, will I be able to assign uart1 to mcumgr in devicetree?

RE: UART pins change in a runtime

Susheel Nuguru — Wed, 22 Jan 2025 11:30:21 GMT

Not sure which version you were using, but yes CONFIG_UART_1_GPIO_MANAGEMENT seems to have been removed as a configurable option from the SDK some time ago (not sure which SDK version that was removed)

Ability to dynamically change pins on the fly is not officially supported by Zephyr or our drivers. Trying to do additional workarounds like this through the Zephyr API is very tricky with changing API behavior. It looks like due to the fact that CONFIG_UART_1_GPIO_MANAGEMENT is not available anymore, it is not clear if you can even attempt to change the pins on the fly using Zephyr API. I would have tried to use only nrfx driver for uart1 you have a resource restriction and you need to reconfigure pin on the fly, something that have been discussed here