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]

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