ESP32 Forum

Hi, this is my partition table
I configured via make menuconfig Factory app partition offset to 0x010000 (ota_0).

My prgram executes exactly same functions of ota_example_main.c.
All of them execute with no errrors:
1- esp_ota_get_next_update_partition (here I print what partition returns and returns correctly ota_1 address)
2- esp_ota_begin
3- esp_ota_write (a lot of them, the size of downloaded file corresponds to the file so I'm assuming it's downloading it ok)
4- esp_ota_end
5- esp_ota_set_boot_partition
6- esp_restart

After restart, it doesn't boot from ota_1 and I can see this from configured/running partition check:
Configured OTA boot partition at offset 0x00110000 but running from offset 0x00010000


So what could be wrong?
Is partition table ok?

I'm using make erase_flash before each try (it only takes 4,7s, is this time ok?)

Thanks in advance

EDIT:
That's what is printed when powering on
In https://github.com/espressif/esptool/wi ... -Selection is explained that:

Early flash read error
flash read err, 1000
This fatal error indicates that the bootloader tried to read the software bootloader header at address 0x1000 but failed to read valid data. Possible reasons for this include:

-Physical problem with the connection to the flash chip, or flash chip power.
-Boot mode accidentally set to HSPI_FLASH_BOOT, which uses different SPI flash pins. Check GPIO2 (see above).
-VDDSDIO has been enabled at 1.8V (due to MTDI/GPIO12, see above), but this flash chip requires 3.3V.

So that could explain why isn't booting the corresponent partition.

However in our custom pcb IO2, IO12 and IO15 are left unconnected. Checked them and are all ok:
-IO2: low
-IO12: low
-IO15: high

Checked the power and EN pin, they're stable at 3,3V.
Checked other boards with same hardware and the 'flash read err, 1000' happens too.

Also I've runned this command I read somewhere:

$ py esptool.py -p COM13 verify_flash 0x1000 ../../../../../../../build/bootloader/bootloader.bin
esptool.py v2.1
Connecting......
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Verifying 0x5560 (21856) bytes @ 0x00001000 in flash against ../../../../../../../build/bootloader/bootloader.bin...
-- verify OK (digest matched)
Hard resetting...

Seems like bootloader is written correctly... so I guess it's a hardware problem?

We connected the module like this schematic from "esp_wroom_32_datasheet_en.pdf" (SD0, SD1, SD2, SD3, CMD, CLK are unconntected)


But I've seen it's slightly different from the one from "ESP32-Core-Board-V2_sch.pdf" (capacitor values)


Can this have some effect?

I've tried my program in a ESP32-Core-Board-V2 and show no 'flash read err, 1000'

Flash read error likely happens because flash chip start up time is too slow, and ROM code tries to read from it before it is ready. It should not cause problems though, just an extra RTC WDT reset. Can you enable debug log level for both bootloader and app, and post the log produced when doing OTA, perhaps this can help better understand your original problem.

ESP_igrr wrote:Flash read error likely happens because flash chip start up time is too slow, and ROM code tries to read from it before it is ready. It should not cause problems though, just an extra RTC WDT reset. Can you enable debug log level for both bootloader and app, and post the log produced when doing OTA, perhaps this can help better understand your original problem.

Thanks Ivan, showing the bootloader debug info I found what was wrong
Apparently the partition 'more_space' was being detected as 'OTA partition data' and when bootloader readed that was always full of FF's so it would boot the first partition.

Changed the partition table to this and seems to work (added factory app, and renamed subtype of space from 'data' to 0x40): I have to verify and test a lot of times now but I think this is it.
And the flash error isn't happening with SW_CPU_RESET indeed, only in the power on, so I was tangling myself there
Thanks again and cheers.

I see now, thanks and good to know that you got the problem solved. This might explain a few other bug reports we got. We should update the partition table generation tool to detect duplicate partitions of certain types, such as in your case:

otadata, data, ota, 0xd000, 0x2000
some_space, data, , 0x210000, 384K
more_space, data, , 0x270000, 384K

is not a great idea