espflash
espflash copied to clipboard
OTA support - image written to wrong address
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.
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
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.
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.
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.
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.
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.
Unfortunately I won't be able to check this in the near future. When is the release scheduled to happen?
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?
Gotcha. I'm currently working on a few prs for mosquito, I'll circle back to this afterwards. Probably end of next week
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.
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.
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.