flash read err, 1000 after deep sleep reset #117

Closed
krzychb opened this Issue Nov 23, 2016 · 17 comments

Comments

Projects
None yet
6 participants
@krzychb
Collaborator

krzychb commented Nov 23, 2016

I see this issue on two boards:

  1. ESP-WROVER V1 (aka DevKitJ)
  2. ESP32 Demo Board V2

Application does not retain date and time after wake up from deep sleep and retrieves it from NTP server on each soft restart:

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 (548) heap_alloc_caps: Initializing heap allocator:
I (548) heap_alloc_caps: Region 19: 3FFC16C8 len 0001E938 tag 0
I (550) heap_alloc_caps: Region 25: 3FFE8000 len 00018000 tag 1
I (560) cpu_start: Pro cpu up.
I (565) cpu_start: Starting app cpu, entry point is 0x40080bf8
I (0) cpu_start: App cpu up.
I (581) cpu_start: Pro cpu start user code
rtc v134 Oct 20 2016 12:36:18
XTAL 40M
I (822) phy: phy_version: 246, Nov 18 2016, 17:30:07, 0, 0

I (1252) cpu_start: Starting scheduler on PRO CPU.
I (1254) cpu_start: Starting scheduler on APP CPU.
I (1254) example: Boot count: 1
I (1254) example: Time is not set yet. Connecting to WiFi and getting time over                    NTP.
tcpip_task_hdlxxx : 3ffc6180, prio:18,stack:2048
frc2_timer_task_hdl:3ffc7be4, prio:22, stack:2048
I (1284) wifi: pp_task_hdl : 3ffca444, prio:23, stack:8192
I (1284) example: Setting WiFi configuration SSID sensor-net...
mode : sta(24:0a:c4:00:3f:b6)
I (2904) wifi: n:11 0, o:1 0, ap:255 255, sta:11 0, prof:1
I (3744) wifi: state: 0 -> 2 (b0)
I (4744) wifi: state: 2 -> 0 (2)
I (6074) wifi: n:11 0, o:11 0, ap:255 255, sta:11 0, prof:1
I (6074) wifi: state: 0 -> 2 (b0)
I (6074) wifi: state: 2 -> 3 (0)
I (6074) wifi: state: 3 -> 5 (10)
I (6124) wifi: connected with twc-net-3, channel 11
I (13734) event: ip: 192.168.1.113, mask: 255.255.255.0, gw: 192.168.1.234
I (13734) example: Initializing SNTP
I (13734) example: Waiting for system time to be set... (1/10)
I (15734) example: The current date/time in New York is: Wed Nov 23 14:28:39 2016
I (15734) example: The current date/time in Shanghai is: Thu Nov 24 03:28:39 2016
I (15734) example: Entering deep sleep for 10 seconds
ets Jun  8 2016 00:22:57

rst:0x5 (DEEPSLEEP_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:0x7 (TG0WDT_SYS_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 (548) heap_alloc_caps: Initializing heap allocator:
I (548) heap_alloc_caps: Region 19: 3FFC16C8 len 0001E938 tag 0
I (550) heap_alloc_caps: Region 25: 3FFE8000 len 00018000 tag 1
I (560) cpu_start: Pro cpu up.
I (566) cpu_start: Starting app cpu, entry point is 0x40080bf8
I (0) cpu_start: App cpu up.
I (581) cpu_start: Pro cpu start user code
rtc v134 Oct 20 2016 12:36:18
XTAL 40M
I (830) phy: phy_version: 246, Nov 18 2016, 17:30:07, 0, 0

I (1281) cpu_start: Starting scheduler on PRO CPU.
I (1282) cpu_start: Starting scheduler on APP CPU.
I (1282) example: Boot count: 1
I (1282) example: Time is not set yet. Connecting to WiFi and getting time over NTP.
tcpip_task_hdlxxx : 3ffc6180, prio:18,stack:2048
frc2_timer_task_hdl:3ffc7be4, prio:22, stack:2048
I (1312) wifi: pp_task_hdl : 3ffca444, prio:23, stack:8192
I (1312) example: Setting WiFi configuration SSID sensor-net...
mode : sta(24:0a:c4:00:3f:b6)
I (2932) wifi: n:11 0, o:1 0, ap:255 255, sta:11 0, prof:1
I (3772) wifi: state: 0 -> 2 (b0)
I (3772) wifi: state: 2 -> 3 (0)
I (3782) wifi: state: 3 -> 5 (10)
I (3822) wifi: connected with twc-net-3, channel 11
I (11732) event: ip: 192.168.1.113, mask: 255.255.255.0, gw: 192.168.1.234
I (11732) example: Initializing SNTP
I (11732) example: Waiting for system time to be set... (1/10)
I (13732) example: The current date/time in New York is: Wed Nov 23 14:29:02 2016
I (13732) example: The current date/time in Shanghai is: Thu Nov 24 03:29:02 2016
I (13732) example: Entering deep sleep for 10 seconds
ets Jun  8 2016 00:22:57

rst:0x5 (DEEPSLEEP_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

Module continue to soft restart from deep sleep and each time retrieving date and time from NTP instead of internal RTC.

Please see another behaviour of this application reported under #116.

@igrr igrr changed the title from Example "06_sntp" does not retain time after wake up from deep sleep to flash read err, 1000 after deep sleep reset Nov 24, 2016

@igrr

This comment has been minimized.

Show comment
Hide comment
@igrr

igrr Nov 24, 2016

Member

It may be that we are leaving flash HW in some random state when going into deep sleep. I can't reproduce this here, but will watch out for it in case it happens.

Member

igrr commented Nov 24, 2016

It may be that we are leaving flash HW in some random state when going into deep sleep. I can't reproduce this here, but will watch out for it in case it happens.

@igrr

This comment has been minimized.

Show comment
Hide comment
Member

igrr commented Dec 4, 2016

@igrr

This comment has been minimized.

Show comment
Hide comment
@igrr

igrr Dec 12, 2016

Member

We have found that the problem is related to placing external flash chip into power down mode. We haven't found the root cause so far. The workaround is to disable flash power down by setting a register before going into deep sleep mode:

    SET_PERI_REG_MASK(RTC_CNTL_SDIO_CONF_REG, RTC_CNTL_XPD_SDIO_REG_M);
    SET_PERI_REG_MASK(RTC_CNTL_SDIO_CONF_REG, RTC_CNTL_SDIO_FORCE_M);

This will disable flash power-down in deep sleep mode. Current consumption will obviously be higher...

We're looking into this, I will update this issue once we figure out why flash power down is causing problems.

Member

igrr commented Dec 12, 2016

We have found that the problem is related to placing external flash chip into power down mode. We haven't found the root cause so far. The workaround is to disable flash power down by setting a register before going into deep sleep mode:

    SET_PERI_REG_MASK(RTC_CNTL_SDIO_CONF_REG, RTC_CNTL_XPD_SDIO_REG_M);
    SET_PERI_REG_MASK(RTC_CNTL_SDIO_CONF_REG, RTC_CNTL_SDIO_FORCE_M);

This will disable flash power-down in deep sleep mode. Current consumption will obviously be higher...

We're looking into this, I will update this issue once we figure out why flash power down is causing problems.

@igrr igrr closed this in eac80b0 Dec 16, 2016

@seopyoon

This comment has been minimized.

Show comment
Hide comment
@seopyoon

seopyoon Jan 20, 2017

One of my chips is suddenly behaving this way.

flash read err, 1000
Falling back to built-in command interpreter.
OK
>ets Jun  8 2016 00:22:57
----- repeats -----

Any solution to revive this dev kit? It is the DevC board.

One of my chips is suddenly behaving this way.

flash read err, 1000
Falling back to built-in command interpreter.
OK
>ets Jun  8 2016 00:22:57
----- repeats -----

Any solution to revive this dev kit? It is the DevC board.

@Spritetm

This comment has been minimized.

Show comment
Hide comment
@Spritetm

Spritetm Jan 20, 2017

Member

Do you maybe have something that forces GPIO12 to a certain level?

Member

Spritetm commented Jan 20, 2017

Do you maybe have something that forces GPIO12 to a certain level?

@seopyoon

This comment has been minimized.

Show comment
Hide comment
@seopyoon

seopyoon Jan 20, 2017

@Spritetm nope. Nothing is connected to it. But perhaps something went wrong in circuit level?? Would manually pulling it LOW or HIGH fix the issue??

@Spritetm nope. Nothing is connected to it. But perhaps something went wrong in circuit level?? Would manually pulling it LOW or HIGH fix the issue??

@Spritetm

This comment has been minimized.

Show comment
Hide comment
@Spritetm

Spritetm Jan 20, 2017

Member

I think it should be HIGH on power-up, to select 3.3V.

Member

Spritetm commented Jan 20, 2017

I think it should be HIGH on power-up, to select 3.3V.

@seopyoon

This comment has been minimized.

Show comment
Hide comment
@seopyoon

seopyoon Jan 20, 2017

It is LOW, when I check the pin-outs on the DevKitC board. It suddenly behaves this way. Could this be a S/W fault??

It is LOW, when I check the pin-outs on the DevKitC board. It suddenly behaves this way. Could this be a S/W fault??

@projectgus

This comment has been minimized.

Show comment
Hide comment
@projectgus

projectgus Jan 20, 2017

Member

It can be a software fault if the software bootloader (flashed at 0x1000) is somehow invalid (not a format the ROM bootloader recognised as bootable).

You can run an esptool.py -fm dio verify_flash 0x1000 build/bootloader/bootloader.bin to make very sure the data at rest hasn't changed (it's read back and verified after writing, so it shouldn't change, but I have noticed that it might if there are power stability problems while flashing something else later on.)

Member

projectgus commented Jan 20, 2017

It can be a software fault if the software bootloader (flashed at 0x1000) is somehow invalid (not a format the ROM bootloader recognised as bootable).

You can run an esptool.py -fm dio verify_flash 0x1000 build/bootloader/bootloader.bin to make very sure the data at rest hasn't changed (it's read back and verified after writing, so it shouldn't change, but I have noticed that it might if there are power stability problems while flashing something else later on.)

@seopyoon

This comment has been minimized.

Show comment
Hide comment
@seopyoon

seopyoon Jan 20, 2017

dear @projectgus

I get the following (not sure if I ran the command correctly. It is a bit different from what you suggested, for it threw error message when I copy-pasted):

python esptool.py -p /dev/tty.SLAB_USBtoUART verify_flash 0x1000 ~/Developer/EmbeddedProjects/blufi/build/bootloader/bootloader.bin
esptool.py v2.0-dev
Connecting...
Detecting chip type... ESP32
Uploading stub...
Running stub...
Stub running...
Verifying 0x2bd0 (11216) bytes @ 0x00001000 in flash against /Users/seopyoon/Developer/EmbeddedProjects/blufi/build/bootloader/bootloader.bin...
-- verify FAILED (digest mismatch)

A fatal error occurred: Verify failed.

seopyoon commented Jan 20, 2017

dear @projectgus

I get the following (not sure if I ran the command correctly. It is a bit different from what you suggested, for it threw error message when I copy-pasted):

python esptool.py -p /dev/tty.SLAB_USBtoUART verify_flash 0x1000 ~/Developer/EmbeddedProjects/blufi/build/bootloader/bootloader.bin
esptool.py v2.0-dev
Connecting...
Detecting chip type... ESP32
Uploading stub...
Running stub...
Stub running...
Verifying 0x2bd0 (11216) bytes @ 0x00001000 in flash against /Users/seopyoon/Developer/EmbeddedProjects/blufi/build/bootloader/bootloader.bin...
-- verify FAILED (digest mismatch)

A fatal error occurred: Verify failed.
@projectgus

This comment has been minimized.

Show comment
Hide comment
@projectgus

projectgus Jan 20, 2017

Member

My mistake, you need the -fm dio argument but it goes after verify_flash rather than before.

If you add --diff yes also, you'll get a summary of which bytes are different.

One last possibility, is it possible flash encryption was somehow enabled on your module? You can check with espefuse.py summary, look at the number next to FLASH_CRYPT_CNT (should be zero.) Would only be enabled if the menuconfig option had been set.

Member

projectgus commented Jan 20, 2017

My mistake, you need the -fm dio argument but it goes after verify_flash rather than before.

If you add --diff yes also, you'll get a summary of which bytes are different.

One last possibility, is it possible flash encryption was somehow enabled on your module? You can check with espefuse.py summary, look at the number next to FLASH_CRYPT_CNT (should be zero.) Would only be enabled if the menuconfig option had been set.

@seopyoon

This comment has been minimized.

Show comment
Hide comment
@seopyoon

seopyoon Jan 23, 2017

@projectgus verify_flash verified to be OK. (Though, again, -fm dio didn't work. I ran, python ~/Developer/esp-sdk/esp-idf/components/esptool_py/esptool/esptool.py -p /dev/tty.SLAB_USBtoUART verify_flash --diff yes 0x1000 build/bootloader/bootloader.bin instead).

But, when I ran, espefuse.py summary, I got, FLASH_CRYPT_CNT Flash encryption mode counter = 1 R/W (0x1). This, as you mentioned above, should have been set to 0. While my co-worker was working on this chip, he must have set this somewhere, somehow... How do I 'unset' this?? Or, how can I make it 'flashable' again?

Thanks in advance.

seopyoon commented Jan 23, 2017

@projectgus verify_flash verified to be OK. (Though, again, -fm dio didn't work. I ran, python ~/Developer/esp-sdk/esp-idf/components/esptool_py/esptool/esptool.py -p /dev/tty.SLAB_USBtoUART verify_flash --diff yes 0x1000 build/bootloader/bootloader.bin instead).

But, when I ran, espefuse.py summary, I got, FLASH_CRYPT_CNT Flash encryption mode counter = 1 R/W (0x1). This, as you mentioned above, should have been set to 0. While my co-worker was working on this chip, he must have set this somewhere, somehow... How do I 'unset' this?? Or, how can I make it 'flashable' again?

Thanks in advance.

@seopyoon

This comment has been minimized.

Show comment
Hide comment
@seopyoon

seopyoon Jan 23, 2017

FLASH_CRYPT_CNT        Flash encryption mode counter                     = 1 R/W (0x1)
FLASH_CRYPT_CONFIG     Flash encryption config (key tweak bits)          = 15 R/W (0xf)
CONSOLE_DEBUG_DISABLE  Disable ROM BASIC interpreter fallback            = 0 R/W (0x0)
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                                      = 1 R/W (0x1)
DISABLE_DL_ENCRYPT     Disable flash encryption in UART bootloader       = 1 R/W (0x1)
DISABLE_DL_DECRYPT     Disable flash decryption in UART bootloader       = 1 R/W (0x1)
DISABLE_DL_CACHE       Disable flash cache in UART bootloader            = 1 R/W (0x1)
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 -/- 
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                          = 128 R/W (0x80)
RD_DIS                 Efuse read disablemask                            = 1 R/W (0x1)
CODING_SCHEME          Efuse variable block length scheme                = 0 R/W (0x0)
KEY_STATUS             Usage of efuse block 3 (reserved)                 = 0 R/W (0x0)

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)

Above is what I get as the summary. Very different from a working chip, where all the values are zero.

FLASH_CRYPT_CNT        Flash encryption mode counter                     = 1 R/W (0x1)
FLASH_CRYPT_CONFIG     Flash encryption config (key tweak bits)          = 15 R/W (0xf)
CONSOLE_DEBUG_DISABLE  Disable ROM BASIC interpreter fallback            = 0 R/W (0x0)
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                                      = 1 R/W (0x1)
DISABLE_DL_ENCRYPT     Disable flash encryption in UART bootloader       = 1 R/W (0x1)
DISABLE_DL_DECRYPT     Disable flash decryption in UART bootloader       = 1 R/W (0x1)
DISABLE_DL_CACHE       Disable flash cache in UART bootloader            = 1 R/W (0x1)
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 -/- 
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                          = 128 R/W (0x80)
RD_DIS                 Efuse read disablemask                            = 1 R/W (0x1)
CODING_SCHEME          Efuse variable block length scheme                = 0 R/W (0x0)
KEY_STATUS             Usage of efuse block 3 (reserved)                 = 0 R/W (0x0)

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)

Above is what I get as the summary. Very different from a working chip, where all the values are zero.

@seopyoon

This comment has been minimized.

Show comment
Hide comment
@seopyoon

seopyoon Jan 25, 2017

@projectgus please help me 'undo' the encryption!

@projectgus please help me 'undo' the encryption!

@projectgus

This comment has been minimized.

Show comment
Hide comment
@projectgus

projectgus Jan 26, 2017

Member

It looks like at some point flash encryption was definitely enabled! Steps to reverse:

  1. Go into menuconfig -> Security Features and disable "Enable flash encryption on boot". If you don't do this then disabling flash encryption will just cause it to re-enable (the first 4 times, after that it's done!) All the options in this menu should be kept turned off, unless you want to enable these kind of security features (and have read the relevant docs.)
  2. Run espsecure.py burn_efuse FLASH_CRYPT_CNT. This will increase the flash encryption count from "1" to "3". The number of bits set in this efuse determines whether flash encryption is on (odd = on, even = off.)
  3. make flash monitor and the ESP32 should flash and then boot correctly.

For more about how flash encryption works, see the docs here:
http://esp-idf.readthedocs.io/en/latest/security/flash-encryption.html

Member

projectgus commented Jan 26, 2017

It looks like at some point flash encryption was definitely enabled! Steps to reverse:

  1. Go into menuconfig -> Security Features and disable "Enable flash encryption on boot". If you don't do this then disabling flash encryption will just cause it to re-enable (the first 4 times, after that it's done!) All the options in this menu should be kept turned off, unless you want to enable these kind of security features (and have read the relevant docs.)
  2. Run espsecure.py burn_efuse FLASH_CRYPT_CNT. This will increase the flash encryption count from "1" to "3". The number of bits set in this efuse determines whether flash encryption is on (odd = on, even = off.)
  3. make flash monitor and the ESP32 should flash and then boot correctly.

For more about how flash encryption works, see the docs here:
http://esp-idf.readthedocs.io/en/latest/security/flash-encryption.html

@seopyoon

This comment has been minimized.

Show comment
Hide comment
@seopyoon

seopyoon Jan 26, 2017

Thank you! @projectgus It has been undone. I shall be careful.

Thank you! @projectgus It has been undone. I shall be careful.

@ilioss

This comment has been minimized.

Show comment
Hide comment
@ilioss

ilioss Jul 3, 2017

Good day,
As user of a esp32 I run into the same problem flash read err, 1000.
The esp32 I use for the Edzelf internetradio. As can be found on github. A really nice project.
With this fault it looks like the software is not working as it should be.
This article is related to this flash error. But as far as I understand it is for linux? Is this correct?
My question is is there a procedure to reset the encryption parameter which causes this error for windows7?
I have installed the esptool.py in my hardware folder.
The problem I faces is that the internet radio is not responding correct on instructions. I can immagine that this must have worked correct by the authr of the internetradio. So I will correct the encription parameter to (0) zero.
Like to hear,
Kind regards,
Theo
ps I uses the arduino ide for flashing my esp32 devkit (DOIT)

ilioss commented Jul 3, 2017

Good day,
As user of a esp32 I run into the same problem flash read err, 1000.
The esp32 I use for the Edzelf internetradio. As can be found on github. A really nice project.
With this fault it looks like the software is not working as it should be.
This article is related to this flash error. But as far as I understand it is for linux? Is this correct?
My question is is there a procedure to reset the encryption parameter which causes this error for windows7?
I have installed the esptool.py in my hardware folder.
The problem I faces is that the internet radio is not responding correct on instructions. I can immagine that this must have worked correct by the authr of the internetradio. So I will correct the encription parameter to (0) zero.
Like to hear,
Kind regards,
Theo
ps I uses the arduino ide for flashing my esp32 devkit (DOIT)

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