-
Notifications
You must be signed in to change notification settings - Fork 699
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Requirements for writing to slot-1? #488
Comments
You should never touch scratch yourself. What was your |
I did not add padding, so that's probably the issue - what format should the padding be? |
You only need to pad the image that goes into slot-1. |
Btw, those messages look totally fine, it does not show any info about slot-1's image if it is not set for an upgrade operation. |
But it SHOULD be set for an upgrade after I flash an image to slot-1. "Padding" means appending zeros to the binary so that it is of size SLOT_SIZE, yes? |
Oh now I noticed, you just add |
I'm trying to get mcuboot to work outside the context of ready-made samples, because we need to implement our own transport method for delivering FOTA images to slot-1. Tried inspecting the code for mcumgr to see if there's anything special that needs to be done in order to flash a signed image to slot-1 and have mcuboot verify and swap to it at next boot.
From what I could tell, signing and writing the new image to SLOT_1_OFFSET should be sufficient for mcuboot to autodetect it? That doesn't work for me for some reason. Do I have to write something to scratch as well?
Running Zephyr v1.14, mcuboot master on an nRF52840, slot offsets: 0xC000/0x73000, slot size 0x67000. I'm using openocd to flash all slots:
mcuboot works fine, slot-0 works fine, but mcuboot never detects that anything is present in the secondary slot it seems. Console output from mcuboot:
Any ideas? Is it weird that it only reports status for scratch and nothing for "Secondary image"?
The text was updated successfully, but these errors were encountered: