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

  • Thanks Edvin - My math shows the FLASH should not take that long, but maybe so.  If I have some more time I will play with it.  I also am converting the ticket to public in case someone out there has been down this road.

  • FIXED! I fixed this today.  The problem was in the mcumgr go software where it was throttling comms in Tx function in serial_xport.go  found in go\pkg\mod\mynewt.apache.org\[email protected]\nmxact\nmserial\

    func (sx *SerialXport) Tx(bytes []byte) error {
    	/* ..... */
    			/* MJD TierOne speed up over USB ACM UART */
    			time.Sleep(/*20*/1 * time.Millisecond)
    			sx.txRaw([]byte{4, 20})
    		}
    
    		/* ensure that the total frame fits into 128 bytes.
    		 * base 64 is 3 ascii to 4 base 64 byte encoding.  so
    		 * the number below should be a multiple of 4.  Also,
    		 * we need to save room for the header (2 byte) and
    		 * carriage return (and possibly LF 2 bytes), */
    
    		/* all totaled, 124 bytes should work */
    		/* MJD TierOne speed up over USB ACM UART */
    		writeLen := util.Min(/*124*/1020, totlen-written)

    It was both doing a 20msec sleep for "slower platforms" with small buffers and restricting the real MTU to 128 bytes (even though the outer MTU was set to 4096. These are probably good for "real" UART and slower boards. With a USB virtual UART with Mbps speeds it is irrelevant.

    Once I rebuilt mcumgr it smoked. ~10 seconds instead of 1.5 minutes (or 6 before the other changes I showed in my first post). 

Related