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.

[JuanAlm]

AHaug said:

The rcp specific command "ot-cli reset" should reset the device.

No, this just restarts the stack. I can reboot the RaspberryPi anyway and it's enought.

AHaug said:

Does this mean that the flash issue is solved? If so, great!

The building problem is resolved. I would like to know why it is resolved adding "CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x40000" and if it could provoke an error in the future.

I would like to know why the list command show this before and after I upload the update:

mcumgr --conntype serial --connstring "/dev/ttyACM1,baud=115200" image list
Images:
 image=0 slot=0
    version: 0.0.0.0
    bootable: false
    flags:
    hash: Unavailable
Split status: N/A (0)

[AHaug]

JuanAlm said:

No, this just restarts the stack. I can reboot the RaspberryPi anyway and it's enought.

We've tested this on the rcp after you've mentioned this, and you're right. It does reset other OT devices but it only restarts the stack for the RCP. Another option is to use ncp vendor commands, such as the one in user_vendor_hook.cpp (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.1/nrf/ug_thread_vendor_hooks.html#ug-thread-vendor-hooks). This does however demand that you create some custom functionality yourself within the POSIX application, and to implement a handler for it in user__vendor_hook.cpp that ensures that the device restarts.

JuanAlm said:

The building problem is resolved. I would like to know why it is resolved adding "CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x40000" and if it could provoke an error in the future.

It would seem that the mcuboot partition is too small (by ~11080 bytes) to handle the bootloader, so this config allows you to increase the size. However 0x40000 is quite large, so you might get away by increasing it with a smaller amount. I would recommend you to experiment with the size to see if you find something smaller. However, if your app is sufficiently small, there is nothing wrong with having this partition that large as long as you have enough space in the secondary slot to do DFU.

JuanAlm said:

I would like to know why the list command show this before and after I upload the update:

It shows this before the image, as illustrated by this sample that there should not be anything there before the upload. Do you see the same information after uploading but before resetting? 

Sample: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/serial_recovery/mcuboot_serial_recovery_cdc_acm_wait

Kind regards,
Andreas

[JuanAlm]

AHaug said:

It shows this before the image, as illustrated by this sample that there should not be anything there before the upload. Do you see the same information after uploading but before resetting? 

Yes. And I don't have to confirm image. I just upload and reset and the firmware is updated.

[AHaug]

Hi,

JuanAlm said:

Yes. And I don't have to confirm image. I just upload and reset and the firmware is updated.

I had to clarify this with a colleague before answering. The reason for why we only see this information is due to how serial recovery works.

1) You're only seeing one slot because the project only have one slot defined (primary)

2) The info you see when listing with mcumgr is due to serial recovery being sparse with the information it writes

3) With serial recovery you overwrite what is in the primary immediately and there are no swap process requiring you to flag the image with test or confirm. Upload and reset is the correct procedure

Kind regards,
Andreas

[JuanAlm]

Thanks for the info.

I have noticed about a problem with "CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT"... Each time I connect the dongle to my RaspberryPi the time needed to start the APP is totally different. I mean that the time the bootloader is running is totally aleatory. I have set CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT=60000 and the time in multiple tests has been 90 seconds, 165 seconds, 195 sec, etc...

My custom dongle has no external crystal.

[AHaug]

I agree that this does not sound right. The window where the device waits for a mcumgr command (i.e 60000ms in your case) should be identical if not closer in max/min value than a 135 second difference. 

Can you verify if the following, which is what should happen, is observable on your end?:

1. Application starts: Waiting for CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT amount of seconds for a mcumgr cmd to initiate DFU
2. mcumgr cmd sent and received: Initiating bootloader mode
3. You upload the image and it goes through and reset the device
4. Application starts (with new image): Waiting for CONFIG_BOOT_SERIAL_WAIT_FOR_DFU_TIMEOUT amount of seconds for a mcumgr cmd to initiate DFU

Or if step 1 and 4 (and every other time you boot up your application where the device should wait for the timeout) have the interval you're describing?

Kind regards,
Andreas