This has already been referenced in #43

ValueError: invalid literal for int() with base 16: 'U'

If a function was defined but not linked and not called in code, the esptool.py, frightfully so picks it up as undefined and it's field[0] is set to 'U' instead of its address. Wouldn't it make sense to add a try/except and print something descriptive like "Probably forgot to link function " + field[1]? Around this line https://github.com/themadinventor/esptool/blob/master/esptool.py#L381. Since the python error message doesn't make much sense to an unfamiliar user.

Hi! I compiled the nodemcu-firmware and got the 0x00000.bin and the 0x40000.bin. Then I typed "make flash" and writed done, then I turn the power off and on, but it didn't work. The same as I typed “sudo python esptool.py ..........”. When I switched to Windows 7 and used the https://github.com/nodemcu/nodemcu-flasher, it worked. So what is the point I missed?

On a Mac (10.10), as well as from inside the Espressif VirtualBox VM, I'm only getting "Invalid head of packet" when trying:
$ ./esptool.py --port /dev/cu.usbserial dump_mem 0x400000 256 x
or
$ ./esptool.py --port /dev/cu.usbserial read_mem 0x40000

After such an attempt, esptool "failed to connect", until I power-cycle the module.

I'm using an Adafruit cable with a Prolific 0x2303 / 0x067b.

I've added some debugging code, and the connect works, but after issuing the command, the module seems to stop responding:

    cmd   00 00 00 00
    write c0 00 0a 04 00 00 00 00 00 00 00 00 00 c0
... reading 1 byte
Traceback (most recent call last):
  File "./esptool.py", line 344, in <module>
    print '0x%08x = 0x%08x' % (args.address, esp.read_reg(args.address))
  File "./esptool.py", line 162, in read_reg
    res = self.command(ESPROM.ESP_READ_REG, struct.pack('<I', addr))
  File "./esptool.py", line 113, in command
    raise Exception('Invalid head of packet')
Exception: Invalid head of packet

The "reading 1 byte" corresponds to the start frame byte in ESPROM.command() (# Read header of response and parse).

The module seems to be working just fine in normal AT mode.

The notes espressif have released for flashing the AT command interpreter onto the module seem incomplete to the point of useless.

I have spent 6 hours now trying to get the latest ESP release AT command interpreter onto the module with no sucess. Esptool itself seems to work but the result of my tries so far is just a solid red and blue LED.

Can somebody help me generate a wiki entry on how to flash the latest AT command interpreter onto modules.
http://bbs.espressif.com/viewtopic.php?f=5&t=346

pwd

....... 1.0.1_may2015/esp_iot_sdk_v1.0.1/bin

esptool.py --port /dev/ttyUSB0 write_flash 0x00000 boot_v1.2.bin 0x01000 at/user1.1024.new.bin 0x7c000 esp_init_data_default.bin 0x7e000 blank.bin

So far I have tried lots of variations around this kind of thing, none seem to produce a working module. I get the "erasing flash" and "writing" messages correctly.

In short how do I use esptool.py to get the AT command interpreter onto a module (from any state, IE flashing all regions with code or defaults so that the flash process will always work!)

http://bbs.espressif.com/download/file.php?id=293

Thanks,
Jon

So the ESP8266 outputs a boot header at 77400 baud containing something like:

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

According to https://github.com/esp8266/esp8266-wiki/wiki/Boot-Process#esp-boot-modes the first value in the boot mode is interesting.

If, after reset, we encounter a boot mode that isn't 1, it's possible to raise an error there and tell the user the board was not put in to flash mode.

Could you have a look at https://github.com/nodemcu/nodemcu-firmware/blob/2709258c44b4fa2397df736b12b9c2ef86dc4d89/tools/esptool.py please, and see if you can/should merge in the fixes there?

basically its setting permissions to 755 so it can be executed on unix and removing the version from the shebang from me as discussed earlier.

also from @nodemcu it seems like a fix for the windows hanging issue - basically uses xt-objcopy instead of xtensa-lx106-elf-objcopy and xt-nm instead of xtensa-lx106-elf-nm

i can't really do a direct PR as its across two different projects, nodemcu should probably use your repo as a submodule i guess, or leave it to the user to install esptool.py in the $PATH somewhere.

Is there any chance to adding read chipid ?

Can you do a python setup.py sdist upload so esptool gets published to PyPI? Then we'd be able to install it with just a pip install esptool.

https://www.python.org/dev/peps/pep-0394/

It suggests to use the supported python version in the shebang, in this case it should be
#!/usr/bin/env python2

My configuration is the following:

ESP8266-01
Silabs USB to UART
Arduino IDE to compile code
esptool.py to upload the binary at 9600 baud rate.
Connections:
esp8266 ---------------- USBtoUART
GND----------------------GND
VCC-----------------------3.3V
TX-------------------------RX
RX-------------------------TX (with voltage divider to 3.3v)
GPIO0--------------------GND
CH_PD-------------------3.3V

I upload my code to the esp8266 and it works fine, I can control an LED from my browser.
However , when I unplug the USB from my laptop and plug it in to a power supply or simply replug to my MacBook , it seems that the chip loses the firmware. After I unplug the chip I also free GPIO0 or connect to high with a resistor.

How do I properly reboot my chip after reflashing firmware?

Opposed to what is written under installation/dependencies the official pySerial installation instructions are NOT here

Dunno where to report else.

Hi,

I'm having trouble flashing the 8266 via serial relay.
Here is the scenario:
esptool works great if I use FTDI. However, In my application, I need to flash it using a Mega32U4.
I hooked up the Mega32U4 => ESP like this:
3.3V => VCC
GND => GND
TX => RX
RX => TX

I then upload to the mega32U4 a serial relay program:
`void setup() {
Serial.begin(115200);
Serial1.begin(115200);
}

void loop() {
while(Serial1.available())
Serial.write((uint8_t)Serial1.read());

while(Serial.available())
Serial1.write((uint8_t)Serial.read());
}
`

Then, I try to upload (all 8266 pins are set correctly, just like it worked with the FTDI), but I keep getting this error:

`Connecting...

A fatal error occurred: Failed to connect to ESP8266
`

Any idea why this is happening? I tried lower baud rate (9600) without any success.
This should work in theory....right?

I am using esptool.py within cygwin. It took a bit of googling to figure out how to specify a valid serial port. The answer is:

esptool.py --port /dev/ttySx

where x is the Windows com port number minus one, e.g. to use COM5 the command would look like:

esptool.py --port /dev/ttyS4

May I request this information be added to the documentation?

Is it correct that esptool doesn't support elf2image with "boot mode 2", which is what the newer boot loaders support (boot_v1.2+) and is required to support OTA flashing? Is support planned?

When I flash my ESP8266, I must keep GPIO0 low during the entire procedure. If I disconnect it during flashing, it immediately stops.

I'm now trying to let esptool handle RESET and GPIO0 with RTS and DTR. But esptool only enables DTR (which holds GPIO0 low) for 0.1 seconds.

By removing "self._port.setDTR(False)", esptool seems to work perfectly.

Hi,

I'm running into this error:

Traceback (most recent call last):
File "../../esp8266/esp_iot_sdk_v0.9.2/esptool/esptool.py", line 412, in
esp.flash_block(image[0:esp.ESP_FLASH_BLOCK], seq)
File "../../esp8266/esp_iot_sdk_v0.9.2/esptool/esptool.py", line 189, in flash_block
raise Exception('Failed to write to target Flash')
Exception: Failed to write to target Flash

when flashing this file:
-rw-r--r--+ 1 joostn staff 164931 Dec 6 15:36 0x40000.bin

$ esptool.py --port /dev/cu.SLAB_USBtoUART write_flash 0x40000 build/0x40000.bin

It happens when flashing the last block of the file, it turns out that the flash command returns [1,5] instead of [0,0]. It seems to be caused by the fact that the last block is not 1024 bytes in size, I could fix it by padding to 1024 bytes:

python """ Write block to flash """
def flash_block(self, data, seq):
while len(data) < 0x400:
data += "\0"
flashresult=self.command(ESPROM.ESP_FLASH_DATA,
(etc)

If you need my .bin file let me know (can't attach it here).

When flashing via esptool.py the device stucks in boot(3,0) and won't start. When flashing the same firmware via flash_download_tool everything works fine. How to troubleshoot this issue?

Having downloaded esptool, I found there was a dependency on pyserial. This is not documented and I needed to google for a while to find an answer. I am using cygwin and the solution for me was:

easy_install -U pyserial

It would be advantageous for this dependency (and tips on satisfying it) were documented in the README or similar location.

Hello,

I tried to write_flash binaries to ESP-01 but every time got exception. Full log:
sudo ./esptool.py write_flash 0x00000 WiFiWebServer.cpp_00000.bin 0x40000 WiFiWebServer.cpp_40000.bin
Connecting...
Erasing flash...
Traceback (most recent call last):
File "./esptool.py", line 525, in
esp.flash_begin(blocks*esp.ESP_FLASH_BLOCK, address)
File "./esptool.py", line 188, in flash_begin
struct.pack('<IIII', size, num_blocks, ESPROM.ESP_FLASH_BLOCK, offset))[1] != "\0\0":
File "./esptool.py", line 110, in command
raise Exception('Invalid response')
Exception: Invalid response

MAC OS 10.10.2

The same binaries I can to write to flash from Windows computer, what's wrong with MAC? Also I can't upload compiled sketch from esp8266 arduino IDE on my MAC but there is no problem on Windows PC. Please help to understand.

Hi~
I want to download ESP8266 WiFi bin file through the C language program by uart。
However，I have no document about ESP8266 Bootloader. I don't how to set up a communication with
ESP8266 Boot Mode. If different types of flash，if I should send flash driver to ESP8266 Boot before downloading ESP8266 WiFi bin file ？Where could I get the datasheet of A serial port communication protocol ？
Thank you !!!

I try to flash the esp-link firmware with the esptool and got a error during boot.
See jeelabs/esp-link#94
The same firmware flashed with NodeMCU-Flasher and espressif flash download tool (only user1.bin) works.
I've work mostly with linux and would prefer the usage of esptool.py. What's the difference in flashing with the flash tools?

I tried to use the esptool for quite a while last night. I have an ESP8266 201 with the nodemcu firmware. I wanted to flash the latest nodemcu firmware on my Mac and only got the "Failed to connect" error message.

I tried setting the baud rate to some specific value, no change.
I tried it with GPIO2 pulled up and floating, no change.
I first powered the board from the USB-serial adaptor and then switched to a breadboard power supply (that ultimately is also powered by the USB port course), no change.

I finally installed a Windows trial version in Virtual Box and tried the nodemcu flasher, worked like a charm. So I suppose my wiring is OK. I have a cheap CH341 chipset USB-serial adapter, if that makes a difference.

Is there any way I could provide some debug information that would make it easier to solve this issue?

Can you please add single file operation?

If the irom_text region starts at 0x10000, the gap from 0x8000 is quite small, I would like it...

I used esptools about 2 weeks ago to flash up to the latest Bin images ( from espressif github). in that I went from V0018 0.9.2 to V 020 0.9.4 all worked fine no issues

I now find I cannot communicate with the ESP unit using ESPtools

I m trying CH_PD high, ( direct to 3V3) , pulling GPIO0 low and reseting to enter boot loader mode

I wonder did the boat loader get changed and this is why I can't connect

I have a module with GigaDevice 25Q80BSIG 8mbit flash. Esptool uses QIO by default, and that leads to corruption when writing flash. Most of the chip gets written properly, but some data ends up in the wrong place, as if some address bits get flipped, commonly in some specific small areas of the chip. It does not seem like data bits get flipped. Reads seem fine with QIO. Going to 20 MHz SPI clock does not help. Adding a 10 microfarad tantalum capacitor at the module also didn't help. I don't get any corruption with DIO.

The original firmware was set up for QIO, and it worked. I modified esptool to write firmware set up for QIO even when writing using DIO, and the new firmware also works with QIO. Of course the firmware does a lot less writing during normal operation, so I can't be sure it won't corrupt the flash sometimes. I realize this could be a hardware issue with the module.

i tied to upload the firmware coming from the compiler on the windows VM got this error

./esptool.py --port /dev/tty.usbmodem0E102EE1 write_flash 0x000000 at/eagle.app.v6.flash.bin
Connecting...
Erasing flash...
Writing at 0x00007c00... (100 %)
Leaving...
Traceback (most recent call last):
File "./esptool.py", line 351, in
esp.flash_finish(False)
File "./esptool.py", line 188, in flash_finish
raise Exception('Failed to leave Flash mode')
Exception: Failed to leave Flash mode

same for esp8266_sdk_v0.9.1/bin/at/eagle.app.v6.flash.bin

I have this error when I try to flash
I`m on Mac OSX 10.10

Connecting...
Traceback (most recent call last):
File "esptool.py", line 393, in
assert len(args.addr_filename) % 2 == 0
AssertionError

I could not flash firmware to my ESP-01 and was consistently getting failures like this:

$ sudo python esptool.py --port /dev/ttyUSB0  write_flash 0x00000 nodemcu_latest.bin
Connecting...
Erasing flash...
Writing at 0x00008400... (8 %) 
Traceback (most recent call last):
  File "esptool.py", line 536, in <module>
    esp.flash_block(block, seq)
  File "esptool.py", line 195, in flash_block
    struct.pack('<IIII', len(data), seq, 0, 0)+data, ESPROM.checksum(data))[1] != "\0\0":
  File "esptool.py", line 106, in command
    raise Exception('Invalid head of packet')
Exception: Invalid head of packet

After some googling, I found this http://www.esp8266.com/viewtopic.php?f=6&t=2791#p16082
which resolved the problem. You may want to consider incorporating it or something equivalent in the main version.

Downloaded esptool, connected GPIO2 to 3.3V and GPIO0 to ground, booted up and executed the esptool as follows (with resulting output).

$ sudo esptool.py --port /dev/tty.usbmodem1451 write_flash 0x000000 Firmware.bin
Connecting...
Traceback (most recent call last):
File "/usr/local/bin/esptool.py", line 5, in
pkg_resources.run_script('esptool==0.1.0', 'esptool.py')
File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 492, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 1357, in run_script
exec_(script_code, namespace, namespace)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 47, in exec_
exec("""exec code in globs, locs""")
File "", line 1, in
File "/Library/Python/2.7/site-packages/esptool-0.1.0-py2.7.egg/EGG-INFO/scripts/esptool.py", line 471, in

File "/Library/Python/2.7/site-packages/esptool-0.1.0-py2.7.egg/EGG-INFO/scripts/esptool.py", line 149, in connect

Exception: Failed to connect

Given the error messages, and not a trace of similar issues reported by others, is this due to the code? The 'failed to connect' could be interpreted by a wrong connection on the board or so, but the error messages makes me assume there is something not right with the esptool.

Hi
I'm using an Olimex Dev Board which has a W25Q16BVSSIG (64Mbit aka 2MB) flash on-board.
(see https://www.olimex.com/Products/Modules/Ethernet/MOD-WIFI-ESP8266-DEV/open-source-hardware#)

I currently playing around with the lua-nodemcu-firmware (see https://github.com/nodemcu/nodemcu-firmware). The firmware uses the free flash memory as a filesystem. However, each time the firmware tries to access an area above 512k it fails. But only if I use this tool for the upload process. If I use the original provided one (http://bbs.espressif.com/viewtopic.php?f=7&t=25) and upload the SAME bins at the same locations, everything works fine...

Regards,
Juergen

SPIEraseArea function in the esp8266 ROM has a bug which causes extra area to be erased.
If the address range to be erased crosses the block boundary (block is 16 sectors), then extra head_sector_count sectors are erased.
If the address range doesn't cross the block boundary, then extra total_sector_count sectors are erased.
Where head_sector_count is the number of sectors from the start of erased area to the block boundary, and total_sector_count is the total number of sectors to be erased.

Espressif added the workaround to their version of flash tools. The trick is to modify the erased size:

    """ Start downloading to Flash (performs an erase) """
    def flash_begin(self, _size, offset):
        old_tmo = self._port.timeout
        self._port.timeout = 10

        area_len = int(_size)
        sector_no = offset/4096;
        sector_num_per_block = 16;
        #total_sector_num = (0== (area_len%4096))? area_len/4096 :  1+(area_len/4096);
        if 0== (area_len%4096):
            total_sector_num = area_len/4096
        else:
            total_sector_num = 1+(area_len/4096)
        #check if erase area reach over block boundary
        head_sector_num = sector_num_per_block - (sector_no%sector_num_per_block);
        #head_sector_num = (head_sector_num>=total_sector_num)? total_sector_num : head_sector_num;
        if head_sector_num>=total_sector_num :
            head_sector_num = total_sector_num
        else:
            head_sector_num = head_sector_num

        if (total_sector_num - 2 * head_sector_num)> 0:
            size = (total_sector_num-head_sector_num)*4096
            print "head: ",head_sector_num,";total:",total_sector_num
            print "erase size : ",size
        else:
            size = int( math.ceil( total_sector_num/2.0) * 4096 )
            print "head:",head_sector_num,";total:",total_sector_num
            print "erase size :",size


        if self.command(ESPROM.ESP_FLASH_BEGIN,
                struct.pack('<IIII', size, 0x200, 0x400, offset))[1] != "\0\0":
            raise Exception('Failed to enter Flash download mode')
        self._port.timeout = old_tmo

Perhaps after some cleanup this fix should be applied here as well.
This issue causes the first 0x1000 to be erased in some cases when writing near the end of flash. In turn, this leads to a corrupted flash image when writing two binaries (0x00000 and 0x40000) separately.

I've been bitten by this ever since 1st module I tried. For some modules, programming speed is very slow. Example below (using a patch to be submitted) shows that actual UART speed used by bootloader is likely 9600. The issues definitely depends on USB-serial adapter used. But what's most annoying is "persistent sticky" nature of the problem. For example, today I just unpacked a new board with CH341 adapter builtin, and first programming went fast, but all subsequent show speed as below. Google is pretty silent on this specific issue, so posting this, as this is more or less appropriate place for it hopefully. Please don't close this prematurely, let's collect stats and maybe find some pattern.

Connecting...
Erasing flash...
Writing at 0x0000d400... (100 %) 
Written 55296 bytes in 60.84 seconds (7270.84 bit/s)...
Erasing flash...
Writing at 0x0004f000... (100 %) 
Written 259072 bytes in 287.08 seconds (7219.56 bit/s)...

Leaving...
0.12user 0.04system 5:50.45elapsed 0%CPU (0avgtext+0avgdata 9224maxresident)k

I'm getting A fatal error occurred: ELF binary has undefined symbol __errno since moving to SDK v1.4 and I don't really know if it's important. It stops esptool working, but can easily be worked around. I can't understand how the linker is happy if there are undefined symbols.

Things go well with commit e96336f.

When I update to current code, esptool fail to flash multiple files.

With 2 files, esptool goes well

../../tools/esptool/esptool.py --port /dev/ttyUSB0 write_flash -fs 32m-c1 0x00000 ../../esp-sdk/bin/boot_v1.4\(b1\).bin 0x01000 .firmwares/4096_user1.bin
Connecting...
Erasing flash...
Writing at 0x00000800... (100 %)
Erasing flash...
Writing at 0x0003f800... (100 %)

Leaving...

, but with 4 files

../../tools/esptool/esptool.py --port /dev/ttyUSB0 write_flash -fs 32m-c1 0x00000 ../../esp-sdk/bin/boot_v1.4\(b1\).bin 0x01000 .firmwares/4096_user1.bin 0x3FC000 ../../esp-sdk/bin/esp_init_data_default.bin 0x3FE000 ../../esp-sdk/bin/blank.bin
Connecting...
Erasing flash...
Writing at 0x00000800... (100 %)
Erasing flash...
Writing at 0x0003f800... (100 %)
Erasing flash...
Writing at 0x003fc000... (100 %)
Erasing flash...
Traceback (most recent call last):
  File "../../tools/esptool/esptool.py", line 579, in <module>
    esp.flash_begin(blocks*esp.ESP_FLASH_BLOCK, address)
  File "../../tools/esptool/esptool.py", line 214, in flash_begin
    raise Exception('Failed to enter Flash download mode')
Exception: Failed to enter Flash download mode

Do you have any suggestion to overcome this?

Many thanks.

See nodemcu/nodemcu-firmware#412 for the problem.
Flashing the module works with dio mode and 32M but in the LUA firmware accessing the Flash storage doesn't work. If using the same module with the latest espressif tool from
http://bbs.espressif.com/viewtopic.php?f=5&t=433 works just fine.

I described the workaround here:
http://blog.squix.ch/2015/05/esp8266-flashing-nodemcu-v10-on-mac-os.html

Please support this mode in the esptool.py

I have a firmware that is using SPIFS already uploaded. If I'm uploading a 64K SPIFFS partition at 0x6B000 using esptool.py, the firmware is not able to connect to Wifi wihout crashing.
If I upload the same partition with IGRR esptool, it is working fine.

Using esptool.py (crash at Wifi connection) :
esptool.py --port /dev/ttyUSB0 write_flash 0x6B000 spiffs_part.bin

Using IGRR esptool (working fine) :
esptool -vv -cd ck -cb 115200 -cp /dev/ttyUSB0 -ca 0x6B000 -cf spiffs_part.bin

I presume that esptool.py is touching/erasing some other parts of the flash that should not be accessed ...

I'm trying to use esptool.py to write a file system generated by mkspiffs at 0xeb000.

To generate the file system i use:

mkspiffs -c html/bin webpages.espfs

The address that SPIFFS is looking for:

SPIFFSImpl: allocating 512+180+1400=2092 bytes
SPIFFSImpl: mounting fs @eb000, size=10000, block=1000, page=100
SPIFFSImpl: mount rc=0

To upload the file system i use:

esptool.py --port=$(ls /dev/cu.usbserial* | head -1) --baud=921600 write_flash 0xeb000 webpages.espfs 

esptool.py writes OK, but the system doesn't boot anymore so everytime i have to upload the sketch.
If i comment the line flash_begin(0,0) at the end of write_flash command it writes OK and i don't have to upload the sketch again.

Is there a way or parameter for writing an SPIFFS without re-upload the sketch or comment this line ?

When running esptool on a cygwin python combined with a non-cygwin objcopy the temp file is placed in virtual paths that are invisible to non-cygwin programs (/tmp).

Unfortunately specifying a local TMP/TEMP/TEMPDIR does not resolve the issue as the path is then replaced with an absolute path inside the virtual cygwin filesystem root again (/cygdrive).

However specifying a local path in mktemp works fine:
tmpsection = tempfile.mktemp(suffix = ".section", dir = "my_local_temp_dir")

So a solution would be to make the dir parameter available via the command line.

Is there any file available that loads and executes with the load_ram option?
I tried basically any file I could think of, but the esp would always crash.

Did you have any success with this option?

This is also posted on esp8266/Arduino: esp8266/Arduino#91

I've seen in a few places people complaining about their setup working with esptool but not with the esp8266 Arduino IDE project (https://github.com/esp8266/Arduino) and was having this problem myself, but I think I've found why that is...

When flashing with esptool the setup sequence looks like this:
RTS goes LOW
DTR goes LOW
RTS goes HIGH
DELAY
DTR goes HIGH

which means that your wiring looks like this...
RTS -> CH_PD (i.e reset)
DTR -> GPIO0

When flashing with the Arduino IDE
RTS and DTR go LOW
DTR goes HIGH
DELAY
RTS goes HIGH

which means that your wiring looks like this...
RTS -> GPIO0
DTR -> CH_PD (i.e reset)

It seems to me that these pins are sorta arbitrarily chosen, but it would be better for everyone if we standardized on the same pin assignments early on. I'm going to post this issue to the Arduino IDE plugin as well, but I guess my suggestion would be that the swap in the esptool code.. Perhaps a --legacy mode switch could be added to allow for older setups?

Please try to flash the block again if error occur

Hi,

So far I was using a switch and a button to program the chip with esptool.
I decided to give a go with RTS(CH_PD) and DTR(GPIO0) so I can program the chip remotely, for dev in the sofa.

It works, but I can't figure out how to run a terminal, because it drives RTS so the chip is reset everytime.
I'm trying with minicom. On linux, without hard/soft flow control, it says "no such device or address", and with them the terminal starts but the chip is unresponsive (because RTS driven). On OSX, no matter what hard/soft flow control, the terminal starts and the chip is unresponsive. Of course it works (linux, osx) if I manually drive CH_PD to 3.3v.

I still can access to it through telnet, but this is not ideal for dev, I love the serial port :)

I'm really wondering how do you guys do.

Thanks

Hi! I've got a couple of NodeMCU Devkits of the 0.9 rev (so the CH340G bridge) and I'm using the signed driver from mac-usb-serial.com. Out of the box, esptool isn't working.

These changes seem useful:

self._port.setRTS(True)
self._port.setDTR(False)
time.sleep(0.1)
self._port.setRTS(False)
self._port.setDTR(True)
time.sleep(0.1)

Doing this causes the ESP to boot in to mode (1,6) - user firmware boot identifies itself as (3,6).

The boot header is ets Jan 8 2013,rst cause:2, boot mode:(3,6) so it's a somewhat older firmware. I can't find any docs on what the second number means, but all of my working devices show a 7...

Any thoughts? :)

When I use a FTDI232R USB --> Serial IC, the connection breaks randomly (on my computer between 6-12% of the upload progress). I can fix this changing on esptool.py this

ESP_RAM_BLOCK = 0x1800
ESP_FLASH_BLOCK = 0x400 

by this

ESP_RAM_BLOCK = 0x180
ESP_FLASH_BLOCK = 0x40

Could you add a switch (like -s/--slow or -f/--ftdi) to make a slow transfer?

The current elf2image implementation uses xtensa-lx106-elf-nm. However if we compile the binary with -ffunction-sections/-fdata-sections and do -gc-sections to strip unused functions from the resulting binary we'll end up with this error message:

  [ESPTOOL]   images/antares.rom
xtensa-lx106-elf-nm: images/antares.elf: no symbols
Traceback (most recent call last):
  File "/home/necromant/bin/esptool.py", line 471, in <module>
    image.entrypoint = e.get_symbol_addr("call_user_start")
  File "/home/necromant/bin/esptool.py", line 283, in get_symbol_addr
    return self.symbols[sym]
KeyError: 'call_user_start'
make: *** [images/antares.rom] Error 1

Proposed solution: Link with -Wl,-Map=$(IMAGENAME).map
and pass either the whole mapfile or the just the call_user_start address to esptool.

Because I don't have a USB2Serial adapter yet for 3.3V, I use my Arduino Due for this purpose. The Microcontroller is disabled (Reset shorted to Ground), so the Arduino Due acts as a pure USB2Serial adapter using an ATMEL 16U2 with firmware as the converter chip.

This setup works fine on a Raspberry Pi, and I could successfully flash the firmware (after I reduced the "Maximum block sized for RAM and Flash writes", as suggested elsewhere).

On the Mac, I only get "Failed to connect". When the ESP8266 is not in firmware mode, I can talk to is successfully with the Mac (using "screen" or the Arduino IDE).

After the firmware upgrade the ESP8266 switched from 9600 to 115200 baud. Now I can successfully flash also with the Mac.

All in all, it looks like the Mac can't work with 9600 Baud, but has no issues with 115200 Baud. The Raspberry Pi on the other hand can work with both speeds.

Yesterday I tried to compile nodemcu with esp-open-sdk and everything went well, but I'm stuck when sending binaries to the module - no difference if I'm sending my binaries or the one from github. Tried on newest esptool.py. Trying to do it on raspberry pi (it has 3.3V and serial output) Previously I had no problems with the upload but I deleted the old version (around 3 jan). The strange thing is that it stops always at different address.

pi@raspberrypi ~ $ python esptool.py -p /dev/ttyAMA0 write_flash 0x000000 nodemcu_latest.bin 
Connecting...
Erasing flash...
Writing at 0x00000300... (0 %) 
Traceback (most recent call last):
  File "esptool.py", line 456, in <module>
    esp.flash_block(block, seq)
  File "esptool.py", line 197, in flash_block
    struct.pack('<IIII', len(data), seq, 0, 0)+data, ESPROM.checksum(data))[1] != "\0\0":
  File "esptool.py", line 108, in command
    raise Exception('Invalid head of packet')
Exception: Invalid head of packet
pi@raspberrypi ~ $ python esptool.py -p /dev/ttyAMA0 write_flash 0x000000 nodemcu_latest.bin 
Connecting...
Erasing flash...
Writing at 0x00000000... (0 %)
Traceback (most recent call last):
  File "esptool.py", line 456, in <module>
    esp.flash_block(block, seq)
  File "esptool.py", line 197, in flash_block
    struct.pack('<IIII', len(data), seq, 0, 0)+data, ESPROM.checksum(data))[1] != "\0\0":
  File "esptool.py", line 108, in command
    raise Exception('Invalid head of packet')
Exception: Invalid head of packet
pi@raspberrypi ~ $ python esptool.py -p /dev/ttyAMA0 write_flash 0x000000 nodemcu_latest.bin 
Connecting...
Erasing flash...
Writing at 0x00000500... (0 %) 
Traceback (most recent call last):
  File "esptool.py", line 456, in <module>
    esp.flash_block(block, seq)
  File "esptool.py", line 197, in flash_block
    struct.pack('<IIII', len(data), seq, 0, 0)+data, ESPROM.checksum(data))[1] != "\0\0":
  File "esptool.py", line 108, in command
    raise Exception('Invalid head of packet')
Exception: Invalid head of packet

Hi There :)

I've Just Got My Very First ESP8266 Set-up, as In The Circuit Schematic (Which is Set According To The "ESP Boot Modes" Table Here : https://github.com/esp8266/esp8266-wiki/wiki/Boot-Process ) :

I'm Able To Communicate With It - via GNU' Screen & Found That It's Current S/W Ver. is "ai-thinker.com v0.9.2.4".

Nevertheless, themadinventor' esptool - While Seem To Be Able To Communiction With The ESP8266 (It's Comms. LED Blinks & GNU' Screen Outputs Some Stuff), Can't Setup an Operable Connection To It & Only Outputs This :

hercules ~ # /opt/esptool.py -p /dev/ttyUSB0 -b 9600 flash_id
Connecting...
Traceback (most recent call last):
File "/opt/esptool.py", line 471, in
esp.connect()
File "/opt/esptool.py", line 149, in connect
raise Exception('Failed to connect')
Exception: Failed to connect

Any Ideas... ? :)