**SOLVED** Has anyone else experienced "flakey" uploads? (ESPtool.exe is broken) - read to bottom

[tim-in-oakton]

My config is as follows:

• ESP8266 -03 modules
• Regulated 3.3v supply - arduino style battery input/USB regulator thing
• 3.3v FTDI USB:serial converter

On my first module I successfully compiled and uploaded maybe 500 times - occasionally I would need to upload twice if the first upload failed to execute correctly. This got worse over time, it seemed like restarting the Arduino IDE and rebooting my PC was some help (hard to prove, it was intemittent). I did try to reflash with a minimal sketch as well, that didn't really seem to help.
The program is a datalogging app for a Beer Keg - maybe 1000 lines of code or so. Not very big.

Recently it got harder & harder to get a "good" upload (I used the serial monitor & wireless behavior to confirm if it was "working"). This morning I was completely unable to get an upload to work - the upload using the Arduino IDE would complete with no errors, but the uploaded executable image would not execute.

Using the Python ESPTool uploader, I was able to "erase" the flash, but not upload the 512K "blank" file - it would consistenly fail at 32% (hex800000).
I replaced the ESP module with another, the FIRST upload worked fine and executed perfectly, when I made a minor change to the code however it would upload with no errors but not execute. Frustrating.

The IDE reports:
Sketch uses 205,912 bytes (39%) of program storage space. Maximum is 524,288 bytes.
warning: unsupported baud rate: 115200, using 115200
Uploading 38112 bytes from C:\Users\timm\AppData\Local\Temp\build7944810091012342573.tmp/Kegerator-v4.3.cpp_00000.bin to flash at 0x00000000
......................................
Uploading 167848 bytes from C:\Users\timm\AppData\Local\Temp\build7944810091012342573.tmp/Kegerator-v4.3.cpp_40000.bin to flash at 0x00040000
....................................................................................................................................................................

I will try to upgrade the power supply to something I trust more than an off-brand Arduino-style regulator, but is this something that others have seen? Are there any tricks to reliable upload&execute?

I am using the 1.6.3 IDE with a GIT pull from maybe 2 weeks ago - have there been any changes to the upload functionality or to the linker directives?

Any thoughts? Not sure if I have a bug or a PEBCAK issue- are there any known "gotchas" to be aware of that complicate uploading?
thanks!
tim

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[tim-in-oakton]

I forgot to specify - Windows build, will try a fresh clone tonight-

[duncan-a]

Hi

I'm now having issues like this too. Everything was fine but now it appears
to upload successfully, then nothing except 'gobbledygook' on the serial
monitor.

From what little I've been able to understand, the 'gobbledygook' is a
bootloader message at 76800 baud - but I don't have that as a baud rate
option for the serial monitor.

It's not the PSU - have tried 3 and they're all 3.3 +/- 0.03V.
It's not the FTDI Friend that I'm using as USB to Serial - that works fine
with an Arduino Pro Mini 3.3V.
The wiring hasn't changed - Vcc, CH_PD and RST (via 1K) to 3V3, GND to 0V,
ESP Rx to FTDI Tx, ESP Tx to FTDI Rx).
The method remains the same - ground GPIO0, ground and release RST, release
GPIO0, upload, ground and release RST.
It's the same problem with all modules - ESP-01 and Olimex.

I'm running Windows XP with the 1.6.1-p1 release from GitHub (I can't
fathom out all the 'pull', 'fork' and everything else to do it any other
way). I've tried closing down the IDE and restarting and I've tried hard
rebooting the laptop.

There's an occasional "4j - Error when starting" type error when I restart
the IDE but that doesn't appear to be consistent (and I have no idea what
it is anyway).

It might (though not guaranteed) be helpful to read the bootloader message
after a reset, so discovering how to get 76800 baud rate in the IDE Serial
Monitor could be a good start...

From what I can understand, it appears that either the 1.6.1-p1 IDE is
failing somehow or seven ESP modules have failed at the same time - which
seems improbable as four of them were previously OK and the other three
were brand new...

All help and advice gratefully received.......

On 22 April 2015 at 04:27, tim-in-oakton [email protected] wrote:

I forgot to specify - Windows build, will try a fresh clone tonight-

—
Reply to this email directly or view it on GitHub
#95 (comment).

[tim-in-oakton]

Your description matches mine exactly, thanks for the 76800bps tip, I may look into that (did not know the magic number was 76800!).

I tried a third module late last night - same behavior... first upload works, second LOOKS fine uploading, but doesn't work. Resetting after upload shows "gobbletygook" in the serial monitor....

AFAIK I changed NOTHING in my upload environment, and I have 3 PCs used for development - all are behaving in this manner (or, changing to a different PC doesn't seem to change the upload-not-working behavior). All PC's are WIndows7, using the earlier 1.6.1 Zip download with patched libs for the UDP port issue (thanks IGRR).

Once in this state, it doesn't appear that I can upload a functioning "minimal sketch" to a module either - although this problem seemed to "grow over time" - from an occasional failed upload to "can't upload at all anymore". Very strange, the common factors would seem to be the IDE/uploader code, the host OS (windows7 with auto-updates) & the power supply in my case... I'll have a better bench supply this evening UMT-5 to test with.

Anyone else seeing flakiness? If so, can you share your system/project specs?

[duncan-a]

I don't get the "first upload works, second LOOKS fine uploading, but
doesn't work" - it's now just "LOOKS fine uploading, but doesn't work",
even with a fresh module.

I'm limited to one (rather ancient) Win XP laptop using "1.6.1 Zip
download" but without "patched libs for the UDP port issue" (I don't
understand how to do things like that!) - but I can use that IDE OK with a
Pro Micro 3.3V (Board: Pro Micro, Processor: ATMega 328 8MHz, Programmer:
AVR ISP) so that's proving that the FTDI Friend is OK and that the 'genuine
Arduino' part of the IDE is OK.

If you discover a way of adding 76800 into the options for the serial
monitor, please share it (in simple terms if possible - anything too techie
is way over my head).

On 22 April 2015 at 13:41, tim-in-oakton [email protected] wrote:

Your description matches mine exactly, thanks for the 76800bps tip, I may
look into that (did not know the magic number was 76800!).

I tried a third module late last night - same behavior... first upload
works, second LOOKS fine uploading, but doesn't work. Resetting after
upload shows "gobbletygook" in the serial monitor....

AFAIK I changed NOTHING in my upload environment, and I have 3 PCs used
for development - all are behaving in this manner (or, changing to a
different PC doesn't seem to change the upload-not-working behavior). All
PC's are WIndows7, using the earlier 1.6.1 Zip download with patched libs
for the UDP port issue (thanks IGRR).

Once in this state, it doesn't appear that I can upload a functioning
"minimal sketch" to a module either - although this problem seemed to "grow
over time" - from an occasional failed upload to "can't upload at all
anymore". Very strange, the common factors would seem to be the
IDE/uploader code, the host OS (windows7 with auto-updates) & the power
supply in my case... I'll have a better bench supply this evening UMT-5 to
test with.

Anyone else seeing flakiness? If so, can you share your system/project
specs?

—
Reply to this email directly or view it on GitHub
#95 (comment).

[abl]

Heh, my debug output works at 77400. :)

My devices are all VERY voltage-sensitive; they pull too much current for the 3.3V lines on most of my serial adapters.

My advice would be to grab PuTTY, monitor the serial port, and try to restart the module in to flash mode.

If you see a boot mode of anything but (1,7) in the debug output, something's wrong. First number is the boot type - 1 means boot from UART (aka flash over serial), 3 means boot from SPI flash (aka normal startup), 5 means boot from SDIO (aka...nobody's doing this yet.) The second number appears to be related to whether or not the chip started cleanly - 7 is good, anything less and you might not be able to flash.

[duncan-a]

Thanks for joining in Alexander

Hmmm...

In my case, I'm running a 5V 1.2A wall wart (stable +/- 0.1V according to a
multimeter) and following it with an AMS117 type 3.3V regulator which,
according to the specs, should be good for 1A - again, on the multimeter,
the 3.3V rail is rock steady.

I'll try and get PuTTY installed and hope that provides an answer to the
what (the heck's happening?) - that may subsequently lead to a why (this is
happening) and a how (to fix it).

One thing I'm wondering relates to tim-in-oakton and I both using the
1.61-p1 from the .zip file on the 'releases' page - most other people are
being much more techie and doing clever things (that I can't follow) from
the regular builds on the main GitHub page. Could it be that this problem
has appeared before, has been fixed by some devious and unfathomable means
on the main page but that it hasn't made it to the .zip file?

Just a thought...

On 22 April 2015 at 22:52, Alexander [email protected] wrote:

Heh, my debug output works at 77400. :)

My devices are all VERY voltage-sensitive; they pull too much current for
the 3.3V lines on most of my serial adapters.

My advice would be to grab PuTTY, monitor the serial port, and try to
restart the module in to flash mode.

If you see a boot mode of anything but (1,7) in the debug output,
something's wrong. First number is the boot type - 1 means boot from UART
(aka flash over serial), 3 means boot from SPI flash (aka normal startup),
5 means boot from SDIO (aka...nobody's doing this yet.) The second number
appears to be related to whether or not the chip started cleanly - 7 is
good, anything less and you might not be able to flash.

—
Reply to this email directly or view it on GitHub
#95 (comment).

[abl]

Yeah, I don't think it's your power supply - which is significantly more stable than mine - I just got VERY similar problems when I had a flaky power supply.

PuTTY should be the easiest way to get a terminal open - no install necessary, you can get it as a standalone executable.

The underlying flash tools probably haven't changed, and that appears to be where the issue lies if it isn't the chip; I'm not familiar with this particular project but I'm fairly familiar at this point (in that when one falls out of a tree, one becomes familiar with many branches) with the ESP8266 and the Arduino platform in general.

I'll dig deeper once I get home.

[duncan-a]

Yup, the belief that USB can power anything and you can always get 3.3V
from an Arduino seems to be a widespread erroneous belief within some
sections of the maker movement. I may be useless with software, out of my
depth with a lot of the modern stuff and totally confused by the
proliferation of unfathomable terms, but fifty years of engineering from
the days of all valves (tubes) has taught me the value of adequate power
supplies.

I could try a chunky electrolytic close to the ESP but I really doubt it
will make any difference - the multimeter may be slow to react but I think
there should be more than enough in hand, even if the 117 is a 'Chinese
copy' of dubious pedigree...

I can't rule out ESP chip failure, but at the attrition rate I've
experienced with 'fresh from the packet' ones not working at the first try
since this problem materialised, I doubt that's at the root of the problem

• and living on a pension doesn't allow me to keep throwing them at the
  problem!!!

Ho hum...............

On 22 April 2015 at 23:35, Alexander [email protected] wrote:

Yeah, I don't think it's your power supply - which is significantly more
stable than mine - I just got VERY similar problems when I had a flaky
power supply.

PuTTY should be the easiest way to get a terminal open - no install
necessary, you can get it as a standalone executable.

The underlying flash tools probably haven't changed, and that appears to
be where the issue lies if it isn't the chip; I'm not familiar with this
particular project but I'm fairly familiar at this point (in that when one
falls out of a tree, one becomes familiar with many branches) with the
ESP8266 and the Arduino platform in general.

I'll dig deeper once I get home.

—
Reply to this email directly or view it on GitHub
#95 (comment).

[abl]

...but it says 3.3 right on the board!

I've done some moderately heinous things to my ESPs - the flashing process is flaky, and without the debug info at that magical baud rate it's really hard to tell what's failing. I suspect your chips are fine. Looking forward to seeing what you get out of PuTTY :)

[codewise-nicolas]

Thank goodness Im not the only with this problem - I thought I was going crazy last night.
Im using the lates github files with the arduino from the readme.

I started to notice problems when I was experimenting with deepsleep.
I noticed the problem when deepsleep would cause a fatal exception instead of the usual "deep sleep 15s".

I would change nothing, simply click verify then upload, and randomly it would work.

I still have not found a solution, but I think its the problem you guys are having as i believe it is programmer related.

My setup:
Windows 7 32 bit
ESP-01 with rst <> xpdc wire
LD1117 3.3v regulator feeding the ESP
Logic level converter (https://www.sparkfun.com/products/12009)
USB-UART is a CP2102 based.
Ground is common across esp and usb-uart.

[duncan-a]

Alexander

Yep, it does say 3.3V and usually it is - but it depends on what you're
trying to do with it, what else is going on with the Arduino and how the
Aeduino is being powered ...

• Desktop/Laptop/Tablet USB ports are very 'variable' in the current
  they can supply - I've seen things crap out at 120mA before now from a
  laptop, others have been happy at 500mA.
• The 5V and 3.3V regulators used in Arduino vary from type to type -
  and the 'clones' complicate things further.
• The 3.3V reg follows the 5V reg so is dependent upon what's being
  drawn off 5V not just the current drawn on the 3.3V line.

Running an Arduino off USB is often a primary source of 'unexplained
problems' - particularly with things taking high peak currents - WiFi,
Bluetooth Classic, RF and Ethernet modules for instance...!!!

Back to the problem in hand...

I can't get PuTTY to work - due, I'm sure, to total incompetence and lack
of experience with terminal programs.

The USB adaptor is on Com8 so, in the Connection/Serial part of the PuTTY
config window, I'm trying to set:

Serial Line: COM8
Speed: 76800
Data Bits: 8
Stop Bits: 1
Parity: None
Flow Control: tried all options...!!!

Hitting "Open" gives me a 'Windows Bong' (feel like I could use a bong at
the moment - flashback many years!) - no more, no less...

What am I doing wrong???

On 23 April 2015 at 02:01, Alexander [email protected] wrote:

...but it says 3.3 right on the board!

I've done some moderately heinous things to my ESPs - the flashing process
is flaky, and without the debug info at that magical baud rate it's really
hard to tell what's failing. I suspect your chips are fine. Looking forward
to seeing what you get out of PuTTY :)

—
Reply to this email directly or view it on GitHub
#95 (comment).

[duncan-a]

Although not directly related to "the problem", I tripped over this on the
ESP8266 Community Forum:

"Did you a add a capacitor across Vcc and GND near the ESP?I also
experienced many unwanted resets like you you have. The majority of these
resets disappeared when I added a pulup resistor from RST to Vcc. Before I
did that I could cause a reset by nearing the ESP with a hand."

I also read something else about pickup on connecting leads causing all
sorts of problems, but I can't remember the context.

Where I'm living in Spain, there is no mains earth anywhere in the house
wiring - that may (or may not?) be significant.

Several schematics I've seen include a resistor and capacitor (to add a
delay to one of the pulses) when using an 'automatic upload' option - I'll
search for one and add details when I find it - any port in a storm!!!

One thing I have concluded in my trawling today is that there do appear to
be some issues with ESPTool - though most of the tecnicalities were over my
head. There seem to be quite a few posts relating to problems in various
configurations (using ESP8266/Arduino, direct to the ESP, etc) so we're not
the only ones with problems, though we do seem to be leading in the"it did
work, now it won't"contest.

For those who are very techie: Is there anything in the 1.6.1-p1 zip
version that might have 'filled up', 'overflowed' or anything like that?
I'm a bit loath to try a reinstall, but has anybody tried it?

Just thinking out loud...!

On 23 April 2015 at 13:02, Duncan Amos [email protected] wrote:

Alexander

Yep, it does say 3.3V and usually it is - but it depends on what you're
trying to do with it, what else is going on with the Arduino and how the
Aeduino is being powered ...

• Desktop/Laptop/Tablet USB ports are very 'variable' in the current
  they can supply - I've seen things crap out at 120mA before now from a
  laptop, others have been happy at 500mA.
• The 5V and 3.3V regulators used in Arduino vary from type to type -
  and the 'clones' complicate things further.
• The 3.3V reg follows the 5V reg so is dependent upon what's being
  drawn off 5V not just the current drawn on the 3.3V line.

Running an Arduino off USB is often a primary source of 'unexplained
problems' - particularly with things taking high peak currents - WiFi,
Bluetooth Classic, RF and Ethernet modules for instance...!!!

Back to the problem in hand...

I can't get PuTTY to work - due, I'm sure, to total incompetence and lack
of experience with terminal programs.

The USB adaptor is on Com8 so, in the Connection/Serial part of the PuTTY
config window, I'm trying to set:

Serial Line: COM8
Speed: 76800
Data Bits: 8
Stop Bits: 1
Parity: None
Flow Control: tried all options...!!!

Hitting "Open" gives me a 'Windows Bong' (feel like I could use a bong at
the moment - flashback many years!) - no more, no less...

What am I doing wrong???

On 23 April 2015 at 02:01, Alexander [email protected] wrote:

...but it says 3.3 right on the board!

I've done some moderately heinous things to my ESPs - the flashing
process is flaky, and without the debug info at that magical baud rate it's
really hard to tell what's failing. I suspect your chips are fine. Looking
forward to seeing what you get out of PuTTY :)

—
Reply to this email directly or view it on GitHub
#95 (comment).

[codewise-nicolas]

I did experience flakyness the very first few times (long ago) with the esp8266 and so the cap+resistors fixed it. Its now standard in all my ESP work.

I think this is somehow related to the compiler or the programmer (esptool).

Im trying to make it happen again so I can grab the crash report and post it for more knowleadgeable people to figure out. But to no avail.

Does this method of programming (arduino ide) also make use of the bank 0/1 concept of the ESP; that is, does it program the same file to both banks ?
Does the ESPtool verify everything it writes ?

[tim-in-oakton]

ABL - thanks for the Putty recommendation, I didn't even thin to use it for Serial!!
Following are results, I uploaded the sketch, reset and reset again with the GPIO left high.....

Reset results after a “apparently successful flash upload” (Arduino IDE output):
Sketch uses 206,664 bytes (39%) of program storage space. Maximum is 524,288 bytes.
warning: unsupported baud rate: 115200, using 115200
Uploading 38224 bytes from C:\Users\timmeyer\AppData\Local\Temp\build2395631062301061534.tmp/Kegerator-v4.3.cpp_00000.bin to flash at 0x00000000
......................................
Uploading 168488 bytes from C:\Users\timmeyer\AppData\Local\Temp\build2395631062301061534.tmp/Kegerator-v4.3.cpp_40000.bin to flash at 0x00040000
.....................................................................................................................................................................

/* connect PUTTY set for 76800bps, reset while still in “upload” mode w GPIO0 pulled low /
ets Jan 8 2013,rst cause:1, boot mode:(1,7)
/ as expected, "I'm cool, waiting for code delivered over the Serial port" */

/* Now reboot/power cycle with the GPIO left to flow high – which normally SHOULD execute the previously uploaded code*/
load 0x40100000, len 30216, room 16
tail 8
chksum 0x2f
load 0x3ffe8000, len 2860, room 0
tail 12
chksum 0x21
ho 0 tail 12 room 4
load 0x3ffe8b30, len 4988, room 12
tail 0
chksum 0x8a
csum 0x8a

/* This is repeatable – power cycle 5X and see the same exact output 5X.
I’ve tried it on three machines now (all Win7 with similar IDE downloads), no change in results.

Previously (last week) this EXACT process worked more than half the time – my code booted up and performed great.
The only changes that I am aware of is my code grew modestly, I’ve written a bit more to the EEPROM (nowhere near what I’d expect to create wear), and the original module was transported from work & back (bit of mechanical jostling).
*/

Any other ideas? When life (work, wife, kids, etc) permits, I'm going to try to use a Linux box as the IDE host and uploader instead of the WIndows boxes used to date, and I'm planning on putting a pair of caps right on the PCB to make sure power is clean. I may also wire other GPIO leads high as a hedge.

I did verify with a 'sillyscope that my power is solid and clean - at least at the power supply (rock solid 3.3v, no noticeable ripple). I don't think that this is power issue now, but I'll throw some caps on to be sure.

Again - my environment was always a little flakey (maybe one upload in 5-10 failed), but it degraded over time to now be unusable - on any of the machines I'm using.

It FEELS like I hit some threshold where the upload process is breaking - setting the wrong jump vectors, putting the code in the wrong place..... dunno.
Based on this info, any more thoughts, suggestions or observations?
thanks all, I really appreciate the positive feedback-
tim

[tim-in-oakton]

Had time on a break to set up on Ubuntu - compiles and uploads without complaints but STILL doesn't run - After uploading using Linux Arduino IDE and rebooting without GPIO held low I see (at 76800bps):

ets Jan 8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 31024, room 16
tail 0
chksum 0x12
load 0x3ffe8000, len 2844, room 8
tail 4
chksum 0x56
load 0x3ffe8b20, len 4956, room 4
tail 8
chksum 0x66
csum 0x66

It seems a little notable that it compiles to different sizes, but I don't expect that is the root issue - I may try with a minimal sketch as well, but this is replicated behavior - two modules, four computers, two different IDE host OS's (Win7&Ubuntu 14something).

Next up is caps & terminating ALL inputs.... still think this is an upload tool issue though.

[duncan-a]

codewise-nicolas: Things are getting a bit too technical for me but I'll
try to survive as long as possible...

My setup' is Win XP Pro with the ESP8266/Arduino .zip 1.6.1-p1 version -
Board: Generic ESP8266 board, Programmer: esptools.

It certainly appears to upload in two blocks, as shown in tim-in-oakton's
latest post (thanks for that Tim - I'd still like to have understood enough
to have done that!) and it terminates with a clean "Done uploading" most of
the time - there do seem to be random errors but nothing particularly
consistent. I don't think it can be verifying as it goes - despite taking
an incredibly long time from hitting upload to it finishing (admittedly my
laptop is incredibly ancient and slow, but it takes several minutes - I can
make a cup of coffee easily).

I think it's probably an issue with esptools but the occasional
inconsistency makes me wonder if it it one single cause...

Thanks to all for the inputs so far.

On 23 April 2015 at 20:25, tim-in-oakton [email protected] wrote:

ABL - thanks for the Putty recommendation, I didn't even thin to use it
for Serial!!
Following are results, I uploaded the sketch, reset and reset again with
the GPIO left high.....

Reset results after a “apparently successful flash upload” (Arduino IDE
output):
Sketch uses 206,664 bytes (39%) of program storage space. Maximum is
524,288 bytes.
warning: unsupported baud rate: 115200, using 115200
Uploading 38224 bytes from
C:\Users\timmeyer\AppData\Local\Temp\build2395631062301061534.tmp/Kegerator-v4.3.cpp_00000.bin
to flash at 0x00000000
......................................
Uploading 168488 bytes from
C:\Users\timmeyer\AppData\Local\Temp\build2395631062301061534.tmp/Kegerator-v4.3.cpp_40000.bin
to flash at 0x00040000

.....................................................................................................................................................................

/* connect PUTTY set for 76800bps, reset while still in “upload” mode w
GPIO0 pulled low

/ ets Jan 8 2013,rst cause:1, boot mode:(1,7) / as expected, "I'm cool,
waiting for code delivered over the Serial port" */

/* Now reboot/power cycle with the GPIO left to flow high – which normally
SHOULD execute the previously uploaded code*/
load 0x40100000, len 30216, room 16
tail 8
chksum 0x2f
load 0x3ffe8000, len 2860, room 0
tail 12
chksum 0x21
ho 0 tail 12 room 4
load 0x3ffe8b30, len 4988, room 12
tail 0
chksum 0x8a
csum 0x8a

/* This is repeatable – power cycle 5X and see the same exact output 5X.
I’ve tried it on three machines now (all Win7 with similar IDE downloads),
no change in results.

Previously (last week) this EXACT process worked more than half the time –
my code booted up and performed great.
The only changes that I am aware of is my code grew modestly, I’ve written
a bit more to the EEPROM (nowhere near what I’d expect to create wear), and
the original module was transported from work & back (bit of mechanical
jostling).
*/

Any other ideas? When life (work, wife, kids, etc) permits, I'm going to
try to use a Linux box as the IDE host and uploader instead of the WIndows
boxes used to date, and I'm planning on putting a pair of caps right on the
PCB to make sure power is clean. I may also wire other GPIO leads high as a
hedge.

I did verify with a 'sillyscope that my power is solid and clean - at
least at the power supply (rock solid 3.3v, no noticeable ripple). I don't
think that this is power issue now, but I'll throw some caps on to be sure.

Again - my environment was always a little flakey (maybe one upload in
5-10 failed), but it degraded over time to now be unusable - on any of the
machines I'm using.

It FEELS like I hit some threshold where the upload process is breaking -
setting the wrong jump vectors, putting the code in the wrong place.....
dunno.
Based on this info, any more thoughts, suggestions or observations?
thanks all, I really appreciate the positive feedback-
tim

—
Reply to this email directly or view it on GitHub
#95 (comment).

[duncan-a]

Tim...

Alexander wrote in his first post in this thread:

"
_My advice would be to grab PuTTY, monitor the serial port, and try to
restart the module in to flash mode. _If you see a boot mode of anything
but (1,7) in the debug output, something's wrong. First number is the boot
type - 1 means boot from UART (aka flash over serial), 3 means boot from
SPI flash (aka normal startup), 5 means boot from SDIO (aka...nobody's
doing this yet.) The second number appears to be related to whether or not
the chip started cleanly - 7 is good, anything less and you might not be
able to flash."

You're seeing 3.7, which would (I think) imply that it's not reacting yo
GPIO0 correctly and is remaining in "normal startup" mode - if I'm
understanding correctly...

Yes? No? Maybe? Rapidly losing the will to live?

On 23 April 2015 at 22:28, Duncan Amos [email protected] wrote:

codewise-nicolas: Things are getting a bit too technical for me but
I'll try to survive as long as possible...

My setup' is Win XP Pro with the ESP8266/Arduino .zip 1.6.1-p1 version -
Board: Generic ESP8266 board, Programmer: esptools.

It certainly appears to upload in two blocks, as shown in tim-in-oakton's
latest post (thanks for that Tim - I'd still like to have understood enough
to have done that!) and it terminates with a clean "Done uploading" most of
the time - there do seem to be random errors but nothing particularly
consistent. I don't think it can be verifying as it goes - despite taking
an incredibly long time from hitting upload to it finishing (admittedly my
laptop is incredibly ancient and slow, but it takes several minutes - I can
make a cup of coffee easily).

I think it's probably an issue with esptools but the occasional
inconsistency makes me wonder if it it one single cause...

Thanks to all for the inputs so far.

On 23 April 2015 at 20:25, tim-in-oakton [email protected] wrote:

ABL - thanks for the Putty recommendation, I didn't even thin to use it
for Serial!!
Following are results, I uploaded the sketch, reset and reset again with
the GPIO left high.....

Reset results after a “apparently successful flash upload” (Arduino IDE
output):
Sketch uses 206,664 bytes (39%) of program storage space. Maximum is
524,288 bytes.
warning: unsupported baud rate: 115200, using 115200
Uploading 38224 bytes from
C:\Users\timmeyer\AppData\Local\Temp\build2395631062301061534.tmp/Kegerator-v4.3.cpp_00000.bin
to flash at 0x00000000
......................................
Uploading 168488 bytes from
C:\Users\timmeyer\AppData\Local\Temp\build2395631062301061534.tmp/Kegerator-v4.3.cpp_40000.bin
to flash at 0x00040000

.....................................................................................................................................................................

/* connect PUTTY set for 76800bps, reset while still in “upload” mode w
GPIO0 pulled low

/ ets Jan 8 2013,rst cause:1, boot mode:(1,7) / as expected, "I'm
cool, waiting for code delivered over the Serial port" */

/* Now reboot/power cycle with the GPIO left to flow high – which
normally SHOULD execute the previously uploaded code*/
load 0x40100000, len 30216, room 16
tail 8
chksum 0x2f
load 0x3ffe8000, len 2860, room 0
tail 12
chksum 0x21
ho 0 tail 12 room 4
load 0x3ffe8b30, len 4988, room 12
tail 0
chksum 0x8a
csum 0x8a

/* This is repeatable – power cycle 5X and see the same exact output 5X.
I’ve tried it on three machines now (all Win7 with similar IDE
downloads), no change in results.

Previously (last week) this EXACT process worked more than half the time
– my code booted up and performed great.
The only changes that I am aware of is my code grew modestly, I’ve
written a bit more to the EEPROM (nowhere near what I’d expect to create
wear), and the original module was transported from work & back (bit of
mechanical jostling).
*/

Any other ideas? When life (work, wife, kids, etc) permits, I'm going to
try to use a Linux box as the IDE host and uploader instead of the WIndows
boxes used to date, and I'm planning on putting a pair of caps right on the
PCB to make sure power is clean. I may also wire other GPIO leads high as a
hedge.

I did verify with a 'sillyscope that my power is solid and clean - at
least at the power supply (rock solid 3.3v, no noticeable ripple). I don't
think that this is power issue now, but I'll throw some caps on to be sure.

Again - my environment was always a little flakey (maybe one upload in
5-10 failed), but it degraded over time to now be unusable - on any of the
machines I'm using.

It FEELS like I hit some threshold where the upload process is breaking -
setting the wrong jump vectors, putting the code in the wrong place.....
dunno.
Based on this info, any more thoughts, suggestions or observations?
thanks all, I really appreciate the positive feedback-
tim

—
Reply to this email directly or view it on GitHub
#95 (comment).

[abl]

@duncan-a something else probably has your serial port captured - I find it helps to unplug, reboot, start PuTTY, and then plug in. Windows doesn't make that easy. I'm happy to set up a Teamviewer session or something to help debug, if you'd like!

@tim-in-oakton yep, @duncan-a is correct: boot mode (3,7) is a normal boot, so your GPIOs are not being pulled the way they need to be pulled. https://github.com/esp8266/esp8266-wiki/wiki/Boot-Process details this a bit - you want UART mode, which is GPIO15 low, GPIO0 low, and GPIO2 high.

[Links2004]

don´t connect GPIO2 to VCC, in boot-loader mode its an alternative TX connect it to VCC can damage the chip!
see #92

[igrr]

Still, a 10k pull-up on GPIO2 has improved stability (both upload time and run time) in my case.

[igrr]

Also, regarding the degraded upload performance — could this be related to increased flash erase time?
If you could grab the behaviour of TX/RX lines during upload using a logic analyser or a scope, we could see if the flash erase time is an issue here.

[tim-in-oakton]

I was unclear - let me try again......
When I pull GPIO0 down and reset while looking at the serial port with PUTTY, I get:
ets Jan 8 2013,rst cause:1, boot mode:(1,7)

After I upload (see above details, looks fine and it HAS worked maybe 500+ times before), I let GPIO0 float and reset the board. Using PUTTY to listen, the board then says:
ets Jan 8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 31024, room 16
tail 0
chksum 0x12
load 0x3ffe8000, len 2844, room 8
tail 4
chksum 0x56
load 0x3ffe8b20, len 4956, room 4
tail 8
chksum 0x66
csum 0x66

I will try a local cap and pulling GPIO2 high with a 10K resistor & report back.

[tim-in-oakton]

OK, I'm feeling more & more confident this is an uploader issue - I put a 470uF cap between power & gnd, pulled up GPIO0&2 w 10K resistors, and zero change in behavior.
Using a "minimum" sketch that just opens the port & prints out "waiting" in a loop, it uploads "normally", I release GPIO0 and boot it and it displays (@76800):

ets Jan 8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 26644, room 16
tail 4
chksum 0xf3
load 0x3ffe8000, len 2532, room 4
tail 0
chksum 0x3b
load 0x3ffe89f0, len 1308, room 8
tail 4
chksum 0x4a
csum 0x4a

And no longer runs or loops.

My thesis is that at a certain point/code size the uploader/bootloader steps on something on the module that breaks the normal bootup process, and as it is written to flash it gets "stuck".

Ivan - I don't have a logic analyzer handy, I do have a scope and an extra FTDI module that I could use to watch the interaction during an upload (now that I know the bitrate and that PUTTY speaks it)...

Could I suggest that someone on the ESP team look into the uploader Python and bootloader code to see if there is an obvious failure to

1. erase all the flash (<-- what i think)
2. properly set the jump vector after upload to point to the uploaded code IF something unexpected was written to the flash

I have a couple more modules on order to see if I can reliably flash smaller sketches before flashing my project (larger) sketch which seems to have killed three modules now (in the same manner).

I'll bet a beer that it's something in the upload process at this point - here is a wall of text from "uploading" in verbose mode..... The only thing that looks like a warning is the line "serialport_receive_C0: 1C instead of C0".... any idea if that is normal or a clue? The upload takes just under 12s at 115kbps, and the "erasing flash" line takes a surprisingly SHORT amount of time.

---

Sketch uses 178,876 bytes (34%) of program storage space. Maximum is 524,288 bytes.
F:\Users\timm\Documents\Arduino\hardware\arduino-esp8266-master/tools//esptool.exe -vv -cd none -cb 115200 -cp COM5 -ca 0x00000 -cf C:\Users\timm\AppData\Local\Temp\build3702862278599651419.tmp/BareMinimumtim_.cpp_00000.bin -ca 0x40000 -cf C:\Users\timm\AppData\Local\Temp\build3702862278599651419.tmp/BareMinimumtim_.cpp_40000.bin
esptool v0.4.1-3-g9ab93f4 - (c) 2014 Ch. Klippel [email protected]
setting board to none
setting baudrate from 230400 to 115200
setting port from COM1 to COM5
setting address from 0x00000000 to 0x00000000
espcomm_upload_file
stat C:\Users\timm\AppData\Local\Temp\build3702862278599651419.tmp/BareMinimumtim_.cpp_00000.bin success
warning: unsupported baud rate: 115200, using 115200
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_cmd: sending command header
espcomm_cmd: sending command payload
read 0, requested 1
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_cmd: sending command header
espcomm_cmd: sending command payload
serialport_receive_C0: 1C 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_cmd: sending command header
espcomm_cmd: sending command payload
read 0, requested 1
resetting board
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_cmd: sending command header
espcomm_cmd: sending command payload
espcomm cmd: receiving 2 bytes of data
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_open
Uploading 30528 bytes from C:\Users\timm\AppData\Local\Temp\build3702862278599651419.tmp/BareMinimumtim_.cpp_00000.bin to flash at 0x00000000
erasing flash
espcomm_cmd: sending command header
espcomm_cmd: sending command payload
setting serial port timeouts to 5000 ms
setting serial port timeouts to 1000 ms
espcomm cmd: receiving 2 bytes of data
writing flash
..............................
setting address from 0x00000000 to 0x00040000
espcomm_upload_file
stat C:\Users\timm\AppData\Local\Temp\build3702862278599651419.tmp/BareMinimumtim_.cpp_40000.bin success
espcomm_open
Uploading 148392 bytes from C:\Users\timm\AppData\Local\Temp\build3702862278599651419.tmp/BareMinimumtim_.cpp_40000.bin to flash at 0x00040000
erasing flash
espcomm_cmd: sending command header
espcomm_cmd: sending command payload
setting serial port timeouts to 5000 ms
setting serial port timeouts to 1000 ms
espcomm cmd: receiving 2 bytes of data
writing flash
.................................................................................................................................................
starting app without reboot
espcomm_cmd: sending command header
espcomm_cmd: sending command payload
espcomm cmd: receiving 2 bytes of data
closing bootloader
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms

flush complete

[AndyKirby]

There are so many different ideas on how the pins go.

The following works every time for me and has been used by folk from our
hackspace with equally reliable results.

http://www.sheffieldhardwarehackers.org.uk/wordpress/

Pull up = 10K resistor to Vcc (3v3)
Pull down = 10K resistor to Gnd (0v)

ESP8266-01

Using 10K resistors

Pull up, GPIO0
Pull up, GPIO2
Pull up, Rst (Reset)
Pull up, CH_PD

To program using the esp bootloader (like you are doing with the arduino
IDE)

Short GPIO0 to Gnd for the duration of loading the code.
Momentarily short RST to Gnd to trigger a reset or alternatively
powercycle the board.

This puts the bootloader into listening mode and you can then load your
code onto the board.

When loading is complete

Remove the Gnd short on GPIO0 and do a reset again.

Board comes up and runs your app fine.

This also works fine on other of the variants of the ESP8266 like 03 and
07. except ones with GPIO15, this should be pulled down to gnd via a 10K
resistor.

https://hackaday.io/project/3253-esp8266-native/log/11726-deep-sleep

10K is a weak pull up/down value that will not do the device any harm if
a pin is brought up in a output mode (Spare serial TX for instance). the
current is about .33 mA so tiny. But will ensure that if in an input
mode it has the default level set so it will always be known what state
it is in. The states as noted above work.

Warning if you leave a pin floating (Unconnected) it can be in any of
the two states or oscillating rapidly between the two depending on how
long a bit of wire is connected to it and how effective it is at being
an antenna. As the pin is in a random state, the results of any action
that is dependant on the state of the pin (Like bootloading) will be
just as random.

Do not put capacitors unnecessarily across pins, they are not pull ups.
Only use resistors for pulling pins up or down.

The little bit of effort taken to pull the important pins reliably into
their necessary default configurations is time and effort well spent.

Dunno if this is useful or already known but thought it worth repeating
just in case. Context and understanding can sometimes be assumed that
isn’t there.

Cheers

Andy Kirby

On 24/04/15 13:30, tim-in-oakton wrote:

I was unclear - let me try again......
When I pull GPIO0 down and reset while looking at the serial port with
PUTTY, I get:
ets Jan 8 2013,rst cause:1, boot mode:(1,7)

After I upload (see above details, looks fine and it HAS worked maybe
500+ times before), I let GPIO0 float and reset the board. Using PUTTY
to listen, the board then says:
ets Jan 8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 31024, room 16
tail 0
chksum 0x12
load 0x3ffe8000, len 2844, room 8
tail 4
chksum 0x56
load 0x3ffe8b20, len 4956, room 4
tail 8
chksum 0x66
csum 0x66

I will try a local cap and pulling GPIO2 high with a 10K resistor &
report back.

—
Reply to this email directly or view it on GitHub
#95 (comment).

[email protected]
www.kirbyand.co.uk

[duncan-a]

Tim

I'm close to being convinced irs an uploader issue, but I don't have the
ability to suss what it might be.

It seems to me that it's only affecting those who are working from the
ESP8266/Arduino/Releases .zip file version (or we're the only ones who
don't know how to integrate a 'build' or whatever) and I can't help feeling
that there may be some significance in that, but tomorrow I will lay the
whole thing out on the breadboard with the shortest possible wiring between
point_s in an attenpt to reduce the possibility of extraneous pickup - I
don't think it's a factor but as Sherlock Holmes said "_When you have
eliminated the impossible, whatever remains, however improbable, must be
the truth"...

Andy

Why did you, and the people at your hackspace, reject the idea of
'automating' the upload sequence using DTR/RTS and CTS combination? I'm
just curious as I would have thought the brains, experience and test
equipment would have been in plentiful supply. I've seen conflicting
methods being suggested, so I've avoided it so far.

The capacitor being referred to, of which you disapprove, was a 'chunky
electrolytic' across the 3.3V rail to reduce the likelihood of PSU Current
issues so nothing rounding-off signals. I agree completely about pullups
and you were right to point it out .

The Olimex modules come with 2Ks built-in (default high with a soldered
jumper) and this failure to upload applied to that board immediately after
an 01 (with 10Ks) failed, so, in my particular case, that can't be part of
the problem...

This is definitely a three pipe problem..........!

On 24 April 2015 at 15:40, Andy Kirby [email protected] wrote:

There are so many different ideas on how the pins go.

The following works every time for me and has been used by folk from our
hackspace with equally reliable results.

http://www.sheffieldhardwarehackers.org.uk/wordpress/

Pull up = 10K resistor to Vcc (3v3)
Pull down = 10K resistor to Gnd (0v)

ESP8266-01

Using 10K resistors

Pull up, GPIO0
Pull up, GPIO2
Pull up, Rst (Reset)
Pull up, CH_PD

To program using the esp bootloader (like you are doing with the arduino
IDE)

Short GPIO0 to Gnd for the duration of loading the code.
Momentarily short RST to Gnd to trigger a reset or alternatively
powercycle the board.

This puts the bootloader into listening mode and you can then load your
code onto the board.

When loading is complete

Remove the Gnd short on GPIO0 and do a reset again.

Board comes up and runs your app fine.

This also works fine on other of the variants of the ESP8266 like 03 and
07. except ones with GPIO15, this should be pulled down to gnd via a 10K
resistor.

https://hackaday.io/project/3253-esp8266-native/log/11726-deep-sleep

10K is a weak pull up/down value that will not do the device any harm if
a pin is brought up in a output mode (Spare serial TX for instance). the
current is about .33 mA so tiny. But will ensure that if in an input
mode it has the default level set so it will always be known what state
it is in. The states as noted above work.

Warning if you leave a pin floating (Unconnected) it can be in any of
the two states or oscillating rapidly between the two depending on how
long a bit of wire is connected to it and how effective it is at being
an antenna. As the pin is in a random state, the results of any action
that is dependant on the state of the pin (Like bootloading) will be
just as random.

Do not put capacitors unnecessarily across pins, they are not pull ups.
Only use resistors for pulling pins up or down.

The little bit of effort taken to pull the important pins reliably into
their necessary default configurations is time and effort well spent.

Dunno if this is useful or already known but thought it worth repeating
just in case. Context and understanding can sometimes be assumed that
isn’t there.

Cheers

Andy Kirby

On 24/04/15 13:30, tim-in-oakton wrote:

I was unclear - let me try again......
When I pull GPIO0 down and reset while looking at the serial port with
PUTTY, I get:
ets Jan 8 2013,rst cause:1, boot mode:(1,7)

After I upload (see above details, looks fine and it HAS worked maybe
500+ times before), I let GPIO0 float and reset the board. Using PUTTY
to listen, the board then says:
ets Jan 8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 31024, room 16
tail 0
chksum 0x12
load 0x3ffe8000, len 2844, room 8
tail 4
chksum 0x56
load 0x3ffe8b20, len 4956, room 4
tail 8
chksum 0x66
csum 0x66

I will try a local cap and pulling GPIO2 high with a 10K resistor &
report back.

—
Reply to this email directly or view it on GitHub
#95 (comment).

[email protected]
www.kirbyand.co.uk

—
Reply to this email directly or view it on GitHub
#95 (comment).

[duncan-a]

Although this thread #101 isn't
(I don't think?) directly related to the upload problem, I was struck by
the line "This should have been fixed in db86766
db86766,
discussed in #98 #98. Are you
using the latest version from git?". It seems to reinforce my thinking
that the code is continually being updated, improved and bug-fixed (with
the odd hiccup - see here #104)

• but only for those who are able to understand and implement "the last
  commit on the repo" (whatever that means), and they're not migrating to
  the .zip file on the /Releases/ page...

I may be totally wrong about this so feel free to correct me - or better
still, can somebody explain what those of us who are not 'hyper-techie'
need to do to maintain what we have at the current (believed correct so
far) status...

On 24 April 2015 at 23:46, Duncan Amos [email protected] wrote:

Tim

I'm close to being convinced irs an uploader issue, but I don't have the
ability to suss what it might be.

It seems to me that it's only affecting those who are working from the
ESP8266/Arduino/Releases .zip file version (or we're the only ones who
don't know how to integrate a 'build' or whatever) and I can't help feeling
that there may be some significance in that, but tomorrow I will lay the
whole thing out on the breadboard with the shortest possible wiring between
point_s in an attenpt to reduce the possibility of extraneous pickup - I
don't think it's a factor but as Sherlock Holmes said "_When you have
eliminated the impossible, whatever remains, however improbable, must be
the truth"...

Andy

Why did you, and the people at your hackspace, reject the idea of
'automating' the upload sequence using DTR/RTS and CTS combination? I'm
just curious as I would have thought the brains, experience and test
equipment would have been in plentiful supply. I've seen conflicting
methods being suggested, so I've avoided it so far.

The capacitor being referred to, of which you disapprove, was a 'chunky
electrolytic' across the 3.3V rail to reduce the likelihood of PSU Current
issues so nothing rounding-off signals. I agree completely about pullups
and you were right to point it out .

The Olimex modules come with 2Ks built-in (default high with a soldered
jumper) and this failure to upload applied to that board immediately after
an 01 (with 10Ks) failed, so, in my particular case, that can't be part of
the problem...

This is definitely a three pipe problem..........!

On 24 April 2015 at 15:40, Andy Kirby [email protected] wrote:

There are so many different ideas on how the pins go.

The following works every time for me and has been used by folk from our
hackspace with equally reliable results.

http://www.sheffieldhardwarehackers.org.uk/wordpress/

Pull up = 10K resistor to Vcc (3v3)
Pull down = 10K resistor to Gnd (0v)

ESP8266-01

Using 10K resistors

Pull up, GPIO0
Pull up, GPIO2
Pull up, Rst (Reset)
Pull up, CH_PD

To program using the esp bootloader (like you are doing with the arduino
IDE)

Short GPIO0 to Gnd for the duration of loading the code.
Momentarily short RST to Gnd to trigger a reset or alternatively
powercycle the board.

This puts the bootloader into listening mode and you can then load your
code onto the board.

When loading is complete

Remove the Gnd short on GPIO0 and do a reset again.

Board comes up and runs your app fine.

This also works fine on other of the variants of the ESP8266 like 03 and
07. except ones with GPIO15, this should be pulled down to gnd via a 10K
resistor.

https://hackaday.io/project/3253-esp8266-native/log/11726-deep-sleep

10K is a weak pull up/down value that will not do the device any harm if
a pin is brought up in a output mode (Spare serial TX for instance). the
current is about .33 mA so tiny. But will ensure that if in an input
mode it has the default level set so it will always be known what state
it is in. The states as noted above work.

Warning if you leave a pin floating (Unconnected) it can be in any of
the two states or oscillating rapidly between the two depending on how
long a bit of wire is connected to it and how effective it is at being
an antenna. As the pin is in a random state, the results of any action
that is dependant on the state of the pin (Like bootloading) will be
just as random.

Do not put capacitors unnecessarily across pins, they are not pull ups.
Only use resistors for pulling pins up or down.

The little bit of effort taken to pull the important pins reliably into
their necessary default configurations is time and effort well spent.

Dunno if this is useful or already known but thought it worth repeating
just in case. Context and understanding can sometimes be assumed that
isn’t there.

Cheers

Andy Kirby

On 24/04/15 13:30, tim-in-oakton wrote:

I was unclear - let me try again......
When I pull GPIO0 down and reset while looking at the serial port with
PUTTY, I get:
ets Jan 8 2013,rst cause:1, boot mode:(1,7)

After I upload (see above details, looks fine and it HAS worked maybe
500+ times before), I let GPIO0 float and reset the board. Using PUTTY
to listen, the board then says:
ets Jan 8 2013,rst cause:1, boot mode:(3,7)

load 0x40100000, len 31024, room 16
tail 0
chksum 0x12
load 0x3ffe8000, len 2844, room 8
tail 4
chksum 0x56
load 0x3ffe8b20, len 4956, room 4
tail 8
chksum 0x66
csum 0x66

I will try a local cap and pulling GPIO2 high with a 10K resistor &
report back.

—
Reply to this email directly or view it on GitHub
#95 (comment).

[email protected]
www.kirbyand.co.uk

—
Reply to this email directly or view it on GitHub
#95 (comment).

[codewise-nicolas]

Iam using the latest version from git, and have the problem.
Its not too complicated to update the "release" version with the git files.
Simply do the "Download Zip" button, and grab the folders inside the "Hardware" folder and replace completely your local ones.

For those having the problem intermitently, try archiving the build bins, so that when you find a compile/upload that has problems you can compare with the same code in a working .bin.
That is, compile upload, fail, copy the .bin, re-compile, re-upload, success, compare this bin to bad bin (should be the same.

This will help determine if its a compile thing or an upload thing.

[duncan-a]

That sounds easy - I'll try that tomorrow (it's 2am now and I was up at 6am
after 4 hours sleep, and that's not good at my age).

I've been wallowing in a swamp of jargon in various posts - pull requests
and various other things - maybe you should get your simple explanation
added to the ReadMe file in the GitHub page...?

The problem (in all cases, I think) appears to be uploading as what did
work now won't. Fore some people, it seemed to go through an intermittent
phase before failing completely, whereby it compiles without problems (but
it could be that the compiler is missing something) and it appears to
upload correctly, but it just does nothing.

As it's completely dead with me now, I'll need to leave it to one of the
others to try comparing .bins...

On 25 April 2015 at 01:01, codewise-nicolas [email protected]
wrote:

Iam using the latest version from git, and have the problem.
Its not too complicated to update the "release" version with the git files.
Simply do the "Download Zip" button, and grab the folders inside the
"Hardware" folder and replace completely your local ones.

For those having the problem intermitently, try archiving the build bins,
so that when you find a compile/upload that has problems you can compare
with the same code in a working .bin.
That is, compile upload, fail, copy the .bin, re-compile, re-upload,
success, compare this bin to bad bin (should be the same.

This will help determine if its a compile thing or an upload thing.

—
Reply to this email directly or view it on GitHub
#95 (comment).

[duncan-a]

Could this be relevant - it relates to compiling...?

I'd be quite happy to have an ESP-Only Arduino IDE (and call it ESP-Ard or
something) if I could get working ESPs again.......................

On 25 April 2015 at 02:08, Duncan Amos [email protected] wrote:

That sounds easy - I'll try that tomorrow (it's 2am now and I was up at
6am after 4 hours sleep, and that's not good at my age).

I've been wallowing in a swamp of jargon in various posts - pull requests
and various other things - maybe you should get your simple explanation
added to the ReadMe file in the GitHub page...?

The problem (in all cases, I think) appears to be uploading as what did
work now won't. Fore some people, it seemed to go through an intermittent
phase before failing completely, whereby it compiles without problems (but
it could be that the compiler is missing something) and it appears to
upload correctly, but it just does nothing.

As it's completely dead with me now, I'll need to leave it to one of the
others to try comparing .bins...

On 25 April 2015 at 01:01, codewise-nicolas [email protected]
wrote:

Iam using the latest version from git, and have the problem.
Its not too complicated to update the "release" version with the git
files.
Simply do the "Download Zip" button, and grab the folders inside the
"Hardware" folder and replace completely your local ones.

For those having the problem intermitently, try archiving the build bins,
so that when you find a compile/upload that has problems you can compare
with the same code in a working .bin.
That is, compile upload, fail, copy the .bin, re-compile, re-upload,
success, compare this bin to bad bin (should be the same.

This will help determine if its a compile thing or an upload thing.

—
Reply to this email directly or view it on GitHub
#95 (comment).

[duncan-a]

Stupid boy, Pike.......

Forgot the link: #110

On 25 April 2015 at 02:15, Duncan Amos [email protected] wrote:

Could this be relevant - it relates to compiling...?

I'd be quite happy to have an ESP-Only Arduino IDE (and call it ESP-Ard or
something) if I could get working ESPs again.......................

On 25 April 2015 at 02:08, Duncan Amos [email protected] wrote:

That sounds easy - I'll try that tomorrow (it's 2am now and I was up at
6am after 4 hours sleep, and that's not good at my age).

I've been wallowing in a swamp of jargon in various posts - pull requests
and various other things - maybe you should get your simple explanation
added to the ReadMe file in the GitHub page...?

The problem (in all cases, I think) appears to be uploading as what did
work now won't. Fore some people, it seemed to go through an intermittent
phase before failing completely, whereby it compiles without problems (but
it could be that the compiler is missing something) and it appears to
upload correctly, but it just does nothing.

As it's completely dead with me now, I'll need to leave it to one of the
others to try comparing .bins...

On 25 April 2015 at 01:01, codewise-nicolas [email protected]
wrote:

Iam using the latest version from git, and have the problem.
Its not too complicated to update the "release" version with the git
files.
Simply do the "Download Zip" button, and grab the folders inside the
"Hardware" folder and replace completely your local ones.

For those having the problem intermitently, try archiving the build
bins, so that when you find a compile/upload that has problems you can
compare with the same code in a working .bin.
That is, compile upload, fail, copy the .bin, re-compile, re-upload,
success, compare this bin to bad bin (should be the same.

This will help determine if its a compile thing or an upload thing.

—
Reply to this email directly or view it on GitHub
#95 (comment).

[duncan-a]

sticilface - well spotted. That was left over from being a debug when
everything was screwed. As I went to rem it out, I noticed that I'd also
got "Serial.write" where I should have had "Serial.println" as a debug - so
a double thank you!!!

Sorry to hear that you're now suffering 'the problem'...

On 1 May 2015 at 14:13, sticilface [email protected] wrote:

@duncan-a https://github.com/duncan-a

You've got a 1s delay in your main loop. Just take it out. Small delay(5)
ok, but that will stop your server from responding. I get approx 10-30k
loops per second on my code, you will be getting 1!

—
Reply to this email directly or view it on GitHub
#95 (comment).

[duncan-a]

According to the schematic, the Olimex modules are fitted with the
W25Q16BVSSIG,
which is 16MB according to the datasheet - presumably that increases the
problems?

On 1 May 2015 at 14:50, Duncan Amos [email protected] wrote:

sticilface - well spotted. That was left over from being a debug when
everything was screwed. As I went to rem it out, I noticed that I'd also
got "Serial.write" where I should have had "Serial.println" as a debug - so
a double thank you!!!

Sorry to hear that you're now suffering 'the problem'...

On 1 May 2015 at 14:13, sticilface [email protected] wrote:

@duncan-a https://github.com/duncan-a

You've got a 1s delay in your main loop. Just take it out. Small delay(5)
ok, but that will stop your server from responding. I get approx 10-30k
loops per second on my code, you will be getting 1!

—
Reply to this email directly or view it on GitHub
#95 (comment).

[Links2004]

W25Q16BVSSIG is an 16Mbit ship --> 2MB
2MB is supported

working version of esptool.py:
https://github.com/Links2004/esptool

[duncan-a]

OK, thanks for that. Presumably there's a good reason that it's capped at
2MB? Os there any way to use the other 14MB for something useful - storing
temperature values over 24 hours and then uploading the file as a CSV to
Google Drive is something I eventually want to do...

I noticed another post "#149", from
which it appears that the chip size can be determined so apologies for not
spotting it earlier.

On 1 May 2015 at 15:19, Markus [email protected] wrote:

W25Q16BVSSIG is an 16Mbit ship --> 2MB
2MB is supported

working version of esptool.py:
https://github.com/Links2004/esptool

—
Reply to this email directly or view it on GitHub
#95 (comment).

[Links2004]

to use the more flash you need to add "-fs 16m" as parameter to the esptool.py then you can access the memory by the SDK api like EEPROM does it.
https://github.com/Links2004/Arduino/blob/esp8266/hardware/esp8266com/esp8266/libraries/EEPROM/EEPROM.cpp#L91

[duncan-a]

OK, thanks - I'll eventualy get to the point of understanding!!!

On 1 May 2015 at 15:31, Markus [email protected] wrote:

to use the more flash you need to add "-fs 16m" as parameter to the
esptool.py then you can access the memory by the SDK api like EEPROM does
it.

https://github.com/Links2004/Arduino/blob/esp8266/hardware/esp8266com/esp8266/libraries/EEPROM/EEPROM.cpp#L91

—
Reply to this email directly or view it on GitHub
#95 (comment).

[duncan-a]

Just erased an 01, uploaded a sketch and it ran OK.
Needed to see the network connection info so hit reset - now it won't run!!!
Grrrrrrrrrrrrrrrrrrrrrrrrrr...........................!!!!!!!!!!!!!!!

On 1 May 2015 at 16:22, Duncan Amos [email protected] wrote:

OK, thanks - I'll eventualy get to the point of understanding!!!

On 1 May 2015 at 15:31, Markus [email protected] wrote:

to use the more flash you need to add "-fs 16m" as parameter to the
esptool.py then you can access the memory by the SDK api like EEPROM does
it.

https://github.com/Links2004/Arduino/blob/esp8266/hardware/esp8266com/esp8266/libraries/EEPROM/EEPROM.cpp#L91

—
Reply to this email directly or view it on GitHub
#95 (comment).

[duncan-a]

Just a question, but may (in another universe) be relevant...

The message pane says:

Sketch uses 196080 bytes (37%) if program storage space. Maximum is 524,288
bytes.
Uploading 35584 bytes from
then the file info
to flash at 0x00000000
.............. etc.

Uploading 160536 bytes from
then the file info
to flash at 0x40000000
.............. etc.

35584 + 160536 = 196120, not 196080

What are the extra 40 bytes for?

Is this also saying that the 01 module is a half-megabyte chip? It appears
to be marked 25Q41BT (I have very bad eyesight) but I can't find a
datasheet for that.

On the basis that the 25Q16 fitted to the Olimex boards is 16MB, this could
be a 4MB chip perhaps, and the half-Megabyte is the default value?

On 1 May 2015 at 16:26, Duncan Amos [email protected] wrote:

Just erased an 01, uploaded a sketch and it ran OK.
Needed to see the network connection info so hit reset - now it won't
run!!!
Grrrrrrrrrrrrrrrrrrrrrrrrrr...........................!!!!!!!!!!!!!!!

On 1 May 2015 at 16:22, Duncan Amos [email protected] wrote:

OK, thanks - I'll eventualy get to the point of understanding!!!

On 1 May 2015 at 15:31, Markus [email protected] wrote:

to use the more flash you need to add "-fs 16m" as parameter to the
esptool.py then you can access the memory by the SDK api like EEPROM does
it.

https://github.com/Links2004/Arduino/blob/esp8266/hardware/esp8266com/esp8266/libraries/EEPROM/EEPROM.cpp#L91

—
Reply to this email directly or view it on GitHub
#95 (comment).

[GerryKeely]

Hi Duncan
I can't explain the missing bytes but the chip size comes from this line "generic.upload.maximum_size=524288" in the "boards.txt" file found under "hardware/esp8266com/esp8266" directory.I think for the Olimex board it can be changed to a value of 2097152( ie 4 * 524288)

Gerry

[duncan-a]

Thanks Gerry

I was wondering if the 40 Bytes might in some way connect with the
problems...

On 1 May 2015 at 17:59, GerryKeely [email protected] wrote:

Hi Duncan
I can't explain the missing bytes but the chip size comes from this line
"generic.upload.maximum_size=524288" in the "boards.txt" file found under
"hardware/esp8266com/esp8266" directory.I think for the Olimex board it can
be changed to a value of 2097152( ie 4 * 524288)

Gerry

—
Reply to this email directly or view it on GitHub
#95 (comment).

[GerryKeely]

Hi Duncan
Additional "information"bytes are included at the beginning of each bin file. See https://github.com/themadinventor/esptool about half down the page under protocol.

Gerry

[tim-in-oakton]

Hopefully final followup - I had another couple of "hung modules", compounding issues seemed to be code size and occasionally interrupted uploads.
The latest pyesptools.py and following the details at #100 has made me a happy camper - I just select "use pyesptools" and the uploader and I've had zero issues since.

From the beginning it felt like a bug in the erase/upload process, who would have thought it was a firmware issue!
Thanks all-
tim

[duncan-a]

Will this be included in the next 'Release' version for Win32 (currently
expected soon)?

I don't understand enough to do it any other way (tried and failed
miserably)...

On 7 May 2015 at 14:25, tim-in-oakton [email protected] wrote:

Hopefully final followup - I had another couple of "hung modules",
compounding issues seemed to be code size and occasionally interrupted
uploads.

The latest pyesptools.py and following the details at #100
#100 has made me a happy camper

• I just select "use pyesptools" and the uploader and I've had zero issues
  since.

From the beginning it felt like a bug in the erase/upload process, who
would have thought it was a firmware issue!
Thanks all-
tim

—
Reply to this email directly or view it on GitHub
#95 (comment).

[igrr]

Will this be included in the next 'Release' version for Win32 (currently
expected soon)?

what is "this" you are referring to?

[duncan-a]

'Esptool.py updated to work around a bug in the SPIEraseArea ROM function'
and 'select "use pyesptools" and the uploader and I've had zero issues
since'... (as the uploader??)

Due to my complete inability to understand Git, I'm way behind on bug fixes
and suggestions of obtaining an up to date build elsewhere only gave a
Win64 version.

Sorry if this doesn't make a lot of sense, but I'm not that tech-savvy...

On 7 May 2015 at 15:54, Ivan Grokhotkov [email protected] wrote:

Will this be included in the next 'Release' version for Win32 (currently
expected soon)?

what is "this" you are referring to?

—
Reply to this email directly or view it on GitHub
#95 (comment).

[igrr]

I'm reluctant to bundle esptool.py because that would require bundling Python as well... which would be going a bit overboard in terms of size.

[duncan-a]

OK, I think I follow that...

I've had, and still have, the upload problems from the IDE so I struggled
and eventually installed Python and now need to erase the Flash from the
command line with esptool.py if I encounter a problem and then try the IDE
upload again...

What I, and I suspect others, want is to be able to upload from the IDE
with a high probability that it will work correctly.

If that can be achieved by other means then that's fine, but I keep seeing
esptool.py mentioned as, from what little I can follow, 'saviour of the
universe' (sorry, couldn't resist the reference to Flash) - hence my
question...

I love the work that's being done - hats off to all involved - but as a
non-techie, there's only so much I can follow, so 'dowload, unzip, install,
run' of a full 'Release' version is at my level.

What we have with ESP running Arduino is a complete game-changer..........

On 7 May 2015 at 18:28, Ivan Grokhotkov [email protected] wrote:

I'm reluctant to bundle esptool.py because that would require bundling
Python as well... which would be going a bit overboard in terms of size.

—
Reply to this email directly or view it on GitHub
#95 (comment).

[skandragon]

I only it worked reliably. Either I have a bad device, or the IDE still needs some work. I can't get simple code to upload and run reliably, when the only change is "int foo;" as a global, for instance.

[tim-in-oakton]

I promised earlier to post the kegerator code that uses the ESP and this IDE module to make signed calls on the AWS platfrom - it is athttps://github.com/tim-in-oakton/ESP8266Kegerator

This project uses the ESP8266 to become an AP and web server if it is unconfigured or can't access wifi to allow user to provide credentials/ssid/pw/etc. It then NTP's to get the time, and then sends SNS events to AWS based upon detection of beer flowing through Adafruit flow sensors. $2 module making secure, signed calls to AWS - please take this and do something cooler with it!
tim

[drmpf]

For a similar approach to configuring the Network and other parameters, like IP and server prot, but one which used a secured AP, with the password as a QR code attached to the device
see Cheap/Simple Wifi Shield
http://www.forward.com.au/pfod/CheapWifiShield/index.html
and ESP8266-01 Wifi Shield
http://www.forward.com.au/pfod/CheapWifiShield/ESP2866_01_WiFi_Shield/index.html

[vicatcu]

@tim-in-oakton I don't think this is a Windows-specific issue, I was running in Ubuntu 14.04 when I ran into this (purely using the Arduino IDE)...

[Keha07]

Hi,
I'm newbie in this area, I bought "Huzzah Esp8266" and after first connection to the Usb to Serial for uploading the simple sketch of Blink is starting a problem with the next uploading, i.e. the first upload was successful but after that I get the error in Arduino 1.6.7
"warning: espcomm_sync failed"
"error: espcomm_open failed"
I started investigate the issue and found your forum... I try to run your solution with esptools.py but got error:
Connecting...

A fatal error occurred: Failed to connect to ESP8266

I tried also with the button of GPIO0 and Reset and nothing solved the problem.

Can anybody help me?

[Keha07]

I think I know in what was the problem, the cable TDI Usb to Serial was not genius and Windows update their drivers which blocking usage of fake stuff.

[tablatronix]

I am gonna chime in here for posterity, I just had this erase issue happen again, so im not sure if its sitll an issue in esptool.exe 0.4.6 win 32.

started getting looping exception restarts, had to use pyesptool and do an erase_flash to fix it.

This is what my stack looked like , hope it helps someone.
Exception (2):

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

load 0x4010f000, len 1264, room 16 
tail 0
chksum 0x42
csum 0x42
~ld

Exception (2):
epc1=0x3ffe854c epc2=0x00000000 epc3=0x00000000 excvaddr=0x3ffe854c depc=0x00000000

ctx: cont 
sp: 3ffef840 end: 3ffefc70 offset: 01a0

>>>stack>>>
3ffef9e0:  feefeffe feefeffe feefeffe feefeffe  
3ffef9f0:  feefeffe feefeffe feefeffe feefeffe  
3ffefa00:  feefeffe feefeffe feefeffe feefeffe  
3ffefa10:  feefeffe feefeffe feefeffe feefeffe  
3ffefa20:  feefeffe feefeffe feefeffe feefeffe  
3ffefa30:  feefeffe 00000004 3ffefa90 3ffefaa1  
3ffefa40:  40107020 00000000 3fff0740 00000484  
3ffefa50:  3ffefbd0 feefeffe 000000a5 feefeffe  
3ffefa60:  feefeffe 00000000 00000000 3ffef9f0  
3ffefa70:  feefeffe feefeffe feefeffe feefeffe  
3ffefa80:  3ffefaa0 3ffefa90 00000004 feefeffe  
3ffefa90:  feefeffe 3ffe8634 3fff0740 00000000  
3ffefaa0:  000000a5 3fff02bc feefeffe feefeffe  
3ffefab0:  feefeffe feefeffe feefeffe 4010031d  
3ffefac0:  feefeffe 00000600 3ffeebfc 40100426  
3ffefad0:  feefeffe feefeffe feefeffe 40100537  
3ffefae0:  feefeffe 00001000 00000484 401006f5  
3ffefaf0:  00000484 00001000 000003fe 4010724c  
3ffefb00:  40004b31 3ffefb30 0000001c 402243f1  
3ffefb10:  40105ea2 402244d9 3fff02bc 000003ff  
3ffefb20:  000003fd 3ffefbd0 3fff02bc 000003fd  
3ffefb30:  ffffff01 55aa55aa 00000009 0000001c  
3ffefb40:  0000001c 00000009 00000009 000003ff  
3ffefb50:  402248c8 3fff02bc 3fff02bc 000000ff  
3ffefb60:  00000001 3ffefbf0 40224a23 00000008  
3ffefb70:  3fff02bc 000000ff 3ffefbd0 00000000  
3ffefb80:  3fff037c 3ffefc31 00000001 40224ab0  
3ffefb90:  3ffefbd0 3fff02bc 3fffdad0 3ffeec48  
3ffefba0:  3ffefbf0 3fff65f4 3fff02bc 3fffdad0  
3ffefbb0:  40224aec 3ffeec1c 00000000 feefeffe  
3ffefbc0:  4020271c feefeffe feefeffe 0001c200  
3ffefbd0:  00000000 00000000 00000018 401006d8  
3ffefbe0:  feefeffe feefeffe 3fff029c 402021bd  
3ffefbf0:  00000000 00000001 feefeffe feefeffe  
3ffefc00:  feefeffe feefeffe feefeffe 0001c200  
3ffefc10:  0000001c 00000000 3ffeec1c 40202d10  
3ffefc20:  40224142 00000001 3ffeeac0 3fffdad0  
3ffefc30:  402025f7 feefeffe feefeffe 3ffeec48  
3ffefc40:  3fffdad0 3ffeeac0 3ffeec1c 402023ce  
3ffefc50:  feefeffe 00000000 3ffeec41 40202f18  
3ffefc60:  feefeffe feefeffe 3ffeec50 40100958  
<<<stack<<<

[realAngie05]

The problem seems to be related with low quality ftdi adapters without chrystal oscillators.
Solution for me was:

in esptool.py change to
ESP_RAM_BLOCK = 0x180
ESP_FLASH_BLOCK = 0x40

and i orderd a new usb2TTL adapter. :)

edit: got my brand new usb2serial adapter :) no more flaky uploads. Everything works as intended now.

[devyte]

Closing as it is marked as solved due to bad usb2serial adapter.