Change the online demo default flash address from `0x1000` to `0x10000`

[arduino12]

Checklist

• [x] Checked the issue tracker for similar issues to ensure this is not a duplicate
• [x] Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• [x] Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

Hi,

Will be very nice and will save lot of time for new users if the online demo default flash address will be the right one for the detected MCU!

For example I use ESP32S3 and it won't boot with the default 0x1000. Took me a while to notice it is not 0x10000:

The 0x10000 address seems to be the one for most ESP32 (s2 s3, c3, esp32...) See the flash command for each here.

Hope we can fix this soon so 0x10000 will be the default - I think it is a typo that the current value is 0x1000.

Actual behavior (suspected bug)

Error logs or terminal output

Steps to reproduce the behavior

Project release version

v

System architecture

Intel/AMD 64-bit (modern PC, older Mac)

Operating system

Linux

Operating system version

Win10

Shell

ZSH

Additional context

No response

[igrr]

The base address depends on the content of the binary you are flashing as well as on the MCU.

On the ESP32, the following parts typically need to be flashed:

• bootloader at 0x1000
• partition table at 0x8000 (might differ depending on the bootloader configuration)
• application at 0x10000 (default offset, might differ depending on the partition table)

On the ESP32-S3, it is the same except the bootloader has to be flashed at 0x0 instead of 0x1000.

So there is no single "correct" offset. If you are flashing the complete binary including bootloader, partition table, and the app, you have to flash it to 0x1000 for the ESP32 or 0x0 for ESP32-S3. If your board already has the correct bootloader and the partition table, then you can flash just the app to 0x10000, or whatever is the app partition offset according to the partition table. Depending on the partition table selected, the app offset could be different.

[arduino12]

Hi,

Thanks for your quick reply!

I think most of the time the bootloader and the partition table are already flashed.. so no need to re-flash them.. Most users will only want to flash the user-app at 0x10000- and that address is the same for all ESP32 as I understand.

Also if the user accidentally flash to 0x1000 - it ruin the bootloader if it was previously flashed.. But if the user accidentally flash to 0x10000 - no damaged is done because the partition-table and bootloader address are well below..

So if possible please change the default address to 0x10000 - will help avoid flashing to the "wrong" memory addresses and overwriting previously bootloader and partition table!

Arad :)

[tyeth]

Personally I usually see merged binaries being used, where they have been merged together with the assumption of being written at offset 0x0. That alleviates all issues with which starting address to use.

Of course if you want to update ONLY a single partition (like app_0) then using that specific offset makes sense (but varies).

Maybe inexperienced users need to be encouraged to backup the entire flash before overwriting it, as a general principle?

Sadly my attempts at getting the flash reading working reliably over web-serial seemed to hit a snag, the early bytes (nvs/boot) seemed to time out more often compared to reading later byte ranges (reading back a data partition). It works fine in offline esptool.

What might make more sense is to allow url parameters to be used in the form, like suggested in #184 (e.g. maybe with no filename but the address offset for first file specified as 0x10000), but you'll notice a similar comment that the better solution may be to create a binary for users that includes everything necessary and flashes at 0x0.

[arduino12]

Thanks @tyeth! I vote for #184 - very elegant solution!

And as you wrote, when the URL have no address parameters - use the default address 0x10000.

[Jason2866]

Not using a merged firmware binary has drawbacks. Are the correct files used? Is the magic image header correct to reflect flash size, flash speed and flash mode? By using a merged binary build with esptool.py all of that is taken care. If the magic header is not correct (flash mode) this can end in flash corruption when using a Filesystem. It gets even worse with the S3 and using OPI. Been there...