MCUBoot usb with openthread sample

[JuanAlm]

I have a custom board with a BMD345-A-R module and working with ncs v2.2.0. It has an USB port to comunicate with a RaspberryPi. The board works perfectly cause I have tried several examples:

- Serial MCUBoot -> I can manage firmware updates with mcumgr via USB.

-  openthread -> I configure the project RCP mode and I can connect with ot-ctl (from my RaspberryPi) to my custom board (RCP).

I have to add this "CONFIG_BOARD_ENABLE_DCDC=n" to my prj.conf and mcuboot.conf. Resuming, I have created an openthread project and added the code necessary to enable MCUBoot like the tutorial explain. 

My problem is openthread is working fine but I cant communicate with mcumgr. I try:

mcumgr --conntype serial --connstring "/dev/ttyACM0,baud=115200" echo hello

But has no response.

I have add the next configuration files to openthread project:

overlay-rcp.conf

overlay-usb-nrf-br.conf

usb.overlay

I tried adding "overlay-cdc.conf" too like SMP_Server indicate to build it, but it is the same result, Openthread works but mcumgr not.

I tried the SMP_Server sample with the next build command:

west build  -p  -b nrf52840dk_nrf52840    zephyr/samples/subsys/mgmt/mcumgr/smp_svr    --    -DOVERLAY_CONFIG='overlay-cdc.conf;custom_config.conf'    -DDTC_OVERLAY_FILE=usb.overlay

And it works too. Mcumgr communicates ok. custom_config.conf has "CONFIG_BOARD_ENABLE_DCDC=n" and I added it to the mcuboot.conf in child_image folder too.

I attach the project, maybe you can try it on a nrf52840DK board.0272.coprocessor_custom.zip

[AHaug]

Hi,

I removed the build folder in the sample you provided and rebuilt it with "west build -b nrf52840dk_nrf52840" , and ran the commands in the image below

This result can be seen both with "CONFIG_BOARD_ENABLE_DCDC=n" and with the config removed from config files. 

Its worth mentioning I have also disabled the Mass Storage feature on the Interface MCU with J-Link commander with the commands:

- MSDDisable
- SetHWFC Force
- exit

As seen here

Are you certain that you've not changed anything else or if you're using the com-port for something else? If you've connected the DK to for instance a RTT viewer, then the device is busy and you will not be able to use it to echo anything.

Kind regards,
Andreas

[JuanAlm]

Yes, but I need it working with USB port... J3 from nrf52840dk is the port I need working with openthread RCP and mcumgr.

I have tried several configurations with the next .conf to try it works over J3 usb connector:

overlay-usb-nrf-br.conf

usb.overlay

overlay-cdc.conf

But I cant get it working. 

Summarizing I have tested the example openthread coprocessor with the next build command:

west build -p -b nrf52840dk_nrf52840 -- -DDTC_OVERLAY_FILE=usb.overlay -DOVERLAY_CONFIG='overlay-usb-nrf-br.conf;overlay-cdc.conf;overlay-rcp.conf'

And it works over J3 usb connector. Now I want to add mcumgr, so I add what is explained here. Adding this to prj.conf:

# Enable mcumgr.
CONFIG_MCUMGR=y

# Enable most core commands.
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y

# Ensure an MCUboot-compatible binary is generated.
CONFIG_BOOTLOADER_MCUBOOT=y

# Enable the serial mcumgr transport.
CONFIG_MCUMGR_SMP_UART=y

# Disable UART Console and enable the RTT console
CONFIG_UART_CONSOLE=n
CONFIG_RTT_CONSOLE=y
CONFIG_USE_SEGGER_RTT=y

# Some command handlers require a large stack.
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

And this into the main:

#include "os_mgmt/os_mgmt.h"
#include "img_mgmt/img_mgmt.h"

os_mgmt_register_group();
img_mgmt_register_group();

But it doesnt work. Just works the openthread via J3 usb connector. 

So I thought that maybe I should add:

 -DOVERLAY_CONFIG=overlay-cdc.conf \
-DDTC_OVERLAY_FILE=usb.overlay

Cause SMP_Server sample is explained here. I have builded that example with the next build command:

west build \
   -b nrf52840dk_nrf52840 \
   samples/subsys/mgmt/mcumgr/smp_svr \
   -- \
   -DOVERLAY_CONFIG=overlay-cdc.conf \
   -DDTC_OVERLAY_FILE=usb.overlay

And I can use mcumgr via J3 usb connector. So I dont know how to mix openthread and mcumgr acces via J3 usb connector.

[AHaug]

Hi,

I have not yet been able to recreate your issue today as it's taken longer time than expected, so I will leave you with some answers to some of your questions before the weekend starts, and I'll get back to you as soon as possible on Monday.

JuanAlm said:

But with the "mcuboot_serial_recovery_cdc_acm_wait" I cant send an mcumgr command while bootloader is on.

This should be possible, and it leaves me suspecting the following:

1. As a sanity check: Could you verify that you're using the nRF USB on the long side of the nRF52840DK (you've mentioned that you're building for 52840dk earlier so I'm assuming you're developing on that DK as well)

JuanAlm said:

I have tried with the sample "mcuboot_serial_recovery_cdc_acm" and if I push the button when I switch on the board I enable mcumgr and I can send commands. But with the "mcuboot_serial_recovery_cdc_acm_wait" I cant send an mcumgr command while bootloader is on.

This should be possible, so I will add this to the investigation list as well. It could indicate that you're not using the nRF USB (which is why I'm asking the previous question), or it could indicate that the USB is being used by something else, such as the RCP.

JuanAlm said:

But I have error building. If I comment "CONFIG_BOOT_SERIAL_CDC_ACM" then it build correctly. The error I get building with "CONFIG_BOOT_SERIAL_CDC_ACM=y" is:

Line 480 in the error log says something about flash overflow. Can you see how large your application is (both with and without the bootloader(s))  

FAILED: zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map 
: && ccache /home/scada/ncs/toolchains/v2.2.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc  -gdwarf-4 zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj -o zephyr/zephyr_pre0.elf  -fuse-ld=bfd  -Wl,-T  zephyr/linker_zephyr_pre0.cmd  -Wl,-Map=/home/scada/Documents/coprocessor_bootloader/build/mcuboot/zephyr/zephyr_pre0.map  -Wl,--whole-archive  app/libapp.a  zephyr/libzephyr.a  zephyr/arch/common/libarch__common.a  zephyr/arch/arch/arm/core/aarch32/libarch__arm__core__aarch32.a  zephyr/arch/arch/arm/core/aarch32/cortex_m/libarch__arm__core__aarch32__cortex_m.a  zephyr/arch/arch/arm/core/aarch32/mpu/libarch__arm__core__aarch32__mpu.a  zephyr/lib/libc/minimal/liblib__libc__minimal.a  zephyr/soc/arm/common/cortex_m/libsoc__arm__common__cortex_m.a  zephyr/soc/arm/nordic_nrf/nrf52/libsoc__arm__nordic_nrf__nrf52.a  zephyr/drivers/usb/device/libdrivers__usb__device.a  zephyr/drivers/clock_control/libdrivers__clock_control.a  zephyr/drivers/gpio/libdrivers__gpio.a  zephyr/drivers/hwinfo/libdrivers__hwinfo.a  zephyr/drivers/flash/libdrivers__flash.a  zephyr/drivers/serial/libdrivers__serial.a  zephyr/drivers/timer/libdrivers__timer.a  zephyr/drivers/pinctrl/libdrivers__pinctrl.a  modules/nrf/lib/fprotect/lib..__nrf__lib__fprotect.a  modules/nrf/lib/fatal_error/lib..__nrf__lib__fatal_error.a  modules/nrf/drivers/hw_cc310/lib..__nrf__drivers__hw_cc310.a  modules/mcuboot/boot/bootutil/zephyr/libmcuboot_util.a  modules/hal_nordic/nrfx/libmodules__hal_nordic__nrfx.a  modules/segger/libmodules__segger.a  -Wl,--no-whole-archive  zephyr/kernel/libkernel.a  zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj  -L"/home/scada/ncs/toolchains/v2.2.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/thumb/v7e-m+fp/hard"  -L/home/scada/Documents/coprocessor_bootloader/build/mcuboot/zephyr  -lgcc  zephyr/arch/common/libisr_tables.a  -no-pie  -mcpu=cortex-m4  -mthumb  -mabi=aapcs  -mfpu=fpv4-sp-d16  -mfloat-abi=hard  -mfp16-format=ieee  -Wl,--gc-sections  -Wl,--build-id=none  -Wl,--sort-common=descending  -Wl,--sort-section=alignment  -Wl,-u,_OffsetAbsSyms  -Wl,-u,_ConfigAbsSyms  -nostdlib  -static  -Wl,-X  -Wl,-N  -Wl,--orphan-handling=warn  /home/scada/ncs/v2.2.0/nrfxlib/crypto/nrf_cc310_platform/lib/cortex-m4/hard-float/no-interrupts/libnrf_cc310_platform_0.9.16.a  /home/scada/ncs/v2.2.0/nrfxlib/crypto/nrf_cc310_bl/lib/cortex-m4/hard-float/no-interrupts/libnrf_cc310_bl_0.9.12.a && cd /home/scada/Documents/coprocessor_bootloader/build/mcuboot/zephyr && /home/scada/ncs/toolchains/v2.2.0/usr/local/lib/python3.8/site-packages/cmake/data/bin/cmake -E echo
/home/scada/ncs/toolchains/v2.2.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/zephyr_pre0.elf section `text' will not fit in region `FLASH'
/home/scada/ncs/toolchains/v2.2.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld.bfd: region `FLASH' overflowed by 10808 bytes

Kind regards,
Andreas

[JuanAlm]

AHaug said:

As a sanity check: Could you verify that you're using the nRF USB on the long side of the nRF52840DK (you've mentioned that you're building for 52840dk earlier so I'm assuming you're developing on that DK as well)

Yes, Im using J3 connector (nRF USB)

AHaug said:

This should be possible, so I will add this to the investigation list as well. It could indicate that you're not using the nRF USB (which is why I'm asking the previous question), or it could indicate that the USB is being used by something else, such as the RCP.

I don't think so because in the samples you shared me (https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/serial_recovery/mcuboot_serial_recovery_cdc_acm_wait) the main app is empty.

[JuanAlm]

Any progress?

[AHaug]

Hi,

Apologies for not checking back in with you yesterday. Yes, I have some progress for you. Initial debugging suggests that there is an issue with the BOOT_SERIAL_WAIT_FOR_DFU.

The issue we've uncovered is that CONFIG_BOOT_SERIAL_WAIT_FOR_DFU depends on BOOT_SERIAL_UART", which requires buttons to be set. From mcuboot/boot/zephyr/main.c: 

#ifdef CONFIG_MCUBOOT_SERIAL
    if (detect_pin() &&

The patch shown in the image should fix the issue and make the device actually wait for the mcumgr command.

 

I was currently working on testing this and trying to get it to work together with the RCP, but I should've told you yesterday so you could do some work parallelly to our testing.

The next thing you will have to do is to verify that you can see the nRF USB com when connecting the device

- Build and flash the sample -> Change the usb from the programming USB to the nRF USB -> Locate the device (COMxx or TTYACMx depending on which OS you're developing with) -> send mcumgr command to that device to enter serial recovery

You can modify CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT=5000 in child_image to buy you some more time before the timout occurs so you have some time to send the mcumgr command to trigger the serial recovery mode.

Let me know if you have any progress, and in the meanwhile I'll keep working on this as well

Kind regards,
Andreas

[JuanAlm]

Great! It works like a charm! Now I can send mcumgr commands!

Please, don't forget about this:

AHaug said:

You should be able to reset the dongle with RCP-specific commands in the software. From what I can see will have to find a command that calls sys_reboot(). I will have do some investigating to see if I can find a specific command.

And about this:

AHaug said:

Line 480 in the error log says something about flash overflow. Can you see how large your application is (both with and without the bootloader(s))  

Without MCUBoot, the app size this:

Memory region         Used Size  Region Size  %age Used
           FLASH:      171864 B         1 MB     16.39%
             RAM:       81056 B       256 KB     30.92%
        IDT_LIST:          0 GB         2 KB      0.00%

But If I include the MCUBoot, it does not build.