espflash icon indicating copy to clipboard operation
espflash copied to clipboard

OTA support - image written to wrong address

Open axos88 opened this issue 1 year ago • 5 comments

Repro:

  • use a partition table with two ota partitions, such as:
# Name,   Type, SubType, Offset,  Size, Flags
# Note: if you have increased the bootloader size, make sure to update the offsets to avoid overlap
# bootloader                       32K
# partition table                  3K (4K)
phy_init, data, phy,     0x009000, 4K,
nvs,      data, nvs,     0x00A000, 24K,
ota0,     app, ota_0,    0x010000, 1984K
ota1,     app, ota_1,    0x200000, 1984K,
otadata,  data, ota,     0x3F2000, 8K,
storage,  data, spiffs,  0x3F4000, 48K,
  • flash image v1 using cargo-espflash
  • perform an OTA upgrade (v2)
  • reboot, check binary v2, flashed with OTA is active
  • flash v3 of the image with cargo-espflash

Expected:

  • v3 should boot

Actual:

  • v2 boots

Suspicion:

  • v3 image is written to partition ota0 (tool reports writing to address 0x10000), but during previous OTA update the otadata partition has been set to mark ota1 partition as active, hence v2 is booted.

Suggested fix:

  • after flashing either the OTA partition needs to be erased
  • or the utility needs to check the data and determine the active partition before flashing.

axos88 avatar Sep 27 '22 13:09 axos88

In the meantime I saw that 1.7.0 does address this (I used 1.6.0 before), however it does not read the partition table from the device/image, but rather expects it to be supplied as a command line argument, which can be out of sync with the actual binary and also does not work for me:

cargo espflash --release --erase-otadata --speed 1152000 --monitor

Error: espflash::partition_table::no_otadata

cargo espflash --release --erase-otadata --speed 1152000 --monitor --partition-table partitions.csv

Error: espflash::partition_table::invalid_partition_table

axos88 avatar Sep 27 '22 14:09 axos88

I'd expect the partition table to be read from:

  • the command line parameter, if supplied
  • the ELF file, if it contains the appropriate section (I guess it should - since we are writing the partition table to the chip from the ELF)
  • read from the device itself it not present.

And that should be used instead.

axos88 avatar Sep 27 '22 14:09 axos88

Thanks for opening this issue. We had some previous OTA-related issues which were (hopefully) resolved in #119, but I suppose we're not quite there yet 😅

I appreciate you supplying an example to reproduce this! We'll definitely get this fixed before the next release.

jessebraham avatar Sep 27 '22 15:09 jessebraham

The no_otadata error is due to the parsing of the subtype for binary partition tables being broken. I was going to file a MR for it but apparently all of that code has been extracted to another crate and rewritten, and it looks like it's been fixed there.

It would be nice if this was fixed pretty soon though, so any chance we could get a 1.7.1 release with my partition table parsing change?


If that's okay with you, please create a new branch for v1.7 and I'll file a PR against it.

kyrias avatar Sep 29 '22 09:09 kyrias

Sorry for not responding earlier, I've been quite busy lately and have kind of been in my own little world.

I will be publishing new releases, [email protected] and [email protected], early next week. Despite the "alpha" status these should be quite stable, I've just giving myself an opportunity to make last-second API changes :)

As far as I understand this issue should be "fixed" with that release, though there may still be some improvements to be made. Please let me know if I am not correctly understanding the situation, though.

I'll update this thread again next week when the releases have been published.

jessebraham avatar Oct 27 '22 15:10 jessebraham

I apologize, I forgot to mention the new releases when I published them. Fast forward to now, we're now on [email protected] and [email protected]. Would you be able to verify whether these issues persist with the newest version please? If not, we can address the issues prior to the stable release.

jessebraham avatar Jan 26 '23 19:01 jessebraham

Unfortunately I won't be able to check this in the near future. When is the release scheduled to happen?

axos88 avatar Jan 26 '23 21:01 axos88

No worries. No specific date in mind, assuming there continue not to be issues with the latest RC then maybe in a couple weeks or a month?

jessebraham avatar Jan 30 '23 15:01 jessebraham

Gotcha. I'm currently working on a few prs for mosquito, I'll circle back to this afterwards. Probably end of next week

axos88 avatar Jan 31 '23 23:01 axos88

I'm not sure if I am maybe doing something wrong, but I gave [email protected] a try and I am still not seeing the correct partition being set.

julienvincent avatar Feb 16 '23 14:02 julienvincent

Ok I take that back I was actually running into an unrelated issue. I can confirm, for my use-case at least, that 2.0.0-rc.3 seems to behave as expected.

julienvincent avatar Feb 16 '23 17:02 julienvincent

I've published 2.0.0-rc.4, which should hopefully resolve this issue. If you continue to see problems please feel free to re-open this issue, or to open a new issue.

jessebraham avatar Jun 08 '23 14:06 jessebraham