HCI and MCUMGR on the same UART

[tdfilip]

Hello,

My board contains nRF9160 and nRF52840. The nRF52840 is a HCI controller (based on HCI lpuart example). nRF9160 communicates with nRF52840 over UART. I want to perform firmware update for nRF52840 with MCUMGR over the same pins that are used for HCI communication. What would you suggest to achieve that?

Is it possible to use one UART for both HCI and MCUMGR (not in the same time)? Can I use e.g. uart2 to communicate with nRF52840 over HCI so I can use bluetooth and then, if I want to perform DFU for the HCI controller, use also uart2 but now to communicate to nRF52840's mcuboot over MCUMGR?

Setup:
Custom board with nRF9160 and nRF52840
NCS v2.6.1

Best regards,
Filip

[Edvin]

Hello Filip,

I remember that there was a lot more information on what you already did in this ticket. Unfortunately, I can only see that you edited the ticket 9 times, but I can't see the information about what you took away.

But if I understand you correctly, you want to change the GPIOs used by the UART, and you had some devicetree overlay files, right? That is at least the correct approach, to set up several pinctrl combinations, like uart0_default and uart0_sleep, similar to what I think you initially posted in this ticket.

As for using the same UART instance for HCI and DFU, that is possible. But you need to tell the nRF52840 when to enter DFU mode somehow. One way to do this is to write a custom HCI command, and when the nRF52840 receives this, it knows that it should enter DFU mode (serial recovery mode). Another way is to use an additional pin that it can use to trigger DFU mode. This doesn't require a custom HCI command and handler, but it requires an additional GPIO.

Best regards,

Edvin

[tdfilip]

Could you tell me how to configure the uart so it can be used by both bt-uart and uart_mcumgr?

I try to configure it like that:

chosen {
	zephyr,bt-uart=&lpuart;
	zephyr,uart_mcumgr = &uart2;
};
	
&pinctrl {
    uart2_default_alt: uart2_default_alt {
    	group1 {
    		psels = <NRF_PSEL(UART_TX, 0, 18)>,
    				<NRF_PSEL(UART_RX, 0, 17)>;
    	};
    };
    
    uart2_sleep_alt: uart2_sleep_alt {
    	group1 {
    		psels = <NRF_PSEL(UART_TX, 0, 18)>,
    				<NRF_PSEL(UART_RX, 0, 17)>;
    		low-power-enable;
    	};
    };
};

&uart2 {
	current-speed = <250000>;
	status = "okay";
	/delete-property/ hw-flow-control;

	pinctrl-0 = <&uart2_default_alt>;
	pinctrl-1 = <&uart2_sleep_alt>;
	pinctrl-names = "default", "sleep";
	lpuart: nrf-sw-lpuart {
		compatible = "nordic,nrf-sw-lpuart";
		status = "okay";
		req-pin = <20>;
		rdy-pin = <21>;
	};
};

That results in a secure fault right after the application start.

EDIT

I changed
zephyr,uart_mcumgr = &uart2;
to
zephyr,uart_mcumgr = &lpuart;

The application starts and bluetooth works. I then put HCI controller to mcuboot using another pin and I try to communicate over mcumgr but it doesn't work. I keep receiving:

<wrn> lpuart: req pin low when expected high
<err> lpuart: Empty receiver state:4
<wrn> lpuart: Tx timeout

Do I have to manually make the HCI stop using lpuart and mcumgr start using it?

[Edvin]

Hello,

This sounds like the mcumgr doesn't really use the lpuart, but a normal UART. The difference between the two has to do with the flow control pins, and how they work. 

If you look at the hci lpuart sample found in: ncs\nrf\samples\bluetooth\hci_lpuart, you can see that this is mostly an empty project, with just some configuration files, and a CMakeLists.txt file pointing to the ncs\zephyr\samples\bluetooth\hci_uart

So this is where the hci_uart sample get's it's lpuart settings from.

For your case, the child image, mcuboot, is unaware that it should use lpuart instead of normal uart. To tell it, try creating a folder (if you don't already have it) called child_image, and in there, create a file called mcuboot.overlay, where you can enter the devicetree information that the bootloader needs to know about. Pretty much like it is done here, except that here it tells the mcuboot that it has external flash available.

https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/blob/main/bootloader_samples/nrf5340/mcuboot_smp_ble_simultaneous/child_image/mcuboot.overlay

What you need to add into this file is to change the default zephyr,uart-mcumgr instance from &uart0 to &lpuart. I think it is done by adding:

/ {
	chosen {
		zephyr,uart-mcumgr = &lpuart;
	};

in your child_image/mcuboot.overlay file.

Best regards,

Edvin

[tdfilip]

Hello,

Is it possible to enable lpuart in mcuboot without enabling CONFIG_MULTITHREADING?

[Edvin]

Does it build without it? If not, what does the build log say?

BR,
Edvin

[tdfilip]

It doesn't build because uart_nrf_sw_lpuart.c uses function k_msleep in api_poll_out.

[Edvin]

Ok, and any reason why you don't want to use multithreading?

If you send me the application, I can poke around, but it is a lot faster if I have a starting point, rather than having to set it all up myself. 

Best regards,

Edvin