How to enable MCUboot serial log with USB DFU setup?

[Saxman58]

I have our app on the nRF7002-DK board running with MCUboot configured for USB firmware updates.  That is working fine, but is there some way to enable the console output from the bootloader so I could see more of what is happening during boot and updates?

We are using NCS v2.6.2.

Lesson 9 (formerly 8), Exercise 2 of the nRF Connect SDK describes enabling the nRF5340's USB port for the MCUboot controlled updates, but it doesn't mention the logging console, and tells you to disconnect the USB from the programming port and moving it to the nRF5340's USB connector.  I understand doing that in the exercise to make sure you are talking to the right USB port.  But for development I would like:

• to be able to leave two USB cables attached to quickly switch from programming/debugging through the programming interface, to using the target MCU's USB port for firmware update testing and later for USB communication testing on the app as well
• to have both the bootloader and apps console output come out through the VCOM1 (app core for the dual core nRF5340) serial console port

The app console is working (though the USB port hasn't been enabled yet for the app), but nothing comes back from the bootloader on either VCOM0 or VCOM1.

Here is the mcuboot.conf file:

# Enable logging from within MCUboot (uses about 1K, but nothing comes out)
CONFIG_LOG=y
CONFIG_MCUBOOT_LOG_LEVEL_INF=y

# Support DFU over USB serial, but not UART
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_UART=n
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_UART_CONSOLE=n
# Allow the bootloader to enter serial recovery mode if application
# triggers the firmware update through the retention system and then reboots.
CONFIG_RETENTION=y
CONFIG_RETAINED_MEM=y
CONFIG_RETAINED_MEM_ZEPHYR_RAM=y
CONFIG_RETENTION_BOOT_MODE=y
CONFIG_BOOT_SERIAL_BOOT_MODE=y

CONFIG_SINGLE_APPLICATION_SLOT=y

CONFIG_MCUBOOT_INDICATION_LED=y

CONFIG_PM_PARTITION_SIZE_MCUBOOT=0xF000

# No serial flash chip on either QSPI or SPI in our app
CONFIG_NORDIC_QSPI_NOR=n
CONFIG_SPI_NOR=n

CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y

I tried changing CONFIG_UART_CONSOLE to 'y' but then the build process complains about a missing device.  I'm guessing I need to add a 'chosen' or more to the overlay file.  Here is the mcuboot.overlay:

// Configure button and LED for Serial Recovery
/ {
    aliases {
        mcuboot-button0 = &button1;
        mcuboot-led0 = &led1;
    };
};

// Set aside a byte of RAM for MCU to use to flag MCUboot to enter DFU mode
/ {
    sram@2007FFFF {
        compatible = "zephyr,memory-region", "mmio-sram";
        reg = <0x2007FFFF 0x1>;
        zephyr,memory-region = "RetainedMem";
        status = "okay";

        retainedmem {
            compatible = "zephyr,retained-ram";
            status = "okay";
            #address-cells = <1>;
            #size-cells = <1>;

            retention0: retention@0 {
                compatible = "zephyr,retention";
                status = "okay";
                reg = <0x0 0x1>;
            };
        };
    };

    chosen {
        zephyr,boot-mode = &retention0;
    };
};

// Reduce 512 KB SRAM usage by 1 byte to account for non-init area
&sram0 {
    reg = <0x20000000 0x7FFFF>;
};

When I set CONFIG_UART_CONSOLE to 'y' and added `zephyr,console = &uart0;` to the chosen section in the mcuboot.overlay file, I get the following error:

Zephyr UART console must be disabled if CDC ACM is enabled and MCUmgr has not been redirected to other UART with DTS chosen zephyr,uart-mcumgr

This confuses me because I would think the mcumgr interface needs to stay on the USB to support firmware updates through USB.

I also tried hooking up a serial terminal program to the USB virtual serial port and see it connecting and disconnecting, but no bootloader log strings come out.  And then it ties up the USB serial port so I can't run the `mcumgr` to upload a firmware update file.

Is there some way to get the MCUboot logs to come out through the nRF7002-DK's programming interface (like the application logs do) while the local target MCU's USB is used for firmware updates?

[Sigurd Hellesvik]

Hi,

See here: https://github.com/nrfconnect/sdk-mcuboot/blob/3c2f2ff12bc20625cd65730b6036d061de4da5f7/boot/zephyr/Kconfig.serial_recovery#L32-L36.

Looks like you should be able to use chosen "zephyr,uart-mcumgr" for SMP and "zephyr,console" for logs as is done for the application also.

Regards,
Sigurd Hellesvik

[Saxman58]

Thanks once again, Sigurd.  I had tried the chosen settings before to set just the console to the UART, assuming the mcumgr would stay on the USB, but then get compiler errors.  I finally got it to work by being explicit about where to connect each of them with this in the mcuboot.overlay file:

/ {
    chosen {
        zephyr,uart-mcumgr = &usbd;
        zephyr,console = &uart0;
    };
};

...and this in the mcuboot.conf file:

# Support DFU over USB serial, but not UART.  UART used for logs (console).
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_UART=n
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_UART_CONSOLE=y

Thus both files were more explicit about wanting the logs on the UART and the mcumgr/DFU on the USB port.  Now I can see both the bootloader and app logs in the terminal.

[narangmayank]

Hi Saxman58 Sigurd Hellesvik 

I have a similar use case with a little twaek, We have only nRF USB interface in our custom hardware. I have managed to do DFU via the same USB. Now as a next step I want to emulate 2 CDC ACM instance of the same in the mcuboot so 1 will be used for DFU and other will be used for mcuboot logs.

I tried below conf but it didn't worked out,

mcuboot conf

CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_UART=n
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_UART_CONSOLE=y

mcuboot overlay

/ {
	chosen {
		zephyr,console = &cdc_acm_uart0;
		zephyr,uart-mcumgr = &cdc_acm_uart1;
	};
};

&zephyr_udc0 {
	cdc_acm_uart0: cdc_acm_uart0 {
		compatible = "zephyr,cdc-acm-uart";
		label = "CDC_ACM_0";
	};

	cdc_acm_uart1: cdc_acm_uart1 {
		compatible = "zephyr,cdc-acm-uart";
		label = "CDC_ACM_1";
	};
};

Any idea how to do this?

Thanks for any help.