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

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

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

Children
No Data
Related