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,

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.

[JuanAlm]

I will add this info about the flash error. With CONFIG_BOOTLOADER_MCUBOOT=n, the firmware builds and I can run a memory report:

With CONFIG_BOOTLOADER_MCUBOOT=y, the firmware doesn't build.

If I run "ninja partition_manager_report" I get the next info:

  flash_primary (0x100000 - 1024kB): 
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0xf2000 - 968kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0xf1e00 - 967kB)-+
| 0xc200: app (0xf1e00 - 967kB)                   |
+-------------------------------------------------+
| 0xfe000: settings_storage (0x2000 - 8kB)        |
+-------------------------------------------------+

  sram_primary (0x40000 - 256kB): 
+--------------------------------------------+
| 0x20000000: sram_primary (0x40000 - 256kB) |
+--------------------------------------------+

With CONFIG_BOOTLOADER_MCUBOOT=y and CONFIG_BOOT_SERIAL_CDC_ACM=n from mcuboot.conf, the firmware builds.The memory report is:

If I run "ninja partition_manager_report" I get the next info:

  flash_primary (0x100000 - 1024kB): 
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0xf2000 - 968kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0xf1e00 - 967kB)-+
| 0xc200: app (0xf1e00 - 967kB)                   |
+-------------------------------------------------+
| 0xfe000: settings_storage (0x2000 - 8kB)        |
+-------------------------------------------------+

  sram_primary (0x40000 - 256kB): 
+--------------------------------------------+
| 0x20000000: sram_primary (0x40000 - 256kB) |
+--------------------------------------------+

 

Adding to mcuboot.conf "CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x40000" as this thread suggest let the firmware building. I can use mcumgr when bootloader is active:

and I can upload a file:

mcumgr --conntype serial --connstring "/dev/ttyACM1,baud=115200" image upload app_update.bin
 168.48 KiB / 168.48 KiB [=================================================================] 100.00% 1.24 KiB/s 2m16s
Done

But once the upload is finished, I cant see the image:

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)

Anyway the firmware updates. Great! So my last problem is knowing how to reset the dongle with a RCP command.

[AHaug]

Hi,

JuanAlm said:

Please, don't forget about this:

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

Mcumgr reset allows you to reset with mcumgr https://docs.zephyrproject.org/3.1.0/services/device_mgmt/mcumgr.html#list-of-commands

https://github.com/apache/mynewt-mcumgr-cli

JuanAlm said:

Without MCUBoot, the app size this:

There definitely shouldn't be any flash overflow as previously suspected

JuanAlm said:

Anyway the firmware updates. Great! So my last problem is knowing how to reset the dongle with a RCP command.

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

Kind regards,
Andreas

[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)