Currently, the simulator is used to ensure an interruption of an upgrade or revert process occurring between any flash_area_write or flash_area_erase operation would properly be handled by MCUboot. There is no test checking the behavior of MCUboot in case the interruption occurs in the middle of such an operation.

However, flash_area_write and flash_area_erase operations are not guaranteed to be atomic and a power failure happening in the middle of a such an operation might therefore lead to a state where the data has been partially written or erased. Write operations are made word by word, the size of the word depending on the hardware capabilities and the flash driver implementation. Erase operations are made sector by sector, the size of the sectors depends on the hardware and is not necessarily equal to the sector size used by MCUboot. Any write operation longer than a word and any erase operation performed on multiple sectors is not atomic.

Therefore, the current tests would not reveal issues related to power failures happening in the middle of a write or erase operation, which is the reason why #1966 passed unnoticed until recently.

Simulating an interruption between every word writing would be extremely time consuming. Doing it randomly could work but lead to a non-deterministic test. However, it should be noted that, in practice, a power failure occurring in the middle of a write or erase operation is not likely to cause any issue unless the operation is modifying data that is read by MCUboot at boot and interpreted to determine where the upgrade or revert process has to be resumed. Therefore, it should not be necessary to simulate interruptions in the middle of operations that are not altering a trailer. This could be extended to the image header and TLV areas if considered useful.