Craig,

Ok, that works better. The only nit I have is that it left me with the boot partition set to factory, not sure what happens if you try booting with that set after the factory partition was renamed.

Not sure what you mean by this. The upgrade doesn’t change the boot partition selection at all, it just resizes it 4MB -> 6MB, with the extra 2MB empty (or garbage and never executed). In your case, the erase partition failed, so the partition upgrade would have aborted out at that time with nothing changed. There is a time critical region between erasing the partition table and writing a new one (a single 4KB flash write operation). That is as robust as it can be. Regards, Mark.

On 26 Feb 2026, at 6:04 AM, Craig Leres <leres@xse.com> wrote:

[I'm having trouble with dkim, *only* with lists.openvehicles.com ...]

On 2/25/26 12:10, Michael Balzer wrote:

...

your backtrace is in is_safe_write_address() -- is it possible you forgot to change your sdkconfig?

...

One big ‘gotcha’ I found was that we need to set CONFIG_SPI_FLASH_WRITING_DANGEROUS_REGIONS_ABORT= and CONFIG_SPI_FLASH_WRITING_DANGEROUS_REGIONS_ALLOWED=y in our sdkconfig - otherwise the partition table cannot be re-flashed.

Of course you're right...

Ok, that works better. The only nit I have is that it left me with the boot partition set to factory, not sure what happens if you try booting with that set after the factory partition was renamed.

Craig