nRF9160 DK - UART big picture

RE: nRF9160 DK - UART big picture

Simon — Tue, 14 Jun 2022 10:55:06 GMT

I'm glad we were able to help you and good luck with the project!

RE: nRF9160 DK - UART big picture

Sebastian Stein — Tue, 14 Jun 2022 09:45:40 GMT

Hi Simon,

thank you for your explanation.

[quote userid="72692" url="~/f/nordic-q-a/88494/nrf9160-dk---uart-big-picture/372333#372333"]Is this suficcient for you? Every time you need to change pins, you reboot?[/quote]

Well, yes and no. Of cause it would be more comfortable to re-configure the HW Peripherals without having to reboot the chip because "state" could be handled much easier this way. However, I understand why it is not possible at the moment and nonetheless, it is very good to know how the task can be tackled using either the reboot or the "direct-nrfx-driver" approach. Now it is up to us to discuss which route to take.

Long story short, I believe I have all the information I was asking for (and more). Thus, many thanks to both of you for your support!

RE: nRF9160 DK - UART big picture

Simon — Tue, 14 Jun 2022 09:21:08 GMT

What pin control enabled was to be able to reconfigure pins without needing to rebuild the app. However, you will need to reset the chip in order to change the configuration*. Is this suficcient for you? Every time you need to change pins, you reboot?

If this is not sufficient, you could use the nrfx drivers directly, which gives you more control. However, then you loose the advantages and simplicity Zephyr brings with it. Here is a sample demonstrating how to use the nrfx drivers: https://github.com/nrfconnect/sdk-zephyr/tree/v3.0.99-ncs1/samples/boards/nrf/nrfx

*The reason you need to reset your chip, is because the reconfiguration needs to happen before the pins gets initialized. For example for UART, the function uart_nrfx_uarte.c-->uarte_instance_init() will run at boot (before main), and will use the pins set by the UART_NRF_UART_DEVICE macro (which gets the pins from the device tree using DT_PROP(_OR)). By using SYS_INIT, you can run stuff at boot before the initialization functions, and this is what the dynamic_pinctrl sample does: https://github.com/nrfconnect/sdk-zephyr/blob/v3.0.99-ncs1/samples/boards/nrf/dynamic_pinctrl/src/remap.c#L61.

Best regards,

Simon

RE: nRF9160 DK - UART big picture

Sebastian Stein — Tue, 14 Jun 2022 06:23:37 GMT

Hi Simon,

thank you for your answer. The documentation you pointed at looks promising. However,

[quote userid="81181" url="~/f/nordic-q-a/88494/nrf9160-dk---uart-big-picture/370744#370744"]However, it is possible to re-configure them at runtime. So, e.g. assuming you don't need the SPI and the I2C at the same time, you can use the same peripheral for both (with different pins, or some switching mechanism).[/quote]

I am looking for a mechanism to re-configure (periodically back and forth) the HW peripherals at later stages during runtime (sorry if I was not clear about that). The description of the dynamic_pinctrl sample makes the following two statements:

"The Dynamic Pin Control (nRF) sample demonstrates how to change uart0 at early boot stages, [...]"

"Alternative configurations can only be applied if the device driver using the associated pins has not been initialized yet."

I interpret these statements as if re-configuring HW peripherals is only possible during very early stages during the system startup and not during the "mode of operation" later on.

Is it possible to re-configuring HW peripherals dynamically multiple times at runtime after boot and initialization? If yes, could you please explain to me how that can be done or point at the corresponding documentation?

Thank you allot for your help!

RE: nRF9160 DK - UART big picture

Simon — Mon, 13 Jun 2022 20:51:14 GMT

Re-configuring pins of a peripheral in runtime is possible in NCS v2.0.0 with the introduction of Pin control

The sample dynamic_pinctrl demonstrates how to do this:

Read more about dynamic pin control in the Zephyr documentation:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/zephyr/hardware/pinctrl/index.html#dynamic-pin-control

Best regards,

Simon

RE: nRF9160 DK - UART big picture

Sebastian Stein — Mon, 13 Jun 2022 06:00:58 GMT

Hi Didrik,

thank you for your Reply.

[quote userid="81181" url="~/f/nordic-q-a/88494/nrf9160-dk---uart-big-picture/370744#370744"]However, it is possible to re-configure them at runtime.[/quote]

That sounds like a good solution to me. Can you please provide a link to the documentation of this feature or tell me in which header the corresponding functions are declared?

Thank you!

RE: nRF9160 DK - UART big picture

Didrik Rokhaug — Thu, 02 Jun 2022 15:23:38 GMT

Correct. The nRF9160 only has 4 serial peripherals.

However, it is possible to re-configure them at runtime. So, e.g. assuming you don't need the SPI and the I2C at the same time, you can use the same peripheral for both (with different pins, or some switching mechanism).

RE: nRF9160 DK - UART big picture

Sebastian Stein — Wed, 01 Jun 2022 14:15:39 GMT

Hi Didrik,

thank you allot for you comprehensive answer. It clarified allot of things. I'll make sure to have a look at the course you suggested.

[quote userid="81181" url="~/f/nordic-q-a/88494/nrf9160-dk---uart-big-picture/370459#370459"]We use the same HW peripheral for all serial busses: UART, SPI and I2C. The peripheral can only be one of those at a time.[/quote]

If I interpret your statement and the device tree files correct, I have four and only four HW peripherals at my disposal when working with the nRF9160 DK. That means for example if I would use three of them as UARTs and one of them as SPI interface, I would be in trouble if I would need an additional I2C interface. Is that correct?

RE: nRF9160 DK - UART big picture

Didrik Rokhaug — Wed, 01 Jun 2022 13:13:22 GMT

Hi,

[quote user=""]How do the different UART entities UART_9160_[0,1,2,3], UART_52840_[0,1], and UART_DK_[0,1,2] relate to each other?[/quote]

As you say, the nRF9160 can have 4 UARTs (UART_NRF9160_[0,1,2,3]), while the nRF52840 can have 2 UARTs (UART_NRF52840_[0,1]). We use the same HW peripheral for all serial busses: UART, SPI and I2C. The peripheral can only be one of those at a time. So, depending on your configuration, you might not have 4 UARTs available, but e.g. 2 UARTs, 1 I2C and 1 SPI. For simplicity going forward, let's assume we always have the maximum possible amount of UARTs, unless explicitly stated otherwise.

Which pins are assigned to which peripheral is configurable at runtime. In NCS and Zephyr, that configuration is done by the device tree files. So the pins you see in the SoC .dts files are simply the "default" pins used by the SDK, but they can be changed by boards and applications.

When you look at ncs\v1.9.1\zephyr\boards\arm\nrf9160dk_nrf9160\nrf9160dk_nrf9160_common.dts, you see the configuration of the nRF9160 on the nRF9160 DK. Note that in the SoC board files, all the UARTs are disabled. In the DK board files, two of them are enabled, and the pins of the third are modified.

In other words, UART_DK_[0,1,2] = UART_NRF9160_[0,1,2]. UART_NRF9160_3 are not mentioned in the DK board files. I.e. it uses the same pins as in the SoC files, and is still disabled.

Again, I want to repeat that the both the board and SoC configurations can be overwritten by the application.

The story for the nRF52840 is similar. In the SoC device tree files both UARTs are disabled, while in the board files (zephyr/boards/arm/nrf9160dk_nrf52840.dts) UART_NRF52840_0 is enabled, and the pinout is changed.

In either case, these .dts files only tell you which UARTs has been routed to which pins of the SoCs. Not where those pins are routed on the actual DK.

[quote user=""]Why does the nRF9160 DK only expose three UART entities while the nRF9160 has four?[/quote]

If you are talking about UART_DK_[0,1,2], that is not the correct interpretation. See above.

However, you are correct that the nRF9160 DK only converts 3 UARTs to virtual serial ports that you can see on your computer. This is because the on-board debugger only can convert 3 UARTs to USB veirtula serial ports (VCOMs). Of these three UARTs, two are used by the nRF9160 (UART_NRF9160_0 and UART_NRF9160_1 by default), and one by the nRF52840 (UART_NRF52840_0 by default).

[quote user=""]How can I configure which UART entity is exposed through which pins of the nRF9160 DK[/quote]

To better understand how to use the device tree, I recommend you our nRF Connect SDK Fundamentals course on our Nordic Developer Academy: https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/

[quote user=""]Which UART entities are forwarded per default through the virtual comports?[/quote]

See my answer above, as well as the schematics and documentation for the DK.

[quote user=""]How can I configure which UART entities are forwarded through the virtual comports?[/quote]

As previously mentioned, you can change the pinout so that the UART entity you want use the pins connected to the on-board debugger.

[quote user=""]How can I stop an UART entity from being forwarded through the virtual comports?[/quote]

You can either not use the pins connected to the on-board debugger, or you can change the routing on the DK so those pins are routed to the pin headers instead. For more information, see the board controller FW documentation: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.1/zephyr/boards/arm/nrf9160dk_nrf52840/doc/index.html#board-controller-firmware

[quote user=""]Assuming that UART_DK_0 is the "primary" UART used for console and AT data traffic, would it mess with the nRF9160 DK if UART_DK_0 would additionally be used to communicate to other external devices?[/quote]

UART is only designed to be used between two nodes. Adding a third device is not really supported. However, you can use other UARTs for console and/or AT commands, or you can not use the console/AT commands at all.

[quote user=""]I would like to use the UARTs of the nRF9160 DK in the following way:[/quote]

This should be easily enough with a device tree overlay file. I recommend staying with UART_NRF9160_0 for communicating over a VCOM, as well as having UART_NRF9160_1 for modem tracing. Modem traces are really an invaluable tool for debugging network and connection issues.

The two UARTs for sensor communication can be UART_NRF9160_[2,3]. Just remember to disable I2C 2 and 3 and SPI 2 and 3.

All that, as well as choosing which pins are used can be done in a device tree overlay file. As for which pins to use, you should look at the DK schematics.

Best regards,

Didrik