Dead ESP

[scargill]

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).

[pratik]

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.

[scargill]

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

[pratik]

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.

[scargill]

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/

[scargill]

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

[pratik]

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.

[scargill]

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

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.

[scargill]

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.

[scargill]

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/