HCI and MCUMGR on the same UART

RE: HCI and MCUMGR on the same UART

Edvin — Tue, 12 Nov 2024 14:01:07 GMT

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

RE: HCI and MCUMGR on the same UART

tdfilip — Tue, 12 Nov 2024 07:49:46 GMT

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

RE: HCI and MCUMGR on the same UART

Edvin — Mon, 11 Nov 2024 10:13:56 GMT

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

BR,
Edvin

RE: HCI and MCUMGR on the same UART

tdfilip — Thu, 07 Nov 2024 14:33:05 GMT

Hello,

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

RE: HCI and MCUMGR on the same UART

Edvin — Thu, 07 Nov 2024 14:15:37 GMT

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

RE: HCI and MCUMGR on the same UART

tdfilip — Wed, 06 Nov 2024 12:37:27 GMT

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?

RE: HCI and MCUMGR on the same UART

Edvin — Wed, 06 Nov 2024 11:18:59 GMT

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