I'm trying to flash anything at all onto a module that's been used for a number of things, but after erasing the flash and then flashing the esp32 core, I open a terminal to the COM port and see:
rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57
repeated over and over.
I've used the Espressif flash tool to erase, and get the same response whether I flash the module or just erase it.
Just curious if I've somehow bricked this and need a new one.
Thanks,
Paul
Is this the response of a "bricked" module?
-
- Posts: 12
- Joined: Thu Dec 06, 2018 4:03 am
Re: Is this the response of a "bricked" module?
Hi Paul,
This error indicates whatever is found at offset 0x1000 doesn't look like a valid bootloader image. There are three possible explanations for this:
1. A valid bootloader isn't flashed at offset 0x1000. This can be corrected by reflashing a valid bootloader at offset 0x1000 (ESP-IDF, arduino-esp32, and other software environments will all include a bootloader).
2. Flash encryption is enabled. You can check this by running "espefuse.py summary" and looking at the value of FLASH_CRYPT_CNT efuse. If it is non-zero and an odd number of bits are set, flash encryption is enabled. In this case, the ESP32 expects to see an encrypted bootloader.
3. There is some hardware problem with the flash chip, or the ESP32 GPIO pins which are connected to the flash chip. If esptool.py succeeds and its output indicates "Hash of data verified" then this reason is unlikely.
This error indicates whatever is found at offset 0x1000 doesn't look like a valid bootloader image. There are three possible explanations for this:
1. A valid bootloader isn't flashed at offset 0x1000. This can be corrected by reflashing a valid bootloader at offset 0x1000 (ESP-IDF, arduino-esp32, and other software environments will all include a bootloader).
2. Flash encryption is enabled. You can check this by running "espefuse.py summary" and looking at the value of FLASH_CRYPT_CNT efuse. If it is non-zero and an odd number of bits are set, flash encryption is enabled. In this case, the ESP32 expects to see an encrypted bootloader.
3. There is some hardware problem with the flash chip, or the ESP32 GPIO pins which are connected to the flash chip. If esptool.py succeeds and its output indicates "Hash of data verified" then this reason is unlikely.
-
- Posts: 12
- Joined: Thu Dec 06, 2018 4:03 am
Re: Is this the response of a "bricked" module?
Thanks for the info Angus, that gives me a path to hunt down
Who is online
Users browsing this forum: iParcelBox and 106 guests