Flashing ESP8266 on OSX High Sierra

[codmpm]

Hi guys,

I have a problem uploading code via the Arduino IDE with my normal ESP8266 (ESP-12F, https://github.com/codmpm/esp8266-proto-board) board together with an FTDI adaptor on OSX High Sierra.
Arduino IDE is 1.8.5, as the older versions don't show items in the menu bar. I'm using ESP8266-Arduono-Core, current master from github.

I can use esptool.py 2.0.1 without any problem to upload binaries. But if I use the Arduino IDE (did python get.py again) I got the following error:

esptool v0.4.9 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de>
Beim Hochladen des Sketches ist ein Fehler aufgetreten
	setting board to ck
	setting baudrate from 115200 to 115200
	setting port from /dev/tty.usbserial to /dev/cu.usbserial-AL009RYR
	setting address from 0x00000000 to 0x00000000
	espcomm_upload_file
	espcomm_upload_mem
opening port /dev/cu.usbserial-AL009RYR at 115200
	tcgetattr
	tcsetattr
	serial open
opening bootloader
resetting board
trying to connect
	espcomm_send_command: sending command header
	espcomm_send_command: sending command payload
trying to connect
	espcomm_send_command: sending command header
	espcomm_send_command: sending command payload
	espcomm_send_command: receiving 2 bytes of data
	espcomm_send_command: receiving 2 bytes of data
	espcomm_send_command: receiving 2 bytes of data
	espcomm_send_command: receiving 2 bytes of data
	espcomm_send_command: receiving 2 bytes of data
	espcomm_send_command: receiving 2 bytes of data
	espcomm_send_command: receiving 2 bytes of data
	espcomm_send_command: receiving 2 bytes of data
Uploading 243504 bytes from /var/folders/cw/ckgc0g2j0qz6nn7djlc_37qr0000gn/T/arduino_build_979142/Blink.ino.bin to flash at 0x00000000
	erasing flash
	size: 03b730 address: 000000
	first_sector_index: 0
	total_sector_count: 60
	head_sector_count: 16
	adjusted_sector_count: 44
	erase_size: 02c000
	espcomm_send_command: sending command header
	espcomm_send_command: sending command payload
	setting timeout 15000
	setting timeout 100
	espcomm_send_command: receiving 2 bytes of data
	writing flash
warning: espcomm_send_command: didn't receive command response
warning: espcomm_send_command(FLASH_DOWNLOAD_DATA) failed
warning: espcomm_send_command: wrong direction/command: 0x01 0x03, expected 0x01 0x04
closing bootloader
error: espcomm_upload_mem failed

("Beim Hochladen des Sketches ist ein Fehler aufgetreten" means "An error occured while uploading the sketch")

I try to upload the standard blink example with the - to me - common settings:

I've also tried the nightly of the arduino IDE but get the same result. Also tripple checked my wiring, but as the upload via esptool.py works without any flaws I think I'm fine with that.

Python Version is 2.7.10...

Any help or ideas are apreciated.

Thank you!

[buchf1]

I have the same problem. Please let me know if you find any solution.

Thx.

[igrr]

Were you able to flash successfully from Arduino IDE before updating OS X?

[codmpm]

Yes. No Problems with Arduino 1.8.2 on OSX 10.12 also using github master of the ESP8266 Arduino Core - maybe not the newest version, though.

[igrr]

I see, can you please check which FTDI driver is being used now, by running kextstat | grep FTDI in Terminal?

Based on the log, it looks like esptool-ck times out early waiting for the response. It sends FLASH_DOWNLOAD_DATA command, gets no response (espcomm_send_command: didn't receive command response line), then sends FLASH_DOWNLOAD_DONE command and gets response for FLASH_DOWNLOAD_DATA instead (wrong direction/command: 0x01 0x03, expected 0x01 0x04). Which means that the chip did respond, but later than the timeout.
Perhaps some changes in the serial drivers caused the existing code to time out earlier.

I have not yet updated to 10.13 myself because i have some important stuff to do next week, and can't risk breaking the dev environment on the laptop. I hope to have a chance to do the update next week and look into this.

If anyone wants to dive into esptool-ck and debug this, please do :)
Maybe the code can be modified to attempt reading the response several times until an acceptable response is received, as done is esptool.py:
https://github.com/espressif/esptool/blob/293b78102d327da8f627f8abb4d918e24fed326e/esptool.py#L249-L264

[codmpm]

Very good point. Here's the output of kextstat:

197    0 0xffffff7f88664000 0x3000     0x3000     com.apple.driver.AppleUSBFTDI (6.0.0) 4AB9F7CD-9185-32E6-8471-053EB5E81C35 <196 99 18 5 4 3 1>

Thank you for your effort.
Sadly I'm not a python person so helping out is difficult on my side.

Silly question: Is it possible to use esptool.py 2.0.1 insteaed of the 0.4.9 version supplied with the esp-core? I've interchanged them but the parameters are completely different...
Or are these two completely different parts?

[igrr]

Oh so it's Apple driver after all. Can you please try installing official FTDI driver and doing another test?

…

On Thu, Oct 12, 2017, 15:32 Patrik Mayer ***@***.***> wrote: Very good point. Here's the output of kextstat: 197 0 0xffffff7f88664000 0x3000 0x3000 com.apple.driver.AppleUSBFTDI (6.0.0) 4AB9F7CD-9185-32E6-8471-053EB5E81C35 <196 99 18 5 4 3 1> Thank you for your effort. Sadly I'm not a python person so helping out is difficult on my side. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3711 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEJceswYN9TQfhTvFQa5JCqvKOQAlM3Tks5srmlGgaJpZM4P2NXN> .

[codmpm]

Sure, will do. Could you point me to the right one? http://www.ftdichip.com/FTDrivers.htm
My guess is the VCP-driver...

I have an FT232RL on my FTDI Adaptor.

[igrr]

http://www.ftdichip.com/Drivers/VCP.htm Pick the one for your OS.

…

On Thu, Oct 12, 2017, 15:55 Patrik Mayer ***@***.***> wrote: Sure, will do. Could you point me to the right one? http://www.ftdichip.com/FTDrivers.htm I have an FT232RL on my FTDI Adaptor. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3711 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEJcejZFxMSJS-ecPJ8SWAXcdFKIFGQhks5srm6ugaJpZM4P2NXN> .

[codmpm]

Hmmm. I've installed the VCP driver 2.4.2 for "Mac OS X 10.9 and above" and did a reboot, but according to kextstat | grep FTDI the apple driver still gets loaded.

As expected it still does not work.

[igrr]

That's odd, FTDI driver is supposed to have precedence over Apple's. Have you restarted the computer after installing the driver?
If yes, can you try unplugging the device and running sudo kextunload -b com.apple.driver.AppleUSBFTDI, then plugging device in again? That should cause FTDI driver to be loaded.

[codmpm]

I've rebootet, yes.

Also tried to kextunload but after that no driver gets loaded to the kernel extensions. After a reboot com.apple.driver.AppleUSBFTDI gets loaded again.

I understand that this could be a driver issue, but - as said - using esptool.py or somehting like CoolTerm everything works fine. Also, I've never installed an FTDI driver before...

[codmpm]

I've also tried to rename the original driver in /System/Library/Extensions/AppleUSBFTDI.kext/Contents/MacOS as suggested for OSX 10.12- but I'm not allowed tomv` the file, even as root.

[igrr]

Thanks for all the attempts. I don't think that this really is a driver issue, just esptool-ck is not robust enough with regards to timeouts, and some change in driver behavior probably causes it to fail. Weird that FTDI driver does not want to load though. Maybe they also need to update the driver for 10.13...

…

On Thu, Oct 12, 2017, 17:03 Patrik Mayer ***@***.***> wrote: I've also tried to rename the original driver in /System/Library/Extensions/AppleUSBFTDI.kext/Contents/MacOS as suggested vor OSX10.12- but I'm not allowed tomv` the file, even as root. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3711 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEJcehosi04KTFnbMJoKMzS85e-P8N70ks5srn6XgaJpZM4P2NXN> .

[codmpm]

That's what I've though cause of the new kext regulations in 10.13.

Thank you for you help and the attempts to solve this. Glad to test something anytime.