Issue with OTA partitions (invalid magic byte)

[d.cook]

Hello,

I've been attempting to start working with the OTA functions in our project, but I've had some issue getting the firmware to boot with the OTA partitions added.

I'm using the 'factory+2 OTA' csv, however I've shrank the partitions just to ensure I wasn't running out of space on the device.

On boot, I get the following error:

load:0x40080000,len:260
entry 0x40080034
␛[0;31mE (31) esp_image: image at 0x110000 has invalid magic byte␛[0m
␛[0;33mW (32) esp_image: image at 0x110000 has invalid SPI mode 255␛[0m
␛[0;33mW (34) esp_image: image at 0x110000 has invalid SPI size 15␛[0m
␛[0;31mE (40) boot: Failed to verify app image @ 0x110000 (8194)␛[0m
user code done

This is with the following CSV file:

# Name, Type, SubType, Offset, Size
# Note: if you change the phy_init or app partition offset, make sure to change the offset in Kconfig.projbuild
nvs, data, nvs, 0x9000, 0x4000
otadata, data, ota, 0xd000, 0x2000
phy_init, data, phy, 0xf000, 0x1000
factory, 0, 0, 0x10000, 512K
ota_0, 0, ota_0, , 512K
ota_1, 0, ota_1, , 512K

I'm testing on a Sparkfun ESP32Thing, however I've gotten similar errors on the WROOM-32. Am I missing something? The docs on partitioning don't suggest much beyond what I've done as far as I can tell.


Thanks

[WiFive]

It looks like it is looking for the partition at 0x110000 but if your partition is 512k shouldn't it be looking at 0x90000? Did you configure the partition table CSV name in make menuconfig and then "make partition_table"? And ensure the new partition table is written to flash? Although you'd think that alone shouldn't break ota because it should still be consistent across the bootloader and ota code.

[d.cook]

I ran 'make menuconfig' and then 'make partition_table' and 'make partition_table-flash'. I also tried it with just 'make' and 'make flash'. No difference either way. I also tried commenting out the second OTA partition, and I get the same error but at a different address (but still not one you would expect).

[ESP_Angus]

0x110000 is the correct offset for the ota_1 partition, with 512K partitions.

There errors imply that nothing has been written to this partition. (It's all 0xFF, unwritten flash.)

Is it possible that the OTA code has updated ota_0 partition but set ota_data to point to ota_1? What is the full output from the boot log? Can you share any more details about how which manual serial flashes and OTA update(s) have been performed, in which order?

There is at least one bug, which is that the OTA boot logic should fall back to a valid app partition rather than exit entirely like this.

And there's also least one shortcoming, that I just realised, which is that re-flashing the factory partition won't erase the ota_data partition, unless you perform an "esptool.py erase_flash" to clear the entire chip.

[aschweiz]

Hi Daniel,

there's another issue in the bootloader code, see here: http://www.esp32.com/viewtopic.php?f=14&t=615

I've "fixed" it in my checkout of bootloader_start, function bootloader_main():

sa = ota_select_map[0];
// TODO
// The [128] is a workaround to make this consistent with the app_update component.
sb = ota_select_map[128];
bootloader_munmap(ota_select_map);

cheers
Andreas

[d.cook]

Running 'erase_flash' and then re-flashing everything seemed to work - I had assumed that an erase was part of the 'make flash' process. Is an erase required each time the partition map changes? Maybe that's something that shouldn't happen very often, but it should still be reflected in the docs if that's the case.

Andreas, thanks for posting your fix. Looking at the bootloader code, am I correct in thinking that it can only map up to two OTA partitions?

[ESP_Angus]

Running 'erase_flash' and then re-flashing everything seemed to work - I had assumed that an erase was part of the 'make flash' process. Is an erase required each time the partition map changes? Maybe that's something that shouldn't happen very often, but it should still be reflected in the docs if that's the case.

I agree, I'll see about adding it to the docs. I'm not sure if the problem you were seeing was old/junk data in the ota_data partition or the bug Andreas reported (which will be fixed in esp-idf master ASAP).

Looking at the bootloader code, am I correct in thinking that it can only map up to two OTA partitions?

You should be able to have up to 16 OTA partitions. The reason the data is stored in two places is for redundancy, if power is lost during the write of one or the other partition then we can still recover the OTA data contents.

Angus

[aaquilina]

Hi,

I'm having the same issue but using erase_flash did not resolve the issue. On boot, the bootloader tries to boot from 0x110000.
This is my partition table:

And this is the serial output I get:




I have tried switching the ota0 partition with the factory partition such that if it tries to boot from 0x110000 instead of 0x10000, it finds the factory partition. However, this runs and then subsequently, the program (which works in single partition mode) crashes. I have even tried flashing the partition table directly to 0x8000 to ensure that it is being flashed correctly and still get the same result. I have also tried replacing the bootloader components in my IDF using both idf 1.0, 2.0 and the idf provided by Andreas Schweizer at https://blog.classycode.com/over-the-ai ... .b5yksc2qe .

Any ideas as to how I may approach this issue in terms of trouble shooting?

[ESP_Angus]

I have tried switching the ota0 partition with the factory partition such that if it tries to boot from 0x110000 instead of 0x10000, it finds the factory partition.

Can you explain exactly what you mean by this? You flashed the factory partition at 0x110000?

I have also tried replacing the bootloader components in my IDF using both idf 1.0, 2.0 and the idf provided by Andreas Schweizer at https://blog.classycode.com/over-the-ai ... .b5yksc2qe .

If you use IDF current master branch, totally unmodified, does this work?

Is it possible for you to dump your flash and send us a download link to take a look? "esptool.py --baud 921600 --port PORT read_flash 0 0x400000 flash_dump.bin" will do the trick. If it's sensitive then maybe you can send a link via email?

[hiren.virapara]

I have got the issue it looks like the same as you have, but not able to identify the problem.

You can see the error in the attached image