Need some help with CONFIG_UART_CONSOLE_MCUMGR

[David Ormand]

I'm doing a project for adding a Bluetooth capability to an embedded Linux device. The Linux master talks to the nRF52840-based Bluetooth module via a dedicated serial (UART) link. I've got a console feature on the BT module such that the Linux master can send commands and receive responses in plain old ASCII.

I'm at the point of trying to implement DFU, which in the Zephyr world means SMP and MCUMGR. Ultimately, I'm going to want SMP running in the application so that a file can be sent to the BT module (a Central) to perform BT DFU with a Peripheral device. For now, I'm starting with the SMP in MCUboot as described in the blog devzone.nordicsemi.com/.../device-firmware-update-dfu-with-mcuboot-bootloader. In this case, the serial port is the USB CDC ACM feature.

In my development and test activities, I'm using a nRF52840 DK.

I followed the instructions from "Add DFU support to your application" (devzone.nordicsemi.com/.../ncs-dfu). With the log messages coming through RTT, it works.

I had elsewhere seen mention of CONFIG_UART_CONSOLE_MCUMGR, and the guide article states, "Another option is to use the configs from smp_svr/overlay-serial-console.config to enable the UART console with mcumgr pass through". Well, the smp_svr example does indeed have an overlay_serial_console.conf file, although there's nothing in the instructions to explain how to use it or test the result. So I merge the contents of overlay_serial_console.conf into the prj.conf from the instructions. Here's the diff between the config files:
$ diff prj_serial_dfu.conf prj.conf
21a22
> CONFIG_UART_CONSOLE_MCUMGR=y
23a25,26
> CONFIG_CONSOLE_SUBSYS=y
> CONFIG_CONSOLE_GETLINE=y
26,28c29,31
< CONFIG_UART_CONSOLE=n
< CONFIG_RTT_CONSOLE=y
< CONFIG_USE_SEGGER_RTT=y
---
> CONFIG_UART_CONSOLE=y
> #CONFIG_RTT_CONSOLE=y
> #CONFIG_USE_SEGGER_RTT=y

And here's overlay_serial_console.conf:
# Enable USB subsystem
CONFIG_USB_DEVICE_STACK=y
CONFIG_SERIAL=y
CONFIG_UART_LINE_CTRL=y
CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=n
CONFIG_CONSOLE=y
# USB backend is serial device
CONFIG_MCUMGR_TRANSPORT_UART=y
CONFIG_BASE64=y
CONFIG_CRC=y

I can build and flash it, and the console part works, but mcumgr can't talk to it. I have to shut off the terminal for console I/O because the system won't share the COM port (and mcumgr complains "Error: Access is denied". After I kill the terminal and try again, mcumgr waits several seconds and then complains "Error: NMP timeout". I conclude that the SMP server isn't really listening through the console port, and there's something more to using CONFIG_UART_CONSOLE_MCUMGR.

[Kenneth]

Hello,

The blog post you are looking at is very old, please check out:
https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/ 

You can also find various examples here:
https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples 

Kenneth

[David Ormand]

Thank you.  The DevAcademy articles (coursework) is very good.  But it is also somewhat general; the use of CONFIG_UART_CONSOLE_MCUMGR is a special case of DFU over UART.  I wouldn't expect a DevAcademy session to treat this, and I'm not finding any that do.

I had already been directed to Hellesvik's samples, and they too are good and he has some enlightened perspectives on bootloaders and DFU that supplement the "official" literature on the Nordic site.  However, CONFIG_UART_CONSOLE_MCUMGR is for using SMP running in an application, and none of these samples address its use.

[David Ormand]

Alternatively, is there a way to provide a different transport for SMP?  I gather that SMP over UART installs its own UART handlers before main().  Somehow, CONFIG_UART_CONSOLE_MCUMGR directs UART data to the SMP serial transport.  I'd like to do the same thing with a Raw UART driver.

I suppose I should look at https://docs.zephyrproject.org/latest/services/device_mgmt/smp_transport.html and figure how to do this.

[Kenneth]

Hello,

I have been trying to look into this a few times, but haven't really gotten around to it, and the short answer is that I don't know. I would have looked at the shell instead, you can monitor shell commands by registering a callback function SHELL_CMD_REGISTER(), and you can then re-route shell commands to other modules by intercepting them in your callback handler and forwarding them to the appropriate modules instead.

Kenneth

[David Ormand]

Thank you.  If I had discovered "shell" earlier, and the potential for doing _everything_ through SMP, I wouldn't have wasted time trying to run Console/Raw UART and SMP cooperatively.  "shell" is a _much_ cleaner approach.