ESP8266 Developer Zone

Re: Dead ESP

2016-08-04T10:28:56+08:00

Hello guys,

sorry for not open a new topic, but I cannot.

Anyway, i would like to ask who can I fix this error:

Code:

Sketch uses 221,995 bytes (51%) of program storage space. Maximum is 434,160 bytes.
Global variables use 31,568 bytes (38%) of dynamic memory, leaving 50,352 bytes for local variables. Maximum is 81,920 bytes.
C:\Users\root\AppData\Local\Arduino15\packages\esp8266\tools\esptool\0.4.9/esptool.exe -vv -cd ck -cb 115200 -cp COM6 -ca 0x00000 -cf C:\Users\root\AppData\Local\Temp\buildde9605d9d67ae2595f4f5b9646f4a46e.tmp/firstConnection2.ino.bin 
esptool v0.4.9 - (c) 2014 Ch. Klippel 
   setting board to ck
   setting baudrate from 115200 to 115200
   setting port from COM1 to COM6
   setting address from 0x00000000 to 0x00000000
   espcomm_upload_file
   espcomm_upload_mem
   setting serial port timeouts to 1000 ms
opening bootloader
resetting board
trying to connect
   flush start
   setting serial port timeouts to 1 ms
   setting serial port timeouts to 1000 ms
   flush complete
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
   serialport_receive_C0: BB instead of C0
trying to connect
   flush start
   setting serial port timeouts to 1 ms
   setting serial port timeouts to 1000 ms
   flush complete
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
   serialport_receive_C0: 36 instead of C0
trying to connect
   flush start
   setting serial port timeouts to 1 ms
   setting serial port timeouts to 1000 ms
   flush complete
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
   serialport_receive_C0: 36 instead of C0
resetting board
trying to connect
   flush start
   setting serial port timeouts to 1 ms
   setting serial port timeouts to 1000 ms
   flush complete
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
   serialport_receive_C0: BB instead of C0
trying to connect
   flush start
   setting serial port timeouts to 1 ms
   setting serial port timeouts to 1000 ms
   flush complete
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
   serialport_receive_C0: 36 instead of C0
trying to connect
   flush start
   setting serial port timeouts to 1 ms
   setting serial port timeouts to 1000 ms
   flush complete
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
   serialport_receive_C0: 32 instead of C0
resetting board
trying to connect
   flush start
   setting serial port timeouts to 1 ms
   setting serial port timeouts to 1000 ms
   flush complete
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
   serialport_receive_C0: B3 instead of C0
trying to connect
   flush start
   setting serial port timeouts to 1 ms
   setting serial port timeouts to 1000 ms
   flush complete
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
   serialport_receive_C0: 32 instead of C0
trying to connect
   flush start
   setting serial port timeouts to 1 ms
   setting serial port timeouts to 1000 ms
   flush complete
   espcomm_send_command: sending command header
   espcomm_send_command: sending command payload
   serialport_receive_C0: B7 instead of C0
warning: espcomm_sync failed
error: espcomm_open failed
error: espcomm_upload_mem failed
error: espcomm_upload_mem failed

I cannot upload any sketch from arduino IDE and when I open the serial monitor I only see garbage.

Who can I do to fix this problem?

Thanks in advance

Statistics: Posted by luis_filipe — Thu Aug 04, 2016 10:28 am

Re: Dead ESP

2016-08-03T17:49:01+08:00

scargill wrote:
It LOOKs like it was not RBOOT after all..

2. After my initialisation of ports - and other stuff - I finally called a routine to do with WIFI....

wifi_set_opmode(0);

and that was fine until SDK 1.54 - after that - I'm getting no serial output (other than the 78k startup stuff) UNTIL that function is called.

May be you should not use wifi_set_opmode(0); in start up code, because it will do a flash write of settings.

Statistics: Posted by SpenZerX — Wed Aug 03, 2016 5:49 pm

Re: Dead ESP

2016-07-30T01:28:17+08:00

scargill wrote:
..a couple of people wrote into me to say they had killed their boards....
.. I tried the same on 3 new boards of my own - and killed all three...

R.I.P.

do not play with protected area on flash - this is no bug - this is a future -
for more detail, ask your WINBOND dealer.

FYI: if you have the wrong sequence, you kill ( protect ) the flash.
if killed ( protected ) then you can not ( writeable & saved ) flash on this area.

if firmware use protection user key and they crash with RBOOT configs,
then rboot can not boot on the sequence; and if you have the wrong sequence
you can flash new - but your firmware was not written totally - cause -
you have protected area - that can not overriden. ( user key, config key, orig firmware )

please, read data sheets
for I2C Theme: -> I2C
for extended future function -> winbond

then this would help you to understand how you must going on in the future

also, use the search function on the forum,
i have wrote moretimes about protection and firmware protection.
there are possibles ways.

-> protection area on flash
-> protection area on µSDHC ( SDIO ) ..

.. if you boot from µSDHC or load Firmware from µSDHC with combined RBOOT.
you can use a catalog of firmware, that RBOOT can boot/load by reference from µSDHC.
..

regards..

Statistics: Posted by rudi — Sat Jul 30, 2016 1:28 am

Re: Dead ESP

2016-07-25T00:05:18+08:00

It LOOKs like it was not RBOOT after all..

So two problems "solved" - this might be of use to others..

1. I was not blowing the system file at the top of the 4MB on a new board- never had to before SDK 1.54 or thereabouts - now you do!
2. After my initialisation of ports - and other stuff - I finally called a routine to do with WIFI....

wifi_set_opmode(0);

and that was fine until SDK 1.54 - after that - I'm getting no serial output (other than the 78k startup stuff) UNTIL that function is called. Simply moving that to the start of my code fixed it - I've tested this over and over and it is repeatable. NO idea why such a change would be made - assuming it's a bug. Busy checking to see if moving that to the start of my code has any adverse affects - none up to now and Espressif have been very helpful in trying to narrow this down.

Full write-up here.
http://tech.scargill.net/esp8266-home-control-update/

Statistics: Posted by scargill — Mon Jul 25, 2016 12:05 am

Re: Dead ESP

2016-07-21T10:57:43+08:00

The problem I reported in 1.54 is still there in 2.0

RBOOT or rather a program using RBOOT is not booting up correctly. Messages at powerup are not coming up in the right order.

Notice below - some simple informative text at the beginning.. with ~ESP Starting- and about 7 lines down, "Station mode" - this is correct behaviour on 1.53 and previous

ESP Starting...
GPIO4 and 5 are outputs.
Current web programming pin: 2
GPIO13 is a serial RGB LED indicator.
Software version 1.5.2
Use the {debug} command for more information.

STATION mode
Web page control enabled
Connected as 192:168:1:33
MQTT connecting
MQTT Broker connected
Device ID is ARPS_00A68508
-->
Time is 04:51:01 21/07/2016

On SDK 2.0 - same as 1.54, Everything from "ESP Starting" to "Use the {debug} lines are missing - and if the software is flash to a "clean" flash chip - it will not start up.

Statistics: Posted by scargill — Thu Jul 21, 2016 10:57 am

Re: Dead ESP

2016-07-19T00:01:45+08:00

Pleas DO come back to me on this - RBOOT is well used out there - and we put a lot of work into understanding how to use it. It's ok to say the latest version is ok if you use Espressif boot binary - but that's a big learning curve - in software that has worked for many months... I think I'd rather if possible that either RBOOT could be tweaked or the SDK be tweaked - it's not right to make changes that invalidated code that has been out there and stable for a long time. I've a lot of people on the blog using our code as-is and I don't want to tell them things have to change.

Please do let me know, For some reason I'm not getting these responses in email - my email is pete at scargill dot net

Thanks

pratik wrote:
Hello,

I will forward the information to the firmware developers. I suspect rboot uses a simple entry to main code, which has probably changed since the addition of one-time RF calibration feature to the SDK.
The latest release is quite stable if you use Espressif boot binary and associated flash download tools.

I will update the thread when I find any relevant information. Please make sure you are subscribed to notifications.

Statistics: Posted by scargill — Tue Jul 19, 2016 12:01 am

Re: Dead ESP

2016-07-18T12:21:38+08:00

Hello,

I will forward the information to the firmware developers. I suspect rboot uses a simple entry to main code, which has probably changed since the addition of one-time RF calibration feature to the SDK.
The latest release is quite stable if you use Espressif boot binary and associated flash download tools.

I will update the thread when I find any relevant information. Please make sure you are subscribed to notifications.

Statistics: Posted by Guest — Mon Jul 18, 2016 12:21 pm

Re: Dead ESP

2016-07-17T12:25:23+08:00

and yes, I'd included the 1.541 patch of 1st July.

Statistics: Posted by scargill — Sun Jul 17, 2016 12:25 pm

Re: Dead ESP

2016-07-17T04:43:10+08:00

Hi there

I'm a little further on - this ONLY happens with SDK 1.5.4 - return to 1.5.3 and the problem disappears completely. I have an idea that something has changed in 1.5.4 that is making Richard Burton's RBOOT fail given a totally blank FLASH.

It took me a while to come to this conclusion, as running the code with 1.5.4 worked on all my ESP12 boards which already had my code on them. On brand new boards, or a board properly wiped clean with your ESPTOOL - as in the blog below - and the code fails.

If you want to try this - the blog entry details ROMS which are available to test. With a completely blanked FLASH, the 1.5.4 roms will fail every time.. with 1.5.3 (identical code) they work every time. This has all the hallmarks of a RAM location being random at power up - I don't of course know what you have changed in 1.5.4. but Richard's RBOOT code has not changed and has been the same for a long time - several versions of the SDK. I can only conclude that a change in the SDK is causing RBOOT to fail to select the right location for the startup code.

Please read the blog entry - links are there for the ROMS. I hope you can help. I've send an email to Richard also but I suspect it is the SDK that needs a fix.

http://tech.scargill.net/esp-sdk-and-rboot-woes/

Statistics: Posted by scargill — Sun Jul 17, 2016 4:43 am

Re: Dead ESP

2016-07-16T00:15:17+08:00

Hello,

How did you flash the AT software on the ESP-12 modules?
Did you use the official flash download tool (for Windows) downloaded from the Espressif website?
Please post the log produced by that tool in the command prompt style window. It will probably show up what the problem is.
It seems like some jump address is not being programmed properly.

Statistics: Posted by Guest — Sat Jul 16, 2016 12:15 am

Re: Dead ESP

2016-07-15T17:09:24+08:00

Hi there Pratik

Ok, so I'm using the ROMS from my site - www.scargill.net

http://www.scargill.net/rboot.bin
http://www.scargill.net/romx.bin

These should be blown at 0x0000 and 0x2000 respectively. The board should boot up and start looking for an access point at 115k baud. This assumes any ESP-12 or similar module with GPIO2 pulled up with a resistor.

The software is the NodeMCU esp8266flasher.exe

Here is the Windows 64 bit version I used - this is pretty standard software.

https://github.com/nodemcu/nodemcu-flas ... 64/Release

I don't normally use this - I use the Eclipse Windows environment and blow C code - or OTA from these ROMS....

So here's the thing: I used addresses 0x0000000 and 0x2000 and this has now destroyed (apparently) 3 of my boards and a couple of boards for people on the web who use the software.

What you get out of the boards (at 78K )is below - and that's it - they will go no further. I cannot find any way to resurrect the boards up to now. I've tried the usual 512K blank, I've tried putting in the AT software etc... one of my readers suggested that using 0x02000 the boards work - but there is no difference between 0x2000 and 0x02000 - this software normally works absolutely perfectly.

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 212, room 16
tail 4
chksum 0x5e
load 0x3ffe8000, len 788, room 4
tail 0
chksum 0x1c
load 0x3ffe8314, len 72, room 8
tail 0
chksum 0x55
csum 0x55
jump to user1
??j?l

Statistics: Posted by scargill — Fri Jul 15, 2016 5:09 pm

Re: Dead ESP

2016-07-14T12:27:11+08:00

Hello,

This might be a flash issue. If the same happens with an ESP-WROOM-02 module, please let us know.
As for the ESP-12, the flash chip it contains may have programmable write protection, which may be accidentally programmed. That would lock the program in.
But this is more likely a software fault than a hardware issue. Because there are so many solutions online for flashing, and not all are reliable, we always highly recommend that only the official Flash tool be used for programming the ESP8266 modules.

Please provide the relevant UART log file so that the issue can be understood better.

Statistics: Posted by Guest — Thu Jul 14, 2016 12:27 pm

Dead ESP

2016-07-14T06:52:38+08:00

Not sure if you'd describe this as a bug - but I'm hoping it will reach an Espressif engineer or someone really familiar with the devices.

ESP-12 - doesn't really matter which device - but an ESP with 4Meg of RAM.

We have software which uses the SDK - and is now fairly big at just over 0.6 meg. We use Richard Burton's RBOOT.

In the process of updating boards, we have been flashing existing boards - and OTA programming them - no problems at all.

This week, 3 separate people have used the NODEMCU Flasher to flash the .bin files - one at 0x000000 (rboot) and the other at 0x02000

I'm not sure if this REALLY has anything to do with it - but when flashing a board at 0x2000 instead of 0x02000 (I know - they are the same) a couple of people wrote into me to say they had killed their boards. I tried the same on 3 new boards of my own - and killed all three.

The bring up the 78k boot info then go into a loop producing rubbish.

Now - I'm not stupid - I've tried over-writing them - no avail. I've grabbed a 1 MEG empty file (FFFF etc) and tried to blow that into 0x000000, 0x100000, 0x200000 and 0x300000.

The first 3 work, the last one will NOT work... but blowing at 0x2fff000 WILL so for some reason just that last block will not allow programming.

BUT to no avail - having almost completely WIPED the entire FLASH they will will NOT work when you reprogram the boards - I've flashed many hundreds of ESP12 boards and similar and NEVER had this before. Two other readers are the same.

What could we be missing? Is there something OTHER than flash that could be wrong? I'm lost. Ideas? (boards are fine, power supply is well adequate).

Statistics: Posted by scargill — Thu Jul 14, 2016 6:52 am