Fix bootloader's OTA partition selection after some OTA flashing

[yanbe]

Problem

With default two OTA partitions, according to the algorithm of esp_rewrite_ota_data(...) in latest esp_ota_ops.c, boot partition should be alternated after every OTA flashing. The problem happens after third one.

Initial (flash via USB-UART)

D (1659) boot: OTA sequence values A 0xffffffff B 0xffffffff
D (1712) boot: OTA sequence numbers both empty (all-0xFF)

After first OTA

D (1665) boot: OTA sequence values A 0x00000001 B 0xffffffff
D (1717) boot: Only OTA sequence A is valid, using OTA slot 0

After second OTA

D (1665) boot: OTA sequence values A 0x00000001 B 0x00000002
D (1717) boot: Both OTA sequence valid, using OTA slot 1

After third OTA (wrong behavior)

D (1665) boot: OTA sequence values A 0x00000003 B 0x00000002
D (1717) boot: Both OTA sequence valid, using OTA slot 2 # WRONG! only slot 0 and 1 are available

In boot process after third OTA, app boot from OTA slot 1 actually. As there are only two (slot 0 and 1) OTA partitions, OTA slot 2 (i.e. third OTA parttiion) not exists. Nevertheless, bootloader automatically fallbacks to earlier partition (slot 1).

This problem can be reproduced with offical OTA excample too.

After third OTA, bootloader repeatedly boot from OTA slot 1 (second OTA partition) only. It refuses further OTA flashed onto OTA slot 0.

This happens because get_selected_boot_partition(...) returns auto-incremented ota_seq based value, NOT OTA app partition index, and it is passed to index_to_partition(...) via load_boot_image(...) without special care.

Consequently, developers cannot try updated program via OTA after second one.

Solution

To fix this, referring the algorithm of esp_rewrite_ota_data(...) in esp_ota_ops.c, I modified index_to_partition(...) to point latest (most recently flashed) OTA slot correctly.

In my opinion, modifying get_selected_boot_partition(...) (around here) is not good idea in terms of fallback ordering of partitions.

[CLAassistant]

All committers have signed the CLA.

[projectgus]

Thanks @yanbe. This looks like I regression that I introduced in 43e231c (for a different situation, when some OTA slots didn't contain valid images the bootloader would re-verify them multiple times). Apologies for that.

Will verify & merge this ASAP.

[yanbe]

@projectgus Thanks for fixing this issue on 1cd2ce2 at master. I confirmed changes and It seems better solution. Great!

[projectgus]

Thanks @yanbe, I'm glad this works for you as well. Eventually we want to deprecate the current "ota_seq" ota_data format and introduce a new ota_data format, which will probably just store a partition number or an address offset.