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.

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

Children
  • Hi,

    JuanAlm said:

    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. 

    The USB CDC_ACM version of the smp server sample should work, but I had a look at the requirement of using both the OpenThread RCP and mcumgr over serial usb simultaneously and the reason for why the echo command gives no response is because the RCP uses the serial communication making it unavailable for mcumgr. In other words a similar reason as I mentioned in my previous answer where the the communication medium is busy.

    I discussed this with a colleague of mine and they recommend to use serial recovery instead.

    Kind regards,
    Andreas

  • Yes, I discovered that if I modify the nrf52840dk_nrf52840.overlay with this:

    / {
    	chosen {
    		zephyr,uart-mcumgr = &cdc_acm_uart0;
    	};
    };
    
    zephyr_udc0: &usbd {
    	compatible = "nordic,nrf-usbd";
    	status = "okay";
    };
    
    &zephyr_udc0 {
    	cdc_acm_uart0: cdc_acm_uart0 {
    		compatible = "zephyr,cdc-acm-uart";
    	};
    };

    I can enable mcumgr to work via J3 usb connector. I tried it with blinky sample and it works. So I tried to apply this to openthread sample but I get an error building. I can imagine that it is because openthread and mcumgr are trying to use the same uart0.

    So my question is:

    1º) Can I set uart0 for openthread and uart1 for mcumgr, both working via USB at the same time?

    2º) How should I modify nrf52840dk_nrf52840.overlay for it?

    I need that mcumgr works buttonless, so I think that serial recovery is not an option.

  • Hi,

    JuanAlm said:
    Yes, I discovered that if I modify the nrf52840dk_nrf52840.overlay with this:

    I saw your solution to your other case from yesterday, so I'm glad you got that to work!

    On another note, I see you've created another case asking the same question as q1 here. Could you elaborate a bit about why you create so many cases with very similar topics? It is usually a good policy to keep the cases to "one topic per case", but the cases you've created the past week seems all to be on the same topic. In this case you should strongly consider to keep your questions within the same case to make it easier to follow your development.

    Which brings me to my first question. As I haven't followed your cases due to the number of cases created on your project, what are your goal other than "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"? Are you creating your own RCP device/dongle that you want to use to initiate firmware updates to other devices in your Openthread network? Are you trying to add DFU support to your Openthread devices? 

    JuanAlm said:
    1º) Can I set uart0 for openthread and uart1 for mcumgr, both working via USB at the same time?

    Two distinct UARTs can be used, but I don't think there are enough pins to the USB connector to have both working through the USB simultaneously. But nonetheless, you should be able to swap which UART you're using based on which mode your device are in. MCUboot/firmware updates are not running at the same time as the application firmware is running, so if you find a way to pause the RCP when you want to initiate firmware update you should get closer to (what I believe is) your goal.

    JuanAlm said:
    I need that mcumgr works buttonless, so I think that serial recovery is not an option.

    Serial recovery does have a wait functionality, so you could implement a buttonless app with serial recovery. This sample should illustrate how to do this: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/serial_recovery/mcuboot_serial_recovery_cdc_acm_wait

    Let me know if this is also outside the scope of your application, so I can see if I find some other options for you.

    Kind regards,
    Andreas

  • On another note, I see you've created another case asking the same question as q1 here

    Sorry, I thought that would be worth for the community to have a ticket with a clean description about the problem and the solution. No more unnecessary tickets, sorry again!

    Are you creating your own RCP device/dongle that you want to use to initiate firmware updates to other devices in your Openthread network? Are you trying to add DFU support to your Openthread devices? 

    I'm creating my own RCP dongle that I want to use for openthread communications. On the other hand, I want to enable the possibility to update the dongle via USB. The only port that has this custom dongle is an USB port, so openthread (the openthread demon "ot-ctl" running in a RaspberryPi connected to my dongle via the USB port) has to share the USB connector with mcumgr.

    Two distinct UARTs can be used, but I don't think there are enough pins to the USB connector to have both working through the USB simultaneously. But nonetheless, you should be able to swap which UART you're using based on which mode your device are in. MCUboot/firmware updates are not running at the same time as the application firmware is running, so if you find a way to pause the RCP when you want to initiate firmware update you should get closer to (what I believe is) your goal.

    So the point would be set the same UART for openthread and mcumgr and enable 1 service when I disable the other one? Is it possible set the same uart for both services in the .dts file? Or you tell me that I should enable 2 UARTs (one for each service) and enable/disable the UARTs? Or maybe what you are trying to tell me is not using mcumgr and reset the dongle, entering in bootloader mode?

    Serial recovery does have a wait functionality, so you could implement a buttonless app with serial recovery. This sample should illustrate how to do this: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/serial_recovery/mcuboot_serial_recovery_cdc_acm_wait

    This might works but I can't imagine a way to reset the dongle butonless... It's powered by USB, is there a function from zephyr to restart the USB (switch off the current and switch on)?

  • JuanAlm said:
    Sorry, I thought that would be worth for the community to have a ticket with a clean description about the problem and the solution. No more unnecessary tickets, sorry again!

    I agree to the sentiment about having tickets with clean descriptions about the problem and solution, so no need to apologize, but a balance between creating new cases and continuing in one case is desired! Thank you for both thinking of the community and taking this into consideration.

    JuanAlm said:
    I'm creating my own RCP dongle that I want to use for openthread communications. On the other hand, I want to enable the possibility to update the dongle via USB. The only port that has this custom dongle is an USB port, so openthread (the openthread demon "ot-ctl" running in a RaspberryPi connected to my dongle via the USB port) has to share the USB connector with mcumgr.

    Thank you for filling in the details

    JuanAlm said:
    So the point would be set the same UART for openthread and mcumgr and enable 1 service when I disable the other one? Is it possible set the same uart for both services in the .dts file? Or you tell me that I should enable 2 UARTs (one for each service) and enable/disable the UARTs? Or maybe what you are trying to tell me is not using mcumgr and reset the dongle, entering in bootloader mode?

    I see I was a bit unclear in my previous reply. I will try to expand on this in the coming section.

    JuanAlm said:
    Or you tell me that I should enable 2 UARTs (one for each service) and enable/disable the UARTs?

    If you intend to not use serial recovery, you will have to use 2 UARTs, one for each service. As far as I understand the issue is that you can't use two UARTs over one J3 USB (correct me if you believe I am wrong) due to pin limitations. This leads to you having to implement some kind of logic that chooses which UART that should be allowed to use the J3 at a given time, alternatively you run one through J2 and the interface MCU.

    JuanAlm said:
    This might works but I can't imagine a way to reset the dongle butonless... 

    I discussed this with a colleague and this is how they imagine the sequence to look

    You have two devices, the host + dongle where we start with the dongle in RCP mode

    Dongle: RCP Mode

    Host: sends reset command over RCP protocol

    Dongle: Resets

    Dongle: Enter wait Wait for Serial Recovery mode, 5 sec

    Host: Change to DFU Mode

    Host: Send mcumgr command

    Dongle: See mcumgr command -> Change to Serial recovery

    Host: Send update to dongle using mcumgr

    Dongle: Receive update

    Host: Send reset command to dongle over mcumgr

    Dongle: Reset into new firmware

    Dongle: Wait for Serial Recovery mode, 5 sec

    Dongle: No command received, enter RCP mode

    Dongle: RCP mode

    Host: Change to RCP mode

    Let me know if this clarifies anything and feel free to ask more questions if anything is unclear

    Kind regards,
    Andreas

Related