search

espressif / arduino-esp32

Arduino core for the ESP32
GNU Lesser General Public License v2.1
13.44k stars 7.38k forks source link

REGRESSION: ESP32-S3-DevKitC-1-N8R8 reboot cycle under 2.0.4, partially worked in 2.0.3 #6980

Closed avillacis closed 2 years ago

avillacis commented 2 years ago

Board

ESP32-S3

Device Description

ESP32-S3-DevKitC-1-N8R8 as described in https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/hw-reference/esp32s3/user-guide-devkitc-1.html#ordering-information

Hardware Configuration

Default "official" development board, 8MB PSRAM, 8MB Flash

Version

latest development Release Candidate (RC-X)

IDE Name

Arduino IDE

Operating System

Linux, Fedora 36 x86_64

Flash frequency

80Mhz

PSRAM enabled

yes

Upload speed

921600

Description

The board is a ESP32-S3-DevKitC-1-N8R8 from Espressif. This board is supposed to have: 8MB SPI RAM, 8MB flash storage. The latter is supposedly confirmed if I run esptool.py with the --flash-size detect option:

python /home/alex/.arduino15/packages/esp32/tools/esptool_py/3.3.0/esptool.py \
    --chip esp32s3 \
    --port /dev/ttyUSB0 \
    --baud 921600 \
    --before default_reset \
    --after hard_reset \
    write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect \
    0x0 build/ybx-blinktest.ino.bootloader.bin \
    0x8000 build/ybx-blinktest.ino.partitions.bin \
         0xe000 /home/alex/.arduino15/packages/esp32/hardware/esp32/2.0.3/tools/partitions/boot_app0.bin \
       0x10000 build/ybx-blinktest.ino.bin \
      0x670000 build/ybx-blinktest.spiffs
esptool.py v3.3-dev
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-S3
Features: WiFi, BLE
Crystal is 40MHz
MAC: 7c:df:a1:e3:c5:20
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 8MB
Flash will be erased from 0x00000000 to 0x00003fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x0010afff...
Flash will be erased from 0x00670000 to 0x007fffff...

Under Arduino-ESP32 v2.0.3, if I choose Flash Size: "4MB (32 Mb)" and Partition Scheme: "Default 4MB with spiffs (1.2MB APP/1.5MB SPIFFS)", the sketch can boot correctly when uploaded. With same Arduino-ESP32 version, if I choose Flash Size: "8MB (64 Mb)" BUT keep the 4MB partition scheme, it still works correctly. However, if I then keep the 8MB flash size and choose Partition Scheme: "8M Flash (3MB APP/1.5MB FAT)", the board enters a reboot loop:

14:39:29.661 -> ESP-ROM:esp32s3-20210327
14:39:29.661 -> Build:Mar 27 2021
14:39:29.661 -> rst:0x3 (RTC_SW_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
14:39:29.661 -> Saved PC:0x403bb22e
14:39:29.661 -> SPIWP:0xee
14:39:29.661 -> mode:DIO, clock div:1
14:39:29.661 -> load:0x3fcd0108,len:0x43c
14:39:29.661 -> load:0x403b6000,len:0xbd0
14:39:29.661 -> load:0x403ba000,len:0x29c8
14:39:29.661 -> entry 0x403b61d8
14:39:29.661 -> ESP-ROM:esp32s3-20210327
14:39:29.661 -> Build:Mar 27 2021
14:39:29.661 -> rst:0x3 (RTC_SW_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
14:39:29.661 -> Saved PC:0x403bb22e
14:39:29.661 -> SPIWP:0xee
14:39:29.661 -> mode:DIO, clock div:1
14:39:29.661 -> load:0x3fcd0108,len:0x43c
14:39:29.661 -> load:0x403b6000,len:0xbd0
14:39:29.661 -> load:0x403ba000,len:0x29c8
14:39:29.661 -> entry 0x403b61d8
14:39:29.663 -> ESP-ROM:esp32s3-20210327
14:39:29.663 -> Build:Mar 27 2021
14:39:29.663 -> rst:0x3 (RTC_SW_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
14:39:29.663 -> Saved PC:0x403bb22e
14:39:29.663 -> SPIWP:0xee
14:39:29.663 -> mode:DIO, clock div:1
14:39:29.663 -> load:0x3fcd0108,len:0x43c
14:39:29.663 -> load:0x403b6000,len:0xbd0
14:39:29.663 -> load:0x403ba000,len:0x29c8
14:39:29.663 -> entry 0x403b61d8

With Arduino-ESP32 2.0.4, the situation is worse. No matter what combination of flash size and partition I choose, I get the reboot loop. Of course, I do not test a 4MB flash size with an 8MB partitioning.

HOWEVER... if I flash the 2.0.4 with the 4MB partitioning and either the 4MB or 8MB flash size, and I then carefully flash the 2.0.3 bootloader at the correct address, the board is then able to boot correctly:

$ python /home/alex/.arduino15/packages/esp32/tools/esptool_py/3.3.0/esptool.py --chip esp32s3 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect  0x0 /home/alex/.arduino15/packages/esp32-alternatives/2.0.3/hardware/esp32/2.0.3/tools/sdk/esp32s3/bin/bootloader_qio_80m.bin 
esptool.py v3.3-dev
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-S3
Features: WiFi, BLE
Crystal is 40MHz
MAC: 7c:df:a1:e3:c5:20
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 8MB
Flash will be erased from 0x00000000 to 0x00003fff...
Compressed 14896 bytes to 10242...
Wrote 14896 bytes (10242 compressed) at 0x00000000 in 0.4 seconds (effective 307.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

This points me at the 2.0.4 bootloader as the one containing the reboot bug.

Sketch

/* Any sketch will work, as this is not sketch related */

void setup() {
  // put your setup code here, to run once:

}

void loop() {
  // put your main code here, to run repeatedly:

}

Debug Message

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x400454d5
SPIWP:0xee
mode:QIO, clock div:2
load:0x3fce3808,len:0x43c
ets_loader.c 78 
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x400454d5
SPIWP:0xee
mode:QIO, clock div:2
load:0x3fce3808,len:0x43c
ets_loader.c 78 
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x10 (RTCWDT_RTC_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:QIO, clock div:2
load:0x3fce3808,len:0x43c
ets_loader.c 78 
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x400454d5
SPIWP:0xee
mode:QIO, clock div:2
load:0x3fce3808,len:0x43c
ets_loader.c 78 
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x400454d5
SPIWP:0xee
mode:QIO, clock div:2
load:0x3fce3808,len:0x43c
ets_loader.c 78

Other Steps to Reproduce

I have found https://github.com/espressif/arduino-esp32/issues/6803 while searching for similar bugs. The comments make me think some of the commenters are suffering the same symptoms as I do. For example, https://github.com/espressif/arduino-esp32/issues/6803#issuecomment-1138029823. However, I really am careful of not attempting a 8MB partitioning on a 4MB configuration, and this does not explain the reboot loop with 4MB flash/4MB partitioning anyway. As I am not using PlatformIO, the comments suggesting board definition fixes do not appear to be relevant.

From this comment: https://github.com/espressif/arduino-esp32/issues/6803#issuecomment-1138030722 it seems that at least one other has identified a bootloader regression for ESP32-S3.

I have checked existing issues, online documentation and the Troubleshooting Guide

Jason2866 commented 2 years ago

The bootloader boots in QIO mode. This is not supported. The bootloader has to boot in DIO mode. The started application firmware switches to the needed flash mode (QIO). In 2.0.3 the core did this by default. In 2.0.4 the user has to take care to choose the correct needed settings. So you have to set boot mode dio, and flash modes QIO / OPI for Flash/Psram with 8MB each. Use a 8MB partition scheme. Dont ask how to do in Arduino IDE. I do not use. This settings are possible in PlatformIO and device starts with core 2.0.4

Jason2866 commented 2 years ago

Mhh the flash command is not perfect --flash_size detect is dangerous to use. It can happen that flash size is not correctly detected or/and the header patching (when the detected flash size is different) is not done correctly. The flash command should send the correct and wanted flash size! The starting of the bootloader in mode QIO is a indicator that something failed here. I encountered a similar problem when creating a merged firmware (factory firmware with all needed files in one binary file). I had to explicit set flash mode for core 2.0.4 For core 2.0.3 this was NOT needed! See the needed change for creating a valid factory firmware for core 2.0.4 for project Tasmota. @me-no-dev Considering to update to esptool v4.1 for building the Arduino libs and for Arduino core? Only with v4.1 there is the option -dont-append-digest to strip the sha256 diggest to solve the optical issue sha failed... at boot time? The needed firmware header patching will not work with esptool v.4.x anymore when the sha digest are there.

avillacis commented 2 years ago

The bootloader boots in QIO mode. This is not supported. The bootloader has to boot in DIO mode. The started application firmware switches to the needed flash mode (QIO). In 2.0.3 the core did this by default. In 2.0.4 the user has to take care to choose the correct needed settings.

When you say that QIO mode is not supported, do you mean, not supported for any ESP32-S3 board? Or not supported specifically for the ESP32-S3-DevKitC-1-N8R8 ? If the latter, what in the output gives away that the issue is a DIO/QIO mismatch?

So you have to set boot mode dio, and flash modes QIO / OPI for Flash/Psram with 8MB each. Use a 8MB partition scheme. Dont ask how to do in Arduino IDE. I do not use. This settings are possible in PlatformIO and device starts with core 2.0.4

The file I am examining for how Arduino IDE is supposed to assign the bootloader is: ~/.arduino15/packages/esp32/hardware/esp32/2.0.4/boards.txt . Here, from context, I deduce that the default bootloader for the esp32s3 is esp32s3.build.boot=qio, and that the esp32s3.menu.FlashMode menu selections allow selection of the bootloader (options show are qio twice, dio, opi).

avillacis commented 2 years ago

My experiment is to explicitly flash just the bootloader from the following files (with sha1sum):

$ sha1sum ~/.arduino15/packages/esp32/hardware/esp32/2.0.4/tools/sdk/esp32s3/bin/*
d0b3cc194c70136e8322acceefb3d4fad20316e4  /home/alex/.arduino15/packages/esp32/hardware/esp32/2.0.4/tools/sdk/esp32s3/bin/bootloader_dio_80m.bin
f4e43195a974ac130003a0c8752d2d89c7f2fd1e  /home/alex/.arduino15/packages/esp32/hardware/esp32/2.0.4/tools/sdk/esp32s3/bin/bootloader_opi_80m.bin
e5a8a011594d3375e722df4a3536efeb724f847b  /home/alex/.arduino15/packages/esp32/hardware/esp32/2.0.4/tools/sdk/esp32s3/bin/bootloader_qio_120m.bin
e5a8a011594d3375e722df4a3536efeb724f847b  /home/alex/.arduino15/packages/esp32/hardware/esp32/2.0.4/tools/sdk/esp32s3/bin/bootloader_qio_80m.bin

The command I use to flash the files is: python /home/alex/.arduino15/packages/esp32/tools/esptool_py/3.3.0/esptool.py --chip esp32s3 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size 8MB 0x0 /PATH/TO/BOOTLOADER/FILE.BIN

What I expected to happen is that the bootloaders with qio in their name will boot in QIO mode (and cause the reboot cycle), but that the bootloader with dio in its name will boot in DIO mode, and succeed.

What actually happened is that BOTH the qio bootloaders and the dio one (and the opi one too) show the reboot cycle:

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x400454d5
SPIWP:0xee
mode:QIO, clock div:2
load:0x3fce3808,len:0x39c
ets_loader.c 78 
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x10 (RTCWDT_RTC_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:QIO, clock div:2
load:0x3fce3808,len:0x39c
ets_loader.c 78 
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x400454d5
SPIWP:0xee
mode:QIO, clock div:2
load:0x3fce3808,len:0x39c
ets_loader.c 78

Again, if I flash the 2.0.3 dio bootloader with the same command as above, it boots correctly in DIO mode:

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd0108,len:0x39c
load:0x403b6000,len:0x9a4
load:0x403ba000,len:0x2868
entry 0x403b61c0
[   243][I][esp32-hal-psram.c:96] psramInit(): PSRAM enabled
[   639][D][YuboxWiFiClass.cpp:505] _loadSavedNetworksFromNVRAM(): net/sel = 0
[   640][D][YuboxWiFiClass.cpp:508] _loadSavedNetworksFromNVRAM(): net/n = 1
[   643][E][Preferences.cpp:483] getString(): nvs_get_str len fail: net/1/identity NOT_FOUND
[   650][E][Preferences.cpp:483] getString(): nvs_get_str len fail: net/1/password NOT_FOUND

So, as far as I understand, there is something wrong with the 2.0.4 bootloaders for ESP32-S3 that, at least on my particular board, make them attempt to boot in QIO mode regardless of the selected bootloader, and (if the particular board does not support booting in QIO mode) causes a reboot cycle.

This is confirmed when firing up Arduino IDE and then locating the temporary build directory under /tmp/arduino_build_329921/ (for my example session). The file /tmp/arduino_build_329921/test-BlinkRGB.ino.bootloader.bin has the sha1sum of d0b3cc194c70136e8322acceefb3d4fad20316e4 which matches the supposed dio bootloader mentioned above. Yet, when flashing from Arduino IDE, the board attempts to boot in QIO mode and reboots endlessly.

Jason2866 commented 2 years ago

The 1stage bootloader can not start in flash mode qio! It has to start in mode dio when later the second stage boot loader switches to mode qio. If the target flash mode is qout the bootloader has to start in mode dout. Again the second stage bootloader does this switching. Described here

Jason2866 commented 2 years ago

The sha checksum is invalid since esptool patches the magic bytes in the firmware regarding the settings choosen/needed. Described here

avillacis commented 2 years ago

The 1stage bootloader can not start in flash mode qio! It has to start in mode dio when later the second stage boot loader switches to mode qio. If the target flash mode is qout the bootloader has to start in mode dout. Again the second stage bootloader does this switching. Described here

The sha checksum is invalid since esptool patches the magic bytes in the firmware regarding the settings choosen/needed. Described here

My use of sha1sum is merely to document the chosen bootloader file in case there was any doubt on which bootloader was actually used.

If esptool.py is supposed to patch the header file of the bootloader in order to give hints to the first stage bootloader, then I am at a loss on what is actually happening. As mentioned previously, I passed --flash_mode dio in all my tests. Also, the flash mode is selected as DIO in Arduino IDE. Yet, the boot process somehow selects QIO and goes into the reboot cycle. Why?

@Jason2866 Could you please suggest which bootloader and/or program argument should I be using?

avillacis commented 2 years ago

I am assuming the second-stage bootloader is the file I am picking from the ~/.arduino15/packages/esp32/hardware/esp32/2.0.4/tools/sdk/esp32s3/bin/ directory.

Does the reboot cycle give any hints on whether the second-stage bootloader has finished executing and is attempting to hand off control to some successfully loaded portion of the application binary? As opposed of failing to read the app binary at all?

Jason2866 commented 2 years ago

No, you do not see (afaik) when 2nd stage bootloader kicks in. BUT if you see QIO in this early stage of the boot process it is from 1st stage bootloader and this is wrong. Sorry i do not use Arduino IDE and have no knowledge about. I just can say the way i described works to build a one file firmware with all needed parts merged together. This file can simply flashed with esptool.py write_flash 0x0 factory_img.bin We use this factory images to flash Tasmota with https://tasmota.github.io/install/ just this way.

avillacis commented 2 years ago

When I checked an hexdump of the bootloaders across Arduino-ESP32 versions, I found the following difference in the headers:

esp32-alternatives/2.0.3/hardware/esp32/2.0.3/tools/sdk/esp32s3/bin/bootloader_dio_80m.bin

00000000  e9 03 02 2f c0 61 3b 40  ee 00 00 00 09 00 00 00  |.../.a;@........|
00000010  00 00 00 00 00 00 00 01  08 01 cd 3f 9c 03 00 00  |...........?....|
00000020  ff ff ff ff 28 50 04 00  ff 64 00 00 01 00 00 00  |....(P...d......|
00000030  00 f0 01 60 00 00 00 00  04 00 00 00 05 00 00 00  |...`............|

esp32-alternatives/2.0.3/hardware/esp32/2.0.3/tools/sdk/esp32s3/bin/bootloader_qio_80m.bin

00000000  e9 03 02 2f d8 61 3b 40  ee 00 00 00 09 00 00 00  |.../.a;@........|
00000010  00 00 00 00 00 00 00 01  08 01 cd 3f 3c 04 00 00  |...........?<...|
00000020  ff ff ff ff 28 50 04 00  ff 64 00 00 01 00 00 00  |....(P...d......|
00000030  00 f0 01 60 00 00 00 00  04 00 00 00 05 00 00 00  |...`............|

esp32-alternatives/2.0.4/hardware/esp32/2.0.4/tools/sdk/esp32s3/bin/bootloader_dio_80m.bin

00000000  e9 03 00 00 c0 98 3c 40  ee 00 00 00 09 00 00 00  |......<@........|
00000010  00 00 00 00 00 00 00 00  08 38 ce 3f 9c 03 00 00  |.........8.?....|
00000020  ff ff ff ff 28 50 04 00  ff 64 00 00 01 00 00 00  |....(P...d......|
00000030  00 f0 01 60 00 00 00 00  04 00 00 00 05 00 00 00  |...`............|

esp32-alternatives/2.0.4/hardware/esp32/2.0.4/tools/sdk/esp32s3/bin/bootloader_qio_80m.bin

00000000  e9 03 00 00 d8 98 3c 40  ee 00 00 00 09 00 00 00  |......<@........|
00000010  00 00 00 00 00 00 00 00  08 38 ce 3f 3c 04 00 00  |.........8.?<...|
00000020  ff ff ff ff 28 50 04 00  ff 64 00 00 01 00 00 00  |....(P...d......|
00000030  00 f0 01 60 00 00 00 00  04 00 00 00 05 00 00 00  |...`............|

The relevant difference is: the 2.0.3 versions start with e9 03 02 2f, and the 2.0.4 versions start with e9 03 00 00. From what I understand from here, the 2.0.3 bootloaders are pre-marked as DIO, 4MB flash @ 80MHz, and the 2.0.4 are left with zeroes, which are interpreted as QIO, 1MB flash (?!?) @ 40MHz (?!?), until and unless the esptool.py step patches in the right values.

Soooo... my guess is now that esptool.py is SUPPOSED to patch these bytes when flashing, but fails to do so, contrary to documentation.

avillacis commented 2 years ago

Also, I found this:

$ sha1sum `find . -name esptool.py`
3319ee6ccbc18394f584389b22a62d339061bc83  ./esp32-alternatives/2.0.3/tools/esptool_py/3.3.0/esptool.py
3319ee6ccbc18394f584389b22a62d339061bc83  ./esp32-alternatives/2.0.3/hardware/esp32/2.0.3/tools/esptool.py
3319ee6ccbc18394f584389b22a62d339061bc83  ./esp32-alternatives/2.0.4/tools/esptool_py/3.3.0/esptool.py
6954037a1c20246f2b341d4759a6742542263754  ./esp32-alternatives/2.0.4/hardware/esp32/2.0.4/tools/esptool.py

The esptool.py versions are the same in 2.0.3 (3.3-dev) but in 2.0.4 the one at hardware/esp32/2.0.4/tools/esptool.py is different (3.3.2-dev). In Arduino IDE, the upload ends up using the 3.3-dev version.

avillacis commented 2 years ago

I have just checked, that if I flash the 2.0.4 bootloader using the 3.3.2-dev version, it works correctly:

$ python /home/alex/.arduino15/packages/esp32/hardware/esp32/2.0.4/tools/esptool.py --chip esp32s3 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size 8MB 0x0  /home/alex/.arduino15/packages/esp32-alternatives/2.0.4/hardware/esp32/2.0.4/tools/sdk/esp32s3/bin/bootloader_dio_80m.bin 
esptool.py v3.3.2-dev
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-S3
Features: WiFi, BLE
Crystal is 40MHz
MAC: 7c:df:a1:e3:c5:20
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00003fff...
Flash params set to 0x023f
Compressed 13936 bytes to 9695...
Wrote 13936 bytes (9695 compressed) at 0x00000000 in 0.4 seconds (effective 286.4 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

The output, however, is a bit different:

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3808,len:0x39c
load:0x403c9700,len:0x9bc
load:0x403cc700,len:0x28dc
SHA-256 comparison failed:
Calculated: 5830b36eadda2ccdc73ac0028cd665f9a0ae0dcfc1ccf372c71f9cc6bad2ccc4
Expected: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Attempting to boot anyway...
entry 0x403c98c0
[   107][I][esp32-hal-psram.c:96] psramInit(): PSRAM enabled
[   118][I][test-BlinkRGB.ino:22] setup(): LED_BUILTIN=97

So, why does the 2.0.4 installation fetch an old version and ends up using that one, when a newer version is available elsewhere?

avillacis commented 2 years ago

Just in case, I checked that my Arduino IDE contains only the URL: https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json for ESP32 tool support, as indicated by the documentation, then re-downloaded 2.0.4, and checked the esptool.py files. They are again, identical to my previous installation.

avillacis commented 2 years ago

While re-downloading the Arduino-ESP32, I noticed in ~/.arduino15/staging/packages/ the following files:

total 624156
-rw-r--r--. 1 alex alex 259715595 jul 13 15:23 esp32-2.0.4.zip
-rw-r--r--. 1 alex alex     97026 jul 13 15:25 esptool-3.3-linux.tar.gz
-rw-r--r--. 1 alex alex     50646 jul 13 15:23 mkspiffs-0.2.3-arduino-esp32-linux64.tar.gz
-rw-r--r--. 1 alex alex 106843321 jul 13 15:24 riscv32-esp-elf-gcc8_4_0-esp-2021r2-patch3-linux-amd64.tar.gz
-rw-r--r--. 1 alex alex     46778 jul 13 15:24 x86_64-linux-gnu.mklittlefs-c41e51a.200706.tar.gz
-rw-r--r--. 1 alex alex  90569312 jul 13 15:24 xtensa-esp32-elf-gcc8_4_0-esp-2021r2-patch3-linux-amd64.tar.gz
-rw-r--r--. 1 alex alex  90894048 jul 13 15:24 xtensa-esp32s2-elf-gcc8_4_0-esp-2021r2-patch3-linux-amd64.tar.gz
-rw-r--r--. 1 alex alex  90903617 jul 13 15:25 xtensa-esp32s3-elf-gcc8_4_0-esp-2021r2-patch3-linux-amd64.tar.gz

There is an esptool.py inside esp32-2.0.4.zip, which, going by the file size, is the 3.3.2-dev version. Additionally, there is another version of esptool.py inside esptool-3.3-linux.tar.gz, which matches the 3.3-dev version.

For now, my workaround to this situation is to move esp32/tools/esptool_py/3.3.0/esptool.py out of the way and replace it with a symlink to esp32/hardware/esp32/2.0.4/tools/esptool.py. After doing this, flashing operations to the ESP32-S3 work as they should.

Jason2866 commented 2 years ago

Well done issue tracking and finding a solution! So i know why i had to adjust my factory firmware generation. With 2.0.3 default values where set. With 2.0.4 there are none. The solution (anyways more correct!) i have done (2.0.4) is to explicit set flash type, size and frequency when building the factory firmware binary. The issue we encountered where finally the same.

ztaylor54 commented 1 year ago

For anyone coming across this issue while using PlatformIO / ESP-IDF, I was able to resolve it by locking esptool to v3.3:

platform_packages = 
  tool-esptoolpy@1.30300.0

Hopefully this will save others some headache.

Jason2866 commented 1 year ago

@ztaylor54 No workarounds needed anymore. Using latest Platformio platform espressif32 solved all this issues.

QnBarb commented 1 year ago

I'm having the same issue, could someone point me to where I can find instruction on how to fix for using Arduino IDE with the ESP32-S3DEVKITC-1? Also, I'm a newb at this. Thank you in advance.

Jason2866 commented 1 year ago

What ESP32-S3DEVKITC-1 exactly do you have? Flash and PSRAM size and type (OPI or QIO)?

QnBarb commented 1 year ago

Hello, I have this model: ESP32­-S3­-DevKitC-1 - ESP32-S3-WROOM-2 - 32MB Flash 8MB PSRAM I read through your advise for the others and changed the flash mode to DIO, now it's without errors but just blank on the serial monitor. I couldn't even flash Hello World.

I received this MCU the other day brand new, plugged it in and saw the RGB blinking, so looked fine. But as soon as I tried to upload an example sketch, it started to do the reboot thing indefinitely. Something about core dump...memory corrupted....

Please advise if I should do a factory reset. If so how? Thank you.

On Wed, Feb 8, 2023, 17:15 Jason2866 @.***> wrote:

What ESP32-S3DEVKITC-1 exactly do you have? Flash and PSRAM size and type (OPI or QIO)?

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6980#issuecomment-1423310704, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4Y3ATWFQ5SXJIVV7QXSUPTWWQLGLANCNFSM53MFV7DA . You are receiving this because you commented.Message ID: @.***>

QnBarb commented 1 year ago

I also changed the partition scheme to 8M with spiffs (I don't know what this is) so now it seems to upload the RGB sketch, but nothing happened. Here is what the monitor shows:

Build:Mar 27 2021

rst:0x15 (USB_UART_CHIP_RESET),boot:0x0 (DOWNLOAD(USB/UART0))

Saved PC:0x40041a76

waiting for download

Please help.

On Wed, Feb 8, 2023 at 5:39 PM Marc Ricoh @.***> wrote:

Hello, I have this model: ESP32­-S3­-DevKitC-1 - ESP32-S3-WROOM-2 - 32MB Flash 8MB PSRAM I read through your advise for the others and changed the flash mode to DIO, now it's without errors but just blank on the serial monitor. I couldn't even flash Hello World.

I received this MCU the other day brand new, plugged it in and saw the RGB blinking, so looked fine. But as soon as I tried to upload an example sketch, it started to do the reboot thing indefinitely. Something about core dump...memory corrupted....

Please advise if I should do a factory reset. If so how? Thank you.

On Wed, Feb 8, 2023, 17:15 Jason2866 @.***> wrote:

What ESP32-S3DEVKITC-1 exactly do you have? Flash and PSRAM size and type (OPI or QIO)?

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6980#issuecomment-1423310704, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4Y3ATWFQ5SXJIVV7QXSUPTWWQLGLANCNFSM53MFV7DA . You are receiving this because you commented.Message ID: @.***>

sjxuereb commented 1 year ago

@QnBarb

I have exactly the same issue. If its of help I noticed that I can upload code from ESP-IDF examples[hello serial] with platformio. So the board is alive and well. I could not get it to work with arduino IDE.

the settings you mentioned in adafruit thread did not work for me either.

ESP32-S3DEVKITC-1-N32R8V (32MB): USB CDC On Boot: Enabled CPU Frequency: 240MHz (WiFi) Core Debug Level: None USB DFU On Boot: Disabled Erase All Flash Before Sketch Upload: Disabled Events Run On: Core 1 Flash Mode: DIO 80MHz Flash Size: 4MB (32Mb) JTAG Adapter: Integrated USB JTAG Arduino Runs On: Core 1 USB Firmware MSC On Boot: Disabled Partition Scheme: Default 4MB with spiffs (1.2MB APP/1.5MB SPIFFS) PSRAM: OPI PSRAM Upload Mode: UART0/Hardware CDC Upload Speed: 921600 USB Mode: Hardware CDC/JTAG

I get this:

ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0x1 (POWERON),boot:0x18 (SPI_FAST_FLASH_BOOT) SPIWP:0xee Octal Flash Mode Enabled For OPI Flash, Use Default Flash Boot Mode mode:SLOW_RD, clock div:1 load:0x3fce3808,len:0x3ac load:0x403c9700,len:0x9bc load:0x403cc700,len:0x27c0 entry 0x403c98c0

I am looking for help as well. Thanks

Jason2866 commented 1 year ago

For OPI flash you have to set boot flash mode to DOUT You have used DIO which will not work. Next fault, flash size 32MB not 4MB. This needs a 32MB partition Scheme!