This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

MCUBOOT slow with nRF52840 / Zephyr / USB CDC_ACM protocol

I have MCUBOOT compiled under Zephyr 3.0 working fine with my 52840 based project.  The transport is the CDC ACM "UART" using CONFIG_MCUBOOT_SERIAL

Using mcumgr.exe to load the application from Windows, it was taking 4 1/2 minutes to load/program a 220K app.  That is less than 1KB/sec.  

I was able to do a significant speedup by changing the mtu. This involved changing the config line CONFIG_BOOT_MAX_LINE_INPUT_LEN=4096 and modifying the following in boot_serial.c

#define BOOT_SERIAL_INPUT_MAX   4096 // was 512

That allowed me to change the mtu on the mcumgr as the following

mcumgr --conntype serial --connstring dev=COM4,mtu=4096 image upload signed-app.bin

It is now 1 1/2 minutes, which is still only 2.7KB/sec.  Any ideas on what could be keeping it still so slow?   

Prj.cnf is below

CONFIG_DEBUG=n
CONFIG_PM=n

CONFIG_MAIN_STACK_SIZE=10240
CONFIG_MBEDTLS_CFG_FILE="mcuboot-mbedtls-cfg.h"

CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD=n
CONFIG_BOOT_SWAP_USING_SCRATCH=y
CONFIG_BOOT_ERASE_PROGRESSIVELY=y

CONFIG_BOOT_SWAP_SAVE_ENCTLV=n
CONFIG_BOOT_ENCRYPT_RSA=n
CONFIG_BOOT_ENCRYPT_EC256=n
CONFIG_BOOT_ENCRYPT_X25519=n

CONFIG_MCUBOOT_INDICATION_LED=y

### mbedTLS has its own heap
# CONFIG_HEAP_MEM_POOL_SIZE is not set

CONFIG_FLASH=y

CONFIG_LOG=n

# Serial
CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_NRFX=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_LINE_CTRL=y
CONFIG_UART_CONSOLE=y

# MCUBoot serial
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_BOOT_SERIAL_DETECT_PORT="GPIO_0"
CONFIG_BOOT_SERIAL_DETECT_PIN=12
CONFIG_BOOT_SERIAL_DETECT_PIN_VAL=0
CONFIG_BOOT_MAX_LINE_INPUT_LEN=4096

# Required by USB
CONFIG_MULTITHREADING=y

# USB
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="MCUBOOT"
CONFIG_USB_COMPOSITE_DEVICE=n
CONFIG_USB_MASS_STORAGE=n

  • Hello,

    sorry for the late reply.

    Is it possible for you to upload the zipped application folder that you have used to test this with? Or is it reproducible using the smp_svr sample from Zephyr?

    BR,

    Edvin

  • Not sure what the app has to do with it.  Unless I am missing something the app is just bytes while mcuboot is loading it over USB.  So its mcuboot that is slow, not the app so smp_svr not sure is relevant.  I do see much faster USB serial traffic from my app though (much faster than mcuboot is getting) 

  • You are using UART for your transfer, right? Not USB directly? Or do you use the USB peripheral on the nRF52840?

    MikeInAtlanta said:
    Not sure what the app has to do with it. 

    It is not necessarily relevant. It is just for ease of reproduction, and so that I will see the same as you do if I try the same. If you claim that it is going slower than it should, and I implement my own application then we risk that we don't see the same. Are you using serial recovery, or just normal DFU?

    Best regards,

    Edvin

  • I am using the virtual UART presented over the nrF's USB with the CDC_ACM protocol.  (CONFIG_BOOT_SERIAL_CDC_ACM) . The physical UART is not connected.  And yes using the serial recovery protocol. Looked to me that is what mcumgr supported.

  • I am sorry for the late reply. I wasn't able to build with your configurations, I am sorry. But I see that the mcumgr is pretty slow with UART as well, and changing the baudrate from the default 115200 to 1000000 doesn't affect it much. It is still around 1KBps, which seems to match your observation. 

    I agree that it isn't fast, but I am pretty sure that it is the flash operations (saving the new images to flash) that takes time here, and not the actual serial transport. Whether this delay is optimized or not, I am not sure, but since the DFU is in the background of running an application possibly doing Bluetooth or some network protocol, does it really matter that it isn't very fast? The application will still work as normal during this transfer. Please let me know what you think.

    Best regards,

    Edvin

Related