MCUBoot usb with openthread sample

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

Parents
  • 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

  • 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.

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

    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.

  • 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

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

    Please, don't forget about this:

    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:

    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.

  • 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.

Reply
  • 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.

Children
  • 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

  • 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.

    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)

  • 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

  • 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.

  • 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

Related