Partition Error on Boot

[nrcrast]

Hi guys,

I'm getting an error on startup:

Code: Select all

I (29) boot: ESP-IDF  2nd stage bootloader
I (29) boot: compile time 12:21:48
I (30) boot: Enabling RNG early entropy source...
I (33) boot: SPI Speed      : 40MHz
I (38) boot: SPI Mode       : DIO
I (42) boot: SPI Flash Size : 4MB
I (46) boot: Partition Table:
I (49) boot: ## Label            Usage          Type ST Offset   Length
I (56) boot:  0 nvs              WiFi data        01 02 00009000 00040000
I (64) boot:  1 otadata          OTA data         01 00 00049000 00002000
I (71) boot:  2 ota_0            OTA app          00 10 00050000 00177000
I (79) boot:  3 atmosphere       OTA data        01 02 001c7000 001c2000
I (86) boot: End of partition table
E (91) boot: ota data partition invalid and no factory, will try all partitions
E (98) esp_image: image at 0x50000 has invalid magic byte
W (105) esp_image: image at 0x50000 has invalid SPI mode 12
E (111) boot: OTA app partition slot 0 is not bootable
E (117) boot: No bootable app partitions in the partition table
user code done

If I change the nvs partition to length 0x4000, the error goes away, but the BT/Wifi stacks run out of space. If I make the partition anything other than 0x4000, I get this error. Here's my partition .csv:

Code: Select all

# Name,   Type, SubType, Offset,   Size, Flags
# Note: if you change the phy_init or app partition offset, make sure to change the offset in Kconfig.projbuild
#reserved,  data,   data,       0x0000,     4K
#bootldr,   app,    boot,       0x1000,     28K
#parttbl,   data,   part,       0x8000,     4K
nvs,        data,   nvs,        0x9000,     256K
otadata,    data,   ota,        ,     0x2000
ota_0,      app,    ota_0,      ,    1500K
atmosphere,   data,   ota,        ,   1800K

The atmosphere partition is intended to be used by the application as raw SPI Flash space. I've tried turning off NVS for the Wifi and changing the nvs back to 0x4000. That works, but I don't understand why my configuration doesn't work.

Erasing the spi flash before programming has no effect, and this happens on two different boards with both ESP IDF 2.0 and the latest from git.

Any help would be greatly appreciated,
Nick

[chegewara]

Maybe its not related, but why do you have second ota partition type data? This way you have 2 otadata partitions. Try this way:

Code: Select all

atmosphere,   app,   ota_1,        ,   1800K

[nrcrast]

I'm just looking to define some sort of raw partition that I can use as I please with low level SPI Flash commands. Defining it as data seems to accomplish that. Is there a better way?

[chegewara]

It can be data, but having two partitions type data and subtype ota can cause issues (im not sure here).Try with spiffs subtype and you will see if this can help.

[ESP_Angus]

It can be data, but having two partitions type data and subtype ota can cause issues (im not sure here).Try with spiffs subtype and you will see if this can help.

I agree with chegewara this may cause problems, at minimum it's not recommended. Rather than "data", you can write in any hex byte from 0x40 to 0xFE in the "type" field to create a custom partition type (subtype can also be a number).

More details here: https://docs.espressif.com/projects/esp ... type-field

E (98) esp_image: image at 0x50000 has invalid magic byte

This indicates that the bootloader tried to boot the app at offset 0x50000 (ota_0) and found an invalid "magic byte" header. Is there an app flashed at offset 0x50000?

Until recently, ESP-IDF build system required you to specify the offset where the app should be flashed (default 0x10000) in the config:
https://docs.espressif.com/projects/esp ... bin-offset

This is no longer the case in the current master branch, or V3.1-beta1 - the partition table should be parsed for this info. But it may be worth double-checking that the flashing step is correctly flashing at offset 0x50000, all the same.

[nrcrast]

It can be data, but having two partitions type data and subtype ota can cause issues (im not sure here).Try with spiffs subtype and you will see if this can help.

I agree with chegewara this may cause problems, at minimum it's not recommended. Rather than "data", you can write in any hex byte from 0x40 to 0xFE in the "type" field to create a custom partition type (subtype can also be a number).

More details here: https://docs.espressif.com/projects/esp ... type-field

E (98) esp_image: image at 0x50000 has invalid magic byte

This indicates that the bootloader tried to boot the app at offset 0x50000 (ota_0) and found an invalid "magic byte" header. Is there an app flashed at offset 0x50000?

Until recently, ESP-IDF build system required you to specify the offset where the app should be flashed (default 0x10000) in the config:
https://docs.espressif.com/projects/esp ... bin-offset

This is no longer the case in the current master branch, or V3.1-beta1 - the partition table should be parsed for this info. But it may be worth double-checking that the flashing step is correctly flashing at offset 0x50000, all the same.

Thanks for the tip about custom partition types. I have changed the type for that partition to 0x40 and it works just fine.

The issue was the configuration value for the app offset. I had incorrectly assumed that it would use the partition table to figure it out.

All is well now.

Thanks,
Nick

[nrcrast]

It can be data, but having two partitions type data and subtype ota can cause issues (im not sure here).Try with spiffs subtype and you will see if this can help.

I agree with chegewara this may cause problems, at minimum it's not recommended. Rather than "data", you can write in any hex byte from 0x40 to 0xFE in the "type" field to create a custom partition type (subtype can also be a number).

More details here: https://docs.espressif.com/projects/esp ... type-field

E (98) esp_image: image at 0x50000 has invalid magic byte

This indicates that the bootloader tried to boot the app at offset 0x50000 (ota_0) and found an invalid "magic byte" header. Is there an app flashed at offset 0x50000?

Until recently, ESP-IDF build system required you to specify the offset where the app should be flashed (default 0x10000) in the config:
https://docs.espressif.com/projects/esp ... bin-offset

This is no longer the case in the current master branch, or V3.1-beta1 - the partition table should be parsed for this info. But it may be worth double-checking that the flashing step is correctly flashing at offset 0x50000, all the same.

I upgraded to 3.1, and I've run into a bit of a different problem:

Code: Select all

Flashing binaries to serial port /dev/ttyUSB0 (app at offset 0x0 )...
usage: esptool write_flash [-h] [--flash_freq {keep,40m,26m,20m,80m}]
                           [--flash_mode {keep,qio,qout,dio,dout}]
                           [--flash_size FLASH_SIZE]
                           [--spi-connection SPI_CONNECTION] [--no-progress]
                           [--verify] [--compress | --no-compress]
                           <address> <filename> [<address> <filename> ...]
esptool write_flash: error: argument <address> <filename>: Detected overlap at address: 0x1000 for file: /home/nick/Downloads/esptest4/build/bootloader/bootloader.bin
/home/nick/esp32_atmo/esp-idf/components/esptool_py/Makefile.projbuild:54: recipe for target 'flash' failed
make: *** [flash] Error 2

I get an error saying that there's a bootloader overlap, seemingly because it thinks the app is at offset 0x0. The app offset should be detected from the partition configuration, correct?

Code: Select all

# Name,   Type, SubType, Offset,   Size, Flags
# Note: if you change the phy_init or app partition offset, make sure to change the offset in Kconfig.projbuild
#reserved,  data,   data,       0x0000,     4K
#bootldr,   app,    boot,       0x1000,     28K
#parttbl,   data,   part,       0x8000,     4K
nvs,        data,   nvs,        0x9000,     256K
otadata,    data,   ota,        ,     0x2000
ota_0,      app,    ota_0,      ,    1500K
atmosphere,   data,   0x40,        ,   1800K

This works well with v2.x and the app offset configured to 0x50000.

Any idea?

-Nick

[nrcrast]

It works if I change the type to factory instead of ota_0, so it seems like there's a bug where it doesn't detect ota_0 as an app area.

[chegewara]

Did you do

Code: Select all

make erase_flash

[nrcrast]

Did you do

Code: Select all

make erase_flash

Yes. That doesn't help because it still thinks the app is at offset 0x0, since I think there's just a bug in the partition reading logic in 3.1