Today I received ESP8266 Witty cloud with development board, I am trying to upload the sketch to the board via IDE, but it seems IDE doesnt sees it on any port, following what people mention on various blogs NODEMCU 1.0 profile but whats the point its not detecting the com port its connected to.
Although my MacBook wifi detects new hotspot as AI-Thinker_CC889A.
You need to install the CH340 driver: http://www.wch.cn/download/CH341SER_MAC_ZIP.html
Pert has nailled it.
after you do that (and reboot), open a terminal session and type "ls /dev/cu*"
You should see the board there, if not, its either a driver issue, or a duff board.
Hi, I have a few Gizwits ESP-12F boards ("Witty boards"). They have their own attached FTDI loader. I've been trying to load a basic Arduino sketch for a few days with no success. I always get the same errors:
warning: espcomm_sync failed
error: espcomm_open failed
error: espcomm_upload_mem failed
error: espcomm_upload_mem failed
I've tried the following without success:
The verbose output during upload looks like this:
Arduino: 1.8.1 (Mac OS X), Board: "NodeMCU 1.0 (ESP-12E Module), 80 MHz, 115200, 4M (3M SPIFFS)"
Sketch uses 221951 bytes (21%) of program storage space. Maximum is 1044464 bytes.
Global variables use 31516 bytes (38%) of dynamic memory, leaving 50404 bytes for local variables. Maximum is 81920 bytes.
/Users/xxxxxx/Library/Arduino15/packages/esp8266/tools/esptool/0.4.9/esptool -vv -cd nodemcu -cb 115200 -cp /dev/cu.Repleo-CH341-00001014 -ca 0x00000 -cf /var/folders/rx/2s5j_3055fd68c9v_pmv982c0000gn/T/arduino_build_212684/sketch_mar07a.ino.bin
esptool v0.4.9 - (c) 2014 Ch. Klippel ck@atelier-klippel.de
setting board to nodemcu
setting baudrate from 115200 to 115200
setting port from /dev/tty.usbserial to /dev/cu.Repleo-CH341-00001014
setting address from 0x00000000 to 0x00000000
espcomm_upload_file
espcomm_upload_mem
opening port /dev/cu.Repleo-CH341-00001014 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
trying to connect
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
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
trying to connect
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
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
trying to connect
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
warning: espcomm_sync failed
error: espcomm_open failed
error: espcomm_upload_mem failed
error: espcomm_upload_mem failed
I'm running out of ideas and would appreciate some advice if you have any. Thanks.
Additionally, I have no problem communicating with the ESP8266 using the serial monitor and AT commands.
This might be helpful:
https://github.com/esp8266/Arduino/blob/master/doc/faq/a01-espcomm_sync-failed.md
Pert, thanks for the link. It looks like a great troubleshooting guide. I will get to this on Thursday and let you know what I figure out.
Pert,
I spent the morning going through the "espcomm_sync failed" error troubleshooting guide you provided. When testing the NodeMCU Entering Boot Loader Mode, I hooked up a secondary Sparkfun 3.3v FTDI and connected it to a second computer running an Arduino Serial Monitor. Most of the time I would get:
ets Jan 8 2013, rst cause: 2, boot mode (1,6)
The guide says I should get boot mode (1,7). I can't figure out the difference between 6 & 7. Some of the time I would get boot mode (1,7) but it wouldn't load.
Next I connected a circuit analyser to GPIO0, RST and RXD. The waveforms were similar and consistent with the error messages that I originally posted. From the waveforms, I think that it loads the code but then maybe fails a checksum and resets the esp. It tries this four times before giving up.
Later, I grabbed a basic ESP8266 and used a Sparkfun 3.3V FTDI to load the "Blink" program to blink the onboard LED at pin 2. It loaded successfully with no problem. So then I took a Witty board and tried to flash it the exact same way and it fails. I took the Witty FTDI and tried to flash this "basic" ESP8266 and it fails. I grabbed a brand new Witty board straight out of the package and it would not flash with my Sparkfun FTDI.
All I can gather is that there must be some other setting for flashing the Witty boards that I'm not aware of. At least the Witty Boards are cheap and so if I can't figure this out, then I'll just have to stick with basic ESP8266 boards.
If someone has had success flashing the Witty boards using Arduino, please share your secret.
In case nobody has figured it out yet:
The "ck" reset method does not work quite right on the Witty. It resets the board but it doesn't pull GPIO0 low to put it in flash mode. Net end result is that your work (hold FLASH button and press RESET, then release FLASH) is undone. When the IDE resets the board it doesn't get into flash mode, it just starts the previous program that is already on the Witty.
To fix this, just configure the "reset method" to "nodemcu". That doesn't reset the board, so it will stay in flash mode that you put it in with the buttons--just like an E01.
You can also fix the IDE to add a "none" reset mode.
Edit the file "C:\Documents and Settings{username}\Local Settings\Application Data\Arduino15\packages\esp8266\hardware\esp8266\2.4.0\boards.txt" and in the generic.name=Generic ESP8266 Module section add these two lines:
generic.menu.ResetMethod.none=none
generic.menu.ResetMethod.none.upload.resetmethod=none
Now you'll be able to select "none" as the reset method.
Following up on Fred-2's note above, I went one step further and edited the boards.txt file, cloned the nodemcuv2 section and edited same to effectively add a 'WittyCloud' board definition. After restarting the IDE, the board is found and all seems to work well.
Here is an excellent post for WittyCloud users just getting started:
First Impression on ESP8266 Witty Cloud Board
https://yoursunny.com/t/2016/WittyCloud-first/
This might help someone!
I had issues uploading a sketch to the witty board. After resetting the board the RGB LED was always full on (white) and I was not sure why. Old code I uploaded?
Any attempt to upload would fail. I tried pressing the Flash button, long press, power while pressed all that .. no luck.
I only noticed later that if I reset the board on the serial there was a message showing.
I had to set the baud rate of the monitor to 74880 to see the message.
The message was saying
"esr .... bootmode(7,6) waiting to boot..."
when the Flash button was pressed the message was "bootmode(5,6)" hmm
I tried another witty board, one that would allow flashing via UART; the message there was "bootmode(3,6)"
Looking into the easily available documentation the bootmode indicates the pull high or low status of GPIO 15, 0, 1
The "white RGB led" was due to some old code I uploaded; That was the reason for pulling high GPIO 15 and that is why I got the invalid bootmode! Gotcha!
All I had to do is to pull low GPIO 15 and the correct bootmode(3, 6) would show. Programming worked at that point.