We are using the Nordic forks of mcumgr, mcuboot and Zephyr and ran into a problem where a device could no longer be updated via mcumgr.
There were several compounding issues and one is in img_mgmt_erase.
The initial problem however was that we are doing SWAP_USING_MOVE, and accidentally uploaded and marked for test an image that was too large, i.e. occupying all the sectors with no room for the move.
mcuboot would then refuse to swap the images ("Not enough free space to run swap upgrade"), leaving the secondary slot pending.
Back to mcumgr: img_mgmt_erase checks this pending flag and refuses to erase the secondary slot. We are now stuck with a device that can only be recovered using a debugger.
We are using the Nordic forks of mcumgr, mcuboot and Zephyr and ran into a problem where a device could no longer be updated via mcumgr.
There were several compounding issues and one is in img_mgmt_erase.
The initial problem however was that we are doing SWAP_USING_MOVE, and accidentally uploaded and marked for test an image that was too large, i.e. occupying all the sectors with no room for the move.
This was already reported to Nordic here: https://devzone.nordicsemi.com/f/nordic-q-a/78984/big-primary-image-prevents-fota
mcuboot would then refuse to swap the images ("Not enough free space to run swap upgrade"), leaving the secondary slot pending.
Back to mcumgr: img_mgmt_erase checks this pending flag and refuses to erase the secondary slot. We are now stuck with a device that can only be recovered using a debugger.
https://github.com/apache/mynewt-mcumgr/blob/2a63188477835d1c816d06788bf29c62973956eb/cmd/img_mgmt/src/img_mgmt.c#L309
Could this check be relaxed to allow erasing a pending image?
Alternatively, is there a way to clear the pending flag? I would think not since the flash can only be written 1 -> 0 but not the other way.
A third possibility would be for the "upload" or "test" commands to refuse an image that is too big.