Partition for large app with OTA support

[matthew798]

Hi all,

I've been reading through the docs on partitions and I have a few question. This is what I currently have:

Code: Select all

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x4000,
otadata,  data, ota,     0xd000,  0x2000,
phy_init, data, phy,     0xf000,  0x1000,
factory,  app,  factory, 0x10000, 0x16E360,
ota_0,    0,    ota_0,          , 0x16E360,

I'd like to have a small amount of NVS, and support OTA. My app uses both bluetooth and wifi so it's quite large. As it stands, it occupies 80% of the 1.5M i've allocated to "factory".

Here are my concerns/questions:
1) I think factory has to start at 0x10000. Is that correct?
2) Why do I get an error about alignment when I set the "ota_0" partition's offset? Does it need to be offset (aligned) to multiples of 0x10000?
3) I seem to remember reading that OTA requires no less than 2 OTA partitions. Is this true? I can't find it anywhere, I may have imagined it.
4) As I have it set up, am I taking full advantage of the available 4MB of flash?

Also, my app seems to upload and run fine, but the ESP spits out these errors/warning over serial:

Code: Select all

E (110) esp_image: image at 0x180000 has invalid magic byte
E (116) boot_comm: mismatch chip ID, expected 0, found 38689
E (122) boot_comm: can't run on lower chip revision, expected 1, found 151
W (130) esp_image: image at 0x180000 has invalid SPI mode 83
E (136) boot: OTA app partition slot 0 is not bootable

Thanks!

[boarchuz]

1&2.

Partitions of type app have to be placed at offsets aligned to 0x10000 (64K).

https://docs.espressif.com/projects/esp ... ffset-size

Factory does not need to be at 0x10000.

3. No, you could have a factory + OTA or multiple OTA. The first might be considered safer, as the factory app will not be overwritten and you can always reset back to it (in fact, you would have to boot from it in order to perform OTA updates into the ota partition). The second alternates between boot partitions with each successful OTA update. That seems more suitable for your case here.

4. Not even close. You could fit another large app partition, if you liked.

eg.

Code: Select all

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x4000,
otadata,  data, ota,     0xd000,  0x2000,
phy_init, data, phy,     0xf000,  0x1000,
ota_0,  app,  ota_0, 0x10000, 0x16E360,
# use up to the next valid app offset for custom storage
settings, data, nvs, 0x17E360, 0x1CA0,
ota_1,    app,    ota_1, 0x180000, 0x16E360,
# use up to the next valid app offset for custom storage
storage, data, nvs, 0x2EE360, 0x1CA0,
# factory app
recovery, app, factory, 0x2F0000, 0x110000

You might instead extend the ota partition sizes to allow for larger binaries in future updates, with a smaller factory app. Also phy_init is likely unused.

5. That's probably normal, it's checking if ota0 can be booted and defaulting to factory because it's invalid. It does seem a little excessive, maybe erasing the ota_data partition to reset the ota state will help.