LPUART nRF9160 - nRF52840

[Michal Mühlpachr]

Related to https://devzone.nordicsemi.com/f/nordic-q-a/76545/lpuart-nrf9160---nrf52840 (I can not add reply there).

With ncs v1.6.0 every second AT transaction fails.

We appreciate the addition of the native support for LPUART in SLM (without need to modify sources - just using prj.conf option). We discuss it with a sales representative/support also.

We believe bringing LPUART to the SLM application requires a more extensive understanding of lower-level mechanisms rather than just enabling some Kconfig options, some source patches for binding and recompilation and we think in the future, it could be really important for other customers also.

Why? Let's say the customer wants to use NB-IoT eDRX feature and receive notification from the modem when the datagram from network is available. At the same time, you don't want to keep UARTs on both MCUs running (mainly because high speed clock power consumption), and Nordic's LPUART is a perfect solution for such a situation.

Thank you.

[Albrecht Markus Schellenberger]

Hello Michal,

Michal Mühlpachr said:

LPUART is not supported in SLM in NCS v1.6.0 unfortunately.

I haven’t tried this myself with the Serial LTE modem application, but I’m not quite sure if this actually is the case. The Low Power UART is a module that should be possible to configure individually.

As the Low Power UART example shows, the module itself has to be added to a UART peripheral using an overlay file. 

Michal Mühlpachr said:

We made some SLM code  tweaks (e.g. uart_dev = device_get_binding("LPUART") in slm_at_host.c).

When connection the nRF9160 with an external MCU, the UART2 is designated to be used. Hence, the Low Power UART module has to be added to UART2 in the overlay file.

lpuart: nrf-sw-lpuart {
compatible = "nordic,nrf-sw-lpuart";
status = "okay";
label = "LPUART";
req-pin = <xy>;
rdy-pin = <xy>;
};

This is not done be default in the Serial LTE modem application, hence device binding will fail.

Regarding the configuration option CONFIG_SLM_CONNECT_LPUART, mentioned in this ticket: This is nothing I’m aware of, neither can I find it in the application configuration description.

Regards,

Markus

[Michal Mühlpachr]

Yes, we have added LPUART configuration in .dts, we use our board definitions for both nRF9160 and nRF52840 (no overlay needed). Related nRF9160 part:

&gpiote {
	status = "okay";
	interrupts = <49 NRF_DEFAULT_IRQ_PRIORITY>;
};

&gpio0 {
	status = "okay";
};

&uart0 {
	compatible = "nordic,nrf-uarte";
	current-speed = <115200>;
	status = "okay";
	tx-pin = <21>;
	rx-pin = <22>;
	/delete-property/ hw-flow-control;
	/delete-property/ rts-pin;
	/delete-property/ cts-pin;
	lpuart: nrf-sw-lpuart {
		compatible = "nordic,nrf-sw-lpuart";
		status = "okay";
		label = "LPUART";
		req-pin = <23>;
		rdy-pin = <24>;
	};
};

nRF9160 is interconnected with nRF52840 by 4 wires and nRF52840 uses similar .dts for LPUART and device_get_binding("LPUART"). Both nRF9160 and nRF52840 are on our custom HW. Our custom HW has different pin wiring than nRF9160 DK, so we can use UART0.

CONFIG_SLM_CONNECT_LPUART config option is also our patch, you do not need to pay attention to that.

Core issue is, that 4wire LPUART is not stable, 2wire UART works fine with same code, only related LPUART .dts and device_get_binding("LPUART") have changed.

Both nRF9160 and nRF52840 firmware projects are based on released NCS v1.6.0.