Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

img_mgmt_erase is too strict, won't allow erasing pending secondary slot #157

Open
sw opened this issue Nov 18, 2021 · 0 comments
Open

img_mgmt_erase is too strict, won't allow erasing pending secondary slot #157

sw opened this issue Nov 18, 2021 · 0 comments

Comments

@sw
Copy link

sw commented Nov 18, 2021

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.

if (img_mgmt_slot_in_use(1)) {

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant