New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flash read err, 1000 #113

Closed
krzychb opened this Issue Nov 20, 2016 · 28 comments

Comments

Projects
None yet
@krzychb
Collaborator

krzychb commented Nov 20, 2016

Hi,

I see the above message on average 5 out of 6 times when resetting ESP32 DevKitJ board
The whole log with this message looks like below (02_blink example loaded):

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK
>ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3ffc0008,len:0
load:0x3ffc0008,len:1964
load:0x40078000,len:3648
ho 0 tail 12 room 4
load:0x40080000,len:256
entry 0x40080034
I (305) heap_alloc_caps: Initializing heap allocator:
I (306) heap_alloc_caps: Region 19: 3FFB1B9C len 0002E464 tag 0
I (307) heap_alloc_caps: Region 25: 3FFE8000 len 00018000 tag 1
I (317) cpu_start: Pro cpu up.
I (323) cpu_start: Single core mode
I (329) cpu_start: Pro cpu start user code
rtc v118 Oct 19 2016 15:22:11
XTAL 40M
I (368) cpu_start: Starting scheduler on PRO CPU.

The log without message looks as follows:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x16 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3ffc0008,len:0
load:0x3ffc0008,len:1964
load:0x40078000,len:3648
ho 0 tail 12 room 4
load:0x40080000,len:256
entry 0x40080034
I (305) heap_alloc_caps: Initializing heap allocator:
I (306) heap_alloc_caps: Region 19: 3FFB1B9C len 0002E464 tag 0
I (307) heap_alloc_caps: Region 25: 3FFE8000 len 00018000 tag 1
I (317) cpu_start: Pro cpu up.
I (323) cpu_start: Single core mode
I (329) cpu_start: Pro cpu start user code
rtc v118 Oct 19 2016 15:22:11
XTAL 40M
I (368) cpu_start: Starting scheduler on PRO CPU.

Observations:

  1. Massage flash read err, 1000 shows up as well when I erase_flash using esptool.py.
  2. There seem to be no issues with esp-idf examples running on this board (except the message on start up)
  3. Message show up for all examples I tried
  4. I do not see this message on two other boards I have; ESP32 Demo Board V2 and Core Board V2 (aka DevKitC)

Do you think I can troubleshoot something about it?

@projectgus

This comment has been minimized.

Member

projectgus commented Nov 22, 2016

I don't get this on my DevKitJ.

The "flash read err" probably implies the ROM bootloader can't read the bootloader header at 0x1000.

Is it possible the MTDI pin is being pulled down somehow? This will cause the flash voltage regulator to start up with 1.8V output, and maybe it's browning out as a result? As MTDI is configured by the FTDI chip, it may have something to do with the FTDI driver in use.

You can disable the MTDI pin via efuse and force the flash voltage to 3.3V via efuse. There isn't a tool for this yet, but I'm working on it.

@krzychb

This comment has been minimized.

Collaborator

krzychb commented Nov 22, 2016

Hi @projectgus,

Thank you for support with this issue.

This is intermittent error. It shows up on some reboots and on some not. I believe I observed the same on Windows 7 as well as on Ubuntu 16.04 machine

I will follow your MTDI lead and give it a closer look.

Krzysztof

@krzychb

This comment has been minimized.

Collaborator

krzychb commented Nov 23, 2016

I have checked MTDI / GPIO12 and do not see it pulled down.

If I pull it up, then I see module permanently "Falling back to built-in command interpreter" like below:

>ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK
>ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK
>ets Jun  8 2016 00:22:57

My original issue is instantaneous ""Falling back to built-in command interpreter".
After that application resumes and seems to operate normally until another restart when situation repeats.

When testing 06_sntp I have noticed similar issue on another board.
Now I think this is f/w issue rather than failed h/w.
I will enter separate issue report on that as it deals with 06_sntp example itself.

@projectgus

This comment has been minimized.

Member

projectgus commented Dec 22, 2016

@krzychb @igrr was this error narrowed down to being a problem with some DevKitJ hardware?

@igrr

This comment has been minimized.

Member

igrr commented Dec 22, 2016

I haven't been able to reproduce this (as in, after power on reset). I was able to reproduce similar issue after deep sleep reset — it was caused by the fact that read from flash memory was attempted before the flash chip was ready. Flash chip datasheet mentioned at least 1000us delay after power on, we had around 900us of delay. For deep sleep reset, I have added a menuconfig option to delay wakeup, but i don't think we can do anything equivalent for power-on reset.

It is possible that the same thing happens on normal power on reset sometimes. If @krzychb 's board has particular flash chip which needs slightly longer than average to initialize, this can also explain this error. Now, for the first chip revision this error doesn't make any difference — this chip will undergo WDT reset anyway, on the first startup. But this can be a problem for the next chip revision. We may have to select a flash part with shorter initialization time, to be compatible with the delay which exists in the ROM code.

I think this issue can be closed because it isn't an ESP-IDF issue (this happens before the application is loaded), it is something we need to consider when finalizing BOM for new ESP-WROOM modules.

@igrr igrr closed this Dec 22, 2016

@rmahajan95

This comment has been minimized.

rmahajan95 commented May 2, 2017

I am getting the following continuously on the serial monitor after successfully flashing with the ESP-IDF

ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK

ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK
............................................ and goes on.

I am not able to understand and rectify it. A little help would be appreciated.
Thanks in advance.

@benjaminaigner

This comment has been minimized.

benjaminaigner commented May 2, 2017

@rmahajan95

This comment has been minimized.

rmahajan95 commented May 2, 2017

Thanks, @benjaminaigner.
I tried disabling the flash encryption settings and still facing the same issue.
I even tried doing a fresh installation of the toolchain but that too didn't work out :(

I confirmed by reading the addresses through mongoose that the flash is not encrypted yet and I can see the data in plain text.

Any other possibilities you could think of? I am even attaching the screenshot.
capture

Thanks.

@benjaminaigner

This comment has been minimized.

benjaminaigner commented May 2, 2017

Please provide the output from following command:
espefuse.py --port /dev/ttyUSB0 summary
(replace ttyUSB0 if you use a different port)

@rmahajan95

This comment has been minimized.

rmahajan95 commented May 2, 2017

Timed out waiting for the packet header.

capture3

@benjaminaigner

This comment has been minimized.

benjaminaigner commented May 2, 2017

@rmahajan95

This comment has been minimized.

rmahajan95 commented May 2, 2017

COM port seems to be correct because I can flash code successfully. I tried powering it externally and check the serial value through Rx-tx and got the same error. Seems to be a hardware issue.

Anyway, thanks for your Help. I'll bring it up if I find the solution. :)

@benjaminaigner

This comment has been minimized.

benjaminaigner commented May 2, 2017

@dmody

This comment has been minimized.

dmody commented May 19, 2017

I seem to have this problem also. I find it only happens when I'm trying to use wifi. If I remove the code for connecting to wifi, the error does not occur.

Here's the error message I get:
image

@projectgus

This comment has been minimized.

Member

projectgus commented May 19, 2017

@dmody in your case, the code is proceeding past the "flash error" and booting, then printing "hello world", but then it seems to be crashing ("Guru Meditation Error") in some later part of your app. The PC (execution) address is garbage (0xffffffff), so something goes very wrong there after "hello world".

This is probably an issue with your app's code rather than anything else mentioned in this Issue thread.

@projectgus

This comment has been minimized.

Member

projectgus commented May 19, 2017

@rmahajan95 sorry noone got back to you earlier. The code esptool.py uses to connect to the ESP32 for flashing is the same code than espefuse.py uses to connect to the ESP32 to read the efuses, so I'm not sure what the difference is there - something with the hardware setup may be making connection flaky?

@dmody

This comment has been minimized.

dmody commented May 21, 2017

@projectgus Thanks for replying. I get what I think is the same error when the code is one of the example library (i.e. SimpleWiFitServer). See below for error while running that code.

I built the board I'm using by soldering the module (WROOM-32) to a SEEED studio breakout board. I'm powering it with a lab power supply, so I'm sure I have enough power. The FTDI I'm using is only connected to the TXD0 and RXD0 and ground pins. I don't have DTR and RTS connected to IO13 or IO15. Thus I'm not doing anything with the MTDI, it's floating. I tried connecting GPIO12 (MTDI) to Gnd and get the same error. When I connect it to high, I get the repeating error mentioned above by @rmahajan95 .

Is it possible I damaged something in the module when soldering it to the breakout board? How would I check?

Code:
`#include <WiFi.h>

const char* ssid = "{deleted}";
const char* password = "{deleted}";

WiFiServer server(80);

void setup()
{
Serial.begin(115200);
pinMode(2, OUTPUT); // set the LED pin mode

delay(10);

// We start by connecting to a WiFi network

Serial.println();
Serial.println();
Serial.print("Connecting to ");
Serial.println(ssid);

WiFi.begin(ssid, password);

while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
}

Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());

server.begin();

}
`

output from serial monitor

ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK

ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0008,len:8
load:0x3fff0010,len:2036
load:0x40078000,len:9988
load:0x40080000,len:252
entry 0x40080034

Connecting to default
Guru Meditation Error of type InstrFetchProhibited occurred on core 0. Exception was unhandled.
Register dump:
PC : 0xffffff0f PS : 0x00060930 A0 : 0x8008c716 A1 : 0x3ffcf030
A2 : 0x3f400a40 A3 : 0x3ffc72f6 A4 : 0x000000f2 A5 : 0xffffffe8
A6 : 0xfffffff0 A7 : 0x3ffc25a0 A8 : 0xffffff0f A9 : 0x3ffcf040
A10 : 0x00000000 A11 : 0x00000002 A12 : 0x5fff0007 A13 : 0x00000000
A14 : 0x00000000 A15 : 0x00000000 SAR : 0x00000006 EXCCAUSE: 0x00000014
EXCVADDR: 0xffffff0c LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0x00000000

Backtrace: 0x7fffff0f:0x3ffcf030 0x4008c716:0x3ffcf050 0x400896a1:0x3ffcf090 0x4008a615:0x3ffcf0c0 0x4008ade3:0x3ffcf0e0 0x4011136c:0x3ffcf100 0x401114d5:0x3ffcf120 0x400f3983:0x3ffcf140 0x400f39c1:0x3ffcf170 0x400f3f62:0x3ffcf1a0 0x40094746:0x3ffcf1c0

CPU halted

@projectgus

This comment has been minimized.

Member

projectgus commented May 21, 2017

Given the point where it crashes, this feels like a power issue still. Using bare modules requires placing a high value low ESR capacitor near the power pins of the module. Without this, the surge of power when WiFi is initialised will probably cause a momentary voltage drop and brownout.

@rmahajan95

This comment has been minimized.

rmahajan95 commented May 22, 2017

Hi @dmody ,

I was facing a similar issue with another ESP32 while powering only the ESP32 externally but it somehow worked when I connected the external 3.3v common to both ESP32 and USB to serial converter. (I tried it at my own risk but it worked :P)

You might also try erasing the flash completely using the following command after going to the location where your esptool.py exists.

python esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 115200 --before default_reset --after hard_reset erase_flash

The problem which I earlier mentioned was mostly a hardware issue and I had to desolder the ESP32 from the breakout board and replace it with a new one. It is working for me on the same board with the same power supply.

Let us know if anything works out for you.

@dmody

This comment has been minimized.

dmody commented May 22, 2017

@rmahajan95 Thanks for getting back to me. I think I've tracked the problem down, but I'm not sure exactly why it's occurring. I'm putting my solution here in case there's someone else having this problem.

The problem was occurring when I had the module in a breadboard and being powered by a 3.3V regulator, or my lab power supply. I found the voltage on the 3.3 V input pin was dropping below 3V (as low as 2.7V), when I connected the Enable pin to the 3.3V pin. Somehow the EN pin was pulling the voltages down, and that's what I don't understand. I had a 10K resistor from the Enable pin to the 3.3V supply, but it still pulled it down.

I did not have this same problem when I moved the circuit to a perf board, and that's what really had me puzzled. The voltage on the Vin pin on the perf board design is about 3.2 Volts

I thought maybe I had some wires on the breadboard that had high resistance, but I can't seem to find anything. I then eliminated some wires and am powering the 3.3V pin from the voltage regulator with only a single wire. That's brought the 3.3V pin up to about 3.1 Volts and the board is running. So clearly the problem is voltage losses, I just can't seem to identify why.

I hope this is helpful to someone out there suffering the same problem.

@projectgus

This comment has been minimized.

Member

projectgus commented May 22, 2017

It sounds like it may have been the current consumption of the ESP32 itself that was pulling the voltage down. When EN is pulled low, the ESP32 is disabled so it doesn't draw any significant current. Pulling it high turns it on.

Breadboards themselves (especially cheap ones) can have quite high resistance internally inside the breadboard's own connections. Running the power input to the ESP32 across a breadboard connection may cause a significant voltage drop (you can measure by comparing the voltage on each side of the breadboard link.)

@kanalizator

This comment has been minimized.

kanalizator commented Nov 30, 2017

I know it is an old topic, bud the solution is simple. If you are getting:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK
>ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK
>ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK

Then it basicly tells you, it cant read from addres 0x1000, because that is apparently where it looks for bootloader or whatever. The solution is to set this offset when programming, so for my case it was:

esptool.py --port COM6 write_flash 0x1000 C:\esp32\micropython\esp32-20171130-v1.9.2-445-g84035f0f.bin
esptool.py v2.2
Connecting........___
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 936288 bytes to 587495...
Wrote 936288 bytes (587495 compressed) at 0x00001000 in 52.2 seconds (effective 143.5 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting...

And then after opening port at 115000bauds you get:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:4332
load:0x40078000,len:0
load:0x40078000,len:10992
entry 0x4007a6c4
I (204) cpu_start: Pro cpu up.
I (205) cpu_start: Single core mode
I (205) heap_init: Initializing. RAM available for dynamic allocation:
I (208) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (214) heap_init: At 3FFDCD68 len 00003298 (12 KiB): DRAM
I (221) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (227) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (233) heap_init: At 4008FC7C len 00010384 (64 KiB): IRAM
I (240) cpu_start: Pro cpu start user code
I (33) cpu_start: Starting scheduler on PRO CPU.
OSError: [Errno 2] ENOENT
MicroPython v1.9.2-445-g84035f0f on 2017-11-30; ESP32 module with ESP32
Type "help()" for more information.
>>>
@tista3

This comment has been minimized.

tista3 commented Dec 3, 2017

Thank you @kanalizator
I was running esptool with address 0. Changing it to 0x1000 solved the problem.

@foram3

This comment has been minimized.

foram3 commented Jun 27, 2018

I had similar issue, ESP32 hand soldered used with Arduino IDE. By mistake I initialized serial communication twice with different baud rates (i.e. Serial.begin(9600) and Serial.begin(115200)). Just removed one of the initialization and now working perfectly

@X-Ryl669

This comment has been minimized.

X-Ryl669 commented Oct 7, 2018

If you launched make erase_flash after changing the partition.csv, you'll need to flash the bootloader again (make flash does not do that), else the device will not boot anymore with the error stated in the title.

On my computer, the command is: esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 build/bootloader/bootloader.bin

@projectgus

This comment has been minimized.

Member

projectgus commented Oct 7, 2018

after changing the partition.csv, you'll need to flash the bootloader again (make flash does not do that)

Glad you found a solution. For what it's worth, make flash should flash the bootloader, unless the secure boot feature is turned on.

@johncblacker

This comment has been minimized.

johncblacker commented Dec 3, 2018

Following this thread and have same problem. I'm able to use Arduino fine, but I tried using nodemcu firmware and micropython firmware. I seem to get the following with micropython. Also list are fuses.
C:\Users\jobla\AppData\Local\Programs\Python\Python37-32\Scripts>esptool.py.exe -p COM21 -b460800 write_flash -fm dio 0x1000 g:/load/esp32-errata-sw-docs/micropython-firmware/esp8266-20180511-v1.9.4.bin
esptool.py v2.5.1
Serial port COM21
Connecting........_
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse
MAC: 3c:71:bf:84:d5:b4
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0220
Compressed 604872 bytes to 394893...
Wrote 604872 bytes (394893 compressed) at 0x00001000 in 9.5 seconds (effective 511.9 kbit/s)...
Hash of data verified.

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

C:\Users\jobla\AppData\Local\Programs\Python\Python37-32\Scripts>espefuse.py -p COM21 summary
espefuse.py v2.5.1
Connecting........__
Config fuses:
XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 0 R/W (0x0)
XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 0 R/W (0x0)
XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK Override SD_CLK pad (GPIO6/SPICLK) = 0 R/W (0x0)
SPI_PAD_CONFIG_Q Override SD_DATA_0 pad (GPIO7/SPIQ) = 0 R/W (0x0)
SPI_PAD_CONFIG_D Override SD_DATA_1 pad (GPIO8/SPID) = 0 R/W (0x0)
SPI_PAD_CONFIG_HD Override SD_DATA_2 pad (GPIO9/SPIHD) = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0 Override SD_CMD pad (GPIO11/SPICS0) = 0 R/W (0x0)
DISABLE_SDIO_HOST Disable SDIO host = 0 R/W (0x0)

Security fuses:
FLASH_CRYPT_CNT Flash encryption mode counter = 1 R/W (0x1)
FLASH_CRYPT_CONFIG Flash encryption config (key tweak bits) = 0 R/W (0x0)
CONSOLE_DEBUG_DISABLE Disable ROM BASIC interpreter fallback = 1 R/W (0x1)
ABS_DONE_0 secure boot enabled for bootloader = 0 R/W (0x0)
ABS_DONE_1 secure boot abstract 1 locked = 0 R/W (0x0)
JTAG_DISABLE Disable JTAG = 0 R/W (0x0)
DISABLE_DL_ENCRYPT Disable flash encryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_DECRYPT Disable flash decryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_CACHE Disable flash cache in UART bootloader = 0 R/W (0x0)
BLK1 Flash encryption key
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLK2 Secure boot key
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLK3 Variable Block 3
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W

Efuse fuses:
WR_DIS Efuse write disable mask = 0 R/W (0x0)
RD_DIS Efuse read disablemask = 0 R/W (0x0)
CODING_SCHEME Efuse variable block length scheme = 0 R/W (0x0)
KEY_STATUS Usage of efuse block 3 (reserved) = 0 R/W (0x0)

Calibration fuses:
BLK3_PART_RESERVE BLOCK3 partially served for ADC calibration data = 0 R/W (0x0)
ADC_VREF Voltage reference calibration = 1086 R/W (0x12)

Identity fuses:
MAC MAC Address
= 3c:71:bf:84:d5:b4 (CRC 33 OK) R/W
CHIP_VER_REV1 Silicon Revision 1 = 1 R/W (0x1)
CHIP_VERSION Reserved for future chip versions = 2 R/W (0x2)
CHIP_PACKAGE Chip package identifier = 0 R/W (0x0)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).
After flashing with nodemcu 0x00000.bin to 0x00000 and 0x10000 to 0x10000, I get same problem: flash read err, 1000
ets_main.c 371
ets Jund 8 2016 00:22:57

and then it keeps repeating. I've tried hitting enter to no avail.

@projectgus

This comment has been minimized.

Member

projectgus commented Dec 3, 2018

Hi @johncblacker,

FLASH_CRYPT_CNT Flash encryption mode counter = 1 R/W (0x1)

Your ESP32 seems to have flash encryption enabled. It will expect to boot an encrypted image, plaintext images won't work.

I can't understand how this happened because none of the other efuses associated with flash encryption have been burned (ie flash encryption key is all zeroes, FLASH_CRYPT_CONFIG is all zero which is not a recommended configuration, etc.)

Flash encryption enables when FLASH_CRYPT_CNT has an odd number of bits set (up to 7 bits). You can disable it for now using espefuse.py burn_efuse FLASH_CRYPT_CNT to set another bit. This solution won't scale indefinitely, as efuse bits can only be set to 1 not ever to 0, so if you have any idea what enabled flash encryption in the first place then try to avoid it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment