Dynamic Pin Control/Changing Functionality in runtime

[DamoL]

Hello, 

I recently noticed that I may have an issue with our current design of PCB and firmware. We basically have created a datalogger using the nRF9160, and we take readings for a variety of sensors. One such thing that we have yet to add into firmware, is the ability to read Modbus sensors (RS485), which would need a UART port. 

I am not sure I have ever fully understood the devicetree, so bare with me....

We currently have in use - (Enabled in Overlay file)

I2C0

SPI1

I2C2

UART3

So I don't know how we are going to add a further UART Port. 

Is it possible to disable say I2C0, and enable UART0 in runtime? 

Alternatively, is it possible to dynamically change the pins of UART3 to go to another set of UART pins in runtime?

On the latter I have found this remap function but it runs in PRE_KERNEL_1 sdk-zephyr/samples/boards/nordic/dynamic_pinctrl/src/remap.c at main · nrfconnect/sdk-zephyr

Can this be modified to work without rebooting the firmware? 

I am guessing either of these would be possible, maybe without using the Devicetree, but I cant find any specific reference document. 

Thanks, 

Damien

[FedericaMayorga]

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.

[DamoL]

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?

[DamoL]

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.

[Kenneth]

DamoL said:

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.

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

[DamoL]

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

FedericaMayorga said:

However, according to the documentation this should only be used before the device is initialized,

Surely this violates what the documentation says though?

Thanks, 

Damien

[Kenneth]

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

[DamoL]

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

[DamoL]

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

[Kenneth]

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

[DamoL]

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