sw opened a new issue #185: URL: https://github.com/apache/mynewt-newtmgr/issues/185
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 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 receiver rounds this down to 0x124. mcumgr CLI then tries to continue at offset 0x127, then offset 0x27b, until it realises 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 a wrong offset which is discarded. 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](https://github.com/apache/mynewt-newtmgr/files/6434672/log.txt) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
