We are using Nordic's fork of mcumgr (https://github.com/nrfconnect/sdk-mcumgr) but I believe this also affects upstream https://github.com/apache/mynewt-mcumgr.
The Zephyr port rounds the write size down to the flash write block size:
https://github.com/apache/mynewt-mcumgr/blob/798f7fe28bb32335ba25d1c180808cd88d73a83c/cmd/img_mgmt/port/zephyr/src/zephyr_img_mgmt.c#L571-L576
This smaller size is then reported back in the response. However, the mcumgr CLI takes some time to detect this mismatch, and keeps sending frames with incorrect offsets.
This leads to a large overhead of data transmitted on the serial port.
This happens with the first frame, which is sent with 0x127 bytes of data; the receiving MCU rounds this down to 0x124. mcumgr CLI then tries to continue at offset 0x127, then offset 0x27b, until it realizes something is wrong and restarts at 0x124.
The next 64kbyte then go through without a hitch (no offset problems).
At the 64k block border though, the problem re-occurs, and from then on every fragment is essentially sent 4 times: 3 times with wrong offsets which are discarded. A firmware upgrade thus takes approximately 4 times longer than would be necessary!
The image handling in newtmgr should be improved:
- to detect a wrong offset sooner, rather than sending up to 3 frames with wrong offset
- to only send a multiple of a common flash block size, for example a multiple of 4 bytes.
Attached is a log file from mcumgr image upload file.bin -l debug:
log.txt
We are using Nordic's fork of mcumgr (https://github.com/nrfconnect/sdk-mcumgr) but I believe this also affects upstream https://github.com/apache/mynewt-mcumgr.
The Zephyr port rounds the write size down to the flash write block size:
https://github.com/apache/mynewt-mcumgr/blob/798f7fe28bb32335ba25d1c180808cd88d73a83c/cmd/img_mgmt/port/zephyr/src/zephyr_img_mgmt.c#L571-L576
This smaller size is then reported back in the response. However, the mcumgr CLI takes some time to detect this mismatch, and keeps sending frames with incorrect offsets.
This leads to a large overhead of data transmitted on the serial port.
This happens with the first frame, which is sent with 0x127 bytes of data; the receiving MCU rounds this down to 0x124. mcumgr CLI then tries to continue at offset 0x127, then offset 0x27b, until it realizes something is wrong and restarts at 0x124.
The next 64kbyte then go through without a hitch (no offset problems).
At the 64k block border though, the problem re-occurs, and from then on every fragment is essentially sent 4 times: 3 times with wrong offsets which are discarded. A firmware upgrade thus takes approximately 4 times longer than would be necessary!
The image handling in newtmgr should be improved:
Attached is a log file from
mcumgr image upload file.bin -l debug:log.txt