Recognize the Failure Pattern
In the recorded MIMXRT1170-EVKB failure, the HTTPS transfer completed successfully: the downloaded byte count matched the expected size, and the MD5 values for downloaded and flashed data were identical. Those checks establish transport and flash-write integrity, but they do not prove that MCUboot can use the image.
The decisive fault was visible in image info: slot 0 at was <EMPTY>, while slot 1 at contained the OTA candidate. Both reported slot sizes were 2097152 bytes. Bootloader Version 1.10.0 initially booted the secondary image with flash remapping enabled. On the following boot, it reported Erasing faulty image in the secondary slot and Unable to find bootable image.
| Observation | Engineering conclusion |
|---|---|
| Downloaded and flashed MD5 values match | The HTTPS download and flash write completed consistently; continue with image preparation and slot-state checks. |
Primary slot reports <EMPTY>
|
The directly programmed base image is not recognized in slot 0. |
Candidate boots and state becomes Testing
|
MCUboot selected and executed the test image. |
| Another boot occurs before acceptance | The test image can be rejected; an empty primary slot leaves no recognized fallback image. |
Correct the Two Image-Preparation Paths
Do not prepare a directly programmed base image and an OTA-delivered candidate identically. The evidence identifies two distinct signing requirements:
| Image path | Required treatment | Placement |
|---|---|---|
| Initial client image programmed with a programmer | Add --pad --confirm when signing. The resulting trailer is required by the direct-XIP process. |
Program the complete signed image at , not . |
| Image downloaded through OTA | Sign without --pad. |
Allow the OTA client to write the candidate into its configured inactive slot. |
The original OTA command included --pad --confirm. Those options apply to the image directly programmed into flash, not to the OTA candidate. Conversely, omitting the trailer from the directly programmed base image can leave slot 0 unrecognized.
Understand the RT1170 Remap Behavior
The README expectation that the secondary image must move into the primary slot does not match the observed RT1170 direct-XIP implementation. The evidence attributes this discrepancy to flash remapping and states that the generated documentation was incorrect.
On the recorded configuration, MCUboot can execute either physical slot by changing the remap state. A primary-slot boot reports flash remapping disabled and a chainload offset of 0x40000. A secondary-slot boot reports remapping enabled and a chainload offset of 0x240000. Therefore, successful installation does not require the candidate bytes to be copied from secondary to primary.
After acceptance, the client deletes the header of the inactive image for direct-XIP downgrade handling. If the accepted image is running from slot 1, slot 0 can consequently appear empty while subsequent boots continue from slot 1. This is expected in the demonstrated remap workflow, not evidence that the accepted image failed to move.
Recover and Install the Candidate
- Sign the initial client image with
--pad --confirm, then program the complete signed file at . - Boot the client and run
image info. Stop if slot 0 remains<EMPTY>; correct image generation or programming placement before attempting OTA. - Build and sign the OTA candidate without
--pad, then download it through the OTA client. - Run
image infoagain. Confirm that the current image and the newer candidate are both recognized in their respective slots. - Run
image test 0, then reboot. The tested sequence isimage test 0→ reboot →image info→image accept 0. - Confirm that the candidate version is executing and that the state is
Testing. Use an application-specific print difference or version marker to distinguish the two builds. - Run
image accept 0before another reset. Acceptance makes the running image permanent and removes the inactive image header in the demonstrated direct-XIP flow.
Verify the Final State
Verify success from execution and state, not from an assumption that the image must occupy slot 0. Immediately after the test reboot, the application output must identify the candidate build and image info must report Testing. After image accept 0, it must report Permanent for the accepted running image.
A subsequent boot must select the same accepted version without reporting Erasing faulty image in the secondary slot, No slot to load for image 0, or Unable to find bootable image. An empty inactive slot after acceptance is consistent with the logged message Deleting header of inactive image.
FAQ
Why does MIMXRT1170 MCUboot erase the secondary OTA image?
In the failed sequence, slot 0 was empty and the secondary candidate was booted for testing but not accepted before another boot. Program a recognized base image at , then run image accept 0 after confirming the candidate is executing in the Testing state.
Should an MIMXRT1170 OTA image use imgtool --pad?
No for the demonstrated OTA path: sign the downloaded candidate without --pad. Use --pad --confirm for the signed base image that is programmed directly into flash.
Why does the accepted image remain in the secondary slot?
The demonstrated RT1170 direct-XIP flow uses flash remapping to boot either slot, so it does not need to copy the candidate into the primary slot. After acceptance, deleting the inactive image header is expected behavior in this workflow.
