flash read err, 1000 (IDFGH-807) #113
Comments
|
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. |
|
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 |
|
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: My original issue is instantaneous ""Falling back to built-in command interpreter". When testing |
|
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. |
|
I am getting the following continuously on the serial monitor after successfully flashing with the ESP-IDF
rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT) I am not able to understand and rectify it. A little help would be appreciated. |
|
Hi,
this error is mostly related to wrong flash encryption settings.
Please try to disable flash encryption:
https://esp-idf.readthedocs.io/en/latest/security/flash-encryption.html
IMPORTANT: read the docs carefully, flash encryption can't be
en-/disabled unlimited...
Best regards
…On 02/05/17 09:26, rmahajan95 wrote:
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.
|
|
Thanks, @benjaminaigner. 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. Thanks. |
|
Please provide the output from following command: |
|
Timed out waiting for the packet header.
|
|
Ok, if you are sure that ttyUSB0 is the correct ESP32 port,
than I can't help you :-(.
I would suggest either a hardware fault or a unstable power supply.
@espressif please advise
…On 02/05/17 14:25, rmahajan95 wrote:
Timed out waiting for the packet header.
<img width="367" alt="capture3" src="https://cloud.githubusercontent.com/assets/28288402/25617528/58055f2a-2f60-11e7-85b4-29dd6e4ec7cc.PNG">
|
|
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. :) |
|
I had the same issue, I already replaced the flash chip before I read
the manual carefully enough :-)
Good luck, sry I can't help you (especially if it is possible to flash
the code, but impossible to read the fuses...)
…On 02/05/17 16:43, rmahajan95 wrote:
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. :)
|
|
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: |
|
@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. |
|
@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? |
|
@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: const char* ssid = "{deleted}"; WiFiServer server(80); void setup() } output from serial monitor ets Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) Connecting to default 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 |
|
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. |
|
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. |
|
@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. |
|
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.) |
|
I know it is an old topic, bud the solution is simple. If you are getting: 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: And then after opening port at 115000bauds you get: |
|
Thank you @kanalizator |
|
@X-Ryl669 All types of memory are reset following esp_restart (although esp_restart itself is not responsible for this):
It is possible to have uninitialized variables (usually on the stack) but they will contain values from previous function calls that used the same stack area, not the values before system restart. |
|
Hello, I have the same issue on a board with ESP32-WROVER-B. I understand the flash in the WROVER-B is 3.3V and I have used efuse to maintain voltage as 3.3V. Prior to the reset, the following are the status of the strapping pins Would appreciate any directions to resolve this. |
|
Hi @aizukanne , Thanks for providing these details. When you say "any reset after that results in this error.", do you mean software resets via esp_restart() only, or also resets of other kinds (esptool.py programming resets, etc)? |
|
Perhaps this is a timing issue? If, when programming the flash, the code doesn't check and wait until write-in-progress (WIP) is clear before doing a reset, the flash may not be ready to be read when boot wants to read. For a typical SPI flash, a page program may take 2-3 ms to complete. I'd think that adding a 3 ms delay before doing a reset after a flash program can't hurt - no one can reasonably expect reboot timing to be that tight That could also explain why the issue isn't consistent - it may depend on how long the reset process delays a restart, and a software reset is going to be faster than any reliable hardware one. A longer reset would give the flash time to complete and be ready to be read. But, maybe I'm way off base - just an idea based on my limited knowledge of the gory details. I can only say that I've run into this issue when doing OTA programming, and the comment about uninitialized variables is off-target - the problem stops a proper boot before my code gets a chance to run. I will add that it doesn't happen often, it was a happy circumstance that I caught in on the serial monitor. |
Any reset both software or by pressing a button which pulls EN low. If the esptool.py is run without |
|
Hi @mike-s123 & @aizukanne ,
This is a good idea but I don't think so. All the flash write functions check this flag, and moreover after the OTA write completes, the ESP32 goes back to executing code stored in flash cache - so probably at least a few KB of executable code has been read from flash and executed by the time esp_restart() is called. EDIT: Actually... maybe not, because esp_restart() is in IRAM and if the bit of code that ran the OTA is already in the cache then it's not impossible that the chip finishes the update and then the next line of code restarts, without it needing to read anything new from flash. Probably adding some code in between the two steps, even just If you think it's a timing issue then it may be worth adding a short delay before calling esp_restart() anyhow, just to rule this in or out.
That is quite unexpected, especially as esptool.py Given you both have WROVER-B modules, this seems like it might be something with the 16MB flash chip model. I'll follow this up with the hardware team and get back to you. |
|
@aizukanne Is the only way to recover your module also a power cycle? |
Except timing. For how long does esptool(.py) hold EN low?
If that were the case, why is the boot ROM complaining that it can't read from flash? It can't have its cake, and eat it too! |
Some other things happen during reset and early startup, so it's not impossible. But it's a good question. I made an edit above about a possible sequence of events, though. Do you have an example of your Arduino code that does the OTA update and then restarts, triggering this problem? Can either of you also please post the full output of |
I am unable to recover from this error. However this only occurs when I load Pycom's version of micropython. With Arduino it works ok. No loss of data.
|
|
@aizukanne Thanks for the details. Confused by "I am unable to recover from this error", do you mean that you have an ESP32 board that is permanently bricked? Or does removing power and re-connecting power bring it back? |
When this happens, I am not able to get the device to boot up again. If i flash the firmware again, it works until it is reset. I have been battling with this for a few days now. |
|
I have an esp32 that operated normally for 2 days doing 12h sleeps and then bricked with same symptoms. Common aspect -it was aslo flashed with micropython. |
|
i am facing the same problem also.. i am having esp32 devkit v1... its showing A fatal error occurred: Timed out waiting for packet content |
|
|
This seems like your flash chip is toasted. |
|
NO I HAVENOT CONNECTED ANYTHING |
|
IS THIS A HARDWARE ISSUE? PLEASE LET ME KNOW ABOUT THIS PROBLEM ASAP.. I HAVE ALREADY WASTED MUCH TIME FOR FIXING THIS ISSUE BT WITHOUT ANY SOLUTION |
|
Hi @ritwik123 Please stop posting in all caps and copying the same content onto multiple issues. I've replied to you here: espressif/esptool#394 (comment) . |
|
My problem was that i was using an older IDF template project in the latest ESP-IDF. I get the same error due to ROM bootloader can't find the software bootloader at offset 0x1000. Below is my log and solution, `W (909) phy_init: failed to load RF calibration data (0x1102), falling back to full calibration rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) Solution: Enable 'App compatible with bootloaders before IDF v2.1' option in Ref: https://www.esp32.com/viewtopic.php?t=3939 PS: This error threw only if i use bluetooth, Otherwise it worked fine. |
|
if you error look like this 1.Run "idf.py menuconfig" , select "Security features" 6.Run "python esptool.py --chip esp32 --port com5 --baud 115200 --before default_reset --after hard_reset erase_flash" 7.Run "python espefuse.py -p com5 burn_efuse FLASH_CRYPT_CNT" Sorry for my poor English . |
|
Hi @CJ0104 , Thanks for the advice but please note that Before running these steps run the command "espefuse.py -p PORT summary" and check the value of FLASH_CRYPT_CNT.
|
|
Thank you .
I'm so sorry about my comment.
I will try your advice.
Thank you so much.
And sorry for my poor English.
Angus Gratton <notifications@github.com> 於 2020年1月23日 週四 06:59 寫道：
… Hi @CJ0104 <https://github.com/CJ0104> ,
Thanks for the advice but please note that *flash read err, 1000 can have
difference causes and following these steps may break the board not fix it*
.
Before running these steps run the command "espefuse.py -p PORT summary"
and check the value of FLASH_CRYPT_CNT.
- If FLASH_CRYPT_CNT value is 0, the error is unrelated to flash
encryption and these steps might make it worse not better (by enabling
flash encryption for no reason).
- If FLASH_CRYPT_CNT value is non-zero, following these steps may help
by disabling flash encryption that was previously enabled via efuse but is
not working correctly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#113?email_source=notifications&email_token=AMVGBTKSICMSYGADU7YMQPDQ7DFULA5CNFSM4CW6RYH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJVNGGI#issuecomment-577426201>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMVGBTPOGNSV3DA6ZBWDUY3Q7DFULANCNFSM4CW6RYHQ>
.
|
|
I have tried changng fuses on these and don't recommend doin it because there's no way back if you screw up!
Get BlueMail for Android
…On Jan 22, 2020, 7:09 PM, at 7:09 PM, CJ0104 ***@***.***> wrote:
Thank you .
I'm so sorry about my comment.
I will try your advice.
Thank you so much.
And sorry for my poor English.
Angus Gratton ***@***.***> 於 2020年1月23日 週四 06:59 寫道：
> Hi @CJ0104 <https://github.com/CJ0104> ,
>
> Thanks for the advice but please note that *flash read err, 1000 can
have
> difference causes and following these steps may break the board not
fix it*
> .
>
> Before running these steps run the command "espefuse.py -p PORT
summary"
> and check the value of FLASH_CRYPT_CNT.
>
> - If FLASH_CRYPT_CNT value is 0, the error is unrelated to flash
> encryption and these steps might make it worse not better (by
enabling
> flash encryption for no reason).
> - If FLASH_CRYPT_CNT value is non-zero, following these steps may
help
> by disabling flash encryption that was previously enabled via
efuse but is
> not working correctly.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
>
<#113?email_source=notifications&email_token=AMVGBTKSICMSYGADU7YMQPDQ7DFULA5CNFSM4CW6RYH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJVNGGI#issuecomment-577426201>,
> or unsubscribe
>
<https://github.com/notifications/unsubscribe-auth/AMVGBTPOGNSV3DA6ZBWDUY3Q7DFULANCNFSM4CW6RYHQ>
> .
>
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#113 (comment)
|
|
One of the major problems with "fuses" is that changing the security fuse just adds 1 to the current value; then, when it's checked if it's an even number it means one thing and odd another. You cannot input a specific value for the security fuse (unless they've changed things recently). |
|
I was getting after only running |
|
rst:0x10 (RTCWDT_RTC_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) I am getting this error in my esp32 devkit v1 |
Hi, where can I enable this under PlatformIO? Appreciate it |
and others
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):
The log without message looks as follows:
Observations:
flash read err, 1000shows up as well when Ierase_flashusing esptool.py.Do you think I can troubleshoot something about it?
The text was updated successfully, but these errors were encountered: